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.
Written text leaves a lot of things to the reader's imagination, and therefore gives the reader a lot more freedom to engage with the content in whatever way he likes, at whatever pace he prefers. Some people love to read plays, but not all of them like to watch movies based on those plays.
Imagining a couple of computer scientists ranting about MACs while flying through space with a laser unicorn is fun. Actually watching a lame animation of two people and a unicorn flying though space might be funny the first time, but it quickly gets tired. Sure, you could pull a Peter Jackson and make that video extremely high-quality, but most people have better things to do than making an epic movie out of every blog post, so most videos will end up mediocre anyway. And then we're just wasting bandwidth.
"GEB takes the form of an interweaving of various narratives. The main chapters alternate with dialogues between imaginary characters, usually Achilles and the tortoise, first used by Zeno of Elea and later by Lewis Carroll in "What the Tortoise Said to Achilles". These origins are related in the first two dialogues, and later ones introduce new characters such as the Crab. These narratives frequently dip into self-reference and metafiction."
It's a thing:
Oh my gosh, this sounds like so much fun! Someone please make this happen. Bonus points if you manage to work in an old-timey silent film scene, complete with plinky piano and over-dramatic reactions.
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):
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.
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.
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:
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. :)
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.
Encrypt Then Authenticate, dammit!
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:
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.
Aside from your point (which is valid itself), it's not even necessarily "smarter". Comparably smart people more specialized at task X are likely to be better at task X.
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.
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.
See, this is why I hate these sorts of statements. They assume it's impossible to be innovative in well-established fields. Or they assume the person they are saying it to is incapable.
It's a sort of arrogant condescension that I don't think should have any place among polite people
The article author was involved there too.
Brute force is really fast, and hash functions don't help you make it slower at all.
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.)
The realist says they do not.
That is not what that link says.
What if I'm signing a comment, "MAESTRO"?