Subject: Re: V3 secret keys

From: [email-masked] ("Hal Finney")
Date: Mon, 6 Feb 2006 14:38:01 -0800 (PST)

Ben Laurie writes:
> OK, I had to resort to reading the PGP 2 source to find out what was
> going on here.
>
> In essence its fairly simple, but is _definitely_ no explained by the I-D.
>
> Firstly, v3 CFB does not use the IV in a standard way. Instead, what it
> does instead is set the IV to all zeroes and then decrypt the IV and
> throw away the result.

This is not correct. The IV is used in the standard way.  You may be
thinking of symmetrically encrypted data packets, which work as you
say here.  V3 private keys are standard.

> Secondly, as I think was correctly explained by someone here (but I
> didn't get it, sorry), when "resynchronisation" occurs it means "set the
> IV to the last 8 bytes of ciphertext".

Right.

> Note that for any standard-sized key resynchronisation does _not_ occur,
> so people who think they've implemented it from AC are in for a surprise
> one day.

This will usually be the case; p and q will be forced to be a multiple
of 8 bytes (64 bits) for keys of usual sizes.  But d, which is e inverse
mod lambda(n) would be shorter sometimes.  lambda(n) is lcm(p-1,q-1) so
lambda will be at least 1 bit shorter (since p-1 and q-1 are both even)
and perhaps 2 bits shorter with probability about 1/2 (in case p-1 and
q-1 have other small common factors).  Independently, d may be shorter
than lambda.  Put it all together and maybe one key in 70 or so would
have a d value which is 1 byte shorter, requiring resynchronization.

> Obviously the I-D should be updated to reflect this (and clearly no-one
> has ever implemented v3 keys from it).

The current text is not inaccurate, but does rely on knowing what
"resynchronized" means.  Since this is a non-standard term we should
explain it better.  Here is the current text:

    Encryption/decryption of the secret data is done in CFB mode using
    the key created from the passphrase and the Initial Vector from the
    packet. A different mode is used with V3 keys (which are only RSA)
    than with other key formats. With V3 keys, the MPI bit count prefix
    (i.e., the first two octets) is not encrypted.  Only the MPI
    non-prefix data is encrypted.  Furthermore, the CFB state is
    resynchronized at the beginning of each new MPI value, so that the
    CFB block boundary is aligned with the start of the MPI data.

The last sentence is the one which is problematic.  What if we changed
it to:

   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 last 8 octets of the ciphertext of the
   previous MPI value.

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.

Hal Finney

---

From: Ben Laurie <[email-masked]>
Date: Tue, 07 Feb 2006 09:36:06 +0000

> say here.  V3 private keys are standard.

Experiment and code reading/running says it is correct.

> have a d value which is 1 byte shorter, requiring resynchronization.

OK, well, I haven't see one yet. As I mentioned before, test
vectors/packets in the I-D would be _really_ nice.

> I think it is OK to explicitly say "8 octets" here.

"re-synchronised to its initial state" is perhaps not entirely clear -
wouldn't it better to just say the IV is set to the last 8 octets of the
previous ciphertext and not mention initial state?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff