Fatal flaw: In the future there will be quantum Computers breaking 256 bit protection. Hence nxt is doomed.
This is not the injected flaw.
Haha. BTW, we will also be using quantum computers to protect Nxt.
Topic: Nxt source code flaw reports - page 21. (Read 113314 times)
This is not the injected flaw.
Haha. BTW, we will also be using quantum computers to protect Nxt.
Regarding the performance criteria, are you referring to curve25519 or crypto operations per second?
+1, also would like to know...
Also, are you giving the whole bounty to the fastest solution, or going to split it among functionally correct submissions?
Still haven't finished, but I think I might have pretty nice solution when it comes to Curve operations (Curve.sign, Curve.verify)
As I was working on the JavaScript conversion bounty, I came across something strange that looks like it might be a bug in somewhere in the Java crypto code.
I wrote a simple console app that uses the NXT crypto code:
I wrote a simple console app that uses the NXT crypto code:
Code:
public static void CryptoVerifyTest(String secret, String message) throws Exception {
byte[] messageBytes = message.getBytes("UTF-8");
byte[] key = Crypto.getPublicKey(secret);
byte[] sig = Crypto.sign(messageBytes, secret);
Boolean result = Crypto.verify(sig, messageBytes, key);
System.out.println("secret = " + secret + ", message = " + message + "; verify result = " + result);
}
I'm quite sure exception is thrown, handled silently, and false is returned.
Passed secret key must be result of hash function and have at least 32 bytes... (in your case they are obviously shorter...)
The result of the hash function has 32 bytes, so that's not the problem. And also there are no exceptions in that code.
As I was working on the JavaScript conversion bounty, I came across something strange that looks like it might be a bug in somewhere in the Java crypto code.
I wrote a simple console app that uses the NXT crypto code:
I wrote a simple console app that uses the NXT crypto code:
Code:
public static void CryptoVerifyTest(String secret, String message) throws Exception {
byte[] messageBytes = message.getBytes("UTF-8");
byte[] key = Crypto.getPublicKey(secret);
byte[] sig = Crypto.sign(messageBytes, secret);
Boolean result = Crypto.verify(sig, messageBytes, key);
System.out.println("secret = " + secret + ", message = " + message + "; verify result = " + result);
}
I'm quite sure exception is thrown, handled silently, and false is returned.
Passed secret key must be result of hash function and have at least 32 bytes... (in your case they are obviously shorter...)
so many replies,great!
As I was working on the JavaScript conversion bounty, I came across something strange that looks like it might be a bug in somewhere in the Java crypto code.
I wrote a simple console app that uses the NXT crypto code:
My expectation is that verify should return true for each (signature, message) pair, but, instead, I get the following output:
I might be overlooking something, but I can't come up with an explanation as to why this would happen. Is this a bug?
I wrote a simple console app that uses the NXT crypto code:
Code:
public static void CryptoVerifyTest(String secret, String message) throws Exception {
byte[] messageBytes = message.getBytes("UTF-8");
byte[] key = Crypto.getPublicKey(secret);
byte[] sig = Crypto.sign(messageBytes, secret);
Boolean result = Crypto.verify(sig, messageBytes, key);
System.out.println("secret = " + secret + ", message = " + message + "; verify result = " + result);
}
public static void main (String args[]) throws Exception {
CryptoVerifyTest("three", "patriots");
CryptoVerifyTest("two", "patriots");
CryptoVerifyTest("patriots", "three");
}
My expectation is that verify should return true for each (signature, message) pair, but, instead, I get the following output:
Code:
secret = three, message = patriots; verify result = [color=red][b]false[/b][/color]
secret = two, message = patriots; verify result = true
secret = patriots, message = three; verify result = true
I might be overlooking something, but I can't come up with an explanation as to why this would happen. Is this a bug?
The implementation used seems to be a port from C++, so it might be worth checking for the usual signed/unsigned stuff that happens if you port bit-shuffling from C to Java.
However, CfB wrote in a different thread that some signatures might be unverifiable, so this could be "normal" behaviour. But I'd be very interested in hearing why the unverifiability happens and to see numbers on how often that happens.
They also took a shortcut from the original description by replacing
r = hash(Y)
h = m XOR r
by
h = hash(m, Y)
and transmitting h instead of r. I'm not exactly sure what effect that has on the inner workings of sign/verify...
On that topic, I haven't checked the full implementation yet, but are you guys aware of this and use the proposed methods to avoid private key leakage in these cases?
http://eprint.iacr.org/2007/357.pdf
I'm not sure if this is the correct place for this question, but regarding the bounty:
I have a working (tested) solution, but I think it is too slow [https://github.com/Jaguar0625/JavaScriptNrs].
Regarding the performance criteria, are you referring to curve25519 or crypto operations per second? And, if you're looking for running this in the browser, what browsers are you looking at supporting? Considering curve25519's heavy reliance on 64-bit arithmetic (which JavaScript doesn't support natively), it will probably be a lot slower than you're expected (especially running outside of v8). Do you have test data you are using for a benchmark?
Also, are you giving the whole bounty to the fastest solution, or going to split it among functionally correct submissions?
Bounty announcement
100'000 NXT will be paid for working JavaScript code that signs and verifies signatures using NRS algo.
- The licence must allow to use the code in any application
- Sign/verify speed must be not lower than 100 signatures per second on a 1 GHz CPU (1 core)
- All the code must be in a single non-obfuscated well-formatted .js file
- Input/output values must be strings like "8302504e4e57c6c65335289879c6915a273d3aae7bd086058e403fcd2bc18341"
The bounty is valid till the 20th of January, 2014 12:00:00 UTC. The complete code must be published in this thread.
100'000 NXT will be paid for working JavaScript code that signs and verifies signatures using NRS algo.
- The licence must allow to use the code in any application
- Sign/verify speed must be not lower than 100 signatures per second on a 1 GHz CPU (1 core)
- All the code must be in a single non-obfuscated well-formatted .js file
- Input/output values must be strings like "8302504e4e57c6c65335289879c6915a273d3aae7bd086058e403fcd2bc18341"
The bounty is valid till the 20th of January, 2014 12:00:00 UTC. The complete code must be published in this thread.
I have a working (tested) solution, but I think it is too slow [https://github.com/Jaguar0625/JavaScriptNrs].
Regarding the performance criteria, are you referring to curve25519 or crypto operations per second? And, if you're looking for running this in the browser, what browsers are you looking at supporting? Considering curve25519's heavy reliance on 64-bit arithmetic (which JavaScript doesn't support natively), it will probably be a lot slower than you're expected (especially running outside of v8). Do you have test data you are using for a benchmark?
Also, are you giving the whole bounty to the fastest solution, or going to split it among functionally correct submissions?
As I was working on the JavaScript conversion bounty, I came across something strange that looks like it might be a bug in somewhere in the Java crypto code.
I wrote a simple console app that uses the NXT crypto code:
My expectation is that verify should return true for each (signature, message) pair, but, instead, I get the following output:
I might be overlooking something, but I can't come up with an explanation as to why this would happen. Is this a bug?
I wrote a simple console app that uses the NXT crypto code:
Code:
public static void CryptoVerifyTest(String secret, String message) throws Exception {
byte[] messageBytes = message.getBytes("UTF-8");
byte[] key = Crypto.getPublicKey(secret);
byte[] sig = Crypto.sign(messageBytes, secret);
Boolean result = Crypto.verify(sig, messageBytes, key);
System.out.println("secret = " + secret + ", message = " + message + "; verify result = " + result);
}
public static void main (String args[]) throws Exception {
CryptoVerifyTest("three", "patriots");
CryptoVerifyTest("two", "patriots");
CryptoVerifyTest("patriots", "three");
}
My expectation is that verify should return true for each (signature, message) pair, but, instead, I get the following output:
Code:
secret = three, message = patriots; verify result = [color=red][b]false[/b][/color]
secret = two, message = patriots; verify result = true
secret = patriots, message = three; verify result = true
I might be overlooking something, but I can't come up with an explanation as to why this would happen. Is this a bug?
same thoughts here 
when saw that flaw description.
when saw that flaw description. I can disclose exact number of chars in each description. Just ask.
That was just thoughts after realizing, what are the chances to find the flaw.
... no cracking sw available, at least here.)
same thoughts here when saw that flaw description.
when saw that flaw description. I can disclose exact number of chars in each description. Just ask.
We need to know all assumptions that we can make when trying to break the system.
If I give you a mathematical theorem and ask you to prove it but don't tell you all assumptions you have to make in order to be able to prove it, then you will waste a lot of time!
If I give you a mathematical theorem and ask you to prove it but don't tell you all assumptions you have to make in order to be able to prove it, then you will waste a lot of time!
True, that's why the OP says
Mathematical proof is not necessary, common sense should be enough.
We need to know all assumptions that we can make when trying to break the system.
If I give you a mathematical theorem and ask you to prove it but don't tell you all assumptions you have to make in order to be able to prove it, then you will waste a lot of time!
If I give you a mathematical theorem and ask you to prove it but don't tell you all assumptions you have to make in order to be able to prove it, then you will waste a lot of time!
Fatal flaw: In the future there will be quantum Computers breaking 256 bit protection. Hence nxt is doomed.
This is not the injected flaw.
Well that was not fair. When I read ur hint it was totally clear. A few pages ago I presented that attack but I assumed (like everyone else) that the block id argument is valid. And now u r telling us that we may assume that there are asics that make the attack possible?
There r no ASICs that crack 512-bit RSA but it's still considered insecure.
PS: Next time I won't give such clear hints. 100K is still waiting for u.
Fatal flaw: In the future there will be quantum Computers breaking 256 bit protection. Hence nxt is doomed.
And no, I decompiled nothing.
Sorry, then my guess was wrong.
If u find another flaw, don't ask questions. Because...
If u think that u found a flaw, post here its description.
You just need to cause a collission of the block ID, which is 64bit.
Critical flaw description:
Code:
Only 64 bits of the previous block hash are used. This gives ability to inject blocks with another set of transactions.
SHA256-hash:
Code:
888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530
Looks legit. Where to send 10K to?
Well that was not fair. When I read ur hint it was totally clear. A few pages ago I presented that attack but I assumed (like everyone else) that the block id argument is valid. And now u r telling us that we may assume that there are asics that make the attack possible?
Well I said that block contains only id of previous block and that blocks can be manipulated afterwards (this sounds close to the hashed flaw description). And no, I decompiled nothing. Nobody asked for more detailed description. But I don't rely on the coins, so no problem here. Have fun with the remaining flaws. When I have more time I will also dig into it again.
I'm trying to brute-force the remaining sha256-hashes that BCNext provided,
think it's easier than learning java and becoming a crypto-genius.
think it's easier than learning java and becoming a crypto-genius.
same thoughts here
when saw that flaw description. And just had printed all 6000 lines of that java code ... likely ineffectual as it seems like a common review praxis won't find any significant flaws.
@everybody else: I'm trying to brute-force the remaining sha256-hashes that BCNext provided, think it's easier than learning java and becoming a crypto-genius. Anybody interested in creating a mining pool for this?
okay, okay, just kidding here
okay, okay, just kidding here
U should do that. Salt wasn't added intentionally.
Jump to: