Re: V3 secret keys

[Ben Laurie <[e-mail]>]

Hal Finney wrote:
> 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.

Experiment and code reading/running says it is correct.

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

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

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

"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