Some more interesting crypto questions, for interested HN'ers:
- Write code to verify message integrity, given a tuple (message, authentication_code) and a function authentication_code(message) (Google "Timing attack" if you think you couldn't possibly get this wrong);
- We store passwords salted and hashed with MD5. What do you think? How about SHA1? (Yes, this is bad, since these algorithms are too fast and hence allow dictionary attacks on the passwords; "PBKDF2" or "OpenBSD's Blowfish scheme" are good; bonus points if they know about scrypt; should include a discussion of password complexity);
- An open source project put a project-1.0.zip, project-1.0.zip.md5 and a project-1.0.zip.md5.sig file on their FTP server. Discuss. How about SHA1? (The .md5.sig file safeguards the .md5 file, provided the PGP key used is well-known. Collision attacks for MD5 exist; therefore, a malicious maintainer could serve a carefully-chosen but benign file to most clients and one with a backdoor to, say, .mil. Conversely, no (second) preimage attacks are known, so only the maintainer could do this. SHA1 is safe, for now, but it would be wise to upgrade. Bonus points if they know that the zip format is easy to manipulate. A small amount of bonus points if they express surprise at seeing a zip, since it's mostly GNU projects that use this "double checksum" and those tend to use tarballs);
- We have an API of the form http://mysite/set/key1=val1,key2=val2,...,keyN=valN,hash=foo where foo=MD5(customer's secret || key1 || val1 || key2 || val2 || ... || keyN || valN), where || denotes concatenation. Discuss. How about SHA1? If you disagree with this design, what would you propose? (This idea, based on an old design of AWS, is completely horrible, for either MD5 or SHA1. The obvious issue is that MD5(secret || "a" || "b" || "c" || "d") = MD5(secret || "ab" || "cd"), so that it's a valid hash for either a=b,c=d or ab=cd; the less obvious issue is that MD5 and SHA1, being based on the Merkle–Damgård construction, allow calculation of MD5(msg || msg2) from MD5(msg) and the length of msg. The correct solution is to use e.g. HMAC-SHA1(customer's secret, key1 || "," || val1 || "," || key2 || "," || val2 || "," || ... || keyN || "," || valN), ideally with a way to select the algorithm. Or use HTTPS with client certificates.)
But I agree that people, by and large, shouldn't be directly using any of this stuff.
- Write code to verify message integrity, given a tuple (message, authentication_code) and a function authentication_code(message) (Google "Timing attack" if you think you couldn't possibly get this wrong);
- We store passwords salted and hashed with MD5. What do you think? How about SHA1? (Yes, this is bad, since these algorithms are too fast and hence allow dictionary attacks on the passwords; "PBKDF2" or "OpenBSD's Blowfish scheme" are good; bonus points if they know about scrypt; should include a discussion of password complexity);
- An open source project put a project-1.0.zip, project-1.0.zip.md5 and a project-1.0.zip.md5.sig file on their FTP server. Discuss. How about SHA1? (The .md5.sig file safeguards the .md5 file, provided the PGP key used is well-known. Collision attacks for MD5 exist; therefore, a malicious maintainer could serve a carefully-chosen but benign file to most clients and one with a backdoor to, say, .mil. Conversely, no (second) preimage attacks are known, so only the maintainer could do this. SHA1 is safe, for now, but it would be wise to upgrade. Bonus points if they know that the zip format is easy to manipulate. A small amount of bonus points if they express surprise at seeing a zip, since it's mostly GNU projects that use this "double checksum" and those tend to use tarballs);
- We have an API of the form http://mysite/set/key1=val1,key2=val2,...,keyN=valN,hash=foo where foo=MD5(customer's secret || key1 || val1 || key2 || val2 || ... || keyN || valN), where || denotes concatenation. Discuss. How about SHA1? If you disagree with this design, what would you propose? (This idea, based on an old design of AWS, is completely horrible, for either MD5 or SHA1. The obvious issue is that MD5(secret || "a" || "b" || "c" || "d") = MD5(secret || "ab" || "cd"), so that it's a valid hash for either a=b,c=d or ab=cd; the less obvious issue is that MD5 and SHA1, being based on the Merkle–Damgård construction, allow calculation of MD5(msg || msg2) from MD5(msg) and the length of msg. The correct solution is to use e.g. HMAC-SHA1(customer's secret, key1 || "," || val1 || "," || key2 || "," || val2 || "," || ... || keyN || "," || valN), ideally with a way to select the algorithm. Or use HTTPS with client certificates.)
But I agree that people, by and large, shouldn't be directly using any of this stuff.