AES: Why is it a good practice to use only the first 16bytes 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?

In a Spin are Both Wings Stalled?

Fully-Firstable Anagram Sets

I'm flying to France today and my passport expires in less than 2 months

Emailing HOD to enhance faculty application

I Accidentally Deleted a Stock Terminal Theme

Forgetting the musical notes while performing in concert

Is "remove commented out code" correct English?

Watching something be written to a file live with tail

In Romance of the Three Kingdoms why do people still use bamboo sticks when papers are already invented?

What's the difference between 'rename' and 'mv'?

How can I prevent hyper evolved versions of regular creatures from wiping out their cousins?

Is it unprofessional to ask if a job posting on GlassDoor is real?

What exploit are these user agents trying to use?

Can a rocket refuel on Mars from water?

What's the point of deactivating Num Lock on login screens?

UK: Is there precedent for the governments e-petition site changing the direction of a government decision?

If a Gelatinous Cube takes up the entire space of a Pit Trap, what happens when a creature falls into the trap but succeeds on the saving throw?

How much of data wrangling is a data scientist's job?

Could gravitational lensing be used to protect a spaceship from a laser?

intersection of two sorted vectors in C++

SSH "lag" in LAN on some machines, mixed distros

What to put in ESTA if staying in US for a few days before going on to Canada

If human space travel is limited by the G force vulnerability, is there a way to counter G forces?

Can one be a co-translator of a book, if he does not know the language that the book is translated into?



AES: Why is it a good practice to use only the first 16bytes 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?













5












$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 pw with sha1 and take only the first 16bytes.



But I don't think this can be a good pratice.



  1. sha1 is weak

  2. taking only the first 16bytes 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/









share|improve this question









New contributor




firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$











  • $begingroup$
    I added the links
    $endgroup$
    – firendlyQuestion
    6 hours ago






  • 2




    $begingroup$
    They are not good sources. Anyway I will call this question as dupe of this and this
    $endgroup$
    – kelalaka
    6 hours ago















5












$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 pw with sha1 and take only the first 16bytes.



But I don't think this can be a good pratice.



  1. sha1 is weak

  2. taking only the first 16bytes 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/









share|improve this question









New contributor




firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$











  • $begingroup$
    I added the links
    $endgroup$
    – firendlyQuestion
    6 hours ago






  • 2




    $begingroup$
    They are not good sources. Anyway I will call this question as dupe of this and this
    $endgroup$
    – kelalaka
    6 hours ago













5












5








5


1



$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 pw with sha1 and take only the first 16bytes.



But I don't think this can be a good pratice.



  1. sha1 is weak

  2. taking only the first 16bytes 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/









share|improve this question









New contributor




firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$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 pw with sha1 and take only the first 16bytes.



But I don't think this can be a good pratice.



  1. sha1 is weak

  2. taking only the first 16bytes 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






share|improve this question









New contributor




firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 6 hours ago







firendlyQuestion













New contributor




firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 7 hours ago









firendlyQuestionfirendlyQuestion

262




262




New contributor




firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






firendlyQuestion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • $begingroup$
    I added the links
    $endgroup$
    – firendlyQuestion
    6 hours ago






  • 2




    $begingroup$
    They are not good sources. Anyway I will call this question as dupe of this and this
    $endgroup$
    – kelalaka
    6 hours ago
















  • $begingroup$
    I added the links
    $endgroup$
    – firendlyQuestion
    6 hours ago






  • 2




    $begingroup$
    They are not good sources. Anyway I will call this question as dupe of this and this
    $endgroup$
    – kelalaka
    6 hours ago















$begingroup$
I added the links
$endgroup$
– firendlyQuestion
6 hours ago




$begingroup$
I added the links
$endgroup$
– firendlyQuestion
6 hours ago




2




2




$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
6 hours ago




$begingroup$
They are not good sources. Anyway I will call this question as dupe of this and this
$endgroup$
– kelalaka
6 hours ago










1 Answer
1






active

oldest

votes


















8












$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)...






share|improve this answer











$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
    3 hours ago






  • 1




    $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
    2 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
    1 hour ago











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.









draft saved

draft discarded


















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-16bytes-of-a-hash-for-encry%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









8












$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)...






share|improve this answer











$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
    3 hours ago






  • 1




    $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
    2 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
    1 hour ago















8












$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)...






share|improve this answer











$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
    3 hours ago






  • 1




    $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
    2 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
    1 hour ago













8












8








8





$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)...






share|improve this answer











$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)...







share|improve this answer














share|improve this answer



share|improve this answer








edited 4 hours ago









Gilles

8,28732755




8,28732755










answered 6 hours ago









Ella RoseElla Rose

16.8k44482




16.8k44482







  • 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
    3 hours ago






  • 1




    $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
    2 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
    1 hour ago












  • 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
    3 hours ago






  • 1




    $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
    2 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
    1 hour 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
