Subject: kcrypto vs randomness

From: Simon Josefsson <[email-masked]>
Date: Fri, 19 Sep 2003 01:05:25 +0200

Hello,

while studying IV carry in AES-CTS, I noticed that
draft-ietf-krb-wg-crypto-05 uses the word "random" several times, but
never discuss random number quality (nor reference RFC 1750).

Specifically: must the confounder be a cryptographically strong random
number?

If yes, I think a warning in the security consideration of kcrypto is
warranted, that the entropy source may be exhausted quickly if the
encryption scheme is used frequently.  Compare, e.g., Kerberos 5 'rsh'
that would waste 8 bytes of entropy for every character you type.

If no, it would be good to make that 'no' explicit, so that people
aren't forced to use strong random numbers as a conservative measure,
just because the specification is unclear.

I'm not sure which answer was originally intended, but could suggest
text once the answer is known.

Thanks.

(Btw, the revised kcrypto text look fine to me.)

---

From: Don Davis <[email-masked]>
Date: Sun, 21 Sep 2003 20:24:47 -0400

>  >>>>> "Don" == Don Davis <[email-masked]> writes:
>
>     Don> [please copy me explicitly on any replies or commentary,
>     Don> because i don't subscribe to the list].
>
>     Don> the confounder doesn't need to be truly random, nor
>     Don> even cryptographically random.  here's what _is_
>     Don> necessary in a confounder generator:
>
>     Don>    * if the generator repeats itself periodically,
>     Don> then the period should be very long, so that each
>     Don> confounder-&-message combination is effectively unique.
>     Don>    * similarly, similar bitstrings should be widely
>     Don> separated from one another, in the generator's output-
>     Don> sequence.  more precisely, it's bad if the Hamming
>     Don> distance between successive confounders is small, as
>     Don> happens with a counter.  (the Hamming distance between
>     Don> two strings is the number of bitwise differences
>     Don> between the strings.)
>
> Why is the second constraint true for an ideal block cipher?

if you're using an ideal cipher, i doubt that
either constraint is necessary.  but, the biham
& shamir differential cryptanalysis attack on
des was an example of the kind of attack that
bellovin mentioned.  recall that their attack
exploited the fact that any des key mill map
some pairs of low-hamming-distance plaintexts
to low-hamming-distance ciphertexts.  given
that des had this flaw despite having been so
extensively studied, it's best not to assume
that any real-world cipher reliably offers the
strong avalanche property.  so, it's best to
avoid encrypting two nearly-identical plaintexts
with the same key.

> If it is not true for an ideal block cipher but
> is true for practical block ciphers, what attack
> is easier?

i'm sorry, but i don't understand your question.

				- don davis. boston

-