Subject: Re: Sample Twofish message

From: [email-masked]
Date: Fri, 9 Apr 1999 10:02:52 -0700

Werner Koch, <[email-masked]>, writes:
> Uri Blumenthal <[email-masked]> writes:
> > IV length normally is equal to the block size. I see no reason to
> > divert from this.
>
> Actually it is not the IV (which is always zero) but the random bytes 
> prepended to the plaintext.  However I think you are right and we
> should agree to use an IV of the blocksize instead of 8.  The problem
> with this is that an application needs to know the blocksize of all
> possible algorithms to parse the packet - maybe it is better to change
> it only if we specify a new version number of the packet, Hmmm...

I believe Uri was referring to the passphrase-protected secret key
data, which does use an IV in the conventional sense.

As far as the need to know the block size, this would only be a problem
if you faced an unknown cipher ID.  But in that case you can't decrypt
the rest of the packet anyway, so there is no need to parse it.  You do
have information about the overall packet size from the packet headers,
so you can just skip past the encrypted data.

I just spoke on the phone with Phil Zimmermann, who suggested a different
approach for this problem.  I will post a summary later this morning.

Hal

---

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

> data, which does use an IV in the conventional sense.

Hmmm, from the pgp 2.6.3 documentation about secret key certificates:

|  and the checksum is used to tell if the password was good.  The CFB
|  IV field is just encrypted random data, assuming the "true" IV was
|  zero.

This is what is done in GnuPG too and I have checked interoperability
against pgp 5.0beta.

> so you can just skip past the encrypted data.

Sure, it adds extra complexity to the already complex issue with 
S2K and pgp2 mode - but no problem ;-)

> approach for this problem.  I will post a summary later this morning.

This means late evening in Europe :-(

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