3 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
3 hours ago




1




1




$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
2 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
2 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
1 hour 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
1 hour ago










firendlyQuestion is a new contributor. Be nice, and check out our Code of Conduct.









draft saved

draft discarded


















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.




draft saved


draft discarded














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-16bytes-of-a-hash-for-encry%23new-answer', 'question_page');

);

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







Popular posts from this blog

Францішак Багушэвіч Змест Сям'я | Біяграфія | Творчасць | Мова Багушэвіча | Ацэнкі дзейнасці | Цікавыя факты | Спадчына | Выбраная бібліяграфія | Ушанаванне памяці | У філатэліі | Зноскі | Літаратура | Спасылкі | НавігацыяЛяхоўскі У. Рупіўся дзеля Бога і людзей: Жыццёвы шлях Лявона Вітан-Дубейкаўскага // Вольскі і Памідораў з песняй пра немца Адвакат, паэт, народны заступнік Ашмянскі веснікВ Минске появится площадь Богушевича и улица Сырокомли, Белорусская деловая газета, 19 июля 2001 г.Айцец беларускай нацыянальнай ідэі паўстаў у бронзе Сяргей Аляксандравіч Адашкевіч (1918, Мінск). 80-я гады. Бюст «Францішак Багушэвіч».Яўген Мікалаевіч Ціхановіч. «Партрэт Францішка Багушэвіча»Мікола Мікалаевіч Купава. «Партрэт зачынальніка новай беларускай літаратуры Францішка Багушэвіча»Уладзімір Іванавіч Мелехаў. На помніку «Змагарам за родную мову» Барэльеф «Францішак Багушэвіч»Памяць пра Багушэвіча на Віленшчыне Страчаная сталіца. Беларускія шыльды на вуліцах Вільні«Krynica». Ideologia i przywódcy białoruskiego katolicyzmuФранцішак БагушэвічТворы на knihi.comТворы Францішка Багушэвіча на bellib.byСодаль Уладзімір. Францішак Багушэвіч на Лідчыне;Луцкевіч Антон. Жыцьцё і творчасьць Фр. Багушэвіча ў успамінах ягоных сучасьнікаў // Запісы Беларускага Навуковага таварыства. Вільня, 1938. Сшытак 1. С. 16-34.Большая российская1188761710000 0000 5537 633Xn9209310021619551927869394п

