31–40 of 76 posts
You've made me so nervous about everything I thought was true that I did a hg revert and am looking at gpgme bindings.
You've done a good deed, I think.
Earlier quoted context omitted.
I enjoyed it, even if it makes my head spin. I'm several years from my last reading of 'Applied Cryptography' and have never really gone into the deep end of that pool. So what, it [edit: meaning the blog article] is a fun read of hacking away in the security code world. [edit: Thomas, thanks for the book recommendation below, I'll definitely grab a copy]
Throw that book away, and buy Ferguson and Schneier's "Practical Cryptography", which Schneier contributed to in penance for writing "Applied Cryptography". Portions of the proceeds of "Practical Cryptography" are donated to a fund that helps the people who wrote crypto based on "Applied Cryptography".
1. Use a blocks-size unique prefix (IV) for each message (random will do as well)
2. SHA-256 your entire message before encryption and add the hash value at the end to prevent tampering
3. Use AES-256 with chaining to encrypt
4. Use SHA-256 to turn a password into a key. If your key space is small harden it with hashing 1000 times or so.
5. The time your algorithm takes should be always the same (or at worst one time for success and one for failure)
6. Don't use any other symmteric crypto algorithm.
Earlier quoted context omitted.
Throw that book away, and buy Ferguson and Schneier's "Practical Cryptography", which Schneier contributed to in penance for writing "Applied Cryptography". Portions of the proceeds of "Practical Cryptography" are donated to a fund that helps the people who wrote crypto based on "Applied Cryptography".
What in particular is wrong with "Applied Cryptography" ?
Everything that is wrong with "Applied" is right with "Practical". "Here are 4 modern block ciphers. We wrote one of them. Don't use it. You should use AES, but if you're a paranoid, use Serpent. But really use AES." It's great stuff, especially because if you really read it, you're going to end up not implementing crypto directly at all.
Thanks, Thomas. I just finished implementing my own crypto in a webapp I am working on. (AES, with Diffie Hellman for a shared secret we needed) You've made me so nervous about everything I thought was true that I did a hg revert and am looking at gpgme bindings. You've done a good deed, I think.
http://www.matasano.com/log/962/adam-bozanovich-did-not-unco...
Earlier quoted context omitted.
It's a Louis CK bit, and an inside joke because the bit does match up with Intelligentsia (there's actually one of those in LA, where LCK wrote the bit, so I've always wondered). Our office is in fact a few floors up from the Intelligentsia in the Monadnock building.
For variety you should head up a block to the Argo in the Marquette building. I work above the Argo, but sometimes visit your Intelligentsia for variety :)
It was a nice read, but the screenplay delivery added a lot of confusion that I felt detracted from the point of the actual message. Maybe if it hadn't been so fragmented. Still, educational, though moderately confusing.
But I actually kind of agree (at the very least, it's visually noisier than the prose wall of text). There's a backstory to this; I haven't blogged in almost a year, and my most infamous blog post from before that was also a screenplay, so doing this post in this style was also an in-joke:
http://www.matasano.com/log/248/metafuzzing/
(This post is funnier than today's post).
I'm sure you're glad you know this now.
Related to this: http://www.codinghorror.com/blog/archives/001267.html I assume.
Perhaps... A comment on that article: http://news.ycombinator.com/item?id=615209 Is the "AES" line a tptacek catchphrase? Or is he quoting someone else?
I don't understand what's so hard about encryption. There are simple, well-known rules (except the timing one that is sort of news), and if you follow them you should be safe, no? 1. Use a blocks-size unique prefix (IV) for each message (random will do as well) 2. SHA-256 your entire message before encryption and add the hash value at the end to prevent tampering 3. Use AES-256 with chaining to encrypt 4. Use SHA-256…
1. Has a well-known problem, which is why "Practical" suggests using a nonce.
2. SHA-256'ing a known plaintext doesn't authenticate a messge. In fact, even simply taking a secret key and appending it to your message before you SHA-256 the message isn't secure; there's a reason HMAC is as complicated as it is.
3. This whole blog post was about things that go wrong with CBC mode. For instance, nothing you wrote addressed padding checks --- btw, not strictly a "timing" attack.
4. Using a password as a crypto key is bad for reasons illustrated in the post, which is why secure keystores use random bytes. Hashing 1000 times has nothing to do with your key space.
5. This is like saying "your algorithm should be secure". Easy to say.
6. Everything we're talking about going wrong goes wrong even when you're using AES.
So, yes, I believe you don't understand what's so hard about encryption. You're obviously smart and you've taken some time with this material, and I still don't believe you'd get this right in your first fielded version.
Isn't the whole problem in this situation that you are trusting the client with critical data? He takes possession of it, has unlimited time and opportunity to work on it, and successful falsification will be obvious for him? Why on earth trust the client with the data in the first place? I have never liked the "encrypted cookie" way of handling session storage. Just have a server side session store and all of this c…