Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I have only about 2 weeks of cryptography experience mostly in the form of questions on bitcoin.se.

Is Curve25519-java up to date with current Curve25519 standards?

Is Curve25519 itself secure?

In other words, is it safe to use as it a cryptocurrency key-generation and transaction signing & verification algorithm?

share|improve this question
As far as we know, Curve25519 itself is secure. But Curve25519 as specified by Bernstein only supports key-exchange, not signing. For signing I recommend using the related Ed25519 instead. –  CodesInChaos Jan 6 at 15:01
Curve25519-java supports signing, but that wasn't in the original code and thus hasn't seen much review. It's also missing the other Ed25519 goodies, such as deterministic signatures, batch verification, or the faster fixed base multiplication. –  CodesInChaos Jan 6 at 15:18
That Ed25519 implementation is glacially slow. Both the Curve25519-java implementation and the ed25519-java you linked aren't constant time, and thus potentially open to timing attacks (probably not a practical issue in this context). –  CodesInChaos Jan 6 at 15:31
I just checked: It simply pushes the responsibility onto the caller. Since it's pretty hard to generate a good enough nonce, any caller who isn't a crypto expert will almost certainly get it wrong. –  CodesInChaos Mar 27 at 18:21
@Gracchus The API of Curve25519-java is so awkward that few people will be able to use it correctly. It doesn't matter if your crypto works in theory if nobody is able to use it. –  CodesInChaos Mar 27 at 18:36
show 2 more comments

1 Answer 1

up vote 1 down vote accepted

There was review of Java implementation


and the authour thinks it's safe

share|improve this answer
They removed the signature field from calculating transaction ID. As I understand it, that fixed transaction replay attack. –  user12480 Apr 1 at 20:24
As for collision prone account number, once an account has outgoing transaction, the 256-bit public key is distributed to blockchain and linked with that account. So it's account number plus the public key. –  user12480 Apr 1 at 20:29
Account number is smaller (64-bit) and will eventually be represented in Reed–Solomon error correction format, something like this, nxtnotify.appspot.com/convert Whoever sends the first transaction with that account number controls it with 256-bit public key. If there is a collision later on for example between the 64-bit account number, the first person controls the account. –  user12480 Apr 2 at 2:24
By the way, can someone really good at math can visit this thread? There is interesting discussion going on right now about if signature generation in this Java implementation is safe: nxtforum.org/general-discussion/… –  user12480 Apr 2 at 2:34
This part has never changed. The account number is 64-bit that is connected to 256-bit public key that is created when the account sends it's first outgoing transaction. It's been like this from the beginning. –  user12480 Apr 2 at 4:32
show 3 more comments

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.