Re: Unique Key vs. Initialization Vector ?

From: Gregory G Rose (ggr_at_qualcomm.com)
Date: 05/17/03 

Date: 17 May 2003 12:00:22 -0700

In article <968f09a.0305161614.76b9be4c@posting.google.com>,
John M. Dlugosz <john@dlugosz.com> wrote:
>Consider a block cipher (e.g. AES) in CBC or CFB mode.
>
>Would using a unique key for each message avoid the need for a unique
>IV for each message? Specifically, if the "main key" (to be used for
>several plaintexts) were used to generate a "derived key" using some
>salt (like a counter) and a hash of the main key, would it serve the
>same purpose as an IV, or would it still be missing something?
>
>I intend for the "salt" to be unique for the message, but not secret,
>just as an IV is not secret. This salt would use information already
>present in the larger context but not part of the plaintext, so doing
>this would not increase the message size.

For those modes, there is a requirement for the IV
to be random and unpredictable to an attacker.
What you're doing is using salt plus the secret
key to derive a per-message key, because the salt
is not "good enough" to meet these requirements.

Now, if the salt is ever allowed to repeat, You'd
have a problem. But you say it isn't, so that's
fine.

But if it doesn't repeat, then encrypting it using
the secret key yields something else non-repeating
that's unpredictable and random looking. That is,
it meets the requirements for a good IV.

So, my suggestion to you is that instead of
rekeying, just use the derived value as the IV,
without bothering to transmit it. Re-derive it at
the receiving end.

Your scheme has a very minor weakness compared to
my suggestion. Doing it my way guarantees a unique
IV per message. But hashing the key and salt to
create a session key allows collisions, so you
might send two messages encrypted using the same
"derived key", and if the messages had fixed
headers or something this would be identifiable
and might represent a weakness.

Greg. 

-- 
Greg Rose                                       INTERNET: ggr@qualcomm.com
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/ 
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

Relevant Pages

  • Re: Best Way To Randomize/Salt A Text String Before SHA256?
    ... secret, it's safe. ... while a computationally unbounded attacker can't get your ... For information-theoretic security, ... Let C = Fbe a commitment to message m with random salt s. ...
    (sci.crypt)
  • Re: Perl Script
    ... It won't help if the attacker has access ... Actually, IIRC, you just need a different salt for different users. ... What a salt protects against is someone pre-computing the md5 (or ... One may implement this as a secret salt, the same for all users, as Ted ...
    (comp.lang.perl.misc)
  • Re: Newbie Salt and Pass Phrase Question.
    ... I'll quote the standard on you, ... of a password, a salt, and an iteration count, where the latter ... two quantities need not be kept secret. ... expect non-secret information to be easily storable, ...
    (sci.crypt)
  • Unique Key vs. Initialization Vector ?
    ... Would using a unique key for each message avoid the need for a unique ... several plaintexts) were used to generate a "derived key" using some ... I intend for the "salt" to be unique for the message, but not secret, ...
    (sci.crypt)
  • Re: Rosen on Domingo
    ... Take that latest suggestion with a grain or ten of salt - it IS actually ... funny. ... hoarseness, vast amounts of convenient, face/ego-saving downward ...
    (rec.music.opera)
Quantcast