
Typing the Letters A-E-S Into Your Code (2009) - zorked
http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html
======
tbirdz
I have a comment more on the presentation than the content. I actually really
enjoyed the "script format" type presentation more than I thought I would when
I first staerted reading it. Having the article be a conversation between two
(and more) people helped to explain various aspects of the topic (just as a
conversation would normally digress), without getting "single speaker fatigue"
as I often get when listening to a traditional lecture. Instead each character
had their own voice and personality. The incidental details also helped me
picture the scene as if it really were a movie, and brought the content to
life in a way simply reading a standard article description would not.

I think this could also be interesting to see in an actually filmed format,
and could be applicable to more topics than just security/cryptography. Maybe
instead of "Comedians in Cars Getting Coffee" we could have "Computer
Scientists in Cars Getting Coffee".

Right now it seems like most of the video content about this field is in
either the single lecturer/presenter format, the interview format, or the
unscripted Q&A panel format, but I have not seen many (or even any)
multicharacter scripted pieces, as the original article presented. It seems
like there is room to innovate in this space. Your "characters" could each
have different concerns, and their contribution to the topic discussion would
be scripted explain the topic in terms of their "personality" (the performance
junky, the "paranoid" security person, etc). I'm just talking off the top of
my head here, so I'm sure there are some more interesting ways to run with
this concept.

If anyone has actually done something like this, I would appreciate if someone
could reply with link or some more information about that project. If not I
think it could be a project worth pursuing.

~~~
Bjartr
In some ways, it's a tried and true concept

