[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7

> From owner-ietf-openpgp@mail.imc.org  Mon Jul 17 06:29:39 2000
> From: "Michael Young" <mwy-opgp97@the-youngs.org>
> To: <ietf-openpgp@imc.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.