5 ms·

Just as an example of how easy* it is for even experts to screw these things up, Viktor's followup email suggests that tools should enforce parameters. One of

by ryan-c 9y ago

Just as an example of how easy* it is for even experts to screw these things up, Viktor's followup email suggests that tools should enforce parameters. One of his suggestions: > exponent is unconditionally 65535 (F_4) The value for public exponent F_4 is actually 65537 (a low hamming weight prime), not 65535. * This comment originally read "hard" instead of "easy", which I totally did on purpose as a joke but fixed because it was confusing.

jlgaddis 9y ago
> The value for public exponent F_4 is actually 65537 ... That's what I thought when I was reading the second post in the thread. I'm certainly no crypto expert, though, so I was left wondering why 65535 was being recommended when, for example, TLS often uses 65537. I was heading for the DNSSEC RFCs in search of an explanation when I decided to click over to the discussion thread and saw your comment so thank you for the clarification! EDIT: I'm subscribed to this list so I just posted a "correction" (which is apparently pending moderation, for some reason).
- dfox 9y ago
  Note that choice of e has no security implications as no valid message can be smaller than length(n)/e. Picking prime speeds up key generation slightly (by eliminating values for which there is no d=e^-1 (mod n), which means that new n or e has to be generated), picking low hamming weight values speeds up public key operations (significantly).
  - Dylan16807 9y ago
    Mostly no security implications. e=3 has some doubts. https://crypto.stackexchange.com/questions/8454/what-security-authorities-and-standards-reject-e-3-in-rsa-when-and-with-what https://crypto.stackexchange.com/questions/8454/what-securit... is very informative.
    - dfox 9y ago
      My comment was meant to say "as long as no valid message", which was intended to imply that for OAEP and PSS it essentially does not matter and for simple padding schemes e has to be sufficiently large (ie. not 3)
xoa 9y ago
>Just as an example of how hard it is for even experts to screw these things up, I assume you meant "...of how easy it is..."? Or was that itself a nice subtle example of the point? Either way it's certainly important to recognize how critical multiple review, as much automated checking (and even full formal verification in some places) as feasible, and so forth is for security. Really, it's just not a very human-firendly area full stop. The details really, really matter. Though none of that means the experts aren't still better, relatively, then the rest of us, or that thoroughly tested and hardened code isn't better then DYI. It's just hard for everyone, and even higher level devs or operators still have to be careful of gotchas.
sowbug 9y ago
Hartman's law of prescriptivist retaliation strikes again... and again. https://en.wikipedia.org/wiki/Muphry%27s_law https://en.wikipedia.org/wiki/Muphry%27s_law
wereHamster 9y ago
> Just as an example of how easy* it is for even experts to screw these things up You can't refer to everyone working in IT as an expert. We must have higher standards than just "Can you use Excel? Great, now go set up DNSSEC", which is what probably happened in this case of a generic hosting provider.

by ryan-c 9y ago

jlgaddis 9y ago

> The value for public exponent F_4 is actually 65537 ... That's what I thought when I was reading the second post in the thread. I'm certainly no crypto expert, though, so I was left wondering why 65535 was being recommended when, for example, TLS often uses 65537. I was heading for the DNSSEC RFCs in search of an explanation when I decided to click over to the discussion thread and saw your comment so thank you for the clarification! EDIT: I'm subscribed to this list so I just posted a "correction" (which is apparently pending moderation, for some reason).

dfox 9y ago
Note that choice of e has no security implications as no valid message can be smaller than length(n)/e. Picking prime speeds up key generation slightly (by eliminating values for which there is no d=e^-1 (mod n), which means that new n or e has to be generated), picking low hamming weight values speeds up public key operations (significantly).
- Dylan16807 9y ago
  Mostly no security implications. e=3 has some doubts. https://crypto.stackexchange.com/questions/8454/what-security-authorities-and-standards-reject-e-3-in-rsa-when-and-with-what https://crypto.stackexchange.com/questions/8454/what-securit... is very informative.
  - dfox 9y ago
    My comment was meant to say "as long as no valid message", which was intended to imply that for OAEP and PSS it essentially does not matter and for simple padding schemes e has to be sufficiently large (ie. not 3)

xoa 9y ago

>Just as an example of how hard it is for even experts to screw these things up, I assume you meant "...of how easy it is..."? Or was that itself a nice subtle example of the point? Either way it's certainly important to recognize how critical multiple review, as much automated checking (and even full formal verification in some places) as feasible, and so forth is for security. Really, it's just not a very human-firendly area full stop. The details really, really matter. Though none of that means the experts aren't still better, relatively, then the rest of us, or that thoroughly tested and hardened code isn't better then DYI. It's just hard for everyone, and even higher level devs or operators still have to be careful of gotchas.

sowbug 9y ago

Hartman's law of prescriptivist retaliation strikes again... and again. https://en.wikipedia.org/wiki/Muphry%27s_law https://en.wikipedia.org/wiki/Muphry%27s_law

wereHamster 9y ago

> Just as an example of how easy* it is for even experts to screw these things up You can't refer to everyone working in IT as an expert. We must have higher standards than just "Can you use Excel? Great, now go set up DNSSEC", which is what probably happened in this case of a generic hosting provider.