[http://en.wikipedia.org/wiki/Category:Dialogues_of_Plato](http://en.wikipedia.org/wiki/Category:Dialogues_of_Plato)

~~~
webnrrd2k
Also used extensively, and to great effect, in Godel, Escher, Bach.

------
sarciszewski
Luckily, in PHP land, I can do it wrong without ever having to type the
letters A-E-S anywhere, because the relevant mcrypt constants are named
MCRYPT_RIJNDAEL_128, MCRYPT_RIJNDAEL_192, and MCRYPT_RIJNDAEL_256.

Nevermind the fact that only MCRYPT_RIJNDAEL_128 is actually AES, most
developers choose MCRYPT_RIJNDAEL_256 and claim they're implementing AES-256.

To wit (trigger warning, encraption and severe arrogance on its developer's
behalf follows):

[https://github.com/opencart/opencart/blob/99bcfb24519ef3a411...](https://github.com/opencart/opencart/blob/99bcfb24519ef3a4117e9300ea759e58e4c0826d/upload/system/library/encryption.php)

[https://github.com/opencart/opencart/issues/1279](https://github.com/opencart/opencart/issues/1279)

[https://github.com/opencart/opencart/issues/1594](https://github.com/opencart/opencart/issues/1594)

And this is an eCommerce platform.

If anyone is feeling frustrated by the constant "don't roll your own crypto"
advice from the experts, it's being said for a _damn_ good reason.

Also, don't use opencart's encryption library.

~~~
F30
It is out of question that you can do it wrong without typing A-E-S: Crypto is
hard, and you can always fuck up in an infinite amount of ways.

That being said, do you have any reference on MCRYPT_RIJNDAEL_256 being an
actual problem? The linked OpenCart issues deal with ECB mode and missing
authentication, rather than the block size.

~~~
sarciszewski
It's not really a _problem_ so much as it's not doing what they think it's
doing. 256-bit block-size Rijndael might even be better than 128-bit (AES). I
don't know.

------
tptacek
I'm flattered by the attention, as always.

Couple quick things:

On our original blog (I have nothing to do with this one; I haven't been at
Matasano for several months), this was CSS-formatted to look like an actual
script, which I think makes it significantly easier to follow. Dave Wagner
copied it to his website, and it's closer to the original:

[http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.h...](http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html)

Second: in case you're impatient (I would be), conceptually, this is what the
post is trying to communicate:

* Unauthenticated CBC is surprisingly malleable. There are two attacks in here that I thought were "clever": using totally random CBC block garbling strategically to eat quote characters and synthesize SQL injection (the motivating example for the post, after I pulled this attack off on a real system) and "stuffing" inputs with known plaintext to make rewriting easier.

* CBC padding oracles. I would be interested if anyone knows a source outside of academic literature that walked through this attack published prior to 2009.

It is not about how to implement single sign-on cookies.

The nice thing about posts about cryptographic attacks, as opposed to
cryptographic constructions, is that they age pretty well. :)

------
cat9
I found this a bit surreal, because the answer in Flask is roughly:

1\. Generate a server signing key using urandom(key_length).encode('base-64')
and store it in app.config['SECRET_KEY'] via config.py and appropriate
.gitignore, or environment variables, whatever toots your horn.

2\. You now have a secure signed session cookie, congratulations. This is a
"user session data" cookie, i.e. a simple key-value store in the user's
cookies accessed from flask via session['key'], so set session['sid'] to some
long random .encode('base-64') key that maps to the user via Redis (or your
RDB, if you want to only use that).

3\. Use Flask's @app.before_request decorator to determine who owns the
session ID and store the appropriate user ID in the Flask.g request context.

4\. The @app.route gets the user ID from Flask.g, never the session. Any calls
it makes that need to know which user are given the internal ID directly (i.e.
the user ID in the users table).

A lot of people don't even go to that extent, you can do more or less the same
thing via Flask-Login or Flask-KVsession. If you're using either, I'd
recommend reading through the project code on GitHub to see what happens as a
result of the context decorators. It's not terribly complicated in either
case.

So back to the original problem, if you want both services to be able to
verify the signing data, you give them the same app.config['SECRET_KEY'] and
have them share data about how session keys map to users.

Or you could use an "I am Joe Johnson" cookie schema and forego session keys,
if that's appropriate. If so, just put it in session['username'] and let the
session sign it. Ta da, done.

If you have to start thinking about encryption strategies in Flask, beyond
"use passlib.hash.bcrypt_sha256 on user passwords," you done fucked up
already. It has great tools to keep you from ever having to touch that stuff,
so please use them.

The above story should be roughly equivalent for Rails, once you change the
names around. Node.js, I'm not sure, but there's probably a library for that
by now. Use it.

~~~
jameshart
If you think answering the SSO question is the point of this piece, you
haven't read it properly.

------
icanhasfay
Obligatory Doom principle link. [http://www.thoughtcrime.org/blog/the-
cryptographic-doom-prin...](http://www.thoughtcrime.org/blog/the-
cryptographic-doom-principle/)

Encrypt Then Authenticate, dammit!

~~~
meowface
Or, from the inverse perspective: always authenticate and/or verify the
integrity of data before processing it at all, whether that processing be
decryption, string manipulation, or otherwise.

~~~
StavrosK
Which you can't do if the MAC is within the encrypted message.

~~~
meowface
Of course. EtM is the only way to go. Just saying it can be applied to other
areas, too.

------
TrainedMonkey
Rule of crypto #1 - never implement your own crypto.

If you want to know what they are talking about, here are two free courses
that go over all of that stuff and more. I particularly liked error oracle
decryption exercise from coursera crypto class:

[https://www.coursera.org/course/crypto](https://www.coursera.org/course/crypto)

[https://www.udacity.com/course/cs387](https://www.udacity.com/course/cs387)

~~~
moron4hire
Someone, somewhere had to implement their own crypto, or there wouldn't be any
crypto.

~~~
snowwrestler
Yes, but they did it wrong. But someone else caught the bug and fixed it. But
the fix was wrong, but yet another person caught that bug and fixed it. But
their fix was wrong, but it got fixed, but that was wrong... and the next, and
the next... Repeat for as long as the library has been in active use and
development.

That's the value of using established libraries. It's not necessarily that
those library authors are so much smarter than the rest of us (although maybe
a few are). It's that they already know a lot of the ways that their code was
wrong.

If you write it yourself, who's going to catch your bugs? Then who's going to
catch theirs?

This is not specific to crypto code, but crypto code is probably harder than
most to get right, and more likely to be used on serious stuff.

~~~
moron4hire
What says any particular person _will_ write said bugs? We have a word for
automatically assuming that any particular individual holds any particular
trait of the group of which they are a member without first confirming that
person has that trait. It's called prejudice. And yes, you can be prejudiced
towards your own in-group.

Good crypto code needs a good understanding of crypto and a good understanding
of code. The person who has both is rare. Far too frequently, the situation
you've described comes about because the only people writing crypto code are
the people who understand crypto.

And I think the admonishment "don't write your own crypto code" is peer-
pressuring people who have a good understanding of code from abstaining from
gaining a good understanding of crypto.

~~~
snowwrestler
When it comes to putting bugs in software, I am prejudiced against the human
race. :-)

Folks saying "don't write your own crypto" are really talking about production
systems that will serve customers, employees, governments, etc. Crypto is not
going to be a market differentiator; it just needs to work. So why not stand
on the shoulders of many others and use a library that is already well tested
and patched up?

But in terms of spending your own time to learn, I doubt many folks would say
don't do that. Matasano even provides a bunch of freely available materials to
do just that.

------
olalonde
I know the cookie example was just an excuse to talk about cryptography but I
found it strange that there was no mention of using a randomly generated
session ID and a session store as most web frameworks do.

~~~
Kliment
Plaintext SID? Couldn't you just replay that SID then? Or generate random SIDs
and see what sticks?

~~~
seszett
If your SIDs are large enough, it's no different from generating random
encrypted cookies until one works, so not practical at all.

------
qznc
Obligatory link if you really want to write A-E-S into your code: Matasano
Crypto Challenge [http://cryptopals.com/](http://cryptopals.com/)

The article author was involved there too.

------
laex
There's a portion that says that using SHA-1 for generating a key is bad. Can
anyone explain why ?

~~~
tedunangst
[http://codahale.com/how-to-safely-store-a-password/](http://codahale.com/how-
to-safely-store-a-password/)

~~~
jerematasno
That link is not wrong, but scrypt is probably significantly better than
bcrypt, and PBKDF2 is not terrible, if you don't have a handy bcrypt/scrypt
library.

------
schizoidboy
But if I use gpg, the default algorithm is CAST-5, so I'll probably still type
AES in my code for --cipher-algo AES256 (or API equivalent) :-P (this is
mostly in jest, I know that CAST-5 is usually a reasonable default)

------
xrstf
Closing with a Futurama quote. Nicely done.

------
JustinBlaird
Portions directly copied from comedian Louis C.K.

~~~
tptacek
No. Really? You don't say!

I don't know why they chose to republish this just now, but if you find the
original date, you'll see that the reference was much more obvious when we
first published it, many years ago.

(The "portion" he's referring to is the Louis CK coffee shop bit.)

------
aburan28
Especially since the NSA has had atleast "a handful of in-house" attacks on
AES since 2012. AES(Rijndael) was given a score 1.11 in the AES competition
and to put that in context a score of 1.0 is considered a broken cipher.
Blowfish scored over 3.0 and was clearly a much stronger candidate algorithm.
[http://www.spiegel.de/international/germany/bild-1010361-793...](http://www.spiegel.de/international/germany/bild-1010361-793640.html)

~~~
tedunangst
Blowfish? Really? Do you know what you're talking about?

~~~
aburan28
Serpent is the cipher with the score over 3.0 not Blowfish my mistake. But
seriously I would read up instead of trusting the conventional wisdom when it
comes to the strongest cipher. [http://qr.ae/6wveK](http://qr.ae/6wveK)

~~~
forgotpasswd3x
So Serpent appears to be strongest, just slow? Is time really that big of an
issue? I mean, why not spend a few extra seconds encrypting something if it is
that much more secure?

~~~
sarciszewski
If by seconds you mean milliseconds ;)

------
dllthomas
_" If You’re Typing the Letters A-E-S Into Your Code You’re Doing It Wrong"_

What if I'm signing a comment, "MAESTRO"?

~~~
dllthomas
... then I'm still doing it wrong. Got it.

