AES: Why is it a good practice to use only the first 16 bytes of a hash for encryption?How can one securely generate an asymmetric key pair from a short passphrase?Key derivation functions (KDF): What are? Main purposes? How can they be used?Cryptography Implementation in softwareHashing - Digital Signing and Trivial StretchingReason for replacing mifare classicFast Forward Hash SignaturesApplication level encryption and key renewalPassword derived hash to encrypt known plaintext as password checkSecurity of non-standard use for AES-256-CTR?Basic encrypted custom protocolcipherText = aes-ctr(key, iv+1, (plainText)); & authTag= aes-ctr(key, iv, aes-ecb(key, sha-1(cipherText+authData+key+iv))); is it secure?What should I use for consequent AES key derivation?
When a company launches a new product do they "come out" with a new product or do they "come up" with a new product?
Took a trip to a parallel universe, need help deciphering
Is it possible to create light that imparts a greater proportion of its energy as momentum rather than heat?
AES: Why is it a good practice to use only the first 16 bytes of a hash for encryption?
How to take photos in burst mode, without vibration?
How could indestructible materials be used in power generation?
I'm flying to France today and my passport expires in less than 2 months
What is a clear way to write a bar that has an extra beat?
I Accidentally Deleted a Stock Terminal Theme
CEO ridiculed me with gay jokes and grabbed me and wouldn't let go - now getting pushed out of company
What does it mean to describe someone as a butt steak?
How can I tell someone that I want to be his or her friend?
Is it inappropriate for a student to attend their mentor's dissertation defense?
What about the virus in 12 Monkeys?
1960's book about a plague that kills all white people
Where does SFDX store details about scratch orgs?
Facing a paradox: Earnshaw's theorem in one dimension
How many spell slots should my level 1 wizard/level 1 fighter have?
Do I have a twin with permutated remainders?
Why does Kotter return in Welcome Back Kotter?
I would say: "You are another teacher", but she is a woman and I am a man
Fully-Firstable Anagram Sets
Is it possible to run Internet Explorer on OS X El Capitan?
In Romance of the Three Kingdoms why do people still use bamboo sticks when paper had already been invented?
AES: Why is it a good practice to use only the first 16 bytes of a hash for encryption?
How can one securely generate an asymmetric key pair from a short passphrase?Key derivation functions (KDF): What are? Main purposes? How can they be used?Cryptography Implementation in softwareHashing - Digital Signing and Trivial StretchingReason for replacing mifare classicFast Forward Hash SignaturesApplication level encryption and key renewalPassword derived hash to encrypt known plaintext as password checkSecurity of non-standard use for AES-256-CTR?Basic encrypted custom protocolcipherText = aes-ctr(key, iv+1, (plainText)); & authTag= aes-ctr(key, iv, aes-ecb(key, sha-1(cipherText+authData+key+iv))); is it secure?What should I use for consequent AES key derivation?
$begingroup$
I'd like to encrypt Text with AES/CTR and a password defined by the user in java. I already checked the internet (and stackoverflow) for answers. The most used version is to hash the user password with sha1 and take only the first 16 bytes.
But I don't think this can be a good practice.
- sha1 is weak
- taking only the first 16 bytes makes the hash also weak
and rise the chance for a collision (even with sha-256)
Is this really the best practice? Why? How can I do things better?
Some links to the articles I mentioned:
- https://stackoverflow.com/questions/3451670/java-aes-and-using-my-own-key
- https://howtodoinjava.com/security/java-aes-encryption-example/
- https://blog.axxg.de/java-aes-verschluesselung-mit-beispiel/
encryption hash aes symmetric
New contributor
$endgroup$
add a comment |
$begingroup$
I'd like to encrypt Text with AES/CTR and a password defined by the user in java. I already checked the internet (and stackoverflow) for answers. The most used version is to hash the user password with sha1 and take only the first 16 bytes.
But I don't think this can be a good practice.
- sha1 is weak
- taking only the first 16 bytes makes the hash also weak
and rise the chance for a collision (even with sha-256)
Is this really the best practice? Why? How can I do things better?
Some links to the articles I mentioned:
- https://stackoverflow.com/questions/3451670/java-aes-and-using-my-own-key
- https://howtodoinjava.com/security/java-aes-encryption-example/
- https://blog.axxg.de/java-aes-verschluesselung-mit-beispiel/
encryption hash aes symmetric
New contributor
$endgroup$
$begingroup$
I added the links
$endgroup$
– firendlyQuestion
12 hours ago
2
$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
12 hours ago
$begingroup$
Nowadays you should probably use HKDF with an appropriate hash.
$endgroup$
– jww
4 hours ago
add a comment |
$begingroup$
I'd like to encrypt Text with AES/CTR and a password defined by the user in java. I already checked the internet (and stackoverflow) for answers. The most used version is to hash the user password with sha1 and take only the first 16 bytes.
But I don't think this can be a good practice.
- sha1 is weak
- taking only the first 16 bytes makes the hash also weak
and rise the chance for a collision (even with sha-256)
Is this really the best practice? Why? How can I do things better?
Some links to the articles I mentioned:
- https://stackoverflow.com/questions/3451670/java-aes-and-using-my-own-key
- https://howtodoinjava.com/security/java-aes-encryption-example/
- https://blog.axxg.de/java-aes-verschluesselung-mit-beispiel/
encryption hash aes symmetric
New contributor
$endgroup$
I'd like to encrypt Text with AES/CTR and a password defined by the user in java. I already checked the internet (and stackoverflow) for answers. The most used version is to hash the user password with sha1 and take only the first 16 bytes.
But I don't think this can be a good practice.
- sha1 is weak
- taking only the first 16 bytes makes the hash also weak
and rise the chance for a collision (even with sha-256)
Is this really the best practice? Why? How can I do things better?
Some links to the articles I mentioned:
- https://stackoverflow.com/questions/3451670/java-aes-and-using-my-own-key
- https://howtodoinjava.com/security/java-aes-encryption-example/
- https://blog.axxg.de/java-aes-verschluesselung-mit-beispiel/
encryption hash aes symmetric
encryption hash aes symmetric
New contributor
New contributor
edited 15 mins ago
hardyrama
8731527
8731527
New contributor
asked 13 hours ago
firendlyQuestionfirendlyQuestion
312
312
New contributor
New contributor
$begingroup$
I added the links
$endgroup$
– firendlyQuestion
12 hours ago
2
$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
12 hours ago
$begingroup$
Nowadays you should probably use HKDF with an appropriate hash.
$endgroup$
– jww
4 hours ago
add a comment |
$begingroup$
I added the links
$endgroup$
– firendlyQuestion
12 hours ago
2
$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
12 hours ago
$begingroup$
Nowadays you should probably use HKDF with an appropriate hash.
$endgroup$
– jww
4 hours ago
$begingroup$
I added the links
$endgroup$
– firendlyQuestion
12 hours ago
$begingroup$
I added the links
$endgroup$
– firendlyQuestion
12 hours ago
2
2
$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
12 hours ago
$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
12 hours ago
$begingroup$
Nowadays you should probably use HKDF with an appropriate hash.
$endgroup$
– jww
4 hours ago
$begingroup$
Nowadays you should probably use HKDF with an appropriate hash.
$endgroup$
– jww
4 hours ago
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
Why is it a good practice to use only the first 16 bytes of a hash for encryption?
As you noted, it isn't.
But, the problem is not with the "16 bytes" part of the statement, or the concern for collisions. The problem is with the "hash" part.
16 bytes
As stated in one of the links you shared, AES only uses key sizes of 128, 192, and 256 bits (or 16, 24, and 32 bytes, respectively). So the key must be one of these sizes, because AES simply does not support other key sizes.
Trying to use a larger key could have a variety of possible outcomes depending on what the implementation chooses to do. It might raise an exception, or continue silently while only using the first N bits of the supplied key.
Hashing a password to use as an encryption key
Using a hash function such as MD5, SHA1, SHA2, SHA3, blake2, etc, would all be bad practice. The first two are obvious: MD5 and SHA1 are known to be weak in general.
But even using a strong cryptographic hash like SHA3 or blake2 would also be bad, because they were not designed to solve the problem of deriving a key from a password. Use of a cryptographic hash function is involved in this process, but it is not the entirety of it.
Good practice would be to use a dedicated key derivation function such as Argon2 that was designed to solve this problem. If your library doesn't support Argon2 but supports scrypt, bcrypt or PBKDF2, any of these three is also a reasonable choice.
Why/How
A normal hash function is designed to be fast and require little space.
A hash function designed for use on passwords is quite the opposite: it is a slow function that requires lots of memory access, in an attempt to try and optimize the function towards what a consumer CPU is good at, and minimize the potential for optimization with special hardware. Specialized hardware is usable by an attacker, but a legitimate user is limited to a commodity CPU; The goal is to try and use a function that cannot take advantage of special hardware to the extent possible.
Details about the hows and whys of password hashing are listed in this paper and quoted below (with minor modifications, e.g. removing citations and modified formatting):
Cryptographic Security: The scheme should be cryptographically secure and as such possess the following properties:
- 1) Preimage resistance
- 2) Second preimage resistance
- 3) collision resistance.
In addition it should avoid other cryptographic weaknesses such as those present in (some)Merkle-Damgård constructions(e.g. length extension attacks, partial message collisions, etc)
Defense against lookup table /TMTOAttacks:
- The scheme should aim to make TMTO attacks that allow for precomputed lookup table generation, such as Rainbow Tables, infeasible
Defense against CPU-optimized 'crackers':
- The scheme should be ‘CPU-hard’, that is, it should require significant amounts of CPU processing in a manner that cannot be optimized away through either software or hardware. As such, cracking-optimized (multi-core) CPU software implementations (eg. written in assembly, testing multiple input sets in parallel) should offer only minimal speed-up improvements compared to those intended for validation (“slower for attackers, faster for defenders”).
Defense against hardware-optimized 'crackers':
- The scheme should be 'memory-hard', that is, it should significant amounts of RAM capacity in a manner that cannot be optimized away through eg. TMTO attacks. As such cracking-optimized ASIC, FPGA and GPU implementations should offer only minimal speed up improvements (eg. in terms of time-area product) compared to those intended for validation. As noted by Aumasson one of the main scheme design challenges is ensuring minimized efficiency on GPUs, FPGAs and ASICs (in order to minimize benefits of cracking-optimized implementations) and maximized efficiency on general-purpose CPUs (in order to maintain regular use efficiency).
Defense against side-channel attacks:
- Depending on the use-case (eg. for key derivation or authentication to a device seeking to protect against modification by the device owner) side-channel attacks might be a relevant avenue of attack. Password hashing schemes should aim to offer side-channel resilience. With regards to password hashing scheme security we will focus on security versus the cache-timing type of side-channel attacks given the existence of such attacks against the commonly used scrypt scheme. The second category of side-channel attacks we will take into consideration are so-called Garbage Collector Attacks (GCAs). GCAs have been discussed in literature as an instance of a 'memory leak' attack relevant to password hashing scheme security. GCAs consist of a scenario where an attacker has access to a target machine's internal memory either after termination of the hashing scheme or at some point where the password itself is still present in memory (the so-called WeakGCA variant)...
$endgroup$
1
$begingroup$
Nitpick: bcrypt is advertised as a password storage and verification function, not so much a key derivation function, and implementations routinely have APIs to match that (e.g., outputting text encoded output, providing an enroll/verify API instead of a hash API, That is not to claim that bcrypt couldn't be used as you suggest, but there are potential practical pitfalls. See, e.g., this article.
$endgroup$
– Luis Casillas
8 hours ago
2
$begingroup$
@LuisCasillas just a note: I actually didn't list bcrypt; that was inserted to my answer by Gilles via an edit...
$endgroup$
– Ella Rose♦
8 hours ago
$begingroup$
@LuisCasillas Argon2 was also the winner of the password hashing competition, not the password-based KDF competition. Is there any reason to believe that Argon2 is good for PBKDF that doesn't also apply to bcrypt?
$endgroup$
– Gilles
7 hours ago
$begingroup$
In conclusion taking the first 16bytes is fine if I use an Argon2 Hash?
$endgroup$
– firendlyQuestion
42 mins ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
);
);
, "mathjax-editing");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
firendlyQuestion 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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f68545%2faes-why-is-it-a-good-practice-to-use-only-the-first-16-bytes-of-a-hash-for-encr%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Why is it a good practice to use only the first 16 bytes of a hash for encryption?
As you noted, it isn't.
But, the problem is not with the "16 bytes" part of the statement, or the concern for collisions. The problem is with the "hash" part.
16 bytes
As stated in one of the links you shared, AES only uses key sizes of 128, 192, and 256 bits (or 16, 24, and 32 bytes, respectively). So the key must be one of these sizes, because AES simply does not support other key sizes.
Trying to use a larger key could have a variety of possible outcomes depending on what the implementation chooses to do. It might raise an exception, or continue silently while only using the first N bits of the supplied key.
Hashing a password to use as an encryption key
Using a hash function such as MD5, SHA1, SHA2, SHA3, blake2, etc, would all be bad practice. The first two are obvious: MD5 and SHA1 are known to be weak in general.
But even using a strong cryptographic hash like SHA3 or blake2 would also be bad, because they were not designed to solve the problem of deriving a key from a password. Use of a cryptographic hash function is involved in this process, but it is not the entirety of it.
Good practice would be to use a dedicated key derivation function such as Argon2 that was designed to solve this problem. If your library doesn't support Argon2 but supports scrypt, bcrypt or PBKDF2, any of these three is also a reasonable choice.
Why/How
A normal hash function is designed to be fast and require little space.
A hash function designed for use on passwords is quite the opposite: it is a slow function that requires lots of memory access, in an attempt to try and optimize the function towards what a consumer CPU is good at, and minimize the potential for optimization with special hardware. Specialized hardware is usable by an attacker, but a legitimate user is limited to a commodity CPU; The goal is to try and use a function that cannot take advantage of special hardware to the extent possible.
Details about the hows and whys of password hashing are listed in this paper and quoted below (with minor modifications, e.g. removing citations and modified formatting):
Cryptographic Security: The scheme should be cryptographically secure and as such possess the following properties:
- 1) Preimage resistance
- 2) Second preimage resistance
- 3) collision resistance.
In addition it should avoid other cryptographic weaknesses such as those present in (some)Merkle-Damgård constructions(e.g. length extension attacks, partial message collisions, etc)
Defense against lookup table /TMTOAttacks:
- The scheme should aim to make TMTO attacks that allow for precomputed lookup table generation, such as Rainbow Tables, infeasible
Defense against CPU-optimized 'crackers':
- The scheme should be ‘CPU-hard’, that is, it should require significant amounts of CPU processing in a manner that cannot be optimized away through either software or hardware. As such, cracking-optimized (multi-core) CPU software implementations (eg. written in assembly, testing multiple input sets in parallel) should offer only minimal speed-up improvements compared to those intended for validation (“slower for attackers, faster for defenders”).
Defense against hardware-optimized 'crackers':
- The scheme should be 'memory-hard', that is, it should significant amounts of RAM capacity in a manner that cannot be optimized away through eg. TMTO attacks. As such cracking-optimized ASIC, FPGA and GPU implementations should offer only minimal speed up improvements (eg. in terms of time-area product) compared to those intended for validation. As noted by Aumasson one of the main scheme design challenges is ensuring minimized efficiency on GPUs, FPGAs and ASICs (in order to minimize benefits of cracking-optimized implementations) and maximized efficiency on general-purpose CPUs (in order to maintain regular use efficiency).
Defense against side-channel attacks:
- Depending on the use-case (eg. for key derivation or authentication to a device seeking to protect against modification by the device owner) side-channel attacks might be a relevant avenue of attack. Password hashing schemes should aim to offer side-channel resilience. With regards to password hashing scheme security we will focus on security versus the cache-timing type of side-channel attacks given the existence of such attacks against the commonly used scrypt scheme. The second category of side-channel attacks we will take into consideration are so-called Garbage Collector Attacks (GCAs). GCAs have been discussed in literature as an instance of a 'memory leak' attack relevant to password hashing scheme security. GCAs consist of a scenario where an attacker has access to a target machine's internal memory either after termination of the hashing scheme or at some point where the password itself is still present in memory (the so-called WeakGCA variant)...
$endgroup$
1
$begingroup$
Nitpick: bcrypt is advertised as a password storage and verification function, not so much a key derivation function, and implementations routinely have APIs to match that (e.g., outputting text encoded output, providing an enroll/verify API instead of a hash API, That is not to claim that bcrypt couldn't be used as you suggest, but there are potential practical pitfalls. See, e.g., this article.
$endgroup$
– Luis Casillas
8 hours ago
2
$begingroup$
@LuisCasillas just a note: I actually didn't list bcrypt; that was inserted to my answer by Gilles via an edit...
$endgroup$
– Ella Rose♦
8 hours ago
$begingroup$
@LuisCasillas Argon2 was also the winner of the password hashing competition, not the password-based KDF competition. Is there any reason to believe that Argon2 is good for PBKDF that doesn't also apply to bcrypt?
$endgroup$
– Gilles
7 hours ago
$begingroup$
In conclusion taking the first 16bytes is fine if I use an Argon2 Hash?
$endgroup$
– firendlyQuestion
42 mins ago
add a comment |
$begingroup$
Why is it a good practice to use only the first 16 bytes of a hash for encryption?
As you noted, it isn't.
But, the problem is not with the "16 bytes" part of the statement, or the concern for collisions. The problem is with the "hash" part.
16 bytes
As stated in one of the links you shared, AES only uses key sizes of 128, 192, and 256 bits (or 16, 24, and 32 bytes, respectively). So the key must be one of these sizes, because AES simply does not support other key sizes.
Trying to use a larger key could have a variety of possible outcomes depending on what the implementation chooses to do. It might raise an exception, or continue silently while only using the first N bits of the supplied key.
Hashing a password to use as an encryption key
Using a hash function such as MD5, SHA1, SHA2, SHA3, blake2, etc, would all be bad practice. The first two are obvious: MD5 and SHA1 are known to be weak in general.
But even using a strong cryptographic hash like SHA3 or blake2 would also be bad, because they were not designed to solve the problem of deriving a key from a password. Use of a cryptographic hash function is involved in this process, but it is not the entirety of it.
Good practice would be to use a dedicated key derivation function such as Argon2 that was designed to solve this problem. If your library doesn't support Argon2 but supports scrypt, bcrypt or PBKDF2, any of these three is also a reasonable choice.
Why/How
A normal hash function is designed to be fast and require little space.
A hash function designed for use on passwords is quite the opposite: it is a slow function that requires lots of memory access, in an attempt to try and optimize the function towards what a consumer CPU is good at, and minimize the potential for optimization with special hardware. Specialized hardware is usable by an attacker, but a legitimate user is limited to a commodity CPU; The goal is to try and use a function that cannot take advantage of special hardware to the extent possible.
Details about the hows and whys of password hashing are listed in this paper and quoted below (with minor modifications, e.g. removing citations and modified formatting):
Cryptographic Security: The scheme should be cryptographically secure and as such possess the following properties:
- 1) Preimage resistance
- 2) Second preimage resistance
- 3) collision resistance.
In addition it should avoid other cryptographic weaknesses such as those present in (some)Merkle-Damgård constructions(e.g. length extension attacks, partial message collisions, etc)
Defense against lookup table /TMTOAttacks:
- The scheme should aim to make TMTO attacks that allow for precomputed lookup table generation, such as Rainbow Tables, infeasible
Defense against CPU-optimized 'crackers':
- The scheme should be ‘CPU-hard’, that is, it should require significant amounts of CPU processing in a manner that cannot be optimized away through either software or hardware. As such, cracking-optimized (multi-core) CPU software implementations (eg. written in assembly, testing multiple input sets in parallel) should offer only minimal speed-up improvements compared to those intended for validation (“slower for attackers, faster for defenders”).
Defense against hardware-optimized 'crackers':
- The scheme should be 'memory-hard', that is, it should significant amounts of RAM capacity in a manner that cannot be optimized away through eg. TMTO attacks. As such cracking-optimized ASIC, FPGA and GPU implementations should offer only minimal speed up improvements (eg. in terms of time-area product) compared to those intended for validation. As noted by Aumasson one of the main scheme design challenges is ensuring minimized efficiency on GPUs, FPGAs and ASICs (in order to minimize benefits of cracking-optimized implementations) and maximized efficiency on general-purpose CPUs (in order to maintain regular use efficiency).
Defense against side-channel attacks:
- Depending on the use-case (eg. for key derivation or authentication to a device seeking to protect against modification by the device owner) side-channel attacks might be a relevant avenue of attack. Password hashing schemes should aim to offer side-channel resilience. With regards to password hashing scheme security we will focus on security versus the cache-timing type of side-channel attacks given the existence of such attacks against the commonly used scrypt scheme. The second category of side-channel attacks we will take into consideration are so-called Garbage Collector Attacks (GCAs). GCAs have been discussed in literature as an instance of a 'memory leak' attack relevant to password hashing scheme security. GCAs consist of a scenario where an attacker has access to a target machine's internal memory either after termination of the hashing scheme or at some point where the password itself is still present in memory (the so-called WeakGCA variant)...
$endgroup$
1
$begingroup$
Nitpick: bcrypt is advertised as a password storage and verification function, not so much a key derivation function, and implementations routinely have APIs to match that (e.g., outputting text encoded output, providing an enroll/verify API instead of a hash API, That is not to claim that bcrypt couldn't be used as you suggest, but there are potential practical pitfalls. See, e.g., this article.
$endgroup$
– Luis Casillas
8 hours ago
2
$begingroup$
@LuisCasillas just a note: I actually didn't list bcrypt; that was inserted to my answer by Gilles via an edit...
$endgroup$
– Ella Rose♦
8 hours ago
$begingroup$
@LuisCasillas Argon2 was also the winner of the password hashing competition, not the password-based KDF competition. Is there any reason to believe that Argon2 is good for PBKDF that doesn't also apply to bcrypt?
$endgroup$
– Gilles
7 hours ago
$begingroup$
In conclusion taking the first 16bytes is fine if I use an Argon2 Hash?
$endgroup$
– firendlyQuestion
42 mins ago
add a comment |
$begingroup$
Why is it a good practice to use only the first 16 bytes of a hash for encryption?
As you noted, it isn't.
But, the problem is not with the "16 bytes" part of the statement, or the concern for collisions. The problem is with the "hash" part.
16 bytes
As stated in one of the links you shared, AES only uses key sizes of 128, 192, and 256 bits (or 16, 24, and 32 bytes, respectively). So the key must be one of these sizes, because AES simply does not support other key sizes.
Trying to use a larger key could have a variety of possible outcomes depending on what the implementation chooses to do. It might raise an exception, or continue silently while only using the first N bits of the supplied key.
Hashing a password to use as an encryption key
Using a hash function such as MD5, SHA1, SHA2, SHA3, blake2, etc, would all be bad practice. The first two are obvious: MD5 and SHA1 are known to be weak in general.
But even using a strong cryptographic hash like SHA3 or blake2 would also be bad, because they were not designed to solve the problem of deriving a key from a password. Use of a cryptographic hash function is involved in this process, but it is not the entirety of it.
Good practice would be to use a dedicated key derivation function such as Argon2 that was designed to solve this problem. If your library doesn't support Argon2 but supports scrypt, bcrypt or PBKDF2, any of these three is also a reasonable choice.
Why/How
A normal hash function is designed to be fast and require little space.
A hash function designed for use on passwords is quite the opposite: it is a slow function that requires lots of memory access, in an attempt to try and optimize the function towards what a consumer CPU is good at, and minimize the potential for optimization with special hardware. Specialized hardware is usable by an attacker, but a legitimate user is limited to a commodity CPU; The goal is to try and use a function that cannot take advantage of special hardware to the extent possible.
Details about the hows and whys of password hashing are listed in this paper and quoted below (with minor modifications, e.g. removing citations and modified formatting):
Cryptographic Security: The scheme should be cryptographically secure and as such possess the following properties:
- 1) Preimage resistance
- 2) Second preimage resistance
- 3) collision resistance.
In addition it should avoid other cryptographic weaknesses such as those present in (some)Merkle-Damgård constructions(e.g. length extension attacks, partial message collisions, etc)
Defense against lookup table /TMTOAttacks:
- The scheme should aim to make TMTO attacks that allow for precomputed lookup table generation, such as Rainbow Tables, infeasible
Defense against CPU-optimized 'crackers':
- The scheme should be ‘CPU-hard’, that is, it should require significant amounts of CPU processing in a manner that cannot be optimized away through either software or hardware. As such, cracking-optimized (multi-core) CPU software implementations (eg. written in assembly, testing multiple input sets in parallel) should offer only minimal speed-up improvements compared to those intended for validation (“slower for attackers, faster for defenders”).
Defense against hardware-optimized 'crackers':
- The scheme should be 'memory-hard', that is, it should significant amounts of RAM capacity in a manner that cannot be optimized away through eg. TMTO attacks. As such cracking-optimized ASIC, FPGA and GPU implementations should offer only minimal speed up improvements (eg. in terms of time-area product) compared to those intended for validation. As noted by Aumasson one of the main scheme design challenges is ensuring minimized efficiency on GPUs, FPGAs and ASICs (in order to minimize benefits of cracking-optimized implementations) and maximized efficiency on general-purpose CPUs (in order to maintain regular use efficiency).
Defense against side-channel attacks:
- Depending on the use-case (eg. for key derivation or authentication to a device seeking to protect against modification by the device owner) side-channel attacks might be a relevant avenue of attack. Password hashing schemes should aim to offer side-channel resilience. With regards to password hashing scheme security we will focus on security versus the cache-timing type of side-channel attacks given the existence of such attacks against the commonly used scrypt scheme. The second category of side-channel attacks we will take into consideration are so-called Garbage Collector Attacks (GCAs). GCAs have been discussed in literature as an instance of a 'memory leak' attack relevant to password hashing scheme security. GCAs consist of a scenario where an attacker has access to a target machine's internal memory either after termination of the hashing scheme or at some point where the password itself is still present in memory (the so-called WeakGCA variant)...
$endgroup$
Why is it a good practice to use only the first 16 bytes of a hash for encryption?
As you noted, it isn't.
But, the problem is not with the "16 bytes" part of the statement, or the concern for collisions. The problem is with the "hash" part.
16 bytes
As stated in one of the links you shared, AES only uses key sizes of 128, 192, and 256 bits (or 16, 24, and 32 bytes, respectively). So the key must be one of these sizes, because AES simply does not support other key sizes.
Trying to use a larger key could have a variety of possible outcomes depending on what the implementation chooses to do. It might raise an exception, or continue silently while only using the first N bits of the supplied key.
Hashing a password to use as an encryption key
Using a hash function such as MD5, SHA1, SHA2, SHA3, blake2, etc, would all be bad practice. The first two are obvious: MD5 and SHA1 are known to be weak in general.
But even using a strong cryptographic hash like SHA3 or blake2 would also be bad, because they were not designed to solve the problem of deriving a key from a password. Use of a cryptographic hash function is involved in this process, but it is not the entirety of it.
Good practice would be to use a dedicated key derivation function such as Argon2 that was designed to solve this problem. If your library doesn't support Argon2 but supports scrypt, bcrypt or PBKDF2, any of these three is also a reasonable choice.
Why/How
A normal hash function is designed to be fast and require little space.
A hash function designed for use on passwords is quite the opposite: it is a slow function that requires lots of memory access, in an attempt to try and optimize the function towards what a consumer CPU is good at, and minimize the potential for optimization with special hardware. Specialized hardware is usable by an attacker, but a legitimate user is limited to a commodity CPU; The goal is to try and use a function that cannot take advantage of special hardware to the extent possible.
Details about the hows and whys of password hashing are listed in this paper and quoted below (with minor modifications, e.g. removing citations and modified formatting):
Cryptographic Security: The scheme should be cryptographically secure and as such possess the following properties:
- 1) Preimage resistance
- 2) Second preimage resistance
- 3) collision resistance.
In addition it should avoid other cryptographic weaknesses such as those present in (some)Merkle-Damgård constructions(e.g. length extension attacks, partial message collisions, etc)
Defense against lookup table /TMTOAttacks:
- The scheme should aim to make TMTO attacks that allow for precomputed lookup table generation, such as Rainbow Tables, infeasible
Defense against CPU-optimized 'crackers':
- The scheme should be ‘CPU-hard’, that is, it should require significant amounts of CPU processing in a manner that cannot be optimized away through either software or hardware. As such, cracking-optimized (multi-core) CPU software implementations (eg. written in assembly, testing multiple input sets in parallel) should offer only minimal speed-up improvements compared to those intended for validation (“slower for attackers, faster for defenders”).
Defense against hardware-optimized 'crackers':
- The scheme should be 'memory-hard', that is, it should significant amounts of RAM capacity in a manner that cannot be optimized away through eg. TMTO attacks. As such cracking-optimized ASIC, FPGA and GPU implementations should offer only minimal speed up improvements (eg. in terms of time-area product) compared to those intended for validation. As noted by Aumasson one of the main scheme design challenges is ensuring minimized efficiency on GPUs, FPGAs and ASICs (in order to minimize benefits of cracking-optimized implementations) and maximized efficiency on general-purpose CPUs (in order to maintain regular use efficiency).
Defense against side-channel attacks:
- Depending on the use-case (eg. for key derivation or authentication to a device seeking to protect against modification by the device owner) side-channel attacks might be a relevant avenue of attack. Password hashing schemes should aim to offer side-channel resilience. With regards to password hashing scheme security we will focus on security versus the cache-timing type of side-channel attacks given the existence of such attacks against the commonly used scrypt scheme. The second category of side-channel attacks we will take into consideration are so-called Garbage Collector Attacks (GCAs). GCAs have been discussed in literature as an instance of a 'memory leak' attack relevant to password hashing scheme security. GCAs consist of a scenario where an attacker has access to a target machine's internal memory either after termination of the hashing scheme or at some point where the password itself is still present in memory (the so-called WeakGCA variant)...
edited 10 hours ago
Gilles
8,28732755
8,28732755
answered 12 hours ago
Ella Rose♦Ella Rose
16.9k44483
16.9k44483
1
$begingroup$
Nitpick: bcrypt is advertised as a password storage and verification function, not so much a key derivation function, and implementations routinely have APIs to match that (e.g., outputting text encoded output, providing an enroll/verify API instead of a hash API, That is not to claim that bcrypt couldn't be used as you suggest, but there are potential practical pitfalls. See, e.g., this article.
$endgroup$
– Luis Casillas
8 hours ago
2
$begingroup$
@LuisCasillas just a note: I actually didn't list bcrypt; that was inserted to my answer by Gilles via an edit...
$endgroup$
– Ella Rose♦
8 hours ago
$begingroup$
@LuisCasillas Argon2 was also the winner of the password hashing competition, not the password-based KDF competition. Is there any reason to believe that Argon2 is good for PBKDF that doesn't also apply to bcrypt?
$endgroup$
– Gilles
7 hours ago
$begingroup$
In conclusion taking the first 16bytes is fine if I use an Argon2 Hash?
$endgroup$
– firendlyQuestion
42 mins ago
add a comment |
1
$begingroup$
Nitpick: bcrypt is advertised as a password storage and verification function, not so much a key derivation function, and implementations routinely have APIs to match that (e.g., outputting text encoded output, providing an enroll/verify API instead of a hash API, That is not to claim that bcrypt couldn't be used as you suggest, but there are potential practical pitfalls. See, e.g., this article.
$endgroup$
– Luis Casillas
8 hours ago
2
$begingroup$
@LuisCasillas just a note: I actually didn't list bcrypt; that was inserted to my answer by Gilles via an edit...
$endgroup$
– Ella Rose♦
8 hours ago
$begingroup$
@LuisCasillas Argon2 was also the winner of the password hashing competition, not the password-based KDF competition. Is there any reason to believe that Argon2 is good for PBKDF that doesn't also apply to bcrypt?
$endgroup$
– Gilles
7 hours ago
$begingroup$
In conclusion taking the first 16bytes is fine if I use an Argon2 Hash?
$endgroup$
– firendlyQuestion
42 mins ago
1
1
$begingroup$
Nitpick: bcrypt is advertised as a password storage and verification function, not so much a key derivation function, and implementations routinely have APIs to match that (e.g., outputting text encoded output, providing an enroll/verify API instead of a hash API, That is not to claim that bcrypt couldn't be used as you suggest, but there are potential practical pitfalls. See, e.g., this article.
$endgroup$
– Luis Casillas
8 hours ago
$begingroup$
Nitpick: bcrypt is advertised as a password storage and verification function, not so much a key derivation function, and implementations routinely have APIs to match that (e.g., outputting text encoded output, providing an enroll/verify API instead of a hash API, That is not to claim that bcrypt couldn't be used as you suggest, but there are potential practical pitfalls. See, e.g., this article.
$endgroup$
– Luis Casillas
8 hours ago
2
2
$begingroup$
@LuisCasillas just a note: I actually didn't list bcrypt; that was inserted to my answer by Gilles via an edit...
$endgroup$
– Ella Rose♦
8 hours ago
$begingroup$
@LuisCasillas just a note: I actually didn't list bcrypt; that was inserted to my answer by Gilles via an edit...
$endgroup$
– Ella Rose♦
8 hours ago
$begingroup$
@LuisCasillas Argon2 was also the winner of the password hashing competition, not the password-based KDF competition. Is there any reason to believe that Argon2 is good for PBKDF that doesn't also apply to bcrypt?
$endgroup$
– Gilles
7 hours ago
$begingroup$
@LuisCasillas Argon2 was also the winner of the password hashing competition, not the password-based KDF competition. Is there any reason to believe that Argon2 is good for PBKDF that doesn't also apply to bcrypt?
$endgroup$
– Gilles
7 hours ago
$begingroup$
In conclusion taking the first 16bytes is fine if I use an Argon2 Hash?
$endgroup$
– firendlyQuestion
42 mins ago
$begingroup$
In conclusion taking the first 16bytes is fine if I use an Argon2 Hash?
$endgroup$
– firendlyQuestion
42 mins ago
add a comment |
firendlyQuestion is a new contributor. Be nice, and check out our Code of Conduct.
firendlyQuestion is a new contributor. Be nice, and check out our Code of Conduct.
firendlyQuestion is a new contributor. Be nice, and check out our Code of Conduct.
firendlyQuestion is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f68545%2faes-why-is-it-a-good-practice-to-use-only-the-first-16-bytes-of-a-hash-for-encr%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
I added the links
$endgroup$
– firendlyQuestion
12 hours ago
2
$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
12 hours ago
$begingroup$
Nowadays you should probably use HKDF with an appropriate hash.
$endgroup$
– jww
4 hours ago