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
1  
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
1  
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
2  
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
1  
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
1  
@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 6 more comments

1 Answer

up vote 1 down vote accepted

There was review of Java implementation

https://gist.github.com/doctorevil/9521116

and the authour thinks it's safe

share|improve this answer
    
Did they really treat signatures as if they're unique in the code? Do you know what the specific workaround was? That, collision prone account numbers, and curve seem to be odd choices at best, nearly fatal at worst. –  Gracchus Mar 27 at 18:41
    
OMG they did! lulz. I wonder how many other surprises are left in there. –  Gracchus Mar 28 at 11:19
    
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
    
You mean for signing? Seems kinda pointless to have account numbers and public keys for destination addresses. –  Gracchus Apr 1 at 20:59
show 8 more comments

Your Answer

 
discard

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.