Password stretching using concatenation of hashes

Question

I'm working on a simple file encryption tool.

Basically, here's how my program works:

password = get_user_typed_password()
salt = uuid4()
key = bcrypt(password + salt)
cipher = AES(key)

for block in input_file:
    output_file.write(AES.encrypt(block))

---

My question is about "how could I make a possibly short and weak password a long and strong one?".

I thought I could use a concatenation of sha512 hashed, like that:

for i from 1 to 1000:
    password += sha512(password).digest()

At the end, I would have a a 64000 long password with 'high ANSII' characters like these ones: ☼¢♣┌¥↕▼║ÅÕ¼■♫.

Do you think it's a good idea to stretch the given password like this? Remember that it will not be stored in a db.

I know that inventing your own mechanism is bad, but here, it's only for making the password longer/stronger...the final key will be key = bcrypt(long_password + salt) anyway.

With that question, I wanted to ask one that I didn't found here: "Hash concatenation is bad for generating a key...but what about password stretching?"

Thanks in advance for your answers, explainations and critics (I'm a newbie in crypto)!

Answer 1

"Long" does not make "strong". What matters is the entropy, a tricky word which means "that which the password could have been". A weak password is weak because it is part of a small set of possible passwords. The attacker is in your head; when you select a raw common English word he knows that he just has to try all common English words; there are about 10000 of these.

Now suppose that you have "stretched" your password. How many distinct stretched passwords can you end up with ? Still 10000. The attacker still has only 10000 passwords to try in order to break into your system. The stretching has make the passwords longer but not stronger because entropy has not changed.

At best, you can try to make each attacker's try as expensive as possible, and that's the role of bcrypt.

Answer 2

No, I don't think it's a good idea. At the end of the day, the number of possible states that your output could have is limited to the number of possible states that your input password can be in. So, if your password is only 5 characters long, alphanumeric, then the number of possible outputs will always be 36^5, or about 60 million. You can't create information entropy by hashing it - you're just making it look more random, which gives people a false sense of security.

Moreover, you're inventing your own key-stretching which has not been peer reviewed. There are existing key-stretching mechanisms that have been properly reviewed, and that have been shown to be at least reasonably strong. PBKDF2 is one such algorithm.

There's also a fault with your encryption code:

for block in input_file:
    output_file.write(AES.encrypt(block))

This is an ECB-mode encryption (each block transformed independently) which is known to be insecure, even if you're using AES or any other strong block cipher. You should look into CBC or another block mode that uses an IV.

Finally, you don't seem to be providing any form of authenticity record in your ciphertext. This means that an attacker can re-shuffle blocks around and modify plaintext without ever knowing the key. If you were to use CBC mode this problem doesn't go away - there's a malleability issue that allows an attacker to modify one plaintext block by trashing an adjacent one.

My advice? Don't use this in production. You need to study cryptography for a while before trying to write a real implementation.