Беларусь Змест Назва Гісторыя Геаграфія Сімволіка Дзяржаўны лад Палітычныя партыі Міжнароднае становішча і знешняя палітыка Адміністрацыйны падзел Насельніцтва Эканоміка Культура і грамадства Сацыяльная сфера Узброеныя сілы Заўвагі Літаратура Спасылкі НавігацыяHGЯOiТоп-2011 г. (па версіі ej.by)Топ-2013 г. (па версіі ej.by)Топ-2016 г. (па версіі ej.by)Топ-2017 г. (па версіі ej.by)Нацыянальны статыстычны камітэт Рэспублікі БеларусьШчыльнасць насельніцтва па краінахhttp://naviny.by/rubrics/society/2011/09/16/ic_articles_116_175144/А. Калечыц, У. Ксяндзоў. Спробы засялення краю неандэртальскім чалавекам.І ў Менску былі мамантыА. Калечыц, У. Ксяндзоў. Старажытны каменны век (палеаліт). Першапачатковае засяленне тэрыторыіГ. Штыхаў. Балты і славяне ў VI—VIII стст.М. Клімаў. Полацкае княства ў IX—XI стст.Г. Штыхаў, В. Ляўко. Палітычная гісторыя Полацкай зямліГ. Штыхаў. Дзяржаўны лад у землях-княствахГ. Штыхаў. Дзяржаўны лад у землях-княствахБеларускія землі ў складзе Вялікага Княства ЛітоўскагаЛюблінская унія 1569 г."The Early Stages of Independence"Zapomniane prawdy25 гадоў таму было аб'яўлена, што Язэп Пілсудскі — беларус (фота)Наша вадаДакументы ЧАЭС: Забруджванне тэрыторыі Беларусі « ЧАЭС Зона адчужэнняСведения о политических партиях, зарегистрированных в Республике Беларусь // Министерство юстиции Республики БеларусьСтатыстычны бюлетэнь „Полаўзроставая структура насельніцтва Рэспублікі Беларусь на 1 студзеня 2012 года і сярэднегадовая колькасць насельніцтва за 2011 год“Индекс человеческого развития Беларуси — не было бы нижеБеларусь занимает первое место в СНГ по индексу развития с учетом гендерного факцёраНацыянальны статыстычны камітэт Рэспублікі БеларусьКанстытуцыя РБ. Артыкул 17Трансфармацыйныя задачы БеларусіВыйсце з крызісу — далейшае рэфармаванне Беларускі рубель — сусветны лідар па дэвальвацыяхПра змену коштаў у кастрычніку 2011 г.Бядней за беларусаў у СНД толькі таджыкіСярэдні заробак у верасні дасягнуў 2,26 мільёна рублёўЭканомікаГаласуем за ТОП-100 беларускай прозыСучасныя беларускія мастакіАрхитектура Беларуси BELARUS.BYА. Каханоўскі. Культура Беларусі ўсярэдзіне XVII—XVIII ст.Анталогія беларускай народнай песні, гуказапісы спеваўБеларускія Музычныя IнструментыБеларускі рок, які мы страцілі. Топ-10 гуртоў«Мясцовы час» — нязгаслая легенда беларускай рок-музыкіСЯРГЕЙ БУДКІН. МЫ НЯ ЗНАЕМ СВАЁЙ МУЗЫКІМ. А. Каладзінскі. НАРОДНЫ ТЭАТРМагнацкія культурныя цэнтрыПублічная дыскусія «Беларуская новая пьеса: без беларускай мовы ці беларуская?»Беларускія драматургі па-ранейшаму лепш ставяцца за мяжой, чым на радзіме«Працэс незалежнага кіно пайшоў, і дзяржаву турбуе яго непадкантрольнасць»Беларускія філосафы ў пошуках прасторыВсе идём в библиотекуАрхіваванаАб Нацыянальнай праграме даследавання і выкарыстання касмічнай прасторы ў мірных мэтах на 2008—2012 гадыУ космас — разам.У суседнім з Барысаўскім раёне пабудуюць Камандна-вымяральны пунктСвяты і абрады беларусаў«Мірныя бульбашы з малой краіны» — 5 непраўдзівых стэрэатыпаў пра БеларусьМ. Раманюк. Беларускае народнае адзеннеУ Беларусі скарачаецца колькасць злачынстваўЛукашэнка незадаволены мінскімі ўладамі Крадзяжы складаюць у Мінску каля 70% злачынстваў Узровень злачыннасці ў Мінскай вобласці — адзін з самых высокіх у краіне Генпракуратура аналізуе стан са злачыннасцю ў Беларусі па каэфіцыенце злачыннасці У Беларусі стабілізавалася крымінагеннае становішча, лічыць генпракурорЗамежнікі сталі здзяйсняць у Беларусі больш злачынстваўМУС Беларусі турбуе рост рэцыдыўнай злачыннасціЯ з ЖЭСа. Дазволіце вас абкрасці! Рэйтынг усіх службаў і падраздзяленняў ГУУС Мінгарвыканкама вырасАб КДБ РБГісторыя Аператыўна-аналітычнага цэнтра РБГісторыя ДКФРТаможняagentura.ruБеларусьBelarus.by — Афіцыйны сайт Рэспублікі БеларусьСайт урада БеларусіRadzima.org — Збор архітэктурных помнікаў, гісторыя Беларусі«Глобус Беларуси»Гербы и флаги БеларусиАсаблівасці каменнага веку на БеларусіА. Калечыц, У. Ксяндзоў. Старажытны каменны век (палеаліт). Першапачатковае засяленне тэрыторыіУ. Ксяндзоў. Сярэдні каменны век (мезаліт). Засяленне краю плямёнамі паляўнічых, рыбакоў і збіральнікаўА. Калечыц, М. Чарняўскі. Плямёны на тэрыторыі Беларусі ў новым каменным веку (неаліце)А. Калечыц, У. Ксяндзоў, М. Чарняўскі. Гаспадарчыя заняткі ў каменным векуЭ. Зайкоўскі. Духоўная культура ў каменным векуАсаблівасці бронзавага веку на БеларусіФарміраванне супольнасцей ранняга перыяду бронзавага векуФотографии БеларусиРоля беларускіх зямель ва ўтварэнні і ўмацаванні ВКЛВ. Фадзеева. З гісторыі развіцця беларускай народнай вышыўкіDMOZGran catalanaБольшая российскаяBritannica (анлайн)Швейцарскі гістарычны15325917611952699xDA123282154079143-90000 0001 2171 2080n9112870100577502ge128882171858027501086026362074122714179пппппп

ValueError: Expected n_neighbors <= n_samples, but n_samples = 1, n_neighbors = 6 (SMOTE) The 2019 Stack Overflow Developer Survey Results Are InCan SMOTE be applied over sequence of words (sentences)?ValueError when doing validation with random forestsSMOTE and multi class oversamplingLogic behind SMOTE-NC?ValueError: Error when checking target: expected dense_1 to have shape (7,) but got array with shape (1,)SmoteBoost: Should SMOTE be ran individually for each iteration/tree in the boosting?solving multi-class imbalance classification using smote and OSSUsing SMOTE for Synthetic Data generation to improve performance on unbalanced dataproblem of entry format for a simple model in KerasSVM SMOTE fit_resample() function runs forever with no result