This is the same in every profession though. Once you know the rules, and the reasons behind the rules, and the consequences of breaking the rules, you can consider the trade-offs of not sticking to the rules in this specific case because it buys you some big benefits.
Then, when it burns you horribly, you can write a informative blog post about why even the experts should follow the rules :-)
(Btdt, although in my case it was with documented project scope. It was probably the right decision, but that didn't make taking the kicking any more fun.)
I would have much preferred if the post wasn't acted out as a narrative as it detracted from the powerful message of not using AES and why it's flawed.
I'd say it didn't detract from the narrative; it made the narrative accessible to a different audience.
The screenplay format both presented a story-based framework for understanding the progression of the argument, and humor (unicorn with laser horn) to provide a contrast to the fairly complex topic.
I'm clueless when it comes to crypto, and if I were to read a very well written paper about it, I'd probably get sidetracked, or accept the conclusion without understanding the steps taken to reach it. The format of this article was perfect for driving the point (and its reasonings) home to the uneducated masses such as myself.
My takeaway from the article wasn't "don't use AES" - it was "use a sufficiently high-level cryptography library such that someone smarter than you is deciding which algorithm to use and with which options".
I agree. I found the narrative "intimidating" and stopped reading after a short while. I'm turned off by all the crypto-testosterone. :D
Ah, if only I could write another Notepad and make money off that.
I love the narrative account. Making a point dramatically is great and a pseudo-mystery story is great way to talk about encryption.
The narrative is right that AES is a wrong solution.
But really, any encryption at all is a wrong, bass-ackwards solution to keeping the user from modifying their account information.
A single cookie or argument that's a randomly generated user id with all the information server-side is much better.
I mean, consider any scenario where you pass the user data you'll later use. Will you not keep track of that data yourself but expect that the user's encrypted cookie will do it for you? This is one way of simulating statefulness in the stateless http protocol but it's a clearly an inferior, dumshit of doing it and it doesn't matter what encryption you use for the purpose. Giving someone encrypted information they can't use is essentially analogous to copy-protection and similar unwinnable scenarios whereas the unique id approach is pretty much the standard and works well for many, many apps of all sorts.
Having unique user-ids and user-information is only costly in terms of accessing the information. But there isn't a point where decrypting information coming from the user becomes less costly than getting it from the database. Indeed, the higher the traffic, the more different brute-force attacks make sense.
I don't think that was the goal. This whole crusade is just to get people to realize the true cost of getting crypto right. It costs time and money to build a resilient protocol. How many person-hours went into the AES competition? What was the proportion of time spent on creating the algorithms versus analyzing them?
In crypto, review costs much more than design. If you understand that tradeoff and the benefits of your own design are worth spending this effort on, congratulations, you are Qualcomm, Netscape, or Intel. All of these companies had staff cryptographers.
More likely, your problem is close enough to other problems that you don't need to spend the time or money to DIY. If that path is available, take it!
Ok, grant it I'm new here, and could be missing the point. I didn't actually go through the full article because I'm not really that much into crypto, and really, didn't the guy fail the interview at the point where he suggest that encryption was the answer for a cookie used for individual identification? I mean, encrypt it all you want, if I can be behind the same NAT as you, and spoof your user agent, all I need to do is get that cookie and put it in my browser, and I've stolen that session.
The real answer is you need to either encrypt the transport, or at the very least minimize the amount of time that cookie is valid for.
1: Encryption isn't magic pixie dust: people can tamper with the ciphertext and fool you. Sometimes they can even mess with the padding and decrypt the entire message.
2: A rule of thumb that falls out of this: never try to decrypt ciphertext that you can't verify is authentic. Consequence: compute the MAC over the ciphertext, not the plaintext, so you don't have to decrypt to check the MAC.
I've done my message format in the past as "{version}{hmac-md5}{ciphertext}". This is suitably secure, to the best of my knowledge. And thanks to the version, it lets me alter the algorithms or keys without service disruption. Once all sessions using it would be expired, the old version can be assumed to be expired.
My answer: I'd implement a real SSO solution, like CAS: http://www.jasig.org/cas -- Open Source, started at Yale, and supported by an amazing team of people.
This is a great example of warning signs. Note the number of times sizes (bits) and algorithm (AES/Rijndael) are mentioned. Note the lack of clarity in the specification (is "+" addition, XOR, or concatenation?) Note the overly-large UID space which has nothing to do with security (will you really have more than 4 billion users?)
Now look at how useful this design is. You've created a single-purpose authenticator that just says "someone at some point in time has seen this exact UID/authenticator pair". All other features (expiration, privileges, source of the authenticator, version, system name the UID is for) are left out.
The point of the article is that some people use encryption to try to achieve authentication, which doesn't work. You're right. Signatures are appropriate for providing authentication. HMAC is a form of symmetric authentication.
Heh; an illustration that the real art here is in cryptographic protocols, not crypto black boxes like AES (well, as long as your "random" numbers are random enough, which turns out to be an issue in the VPS world).
I was lucky enough to learn this in 1979 while in a group trying to puzzle out how to make an authentication system based on public keys (I've read they didn't get it right until the mid-80s).
Final note: these protocols are fragile. If e.g. Microsoft implements Kerberos but changes one little thing without explanation, let alone a serious and public security review, don't trust it!!!
- Harold, a proud member if the Do It Right Society.
Also, don't trust Kerberos. It was built long before things like SRP existed and hasn't caught up with the times. It hasn't fallen apart yet, but it's creaky.
[+] [-] cpach|16 years ago|reply
[+] [-] cperciva|16 years ago|reply
[+] [-] notauser|16 years ago|reply
Then, when it burns you horribly, you can write a informative blog post about why even the experts should follow the rules :-)
(Btdt, although in my case it was with documented project scope. It was probably the right decision, but that didn't make taking the kicking any more fun.)
[+] [-] tptacek|16 years ago|reply
[+] [-] Shamiq|16 years ago|reply
[+] [-] jqueryin|16 years ago|reply
[+] [-] dlytle|16 years ago|reply
The screenplay format both presented a story-based framework for understanding the progression of the argument, and humor (unicorn with laser horn) to provide a contrast to the fairly complex topic.
I'm clueless when it comes to crypto, and if I were to read a very well written paper about it, I'd probably get sidetracked, or accept the conclusion without understanding the steps taken to reach it. The format of this article was perfect for driving the point (and its reasonings) home to the uneducated masses such as myself.
[+] [-] JimmyL|16 years ago|reply
[+] [-] msie|16 years ago|reply
[+] [-] joe_the_user|16 years ago|reply
The narrative is right that AES is a wrong solution.
But really, any encryption at all is a wrong, bass-ackwards solution to keeping the user from modifying their account information.
A single cookie or argument that's a randomly generated user id with all the information server-side is much better.
I mean, consider any scenario where you pass the user data you'll later use. Will you not keep track of that data yourself but expect that the user's encrypted cookie will do it for you? This is one way of simulating statefulness in the stateless http protocol but it's a clearly an inferior, dumshit of doing it and it doesn't matter what encryption you use for the purpose. Giving someone encrypted information they can't use is essentially analogous to copy-protection and similar unwinnable scenarios whereas the unique id approach is pretty much the standard and works well for many, many apps of all sorts.
Having unique user-ids and user-information is only costly in terms of accessing the information. But there isn't a point where decrypting information coming from the user becomes less costly than getting it from the database. Indeed, the higher the traffic, the more different brute-force attacks make sense.
[+] [-] bartl|16 years ago|reply
[+] [-] NateLawson|16 years ago|reply
In crypto, review costs much more than design. If you understand that tradeoff and the benefits of your own design are worth spending this effort on, congratulations, you are Qualcomm, Netscape, or Intel. All of these companies had staff cryptographers.
More likely, your problem is close enough to other problems that you don't need to spend the time or money to DIY. If that path is available, take it!
[+] [-] jrussbowman|16 years ago|reply
The real answer is you need to either encrypt the transport, or at the very least minimize the amount of time that cookie is valid for.
[+] [-] mrcharles|16 years ago|reply
[+] [-] tibbon|16 years ago|reply
Basically encryption isn't authentication?
[+] [-] sapphirecat|16 years ago|reply
2: A rule of thumb that falls out of this: never try to decrypt ciphertext that you can't verify is authentic. Consequence: compute the MAC over the ciphertext, not the plaintext, so you don't have to decrypt to check the MAC.
I've done my message format in the past as "{version}{hmac-md5}{ciphertext}". This is suitably secure, to the best of my knowledge. And thanks to the version, it lets me alter the algorithms or keys without service disruption. Once all sessions using it would be expired, the old version can be assumed to be expired.
[+] [-] judofyr|16 years ago|reply
[+] [-] lr|16 years ago|reply
[+] [-] aschobel|16 years ago|reply
Our userIds are 64-bit with a 128-bit secret.
We generate the authentication cookie as follows:
Rijandael(64-bit userId + 128-bit secret, 192-bit key) = 192-bits of cipher text
If you tamper with the cipher text the 128-bit secret won't be the same.
I don't see a practical cipher text tampering attack against this scheme.
There are authorization issues like how do expire a specific user login.
[+] [-] NateLawson|16 years ago|reply
Now look at how useful this design is. You've created a single-purpose authenticator that just says "someone at some point in time has seen this exact UID/authenticator pair". All other features (expiration, privileges, source of the authenticator, version, system name the UID is for) are left out.
Maybe it's "secure", but it doesn't do anything.
[+] [-] achille|16 years ago|reply
[+] [-] NateLawson|16 years ago|reply
[+] [-] hga|16 years ago|reply
I was lucky enough to learn this in 1979 while in a group trying to puzzle out how to make an authentication system based on public keys (I've read they didn't get it right until the mid-80s).
Final note: these protocols are fragile. If e.g. Microsoft implements Kerberos but changes one little thing without explanation, let alone a serious and public security review, don't trust it!!!
- Harold, a proud member if the Do It Right Society.
[+] [-] cperciva|16 years ago|reply
Make that mid-90s. How to do public key signatures wasn't really settled until Bellare and Rogaway published PSS at Eurocrypt 96.
[+] [-] NateLawson|16 years ago|reply