The first thing I did after the Snowden leaks was read through the entire thing and after doing so I really wished I had done this years earlier. There's very few books that I think should be required reading across the board for software engineers, but this is one that I do think everyone writing code should read every page of.
[0] http://www.amazon.com/Cryptography-Engineering-Principles-Pr...
In general, the authors seem to subscribe to "crypto is black magic" school of thought, which doesn't make for good pedagogy.
I found the course pretty hard as programmer with a strong interest in crypto, but no formal CS/maths background. The coding pieces were fairly straightforward, but the maths hurt.
It is in my "summer reading" pile.
x |= MAC_computed[i] − MAC_computed[i];
It probably should be something like: x |= MAC_computed[i] − MAC_received[i]; x |= MAC_computed[i] ^ MAC_received[i];
If they're not careful and the numeric type being subtracted is wider than CPU registers, depending on architecture, the compiler-generated carry code to implement wider-than-register subtraction may introduce timing attacks. Wider-than-register xor is much much less likely to have such issues.For example, is the suggested key size still the same as 2010?
Thank you.
Considering this, what do you think has changed in the past 5 years? Eg the slides mention SHA3 as a future option, now it is finalized and afaik usable.
There is also one interesting thing about SHA3 which I learned recently, namely that it can apparently be easily used as MAC too:
> Unlike SHA-1 and SHA-2, Keccak does not have the length-extension weakness, hence does not need the HMAC nested construction. Instead, MAC computation can be performed by simply prepending the message with the key
from http://keccak.noekeon.org/
In this light, do you think it would be reasonable to add exception for "DON’T: Try to use a hash function as a symmetric signature." rule?
Another thing is that ECC seems to be on the rise (or is it just my perception?). Do you think a revised slide set would include something more about elliptic curves?
Not much has changed. I still think SHA3 is worth considering 5-10 years into the future; five years ago I was concerned about the implications of MD5 and SHA1 breaks on SHA2, but the lack of recent progress makes me happier with staying on SHA2 while SHA3 gets more analysis.
do you think it would be reasonable to add exception for "DON’T: Try to use a hash function as a symmetric signature." rule?
I mentioned this in the talk; even with SHA3 you need to be careful, since a simple "append and hash" would result in MAC("key", "data") == MAC("keyd", "ata"), which breaks the MAC assumptions. Yes, you can use SHA3 as a MAC, but make sure you know what you're doing.
ECC seems to be on the rise (or is it just my perception?). Do you think a revised slide set would include something more about elliptic curves?
ECC is getting more popular; not necessarily for the right reasons, though. (The big drivers seem to be "bitcoin uses this" and "the most common way of using this provides forward perfect secrecy".) That said, as mathematicians continue to attack ECC systems, I am gradually becoming more comfortable; the 2025 version of this talk might recommend using them, but for now I don't think it makes sense to change my recommendation (except for situations like bitcoin which specifically need ECC's advantages).