From owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org Mon Jul 17 06:29:39
2000
From: "Michael Young" <mwy-opgp97(_at_)the-youngs(_dot_)org>
To: <ietf-openpgp(_at_)imc(_dot_)org>
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Date: Mon, 17 Jul 2000 08:30:50 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-ID: <ietf-openpgp.imc.org>
Yes, I meant Twofish, not Blowfish.
The draft I found at imc.org still says in section 5.5.3:
- [Optional] If secret data is encrypted, eight-octet Initial
Vector (IV).
This should now read "an IV of the same length as the cipher block"?
I suppose so.
[Is there a more recent draft than that posted at imc.org? That one
claims to expire June 2000.]
I don't know.
As Werner Koch pointed out last year, this will require an implementation
to know the block size simply in order to parse the rest of the packet.
Given that the only material after the IV is the encrypted part, and thus
won't be readable anyway without support for that cipher, I suppose this
isn't all that serious. But is there any intention to make the IV size
self-describing for future ciphers, or is this the final plan?
We already have this problem, because StringToKey structures also do not
have their length self-describing. Hitting an unknown S2K identifier
leaves you in the same boat. Luckily it never matters, as in all cases,
there is nothing left in the packet to parse if you don't know how to
decode it.
Hal