
If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong - jeffreyg
http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html
======
cpach
Older HN thread for this article: <http://news.ycombinator.com/item?id=639647>

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

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

~~~
cperciva
Hey, it's a _lot_ of picodollars!

~~~
tptacek
Five hundred billion of those will buy you a cup of coffee, won't it? I think
you should call this the Zimbabwe Pricing Plan.

~~~
spicyj
Fifty cents buys a cup of coffee?

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

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

~~~
joe_the_user
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?

~~~
NateLawson
I agree. That's why "keep the data on the server" is preferable to "send it to
the user but protect it with custom crypto".

~~~
joe_the_user
Yes,

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.

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

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

~~~
NateLawson
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!

------
jrussbowman
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
The real answer is that you sound like you'd benefit from reading the whole
damn article.

~~~
jrussbowman
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.

~~~
zmimon
> as the encrypted cookie can be sniffed, and replayed to the server

I think the whole article is premised on requiring a level of security that
would presume TLS is being used.

~~~
NateLawson
Yes, the focus is on preventing cookie forgery for pre-auth account compromise
or privilege escalation.

------
tibbon
Anyone got a TL;DR version?

Basically encryption isn't authentication?

~~~
sapphirecat
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.

~~~
NateLawson
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.

~~~
sapphirecat
I'm sorry, I don't get it. For session cookies, the client cannot do any
validation of the cookie, so it's a completely different domain.

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.

~~~
NateLawson
Upgrading cookies is a bad idea. Revoking them and requiring reauthentication
is better. See the talk I gave at Google on web crypto where I talk about
exactly that situation.

[http://rdist.root.org/2009/08/06/google-tech-talk-on-
common-...](http://rdist.root.org/2009/08/06/google-tech-talk-on-common-
crypto-flaws/)

Your last paragraph shows you now have better understanding of this.

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

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

~~~
NateLawson
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
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.

~~~
NateLawson
I don't understand how you get "computers are insecure" from "Arbitrary-
MAC(UID) is not a useful protocol".

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

~~~
NateLawson
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.

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

~~~
cperciva
_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.

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

