Subject: Re: Sample Twofish message

From: [email-masked]
Date: Fri, 9 Apr 1999 09:24:19 -0700

Uri Blumenthal, <[email-masked]>, writes:

> Werner Koch says:
> > We use a 8 byte IV for encrypting the secret key material; see
> > section 5.5.3.  Do we keep this 8 bytes or extend it to the blocksize?
>
> IV length normally is equal to the block size. I see no reason to
> divert from this.

With regard to the secret key encryption:

The only real requirement on an IV is that it is unique for that key,
that it does not match any other IV's and it doesn't match any of the
ciphertext blocks which are used with that key.  For this purpose,
64 bits should be adequate unless we store more than 4 billion (2^32)
private keys using the same passphrase (and even then the unique salt
would save us).  So a 64 bit IV is plenty big.

However in the interests of convenience and consistency it would probably
make more sense to use the block size.  This avoids any ambiguities
about whether a shorter IV should be left or right justified and how
the remaining bits of the block should be filled in.

With regard to message encryption, the symmetrically encrypted data
packets:

The 8+2 bytes which precede the message are not technically an IV; the
IV is zero, and the 8+2 bytes are used in place of an IV to accomplish
the same purpose.  However this size does not work properly in the case
of 128 bit blocks.

If we had two messages encrypted with the same key, then for each of
them we would encrypt a block of zeros and XOR that with the first 16
bytes of the message, to form the ciphertext.  Only the first 10 bytes
are random; the remaining 6 are plaintext.  Therefore the last 6 bytes
of this first block of data would be the first 6 bytes of plaintext,
xored with a value which was the same for each encryption where that
same key was used.  This would allow an attacker to recover the XOR of
the first 6 bytes of the plaintexts of multiple messages, and possibly
therefore to find these 6 bytes of plaintext.

This is a serious leak.  We would possibly be saved by the fact that
the spec says to use salt in hashing the passphrase, so it is unlikely
that any two messages are encrypted with the same key even if the same
passphrase is used.  But still there is no reason to take this chance.

Therefore we should increase the 8 bytes to be the size of the block
cipher.

Several people have commented that they don't like the extra CFB sync
operation which is done after the first 8+2 (or now 16+2) bytes are read.
It is a nonstandard operation and requires special code in the CFB module.
I had suggested that we skip the CFB for larger blocks, on the theory
that we would eventually migrate to larger block ciphers throughout,
and then we could retire the CFB sync along with the support of 64 bit
block ciphers.  This would be perhaps four or five years from now.

It is not difficult to code the CFB sync to be optional based on
block size.  Can we consider keeping the language to use the extra
sync only for 64 bit block ciphers?

Hal Finney
NAI, Inc.

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 9 Apr 1999 14:29:12 -0400 (EDT)

> the remaining bits of the block should be filled in.

Exactly!

> the same purpose. However this size does not work properly in the case

In essence those 8+2 bytes *are* performing the function of IV. 

> [...description of a problem....] This is a serious leak.

Probably. (:-)

> .........But still there is no reason to take this chance.

(:-) My wish precisely!

> sync only for 64 bit block ciphers?

Probably. No strong preference either way.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Werner Koch <[email-masked]>
Date: Fri, 9 Apr 1999 20:30:24 +0200

> sync only for 64 bit block ciphers?

Yes.

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: Paul Koning <[email-masked]>
Date: Fri, 9 Apr 1999 16:30:12 -0400

>>>>> "Uri" == Uri Blumenthal <[email-masked]> writes:

 Uri> [email-masked] says:
 >> > IV length normally is equal to the block size. I see no reason
 >> to > divert from this.
 >> 
 >> With regard to the secret key encryption: The only real
 >> requirement on an IV is that it is unique for that key, that it
 >> does not match any other IV's and it doesn't match any of the
 >> 64 bits should be adequate unless we store more than 4 billion
 >> (2^32) private keys using the same passphrase (and even then the
 >> unique salt would save us).  So a 64 bit IV is plenty big.

 Uri> True. But:

 >> However in the interests of convenience and consistency it would
 >> probably make more sense to use the block size.  This avoids any
 >> ambiguities about whether a shorter IV should be left or right
 >> justified and how the remaining bits of the block should be filled
 >> in.

 Uri> Exactly!

I'm very hard pressed to see ANY valid argument for making an IV
smaller than the blocksize.  Even if it technically possible (which I
guess it is with CFB mode) it should not be done.  There is no benefit 
I can see, and a very clear issue: if you have a cypher with 128 bit
blocks, 128 bit strength, etc., what conceivable cryptographic merit
is there in introducing a 64 bit component into the puzzle?  Why go
through the process of analyzing the security implications and
demonstrating that there aren't any when there is no benefit to be
had?  Or of there is one, certainly not one that justifies months of
analysis? 

My impression from watching AES discussions is that weaknesses that
open up O(2^64) attacks of any kind are considered things to be
concerned about.  Not being an academically trained cryptographer I
may be reading too much into the discussion, but even so, that seems
like a logical position to take.

	paul