2
$\begingroup$

Problem:

I'm slightly worried about counter repeats in CTR mode when using random IV.

  • If you split it (like half IV, half counter), it increases chances of same IV (it is smaller) and limits message length (if less than half).
  • If you start with full block IV, counters may overlap.

I would like to somehow get full block IV and half block counter without overlaps.

Proposed solution:

Instead of using random IV as nonce in counter we create new key by encrypting IV with key. We than use that new key for encryption. Counter starts with half zeros and with half of IV or with half of master key to make multi-target attacks harder.

Assume that key, IV, block cipher are all same size.

$k_{data} = E_{k_{master}}(IV)$

$keystream_i = E_{k_{data}}(half(IV) || counter_i)$

Is this any better/worse?

I'm worried this would weaken the key. Different key and IV combination would give same new key. But this is essentially like simple key derivation function with salt. This should allow every message to get up to birthday bound.

Improve this question
$\endgroup$
7
  • 1
    $\begingroup$ There is already a guideline counter/LFSR NIST 800-38-a and AES CTR: Random IV $\endgroup$
    – kelalaka
    Commented Jul 12, 2021 at 21:33
  • $\begingroup$ First approach is perfect, but not practical. Second approach with random IV is kinda limited to number of messages or length of messages as mentioned. $\endgroup$
    – LightBit
    Commented Jul 13, 2021 at 6:37
  • 1
    $\begingroup$ I think it is best to think of your construct as a KBKDF. In that case the question becomes: how secure is that KDF? But there are several things unclear to me. If you write $k = E_k(IV)$, do you mean that $k$ will be replaced? In that case you've created a stateful protocol. Normally you'd have a $k_{master}$ and multiple $k_{data}$. Furthermore, should we always assume 128 bit AES? A single block encrypt is not going to generate a 192 or 256 bit key. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 15, 2021 at 7:34
  • 1
    $\begingroup$ Key is replaced only for a message. It does not change master key. I do assume that key is the same size as block cipher. $\endgroup$
    – LightBit
    Commented Jul 15, 2021 at 7:48
  • $\begingroup$ I don't know where that $half(k_{master})$ suddenly comes from, but generally you'd never include key information in your key stream. If I remember correctly you first just had a zero based counter. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 15, 2021 at 9:51

1 Answer 1

Reset to default
-1
$\begingroup$

If you can say there's a limit on the amount of data that gets encrypted in a single stream, you can split the IV into a random part and a counter part (e.g. 64 bits of random, generated once per stream) and the counter part (starting at 0). You can split it anyway you want, you just need to worry about the birthday problem for the random size.

Or just use a different key for each stream and start the counter at 0. Never need to worry about overlap in that situation.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Yes, but in that case with 64-bit random IV are kinda small. As described here: crypto.stackexchange.com/questions/1849/… $\endgroup$
    – LightBit
    Commented Jul 12, 2021 at 16:55
  • $\begingroup$ Do you think my proposed solution (deriving key from random IV) is as good as using different key for each stream? $\endgroup$
    – LightBit
    Commented Jul 12, 2021 at 17:01
  • $\begingroup$ @LightBit If you're running into the problem they're talking about you've got other bigger problems already. There's research that suggests that CTR mode is kind of leaky and you should be only encrypting as much data with ONE KEY as you do with CBC mode, which for me is around 64 GB (depending on how long you want to keep the data). That's way less data than they're considering. $\endgroup$
    – Swashbuckler
    Commented Jul 13, 2021 at 15:49
  • $\begingroup$ As for deriving a key from a random IV, I wouldn't. The IV is not a secret, the key needs to be secret. If you used a fixed process for deriving the key from the IV then an attacker can repeat that process and get the key. $\endgroup$
    – Swashbuckler
    Commented Jul 13, 2021 at 15:49
  • $\begingroup$ To derive key from IV I would encrypt it with master key. So derived key would be secret. $\endgroup$
    – LightBit
    Commented Jul 13, 2021 at 16:15

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.