3

I am using AES128 in CBC mode, and I need a 16-byte key, so I was wondering if using sha2 or sha3 and then truncating it to 16 bytes (take first 16 bytes from the left) would make sha2/sha3 weaker than crc32 which gives me 16 bytes out of the box.

kelalaka
  • 5,064
  • 5
  • 27
  • 44
NS studios
  • 149
  • 14
  • 2
    But crc32 gives you 32 bits (4 bytes), surely? If you need to convert data into a fixed-length key, use a key derivation function (e.g., [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) – r3mainer Nov 04 '20 at 21:51
  • Flagging this to be moved to crypto.stackexchange.com, where it belongs. I can't find a close-enough duplicate there. – Rob Napier Nov 04 '20 at 22:09
  • This is not an answerable question since how you derive key? Is it a password, is it randomly generated? What is the input to CRC or SHAx? Do you have limited space in your environment? What about your IV? Your question is not clear at all. – kelalaka Nov 05 '20 at 08:45
  • @r3mainer I use UTF8 so that might have something to do with it perhaps? – NS studios Nov 05 '20 at 08:59
  • @kelalaka I mean regardless of the input (say the input was even abcd ), would truncating sha2/3 to 16 bytes be more secure than using crc32. – NS studios Nov 05 '20 at 09:03
  • That is what we call, small input space, Even the secure hashes are not safe. [Secure hashing when the input comes from a small space](https://crypto.stackexchange.com/q/61694/18298) [Is it easy to crack a hashed phone number?](https://crypto.stackexchange.com/a/81652/18298). Next time write all your parameters and your actual aim... – kelalaka Nov 05 '20 at 09:17
  • What is your system, aim it not clear from here. Why don't you use DHKE if this is end-to-end? If this is file storage why don't you use passwords generated with dicewire method, etc.... – kelalaka Nov 05 '20 at 09:21
  • @kelalaka I was just trying to encrypt data like sounds for a game with aes 128, and was just wondering if using only 16 bytes of hashed password-like key with sha2/3 was a more secure solution than using a whole crc32 output instead. I've never worked with any of the other methods you mentioned... – NS studios Nov 05 '20 at 09:28
  • If the key is uniform randomly generated there is no need for the PBKDF2 or HKDF or SHAx, just use the key. This type questions asked many times around. Could you search it a little? You will still need an IV for CBC... – kelalaka Nov 05 '20 at 09:52
  • @r3mainer If you would apply PBKDF2 on the output of CRC32 you end up with 2^32 different keys. The key itself may be longer but if you know the PBKDF2 parameters you can simply generate all possible keys. How much time this costs depends on the PBKDF2 iteration count, but if each key takes a few seconds you can parallelize it and still generate all keys within reasonable time. – Robert Nov 05 '20 at 12:53
  • @Robert I never suggested doing anything of the sort, but yes, you're correct. – r3mainer Nov 05 '20 at 16:07
  • @r3mainer If I read your first comment you start speaking about CRC32 and it's output length and then you mention that you can use PBKDF2 to enlarge it. If the second sentence does not reference the output of CRC32 then this is not not obvious for a reader. – Robert Nov 05 '20 at 16:11
  • @Robert Not obvious to you, apparently. I was merely remarking that a CRC32 checksum is 32 bits, not 128 as claimed by the OP. – r3mainer Nov 05 '20 at 23:11

2 Answers2

3

Each bit of a cryptographically secure hash is effectively random (i.e. independent of all the other bits). This is not true of non-cryptographic hashes. This property is critical for a secure key. You should always use a cryptographic hash for key derivation.

Truncating a long secure hash is a perfectly acceptable way to create a secure hash of shorter length. You may also select any subset of bits rather than just the most significant or least significant. If this weren't true, then the original hash would not itself be secure, because it would suggest some non-randomness in the output.

SHA-2 and SHA-3 intend to be cryptographically secure hashes (and at this point, we believe they are). CRC does not even intend to be cryptographically secure.

If the input key material is not itself random, then a fast hash like the SHA series may be subject to brute force. If so, then you need to use key stretching as well as hashing, for example with PBKDF2.

But you should never use CRC for any of this. It is not intended to be a secure hash.

For more discussion, see Should I use the first or last bits from a SHA-256 hash? and “SHA-256” vs “any 256 bits of SHA-512”, which is more secure?

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • The 2. paragraph need not be true in all of the cases. Actually, this question is not answerable correctly since the input of the CRC/SHAx is not known, – kelalaka Nov 05 '20 at 08:48
2

I am using AES128 in CBC mode, and I need a 16-byte key, so I was wondering if using sha2 or sha3 and then truncating it to 16 bytes (take first 16 bytes from the left) would make sha2/sha3 weaker than crc32 which gives me 16 bytes out of the box.

The question was not clear about how the input to the CRC or SHAx is generated. The OP cleared more. So, I've provided the answer below parts;

I mean regardless of the input (say the input was even abcd ), would truncating sha2/3 to 16 bytes be more secure than using crc32.

First of all, forget CRC, it is not a cryptographical hash function, forget it.

When the input space is small, there is a special case of the pre-image attack of the hash functions. The attacker can try all possible combinations to generate the key. You can read more details in this Cryptography.SE Q/A

Forgot about the small input space!, the entities like BitCoin Miner or SuperComputer like Summit Can reach 2^64 very easily. Which simply says the 8-byte.

One should generate a strong password like the dicewire or Bip-39. This will provide you easy to remember and strong passwords. See also XKCD

Once you generated a good password, then you can pass it to the poor man's KDF1, to better use HKDF. Since your input material is good you can skip the expand part of the HKDF. You can also use the Password-based Key derivation functions like Scrypt, PBKDF2, and Argon2. In this case, choose the Argon2 since it was the winner of the Password Hashing Competition in July 2015.

I was just trying to encrypt data like sounds for a game with AES 128, and was just wondering if using only 16 bytes of the hashed password-like key with sha2/3 was a more secure solution than using a whole crc32 output instead. I've never worked with any of the other methods you mentioned...

For the proper use of CBC mode, you need a nonce, too. You can use HKDF or PBKDF2, Argon2, etc with different info/nonce to derive the nonce, too. This is very common.

Note those about CBC;

  • The nonce must be unique under the same key, i.e (Key,IV) pair must be used once
  • CBC IV must be unpredictable, however, as far as I can see this is not your case
  • CBC is vulnerable to padding oracle attacks on the server-side. This is not possible in your case, too.
  • CBC mode can only provide CPA security, there is no integrity and authentication. To provide integrity and authentication either use HMAC with a different key, or use the combined modes.
  • Use Authenticated Encryption With Associated Data mode of encryptions like AES-GCM and ChaCha20-Poly1305. Correctly using the GCM may be hard, better use ChaCha20-poly1305 or xChaCha20-poly1305 for better nonce random generations.
kelalaka
  • 5,064
  • 5
  • 27
  • 44