http://pastebin.com/raw.php?i=NXgU30xK
(as a Github gist:
https://gist.githubusercontent.com/anonymous/3cc34251e501c2c...)
One minor nit; I believe there is a typo in the review which caused parsing problems on my end:
The contact forward secrecy provides a design is...
s/contact/contract ?
I'd recommend adding some more metadata (when was it posted, maybe a nick/Anonymous) and a clear distinction between "frame" and "content".
But extra meta-data I've been loathe to add so far because I see it as a barrier. I'm open to persuasion though.
The more important recommendation, which this book misses, is NaCl (or its repackaging in libsodium). If you can use NaCl, use NaCl, and nothing else.
I've been reading about this recently, but I'm confused. Wasn't the PS3 issue that the key was static? That's not the opposite of randomized, because there could be a deterministic, yet message-specific scheme for generating the secret key. Or is that known to be unacceptable?
> there is concern that the NIST curves are backdoored and should be disfavored and replaced with Curve25519 and curves of similar construction.
I've heard the opposite, that the curves are not the problem but the choice of basepoint. E.g. [1] states: "...the vulnerabilities in Dual-EC have precisely nothing to do with the specifics of the NIST standard elliptic curves themselves. The 'back door' in Dual-EC comes exclusively from the relationship between P and Q -- the latter of which is published only in the Dual-EC specification."
Is it still a matter of dispute whether the curves themselves are suspect? Or is the referenced blog post outdated?
[1]: http://blog.cryptographyengineering.com/2013/09/the-many-fla...
Dual_EC isn't a curve standard, it's a random number generator standard. The NIST P- curves are thought to possibly be backdoored. Dual_EC is all but certainly a backdoored.
Second, if NSA backdoored a curve standard, they probably did it in a fashion that only allows them privileges. Google [NOBUS NSA]. Dual_EC is a NOBUS backdoor, unless you can efficiently solve the ECDLP, in which case the backdoor doesn't matter anyways.
Finally, even if you stipulate for argument that a curve was backdoored in such a way that a researcher might find the backdoor, who's to say that curve researchers care that much about Bitcoin?
And I can't find anyone anywhere giving evidence of mathematical insecurity of any NIST standard curves. Evidence might come in the form of a (significantly more than state of the art)-subexponential but still superpolynomial time algorithm. Dual_EC has something even better: a proof of insecurity.
This is just reinforcing my point. There is nothing known to be mathematically wrong with the standard curves. Bernstein just warns against all the (admittedly many) pitfalls in implementations, and that the Weierstrass normal form makes it easier to run into problems than the normal form he proposes. This is the only reason he says NIST doesn't guarantee security, and of course they don't guarantee against engineering errors.
But that's extremely different from saying NSA planted backdoored curves intentionally. The only thing in Bernstein's analysis that I could possibly construe as suggesting malicious behavior is that the NIST curves are outdated (the suggestion being that they are intentionally left outdated).
A mistake in crypto can invalidate your entire system, not just make it unreliable or crash, and those mistakes don't have to be something obvious, there are many insidious little things that can happen as well. That's my take on it.
That said, I believe that software engineers should learn basic crypto and fiddle around with their own ideas, _with the understanding that there is always someone smarter than them_ in order to understand some of the problems they'll be facing.