Mixing
Is AES ECB good enough for key spreading?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
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.....
aes ecb
edited 1 hour ago
Maarten Bodewes
50.5k669184
asked 5 hours ago
DrPhill
134
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
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.....
aes ecb
edited 1 hour ago
Maarten Bodewes
50.5k669184
asked 5 hours ago
DrPhill
134
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Do you want a random key generated by the user's password that is Key streching
– kelalaka
4 hours ago
1
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 :)
– Maarten Bodewes
3 hours ago
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.
– DrPhill
3 hours ago
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.
– Maarten Bodewes
1 hour ago
... but you can still comment to kelalaka here and to fgrieu below his answer if there is still a need for it, of course.
– Maarten Bodewes
1 hour ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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.....
aes ecb
edited 1 hour ago
Maarten Bodewes
50.5k669184
asked 5 hours ago
DrPhill
134
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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.....
aes ecb
aes ecb
edited 1 hour ago
Maarten Bodewes
50.5k669184
asked 5 hours ago
DrPhill
134
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
Maarten Bodewes
50.5k669184
asked 5 hours ago
DrPhill
134
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
Maarten Bodewes
50.5k669184
edited 1 hour ago
Maarten Bodewes
50.5k669184
edited 1 hour ago
Maarten Bodewes
50.5k669184
50.5k669184
asked 5 hours ago
DrPhill
134
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
DrPhill
134
asked 5 hours ago
DrPhill
134
134
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
DrPhill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Do you want a random key generated by the user's password that is Key streching
– kelalaka
4 hours ago
1
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 :)
– Maarten Bodewes
3 hours ago
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.
– DrPhill
3 hours ago
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.
– Maarten Bodewes
1 hour ago
... but you can still comment to kelalaka here and to fgrieu below his answer if there is still a need for it, of course.
– Maarten Bodewes
1 hour ago
add a comment |Â
1
Do you want a random key generated by the user's password that is Key streching
– kelalaka
4 hours ago
1
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 :)
– Maarten Bodewes
3 hours ago
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.
– DrPhill
3 hours ago
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.
– Maarten Bodewes
1 hour ago
... but you can still comment to kelalaka here and to fgrieu below his answer if there is still a need for it, of course.
– Maarten Bodewes
1 hour ago
1
1
Do you want a random key generated by the user's password that is Key streching
– kelalaka
4 hours ago
Do you want a random key generated by the user's password that is Key streching
– kelalaka
4 hours ago
1
1
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 :)
– Maarten Bodewes
3 hours ago
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 :)
– Maarten Bodewes
3 hours ago
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.
– DrPhill
3 hours ago
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.
– DrPhill
3 hours ago
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.
– Maarten Bodewes
1 hour ago
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.
– Maarten Bodewes
1 hour ago
... but you can still comment to kelalaka here and to fgrieu below his answer if there is still a need for it, of course.
– Maarten Bodewes
1 hour ago
... but you can still comment to kelalaka here and to fgrieu below his answer if there is still a need for it, of course.
– Maarten Bodewes
1 hour ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
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.
edited 3 hours ago
Maarten Bodewes
50.5k669184
answered 3 hours ago
fgrieu
74.8k7153316
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?
– DrPhill
2 hours ago
1
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.
– Maarten Bodewes
1 hour ago
@Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway.
– fgrieu
1 hour ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
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.
edited 3 hours ago
Maarten Bodewes
50.5k669184
answered 3 hours ago
fgrieu
74.8k7153316
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?
– DrPhill
2 hours ago
1
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.
– Maarten Bodewes
1 hour ago
@Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway.
– fgrieu
1 hour ago
add a comment |Â
up vote
3
down vote
accepted
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.
edited 3 hours ago
Maarten Bodewes
50.5k669184
answered 3 hours ago
fgrieu
74.8k7153316
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?
– DrPhill
2 hours ago
1
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.
– Maarten Bodewes
1 hour ago
@Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway.
– fgrieu
1 hour ago
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
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.
edited 3 hours ago
Maarten Bodewes
50.5k669184
answered 3 hours ago
fgrieu
74.8k7153316
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.
edited 3 hours ago
Maarten Bodewes
50.5k669184
answered 3 hours ago
fgrieu
74.8k7153316
edited 3 hours ago
Maarten Bodewes
50.5k669184
edited 3 hours ago
Maarten Bodewes
50.5k669184
edited 3 hours ago
Maarten Bodewes
50.5k669184
50.5k669184
answered 3 hours ago
fgrieu
74.8k7153316
answered 3 hours ago
fgrieu
74.8k7153316
answered 3 hours ago
fgrieu
74.8k7153316
74.8k7153316
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?
– DrPhill
2 hours ago
1
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.
– Maarten Bodewes
1 hour ago
@Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway.
– fgrieu
1 hour ago
add a comment |Â
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?
– DrPhill
2 hours ago
1
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.
– Maarten Bodewes
1 hour ago
@Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway.
– fgrieu
1 hour ago
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?
– DrPhill
2 hours ago
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?
– DrPhill
2 hours ago
1
1
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.
– Maarten Bodewes
1 hour ago
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.
– Maarten Bodewes
1 hour ago
@Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway.
– fgrieu
1 hour ago
@Maarten Bodewes: thanks for perfectly finishing the answer. I had been interrupted halfway.
– fgrieu
1 hour ago
add a comment |Â
DrPhill is a new contributor. Be nice, and check out our Code of Conduct.
DrPhill is a new contributor. Be nice, and check out our Code of Conduct.
DrPhill is a new contributor. Be nice, and check out our Code of Conduct.
DrPhill is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f63510%2fis-aes-ecb-good-enough-for-key-spreading%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Do you want a random key generated by the user's password that is Key streching
– kelalaka
4 hours ago
1
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 :)
– Maarten Bodewes
3 hours ago
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.
– DrPhill
3 hours ago
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.
– Maarten Bodewes
1 hour ago
... but you can still comment to kelalaka here and to fgrieu below his answer if there is still a need for it, of course.
– Maarten Bodewes
1 hour ago