If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong
chargen.matasano.com
chargen.matasano.com
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.)
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.
But it seems like the situation they describe is one where you wouldn't want to use encryption at all. Why give the user his data in an encrypted form when you can give the user an ID and keep his data entirely away from him? Seriously, when does giving someone data you don't want them to read ever work better than just not giving them data at all?
Having a narrative reinforces the point that what you actually do depends on the entire context of the application. You would almost never be the one implementing cannot-be-broken-under-ANY-circumstances encryption. So you have to know what the circumstances are. In this case, the circumstances point to no-encryption-whatsoever!
Sure, you could point to other circumstances where something like what they're talking about would be useful but that's a million possible circumstances with a million possible encryption solutions and you've lost the useful urgency of the original concrete narrative.
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.
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!
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.
So, while standard user can't hack their own cookie for escalation, they can sniff admin cookies to get that escalation. If the cookie is used for authentication or authorization, encrypting it's content is providing a false sense of security, no matter what nifty library you choose or not choose to do it with.
I think the whole article is premised on requiring a level of security that would presume TLS is being used.
The point isn't the relationship between you, Bank of America, and a hacker; it's the relationship between you (a hacker) and Bank of America.
Basically encryption isn't authentication?
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.
Really, it's very easy to make a mistake.
Also, unlike session cookies, SSLv2 never had a hard expiration date after which it could be unconditionally rejected.
However, I did just realize that for perfect security, there must be a service disruption on change of version. Otherwise you may be upgrading an attacker's forged v1 cookie to v2, if they submit a request before the v1 expiration.
http://rdist.root.org/2009/08/06/google-tech-talk-on-common-...
Your last paragraph shows you now have better understanding of this.
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.
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.
Even with your proposed solution, there are still security breach. How does your solution handle the situation where someone hijacks the user's machine and uses his browser session? How does your solution handle the case of keylogger stealing the user's userid/password and start a valid session?
See there are always ways to make any security solution fall short. The security is always a balance between a number of competing goals. If the solution satisfies the requirement, it's a sound solution.
We use concatenation.
It solved our specific problem.
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.
Make that mid-90s. How to do public key signatures wasn't really settled until Bellare and Rogaway published PSS at Eurocrypt 96.