0

I need to encrypt a file with a password that can be memorized. So I was thinking about running the password through some rounds of Bcrypt before using it for AES encryption, so every time I want to encrypt/decrypt I want it to take about 10 seconds in my machine (meaning brute-forcing it wouldn't be possible).

What I want to ask you is whether doing this is 0K, since normally one shouldn't mess around with cryptography. Doesn't AES have this already built-in? I mean configurable number of rounds or something.

  • 2
    Possible duplicate of [Security of bcrypt/sha256 key used with AES to encrypt a file](http://security.stackexchange.com/q/29481/20074). – TildalWave Jun 08 '13 at 19:02

1 Answers1

1

There are many gotchas in the overall approach so I'll pick a narrow path.

First off, AES does NOT have any such thing in-built. It just takes a key and does it's job. There are no artificial "work factors" built into it.

Secondly, folks rarely "brute force" the password - they use dictionary based attacks along with a long list of permutation rules to try out "likely" password.

For your purpose, you can use either bcrypt, scrypt or pbkdf2 to slow down dictionary attacks. I would still recommend using longer pass phrases and also salting the keyboard password before it enters bcrypt/script or pbkdf2.

You should know that between you entering the "in-your-mind" password on your keyboard and the AES crypto library getting the real AES key, there can be many potential areas of weakness. eg: If you copy-paste the bcrypt output (=AES key?) into some other program (encryption program?), it's on your clipboard for ANY program to snoop on.

DeepSpace101
  • 2,153
  • 3
  • 23
  • 35
  • Why would I add a salt? Doesn't bcrypt already do that? – ChocoDeveloper Jun 09 '13 at 02:18
  • 1
    Yes, bcrypt can accept a salt value in it's input but you still have to actually provide/store it. Basically don't pass null or zeros taking any short cuts. You might not but just saying .... – DeepSpace101 Jun 09 '13 at 03:31