If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong

http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html

by jeffreyg • 17 years ago

94 46 17 years ago

chargen.matasano.com

cperciva3• 17 years ago

I am a proud member of the doing-it-wrong society.

Shamiq• 17 years ago

Man, I love the banter between you and Thomas.

tptacek3• 17 years ago

And you deserve every picodollar you earn for doing it that way, Colin.

cperciva3• 17 years ago

Hey, it's a lot of picodollars!

notauser• 17 years ago

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.)

hga2• 17 years ago

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.

cperciva3• 17 years ago

an authentication system based on public keys (I've read they didn't get it right until the mid-80s).

Make that mid-90s. How to do public key signatures wasn't really settled until Bellare and Rogaway published PSS at Eurocrypt 96.

hga2• 17 years ago

Sorry, I wasn't clear/precise, I meant an "authentication server" type protocol/system, e.g. like Kerberos.

NateLawson11• 17 years ago

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• 17 years ago

Older HN thread for this article: http://news.ycombinator.com/item?id=639647

lr• 17 years ago

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.

tibbon• 17 years ago

Anyone got a TL;DR version?

Basically encryption isn't authentication?

judofyr• 17 years ago

Basically you shouldn't use a library which provides AES-support - you should use a library which provides encryption/authentication/crypo-support.

NateLawson11• 17 years ago

Yes. And cryptographers are culpable for not finishing this critical handoff by assisting in production and review of such libraries.

sapphirecat2• 17 years ago

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.

NateLawson11• 17 years ago

If the version is not covered by the HMAC, you may be subject to rollback attacks. Compare the SSLv2 and v3 protocols to see what was done to address this.

Really, it's very easy to make a mistake.

jqueryin• 17 years ago

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.

msie• 17 years ago

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.

dlytle• 17 years ago

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.

DomesticMouse• 17 years ago

It was stupidly tl;dr. About the only audience this made it accessable to are the bored and those who like reading romance fiction.

JimmyL• 17 years ago

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".

NateLawson11• 17 years ago

Usually people focus on "which algorithm" (you may have heard endless debates about key length) when "which options" is what actually ends up biting you. But one argument seems fun and the other mundane, so the latter doesn't get the attention it requires.

joe_the_user3• 17 years ago

Yes,

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?

jrussbowman2• 17 years ago

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.

mrcharles• 17 years ago

The real answer is that you sound like you'd benefit from reading the whole damn article.

jrussbowman2• 17 years ago

Well, I read the entire article, and it's quite interesting that there are things like Keyczar and cryptlib out there, I still think it's a poor example. Other than a brief note on encryption does not equal authentication, they never touched on the fact that encrypting the cookie data itself isn't a real solution, as the encrypted cookie can be sniffed, and replayed to the server.

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.

achille• 17 years ago

Why encrypt the cookie at all? Why not just have server1 sign it and haver server2 verify server1's signature?

NateLawson11• 17 years ago

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.

bartl• 17 years ago

If the idea of the article was to make me feel inadequate, it did a remarkably good job.

NateLawson11• 17 years ago

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!

aschobel2• 17 years ago

We use the AES cipher for user authentication, we use the Rijndael variant since we want 192-bit block size.

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.

NateLawson11• 17 years ago

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.

Maybe it's "secure", but it doesn't do anything.

fasthead• 17 years ago

And your post, sire, is a great example of not understanding the intent of security. There's always a tradeoff between the requirement on the level of security and cost in implementing it. Security is a matter of tradeoff.

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.

aschobel2• 17 years ago

Our UID share a namespace w/ our note IDs, we don't see a reason to limit it to 4 billion objects (especially since the objects are versioned w/ revision IDs).

We use concatenation.

It solved our specific problem.

joe_the_user3• 17 years ago

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.

If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong

Related Stories