0
$\begingroup$

After some google research, I have found out the IV used in AES 256 bit encryption must be a 128 bit key.

My AES256 encryption is processed with key of random 256 bit key and IV generated of text string.

I am thinking about MD5 to generate such key, but MD5 seems outdated.

So Should it be okay if I use SHA256 generate a 256 bit key than split the hex string of the key equally into 2 parts and use the first part as an IV in AES 256 bit encryption?

$\endgroup$
5
  • 4
    $\begingroup$ NOOO!! IV is public and the key is secret! You gave the half of your secret! $\endgroup$
    – kelalaka
    Apr 11, 2022 at 11:22
  • $\begingroup$ could you please clarify it giving to who? I mean the key is complete random and the whole 256 bit IV is not stored only users know it, only to use half of it? $\endgroup$
    – Kim Mỹ
    Apr 11, 2022 at 11:33
  • 2
    $\begingroup$ You did not mention that. Anyway, use $IV = SHA256(key, random\; salt)$ to be on the safe side. IV is not meant to be secret... $\endgroup$
    – kelalaka
    Apr 11, 2022 at 11:39
  • $\begingroup$ Are you intending to encrypt more than one message with the same key (and thus, by your suggestion, the same IV)? If not, well, in CTR mode or GCM mode, that's completely broken (even with a secret IV); with CBC mode, that's not nearly as bad, but will leak whether the two messages share a common prefix (which is still more information than we'd like the adversary to have) $\endgroup$
    – poncho
    Apr 11, 2022 at 14:34
  • 1
    $\begingroup$ Beware, things like MD5 key creation / derivation and hexadecimal encoding of keys are big red flags. I see a lot of it on Stack Overflow, and in 99% of the cases it means that the users haven't got any clue what they are doing. $\endgroup$
    – Maarten Bodewes
    Apr 11, 2022 at 21:38

2 Answers 2

2
$\begingroup$

So Should it be okay if I use SHA256 generate a 256 bit key than split the hex string of the key equally into 2 parts and use the first part as an IV in AES 256 bit encryption?

No, there are better ways.

First of all, when you create a key you need a cryptographically secure random number generator. If you derive a key from a master secret - sometimes called a seed - you need a key derivation function or KDF. In the latter case you could e.g. use HKDF with a good hash such as SHA-256. In principle you can create e.g. 384 bits output using HKDF - even when using SHA-256, but I don't think that's a good idea, because of the following part of the answer.


Second, reusing a key / IV combination is not a good idea; depending on the mode and message you may leak just some data or all of the message.

In general you can just use an all zero IV if the key is randomly generated for each message. That would be better than reusing part of the key. As indicated, an IV is generally not thought to be secret, so if you use key data as IV implementations may well leak it.'

If you need to encrypt multiple messages with the same key then you could use a synthetic IV or SIV. That way you would only leak data if messages are completely identical, at the cost of some performance, as SIV modes are multi-pass (messages need to be processed twice).

In general though you should just use a randomized IV and send it with the ciphertext. It isn't clear from the question if that has been considered; it would be the most common way of handling the IV generation.


Finally, keys are not alphanumerical; they consist of bits. Each time when a key is translated into text you are opening a security issue. So don't do that: keep keys binary. I'd rather use AES-128 with a fully random key and use the other 128 bits for the IV than revert to using hexadecimals.

Hexadecimals are only useful for human consumption, e.g. during testing or debugging when it comes to secret keys.

$\endgroup$
0
$\begingroup$

I assume you do not reveal this IV. Depends on what you want and what mode you use. IV for AES should be 128 bits for modes like OFB, CBC or CFB but it is usually shorter for modes like CTR or its authenticated variants where the most common way of creating block used to generate the stream would be concatenation of IV (nonce) and counter. There can be many problems with using part of key as IV:

I for once know no huge inherent security risk associated with revealing $E_k(k_{0..|k|/2})$ or $E_k(k_{0..|k|/2} \oplus P)$ or $E_k(k_{0..m} || ctr)$ for some known message $P$ for full AES (Please correct be if I am wrong). These are functions that you might see depending on modes used. Actual usage however may be insecure.

  1. Essentially makes your encryption deterministic. So it does not fully hide the message. For modes like CBC or CFB you can detect common prefixes (full block prefixes in the message). For CFB, this can also allow you to deduce relationship between plain texts corresponding to the first divergent blocks, specifically $P_{1_i} \oplus P_{2_i}$ where the cipher texts diverge at $i^{th}$ block. For modes like CTR or OFB, it can be devastating if you ever reuse the key, you can deduce the xor relationship for the entire plain text for those two. This problem persists even if you use MD5 for IV. Hence, it makes it very unsuitable for reuse, even accidently which is easier said than done.

  2. In some protocols if an attacker finds a way to obtain $E_k(k_{0..|k|/2})$ e.g by tricking into encrypting $0^{|k|}$ in CBC mode and then tricking them into encrypting $p_i||c_{i}$ where he had obtained $c_{i}$ from previous interaction in order to reveal $E_k(0^{|k|})$, he might trick them into revealing half of the key by asking to decrypt $E_k(0^{|k|})$. This is not my original idea so I suggest you see fgrieu 's answer on Here, see drawback 2.

  3. It may be secure to use it if you don't reuse the key or in other similar protocols. For modes like CBC or even ECB with some high entropy (random) messages with no known structure may be OK as well in case you use more than once.

$\endgroup$
7
  • $\begingroup$ "I assume you do not reveal this IV." That assumption is bad. The security analyses of all common AES modes assume a public IV. So you'd have to invent a new mode with a secret IV, and have to ensure it's protected (existing libraries make no effort to hide the IV). That means adding side-channel resistance to the IV handling. It's far harder than just using a hash or KDF on the key, or better yet SIV mode. $\endgroup$ Apr 11, 2022 at 12:11
  • $\begingroup$ @SAIPeregrinus According to OP's question IV is part of the key, so I assumed that is what OP wanted $\endgroup$ Apr 11, 2022 at 12:12
  • 1
    $\begingroup$ Yes, but IV is public by definition. So no software libraries make any attempt to hide it, it gets prepended to the ciphertext output for most! So the question boils down to "what if I leak half the secret key to attackers". $\endgroup$ Apr 11, 2022 at 14:04
  • $\begingroup$ For ECB mode, we typically don't worry that much about the IV... :-) $\endgroup$
    – poncho
    Apr 11, 2022 at 14:37
  • $\begingroup$ thank you all! If IV is meant to be public and prepended to the encrypted output meaning I should swap IV as key and key as IV? $\endgroup$
    – Kim Mỹ
    Apr 11, 2022 at 18:04

Your Answer

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

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