Subject: Re: Sample Twofish message

From: [email-masked]
Date: Wed, 7 Apr 1999 22:39:55 -0700

Jon Callas, <[email-masked]>, writes:
> What about section 12.8 which says:
>
>    Note that for an algorithm that has a larger block size than 64 bits,
>    the equivalent function will be done with that entire block.  For
>    example, a 16-octet block algorithm would operate on 16 octets, and
>    then produce two octets of check, and then work on 16-octet blocks.

Yes, you're right, that is inconsistent with section 5.7.  I don't
know how we should resolve it.

Hal

---

From: Jon Callas <[email-masked]>
Date: Thu, 08 Apr 1999 14:36:18 -0700

At 10:39 PM 4/7/99 -0700, [email-masked] wrote:

|Yes, you're right, that is inconsistent with section 5.7.  I don't
|know how we should resolve it.
|

When we were working on the RFC, the question of larger blocks came up, and
there were some suggestions of changing all the 8s to Ns, and 10s to N+2s
etc. There was the concern that we would make a mistake. We had the
advantage the first time that people (like Tom) coded to the original
description, and thus we had a check that it actually worked. So I put in
the paragraph in 12.8, as a quick way to describe how to do the right thing.

Do we agree now that the right thing to do is to start with a 16-byte IV,
encrypt 16 bytes, sync with 2 and then continue? That's what I thought we
all agreed on. If we agree that, then we don't have a problem, we have an
elided description that needs to be expanded when we revise the RFC. I
believe, though, that that's the right thing to do, work with full blocksizes.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

---

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

> encrypt 16 bytes, sync with 2 and then continue? That's what I thought we

ACK.

> believe, though, that that's the right thing to do, work with full blocksizes.

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?

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

---

From: Werner Koch <[email-masked]>
Date: Fri, 9 Apr 1999 13:21:35 +0200

Hi,

Here is a new sample message for 256 bit block ciphers.  Can anyone
please check it?

Note, that the message is preceded by 16 random bytes, then two more
bytes which are copies of the last two of the random ones. A CFB sync
is done after encrypting these 18 bytes.

The message is encrypted using the one-letter passphrase "x". 

The structure of this message is:

:symkey enc packet: version 4, cipher 10, s2k 3, hash 2
        salt 4f094cb39da872d8, count 96
:encrypted data packet:
        length: 49
:literal data packet:
        mode b, created 923655302, name="tf2",
        raw data: 20 bytes

The 256 bit key is:

  D5 13 A1 FA 34 9C 99 71 55 EC 8A 48 76 F8 BD 2E A1 24 D8 78 75
  0C 86 04 49 DF 3E 6F 85 56 25 D5

The begin of the plaintext messsage is:

  81 3D D9 FE 58 35 62 7A 1E 0D 1C 6F 4D 10 04 4C 04 4C

---

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

> 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.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Werner Koch <[email-masked]>
Date: Fri, 9 Apr 1999 18:11:21 +0200

> IV length normally is equal to the block size. I see no reason to

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...