Earlier quoted context omitted.
What about the disadvantageous aspect of djb’s curves, like that they have a non-unit cofactors? That’s a huge foot-gun that has already maimed a few people. Also, deterministic signing nonces have NOTHING to do the DSA/ECDSA vs alternative signatures scheme. The library you recommend just uses its own deterministic signer internally, just as any ECDSA implementation can and should (e.g. bitcoin’s does).
Could you expand on what's dangerous in using a curve with a non-unit cofactor? I haven't heard of this as an attack vector before.
Cryptographic Right Answers
221–230 of 243 posts
Re: Cryptographic Right Answers
#222Earlier quoted context omitted.
The only place we discuss directly using Curve25519 is in straightforward DH, as with X25519. There is more distinguishing Ed25519 from Deterministic ECDSA than deterministic nonce generation.
You suggest using Ed25519 which is vulnerable to third party signature malleability as its cofactor is 8 and the library doesn’t check that the signature is actually a point in the curve. On the other point, then don’t list deterministic nonces as a comparative advantage since it is not actually distinguishing.
[deleted]
Re: Cryptographic Right Answers
#223Earlier quoted context omitted.
The only place we discuss directly using Curve25519 is in straightforward DH, as with X25519. There is more distinguishing Ed25519 from Deterministic ECDSA than deterministic nonce generation.
You suggest using Ed25519 which is vulnerable to third party signature malleability as its cofactor is 8 and the library doesn’t check that the signature is actually a point in the curve. On the other point, then don’t list deterministic nonces as a comparative advantage since it is not actually distinguishing.
That's fair: we don't alert users that these recommendations aren't adequate for building elaborate new signature schemes. We're assuming people are trying to solve the basic problems described in the use cases we wrote (remember, this document originates as a response to a similar thing Colin Percival wrote a long time ago).
I'll think about a way to articulate that. Obviously, we can't really offer advice on doing state-of-the-art signature schemes in a couple paragraphs, and would not be interested in trying.
On the other point: the 2015 version of the document addressed the point you're making (and recommended deterministic DSA!). I just think it's kind of dumb to design new systems with a DSA dependency in 2018, and so rescinded the recommendation.
Re: Cryptographic Right Answers
#224Earlier quoted context omitted.
What about the disadvantageous aspect of djb’s curves, like that they have a non-unit cofactors? That’s a huge foot-gun that has already maimed a few people. Also, deterministic signing nonces have NOTHING to do the DSA/ECDSA vs alternative signatures scheme. The library you recommend just uses its own deterministic signer internally, just as any ECDSA implementation can and should (e.g. bitcoin’s does).
Could you expand on what's dangerous in using a curve with a non-unit cofactor? I haven't heard of this as an attack vector before.
As a sort of hand-wavy message board explanation: you design a protocol using public-key crypto with the assumption that any given public key pairs with a single private key and with no other public or private keys.
But that's not true: for both Curve25519 and in the Ed25519 signature scheme, which were designed with curves for which point validation is supposedly unnecessary and thus not performed, there are for a given curve point other points --- not valid ones, but ones for which the math will work --- that are equivalent.
For the kinds of things most developers use crypto primitives for, and most of the things everyone was using them for in 2009, these distinctions are --- I'll argue --- not that important. If your transport protocol handshake blows up because of cofactors, the problem probably isn't that you didn't check curve points; it's that you designed a bad key exchange.
But since I don't do cryptocurrency work, like, at all, it's easy to forget that the mainstream of what people do with signature schemes is a lot broader than it was before. I'll try to think of a way to word that and get it into the document.
Re: Cryptographic Right Answers
#225Earlier quoted context omitted.
OK, the latest version of the RFC is much better than what I had initially read. Still, I see no discussion of side channel attacks with Argon2id. When they discuss the "best attack", it looks like they're discussing offline attacks that makes no use of timing information. Assuming timing attacks breaks Argon2d entirely at relatively little cost, the attacker advantage for a 1-pass Argon2id would be twice that of a o…
I think the RFC suggests sufficiently conservative parameters that it doesn't matter much. And, more generally: I don't think Argon2i vs Argon2d vs Argon2id vs scrypt is where people should be racking their brains.
OK, makes sense.
Re: Cryptographic Right Answers
#226Earlier quoted context omitted.
This guide is amazing. It's incredibly useful to be offered one happy path that lets non-experts (myself included) get started easily. BUUUUUT I can't help reading these and being reminded of Vernor Vinge's "Net of a Million Lies", where people looking for shortcuts end up getting traps. We know that state actors have haunted academic and industry efforts to disseminate info and implementations of cryptography, inser…
I don't think HN is good enough. On the (rare) occasions when tptacek does post something wrong, it gets massively upvoted anyway because it's tptacek. (I've even seen posts that boil down to "don't you know who I am?" get upvoted) No-one is trustworthy enough to outsource the whole industry's security to - not tptacek, not djb, not AWS, and certainly not me. I think the key is to take not just the recipe but also th…
I think the time to bring up erroneous posts, is in the thread in which they occur. And as long as we are talking "substantive," how about citing tptacek's incorrect posts instead making vague references?
Even the dumbest of us know tptacek is not infallible, though I do hope cperciva and tptacek revisit this thread.
Re: Cryptographic Right Answers
#227Earlier quoted context omitted.
I don't think HN is good enough. On the (rare) occasions when tptacek does post something wrong, it gets massively upvoted anyway because it's tptacek. (I've even seen posts that boil down to "don't you know who I am?" get upvoted) No-one is trustworthy enough to outsource the whole industry's security to - not tptacek, not djb, not AWS, and certainly not me. I think the key is to take not just the recipe but also th…
I think the time to bring up erroneous posts, is in the thread in which they occur. And as long as we are talking "substantive," how about citing tptacek's incorrect posts instead making vague references? Even the dumbest of us know tptacek is not infallible, though I do hope cperciva and tptacek revisit this thread.
> I think the time to bring up erroneous posts, is in the thread in which they occur. And as long as we are talking "substantive," how about citing tptacek's incorrect posts instead making vague references?
I did bring them up in the threads they occurred in. Not wanting to reopen those old discussions is precisely why I didn't talk about specific examples or give links.
Re: Cryptographic Right Answers
#228Earlier quoted context omitted.
ChaCha is generally faster and has more implementations, including OpenSSL. Salsa is essentially limited to NaCl and Sodium. From a security perspective, there is nothing wrong with Salsa. But libraries implementing ChaCha today are unlikely to add Salsa. It wouldn't take much effort for libraries currently having high-quality implementations of ChaCha to add an extended nonce variant. The only reason it didn't happe…
It may help if we point out that we now have at least two independent implementations of XChacha20: your Libsodium and my Monocypher. This should raise confidence. I'd love to add the extended nonce to RFC 7539, though.
Why would implementation in your own library raise confidence?
Sodium is interesting because thousands of people use it.
Re: Cryptographic Right Answers
#229Earlier quoted context omitted.
Take Monocypher or TweetNaCL, and rip off any primitive you don't need. This may be enough. Even when you take the whole thing, Monocypher only needs 30kb of x86-64 machine code when compiled with -Os. If you only keep authenticated encryption and x25519, which are enough for many uses, I think you should be able to halve that down to 15kb or less. If speed doesn't matter, TweetNaCl is even smaller. If those aren't e…
avr has aes extensions, surely arm cortex-m has similar. are those any good, are they used by the libs you mention?
Neither of those libraries uses any extensions. TweetNaCl is a famously minimal implementation of NaCl in portable C by the NaCl authors. Monocypher is a library 'loup-vaillant wrote as a sort of side project. TweetNaCl does see some use, but libsodium is the most popular NaCl implementation, and libsodium's author provides his own low-footprint misuse-resistant crypto API separately.
Neither TweetNaCl nor 'loup-vaillant's library really addresses the low-footprint concern.
Re: Cryptographic Right Answers
#230Earlier quoted context omitted.
The real question is which of these have actually been vetted . I trust NaCl and, specifically, DJB-associated implementations thereunto. Lots of people have looked at it. I trust DJB and his cohorts to think about and mitigate footguns as much as practical. STROBE is right about a year old. Maybe it's awesome, but it almost certainly hasn't been vetted sufficiently. I seem to recall that most PAKE's relied on one of…
Why do you trust Bernstein more than you trust Mike Hamburg?
I suspect its lingering litigation distrust of RAMBUS and association with Stanford connections.
RAMBUS got shafted by the DRAM manufacturers, but they pulled a LOT of shady crap of their own and Stanford was in the thick of it.
While I have no belief that Mike Hamburg was ever in the middle of that, I have some concerns about what might or might not be patented once RAMBUS's lawyers get done with it.