2

When developing applications that require crypto routines, I know to use libraries like keyczar and libsodium rather than "raw" crypto routines myself.

However, for the specific case of using AES-CBC symmetric encryption of a block of text, I'm wondering what the pitfalls are that I may unwittingly run into.

(For a concrete example, the prudence of using a library such as this one - which I've been reading over - is what I've been curious about: http://www.aescrypt.com/sharp_aes_crypt.html.)

xyz
  • 123
  • 2
  • 1
    http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own and http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html – Adi Jun 05 '13 at 08:48
  • 3
    Just to make things clear. Generally [implementing your own crypto is a good way to learn](http://chat.stackexchange.com/transcript/151?m=1343511#1343511), but shouldn't be done when you want to use your implementation to actually secure something, or in a production environment. So, playing around with crypto is fine, as long as you don't actually believe that you'll write something secure and then use it for that purpose. – Adi Jun 05 '13 at 09:05

2 Answers2

4

The cipher function is just a building-block for encryption. It's an important one, no doubt, but it's just one single component that can be used both securely and insecurely. If you write the the crypto framework yourself and plug in ciphers, etc. where you think they go, you run a very real risk of doing something wrong.

For example:

  • What's your cipher key? Are you using a key derivation function or just naively hashing your password?
  • Initialization vector? Where does it come from and what do you do with it?
  • Block chaining mode, which do you pick and why did you pick it? Did you say "CBC because everyone else uses it"? Does your block chaining mode affect your initialization vector choice?
  • Message authentication; are you testing to ensure that the message hasn't been tampered with? Where do you put that authentication code?
  • Flexibility: do you allow parameters such as cipher specification or chaining mode to be specified at run-time? (How) do you indicate your decision in your output?
  • ...and dozens of other issues that don't spring immediately to mind.

There are lots of decisions to be made, and a huge number of ways to get it wrong. Typically there's an easy-but-horrifyingly-wrong answer to every question which you may stumble into using simply by not knowing that you had to make a decision.

Frameworks (hopefully) answer a lot of these questions for you, and (hopefully) do so in a way that is community-vetted and largely secure. Not all frameworks do things right, and many may punt the question back to you.

But (and here's the important point) if you go it alone and build your own framework, there's an overwhelmingly high probability that you'll come up with the wrong answer for some decision.

If you use a trusted, vetted, well-written framework, you up your odds a bit.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • Thanks for those concrete examples of the tricky decisions points - that's exactly what I was looking for here. I do already try to heed the high-level lesson. If any more issue *do* spring to mind, please feel free to point them out here - I'm just trying to learn! – xyz Jun 06 '13 at 00:59
1

for the specific case of using AES-CBC symmetric encryption of a block of text

The problem here--and with most implementations of crypto algorithms--is that the specific case is insufficiently specific. If you're using 128 bits of output from /dev/random as a key, memorizing that key, then manually entering it to encrypt and decrypt, you're probably safe.

If, however, you don't want to memorize 128 truly random bits, how are you deriving your key? I hope it's a good password-based key derivation function, not a mere cryptographic hash of the password and a salt.

Then, if you're not careful about how many times you'll attempt to decrypt a ciphertext, you're going to need a message authentication code verifying the ciphertext's integrity before you attempt decryption; or you'll become a padding oracle. Thomas Ptacek wrote a fun dramatization of this failure mode: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html

There are many other attacks this application of AES could be prone to, depending on how the actual details flesh out. The underlying cognitive problem is that we humans think by forming mental models of situations; and our mental models are, 99.99999% of the time, insufficiently detailed and precise for implementing crypto securely.

Stephen Bachelor
  • 496
  • 4
  • 5
  • Thanks. I do understand and already heed the high-level lesson you point out. What I sought here were more concrete examples of beginners are likely to make, or at least what the tricky decision points are - precisely to learn. If you have any other examples you can add, that would be really awesome. – xyz Jun 06 '13 at 00:57