Typing the Letters A-E-S Into Your Code (2009)
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.
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/issues/1279
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.
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...
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. :)
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.
Obligatory Doom principle link. http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...
Encrypt Then Authenticate, dammit!
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:
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.
Obligatory link if you really want to write A-E-S into your code: Matasano Crypto Challenge http://cryptopals.com/
The article author was involved there too.
There's a portion that says that using SHA-1 for generating a key is bad. Can anyone explain why ?
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)
undefined
Closing with a Futurama quote. Nicely done.
Portions directly copied from comedian Louis C.K.
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...
"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"?