Skip to main content
IV instead of master key
Source Link
LightBit
  • 1.7k
  • 13
  • 27

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 allhalf zeros (orand with half of IV or with half of master keyor 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(k_{master}) || counter_i)$$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.

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 all zeros (or 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(k_{master}) || 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.

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.

deleted 2 characters in body
Source Link
LightBit
  • 1.7k
  • 13
  • 27

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 all zeros (or with half of IV or with half of originalmaster 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(k_{master}) || 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.

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 all zeros (or with half of IV or with half of original 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(k_{master}) || 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.

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 all zeros (or 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(k_{master}) || 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.

added 4 characters in body
Source Link
LightBit
  • 1.7k
  • 13
  • 27

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 all zeros (or with half of IV or with half of original key to make multi-target attacks harder).

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

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

$keystream = E_{k_{data}}(half(k_{master}) || counter)$$keystream_i = E_{k_{data}}(half(k_{master}) || 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.

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 all zeros (or with half of IV or with half of original key to make multi-target attacks harder).

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

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

$keystream = E_{k_{data}}(half(k_{master}) || counter)$

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.

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 all zeros (or with half of IV or with half of original 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(k_{master}) || 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.

better explaination
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
better explaination
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
explain kdf better
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
add link
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
typo
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
added 35 characters in body
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
edited tags
Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
added 24 characters in body
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
edited tags
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading
Source Link
LightBit
  • 1.7k
  • 13
  • 27
Loading