Prev: Advantages of digital signatures over MACs?
Next: Does entropy ever fall out of a good hash function?
From: mark on 28 Feb 2010 14:32
I understand that using the same key all the time is a bad thing,
since if that key is discovered, it would be considered a total
break. However, why should you *never* reuse a stream cipher's key?
From: unruh on 28 Feb 2010 14:42
On 2010-02-28, mark <cheesemonkey22(a)gmail.com> wrote:
> I understand that using the same key all the time is a bad thing,
> since if that key is discovered, it would be considered a total
> break. However, why should you *never* reuse a stream cipher's key?

for the same reason you should never reuse a OTP key. If you have the
same stream twice, you can xor the two encrypted messages and what you
have is the xor of the two cleartexts. Since the cleartext usually has
lots of redundancy, one can use that to discover both messages.
You can simply lengthen your key be adding something ( eg a count) to
the key each time

1bugsbunny
2bugsbunny
3bugsbunny
etc.
That of course means you have to have some way of keeping track of your
keys.

From: Scott Fluhrer on 28 Feb 2010 22:45

"unruh" <unruh(a)wormhole.physics.ubc.ca> wrote in message
news:slrnholhp5.p9m.unruh(a)wormhole.physics.ubc.ca...
> On 2010-02-28, mark <cheesemonkey22(a)gmail.com> wrote:
>> I understand that using the same key all the time is a bad thing,
>> since if that key is discovered, it would be considered a total
>> break. However, why should you *never* reuse a stream cipher's key?
>
> for the same reason you should never reuse a OTP key. If you have the
> same stream twice, you can xor the two encrypted messages and what you
> have is the xor of the two cleartexts. Since the cleartext usually has
> lots of redundancy, one can use that to discover both messages.
> You can simply lengthen your key be adding something ( eg a count) to
> the key each time
>
> 1bugsbunny
> 2bugsbunny
> 3bugsbunny
> etc.

Actually, depending on the stream cipher, that's a *bad* idea. For example,
we know how to break RC4 (that is, recover the keys) in exactly this
scenario.

Because of this, it might make more sense (for any stream cipher) to make
sure that the keys are unrelated by hashing the related keys, as in:

SHA("1bugsbunny")
SHA("2bugsbunny")
SHA("3bugsbunny")
etc. (and for your favorite flavor of SHA)

--
poncho


From: Ivan Voras on 1 Mar 2010 09:50
On 02/28/10 20:32, mark wrote:
> I understand that using the same key all the time is a bad thing,
> since if that key is discovered, it would be considered a total
> break. However, why should you *never* reuse a stream cipher's key?

Everything said by others on this so far is correct, but I would only
add that this problem is not an intrinsic property of a "stream cipher"
in general but just of most (all?) of the currently frequently used ones.

These ciphers typically generate a stream of pseudo-random numbers
depending on the input password which is XOR-ed with the plaintext to
create the ciphertext. The property of the XOR operations is that two
ciphertexts with the same keystream can be XORed to get the XOR of the
plaintexts, from which you are an XOR or two away from the keystream and
any plaintext.

There are more complex types of stream ciphers which don't work like
that, but AFAIK they are generally slow.
From: Tom St Denis on 1 Mar 2010 10:08
On Mar 1, 9:50 am, Ivan Voras <ivo...(a)fer.hr> wrote:
> On 02/28/10 20:32, mark wrote:
>
> > I understand that using the same key all the time is a bad thing,
> > since if that key is discovered, it would be considered a total
> > break.  However, why should you *never* reuse a stream cipher's key?
>
> Everything said by others on this so far is correct, but I would only
> add that this problem is not an intrinsic property of a "stream cipher"
> in general but just of most (all?) of the currently frequently used ones.
>
> These ciphers typically generate a stream of pseudo-random numbers
> depending on the input password which is XOR-ed with the plaintext to
> create the ciphertext. The property of the XOR operations is that two
> ciphertexts with the same keystream can be XORed to get the XOR of the
> plaintexts, from which you are an XOR or two away from the keystream and
> any plaintext.
>
> There are more complex types of stream ciphers which don't work like
> that, but AFAIK they are generally slow.

Well CTR mode is a stream cipher and you can easily re-use the key
there provided you never re-use the IVs.

Though, yes, for different sessions, even from the same master key
[e.g. a password or whatever] it's ideal to use a salt and a PRF to
derive a session key regardless of the cipher or its mode.

Tom
 |  Next  |  Last
Pages: 1 2
Prev: Advantages of digital signatures over MACs?
Next: Does entropy ever fall out of a good hash function?