Subject: Re: V3 secret keys

From: [email-masked] ("Hal Finney")
Date: Mon, 6 Feb 2006 17:59:43 -0800 (PST)

Vedaal writes:
> On Mon, 06 Feb 2006 17:38:01 -0500 Hal Finney <[email-masked]> 
> wrote:
>
> >Note that V3 keys only support ciphers with a block size of 8 
> >bytes, so
> >I think it is OK to explicitly say "8 octets" here.
>
> are v4 keys different in this respect ?
>
> (i.e., is there any cipher currently within the open pgp standard 
> that v4 keys support that v3 keys could not?

Actually I think I was wrong about what I wrote there.  At the time that
V3 keys were created, only 8-byte ciphers were used by PGP, but now I
think it would be legal to create a V3 key and use a 16-byte cipher like
AES to encrypt the private part.  (Or to re-encrypt the private part of
an existing V3 key using AES instead of IDEA or 3DES.)

So I would have to modify my proposed change to the language of the
spec to say something like:

   Furthermore, at the beginning of each MPI value after the first, the
   CFB state is re-synchronized to its initial state, with the IV for
   that MPI taken as the final octets of the ciphertext of the previous
   MPI value, with the number of such octets being equal to the block
   size of the cipher.

> classically, v3 keys were started when all that was available was 
> IDEA,
> but Disastry extended 2.6x for v3 keys to accept 'any' open-pgp 
> cipher, 
> even for symmetric protection of the secret key
>
> (i have occasionally found it useful to prepare v3 non-IDEA test 
> keys,
> for gnupg testers who prefer not to use patented algorithms, even 
> for testing, if there is a convenient way around it)
>
> [am not trying to awaken a v3 / v4 controversy ;-)
> am just trying to 'understand' what i might have 'missed' ]

Thanks for pointing out my mistake!

Hal Finney

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 17 Feb 2006 00:19:29 +1300

Ben Laurie <[email-masked]> writes:
>Peter Gutmann wrote:
>> Ian G <iang@xxxxxxxxxxxxx> writes:
>>> Ben Laurie wrote:
>>>> Obviously the I-D should be updated to reflect this (and clearly no-one
>>>> has ever implemented v3 keys from it).
>>> (I'm not qualified to rewrite the draft on that issue.)
>>
>> Why not just include the pseudocode (or more usefully straight C code) for
>> the operation? That's the ultimate definitive description, any programmer
>> can understand it, and you don't run into the problems you do with the
>> english description.
>>
>> (Even if an implementer doesn't understand it, they can always just cut &
>> paste the code).
>
>Isn't there some dumb IETF rule against that?

I doubt it, many RFCs containing nontrivial algorithms (specifically ones
where the easiest way to explain them is with code) already include full
implementations, e.g. the MDx RFCs and the Punycode RFC.

Peter.

(Completely off-topic, but while I'm mentioning Punycode does anyone know what
the *real* story behind this was?  It seems to be the Intercal of character-
set representations... does the background explanation by any chance begin
with "Some mathematicians got drunk and made a bet..."? :-).