3
$\begingroup$

My apologies if I get my terminology wrong - I am new to this stuff.

I am writing a routine (in c) to encrypt plaintext. I am using TinyAES to perform a CBC on the plaintext and sending a (pseudo)random IV with the encrypted text.

The user supplies a password (ascii) which I pad to key length with a known (constant) block of bytes (from https://keygen.io/). I then want both to spread the key byte values across the entire key length and to distribute the values of the bytes across the entire 0-255 range.

To do this I am currently using AES ECB with another known (constant) block of byte values (again from https://keygen.io/) as the key. For AES192 and AES 256 I perform a second ECB on the key buffer offset by 8 and 16 bytes respectively.

Using this method I can generate the same key from the same password every time. Is this a good spreading technique? Or am I falling into one of the many traps for the unwary?

I am using AES ECB so that I do not need any more library code in my app.....

Improve this question
$\endgroup$
5
  • 1
    $\begingroup$ Do you want a random key generated by the user's password that is Key streching $\endgroup$
    – kelalaka
    Oct 27, 2018 at 11:24
  • 1
    $\begingroup$ It seems you're well on your way to create your own hash function from a block cipher. Congratulations, that is a common way how those are build. You could take it further and build a password hash from that. The only thing left then is to try and convince everybody that it is secure - we'll try and use the predefined ones in the mean time :) $\endgroup$
    – Maarten Bodewes ♦
    Oct 27, 2018 at 13:02
  • $\begingroup$ I am re-inventing a wonky wheel? No problems. If someone can point at an ANSI C, open source, small ,simple password hash implementation I could try to use it. I guess what I am doing is better than nothing, but not as good as it could be. $\endgroup$
    – DrPhill
    Oct 27, 2018 at 13:13
  • 1
    $\begingroup$ References are off topic here. I've included some algorithms in the answer of fgrieu so you can research the algorithms and find your own implementations - there are plenty of them around. Please do not include references to specific users in your question. As for those edits: 1. no, key stretching stretches the entropy, not the password. 2. I don't think that fgrieu misunderstood you at all. $\endgroup$
    – Maarten Bodewes ♦
    Oct 27, 2018 at 14:25
  • $\begingroup$ ... but you can still comment to kelalaka here and to fgrieu below his answer if there is still a need for it, of course. $\endgroup$
    – Maarten Bodewes ♦
    Oct 27, 2018 at 14:41

1 Answer 1

Reset to default
3
$\begingroup$

I then want both to spread the key byte values across the entire key length

Neither is useful. AES is secure without such "spreading" (not a standard term). The method discussed does that fine.

However it is missed a step critical for security of any password-based encryption: key stretching. The idea is to transform the password into the key for AES (as done by the question's method), in a purposely slow manner. This is necessary to avoid a password search attack.

To derive of a key from a password you need a password based key derivation function or PBKDF. A key derivation function based on a password is also called a password hash for short; it is also commonly used for password verification. Known PBKDF's are bcrypt, scrypt, PBKDF2 and the much newer Argon2 (in various forms). These all perform key stretching.

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ The importance of 'slow' had escaped me (I usually value fast). Would I be correct in saying that a slow method just raises the cost of a password search attack, rather than avoids it? $\endgroup$
    – DrPhill
    Oct 27, 2018 at 13:17
  • 2
    $\begingroup$ Couldn't have said it better. You should make sure that the password is of sufficient strength or that additional countermeasures are present (something that doesn't work for file encryption). Using passwords for encryption is tricky whatever you do; passwords just don't contain that much entropy in general. $\endgroup$
    – Maarten Bodewes ♦
    Oct 27, 2018 at 14:21
  • $\begingroup$ @Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway. $\endgroup$
    – fgrieu ♦
    Oct 27, 2018 at 14:30
  • 1
    $\begingroup$ @DrPhill It depends on the strength of the password and how many iterations the key derivation has. When using AES it's a reasonable assumption that you are aiming for 128 bits of security. If you use a random password with 6 bits of entropy per character it would take 22 characters to reach 128 bits of entropy. If that's the kind of password you are using, there is nothing wrong with a fast key derivation function. If you only have 18 characters you can still reach the same security by a key derivation function with a million iterations. $\endgroup$
    – kasperd
    Oct 27, 2018 at 17:19
  • 1
    $\begingroup$ @DrPhill If you however were to use a password with only 8 characters, it is completely infeasible to compensate entirely for the weakness of such a short password by many iterations of the key derivation. In that case the iterations will slow down a brute force attack on the password, but it will still be faster to brute force the password than brute forcing AES directly. $\endgroup$
    – kasperd
    Oct 27, 2018 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.