6 ms·

With everything in Crypto I have to wonder: Is the information correct? I really have no way of verifying if I'm learning the correct DHE, and I know that it's

With everything in Crypto I have to wonder: Is the information correct? I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited.

clifanatic 10y ago
Well, one benefit of wide exposure (like here on HN) is that if it was wrong, somebody would be bound to come along and point it out. FWIW, I consider myself pretty well-versed on cryptography and although I haven't gone over this book with a fine-toothed comb (yet!), it looks very, very accurate to me.
- dom0 10y ago
  > Well, one benefit of wide exposure (like here on HN) is that if it was wrong, somebody would be bound to come along and point it out. I wouldn't expect that subtle implementation errors or even protocol flaws would get noticed on any news site, or even by contributors / co-developers or whatever.
dom0 10y ago
> I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited. Well this is step 0 in cryptography engineering: You don't implement primitives. Use reviewed components providing primitives and implement your protocol on top of that. Step -1 is to not design your protocol, but use a reviewed protocol and implement that. Finally, step -2 is to not implement a protocol, but rather use a reviewed implementation of a fitting protocol. This isn't sarcasm and I don't mean to attack you.
- eponeponepon 10y ago
  There's a difficult rabbithole here - eventually you have to draw a line and decide to trust someone. Otherwise it's just layer after layer of paranoia until you implode in a puff of Philip Dick :)
  - dom0 10y ago
    Of course; my point is (and I assume that's also the point of other people who assert similar stances on the topic) that the average programmer or software engineer should leave these things to recognized cryptographers. This also highlights a peculiarity with cryptography, in that it is very hard to understand for laymen (assuming laymen are ppl with some CS or math education), so most arguments in discussions of laymen will be appeals to authority (eg. djb said ..., Schneier wrote ..., Rogaway wrote ...), and that very subtle mistakes can have very large consequences (on the other hand SE is full of these things; your entire software can be great and bug-free, yet a single off-by-one could get it 0wned anyway).
    - Cyph0n 10y ago
      Look at DES or MD5. Were they not designed by cryptographers? Or how about the whole Dual_EC_RBG backdoor fiasco? Yes, there was criticism right from the start, but it was adopted and used widely as far as I know. Heck, Dual_EC_RBG was only ousted in 2013: "The ANSI X9F1 Tool Standards and Guidelines Group which discussed the backdoor also included three employees from the prominent security company RSA Security.[6] In 2004, RSA Security made an implementation of Dual_EC_DRBG which contained the NSA backdoor the default CSPRNG in their RSA BSAFE as a result of a secret $10 million deal with NSA. In 2013, after the New York Times reported that Dual_EC_DRBG contained a backdoor by the NSA, RSA Security said they had not been aware of any backdoor when they made the deal with NSA, and told their customers to switch CSPRNG." Besides, I think it's a good learning exercise to try to implement cryptographic primitives based on existing implementations. My opinion is that such language would dissuade people from even trying to design one for fun. Disclaimer: do not design your own crypto primitive for production use.
      - Ar-Curunir 10y ago
TheGorramBatman 10y ago
There is some level of trust when you read books like this (or really any technical book); for that reason I'd probably pass on it for something by an authority in the field (or their recommendations).
baby 10y ago
You learn about DHE reading this. You implement DHE following specs and standards.
lvh 10y ago
Hi! I'm the author of Crypto 101. Firstly, I'm a real, honest-to-God cryptographer. I don't know if there are any particular people you had in mind whose recommendations you'd like to see, but there are a few HN bigwigs who'd probably be willing to generally endorse it :-) Also, it's been posted on HN a few times before, so it's had some scrutiny. That doesn't mean I don't make mistakes, but generally speaking, an active reader should be OK. The other thing is in the way the book is structured. I teach you to break crypto; so when I say something is broken, I prove it by showing you how to break it. Finally, the goal of this book is absolutely not to help you implement DHE. In an ideal world, the primitives we offer people are hard to misuse. Crypto 101 then only exists to satisfy programmer curiosity. It is not a replacement for a traditional academic education that will help you design new primitives; it also doesn't show you how to write secure implementations. However, Crypto 101 is still useful beyond merely satisfying curiosity now, because most cryptographic libraries _do not_ provide that easy-to-use API. Using regular hashes for password storage, various forms of broken AES-CBC (unauthenticated, key=IV, static IV...), et cetera are very real problems for real code, and Crypto 101 teaches you how to avoid that minefield. I'm also working on the "better, more accessible" crypto part, but I only have so much free time :)
- gist 10y ago
  My trust chain: I don't know crypto and didn't know who you were (so I might have asked the same question) but a few days ago I found out you are involved with tptacek with latacora.com so that was all I needed to know and trust what you said.
  - tptacek 10y ago
    That's a little scary but I appreciate the compliment.
    - gist 10y ago
      It's sort of the HN version of 'yeah, he's a goodfella'. Separately with latacora I suggest that you wrap in some ongoing residual that carries on far past the 'eventually you staff your own security team' phase (as added insurance for 'leadership').

clifanatic 10y ago

Well, one benefit of wide exposure (like here on HN) is that if it was wrong, somebody would be bound to come along and point it out. FWIW, I consider myself pretty well-versed on cryptography and although I haven't gone over this book with a fine-toothed comb (yet!), it looks very, very accurate to me.

dom0 10y ago
> Well, one benefit of wide exposure (like here on HN) is that if it was wrong, somebody would be bound to come along and point it out. I wouldn't expect that subtle implementation errors or even protocol flaws would get noticed on any news site, or even by contributors / co-developers or whatever.

dom0 10y ago

> I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited. Well this is step 0 in cryptography engineering: You don't implement primitives. Use reviewed components providing primitives and implement your protocol on top of that. Step -1 is to not design your protocol, but use a reviewed protocol and implement that. Finally, step -2 is to not implement a protocol, but rather use a reviewed implementation of a fitting protocol. This isn't sarcasm and I don't mean to attack you.

eponeponepon 10y ago
There's a difficult rabbithole here - eventually you have to draw a line and decide to trust someone. Otherwise it's just layer after layer of paranoia until you implode in a puff of Philip Dick :)
- dom0 10y ago
  Of course; my point is (and I assume that's also the point of other people who assert similar stances on the topic) that the average programmer or software engineer should leave these things to recognized cryptographers. This also highlights a peculiarity with cryptography, in that it is very hard to understand for laymen (assuming laymen are ppl with some CS or math education), so most arguments in discussions of laymen will be appeals to authority (eg. djb said ..., Schneier wrote ..., Rogaway wrote ...), and that very subtle mistakes can have very large consequences (on the other hand SE is full of these things; your entire software can be great and bug-free, yet a single off-by-one could get it 0wned anyway).
  - Cyph0n 10y ago
    Look at DES or MD5. Were they not designed by cryptographers? Or how about the whole Dual_EC_RBG backdoor fiasco? Yes, there was criticism right from the start, but it was adopted and used widely as far as I know. Heck, Dual_EC_RBG was only ousted in 2013: "The ANSI X9F1 Tool Standards and Guidelines Group which discussed the backdoor also included three employees from the prominent security company RSA Security.[6] In 2004, RSA Security made an implementation of Dual_EC_DRBG which contained the NSA backdoor the default CSPRNG in their RSA BSAFE as a result of a secret $10 million deal with NSA. In 2013, after the New York Times reported that Dual_EC_DRBG contained a backdoor by the NSA, RSA Security said they had not been aware of any backdoor when they made the deal with NSA, and told their customers to switch CSPRNG." Besides, I think it's a good learning exercise to try to implement cryptographic primitives based on existing implementations. My opinion is that such language would dissuade people from even trying to design one for fun. Disclaimer: do not design your own crypto primitive for production use.
    - Ar-Curunir 10y ago

TheGorramBatman 10y ago

There is some level of trust when you read books like this (or really any technical book); for that reason I'd probably pass on it for something by an authority in the field (or their recommendations).

baby 10y ago

You learn about DHE reading this. You implement DHE following specs and standards.

lvh 10y ago

Hi! I'm the author of Crypto 101. Firstly, I'm a real, honest-to-God cryptographer. I don't know if there are any particular people you had in mind whose recommendations you'd like to see, but there are a few HN bigwigs who'd probably be willing to generally endorse it :-) Also, it's been posted on HN a few times before, so it's had some scrutiny. That doesn't mean I don't make mistakes, but generally speaking, an active reader should be OK. The other thing is in the way the book is structured. I teach you to break crypto; so when I say something is broken, I prove it by showing you how to break it. Finally, the goal of this book is absolutely not to help you implement DHE. In an ideal world, the primitives we offer people are hard to misuse. Crypto 101 then only exists to satisfy programmer curiosity. It is not a replacement for a traditional academic education that will help you design new primitives; it also doesn't show you how to write secure implementations. However, Crypto 101 is still useful beyond merely satisfying curiosity now, because most cryptographic libraries _do not_ provide that easy-to-use API. Using regular hashes for password storage, various forms of broken AES-CBC (unauthenticated, key=IV, static IV...), et cetera are very real problems for real code, and Crypto 101 teaches you how to avoid that minefield. I'm also working on the "better, more accessible" crypto part, but I only have so much free time :)

gist 10y ago
My trust chain: I don't know crypto and didn't know who you were (so I might have asked the same question) but a few days ago I found out you are involved with tptacek with latacora.com so that was all I needed to know and trust what you said.
- tptacek 10y ago
  That's a little scary but I appreciate the compliment.
  - gist 10y ago
    It's sort of the HN version of 'yeah, he's a goodfella'. Separately with latacora I suggest that you wrap in some ongoing residual that carries on far past the 'eventually you staff your own security team' phase (as added insurance for 'leadership').