Fw: Secret Key Packet Formats

[Kazu Yamamoto ( 山本和彦 ) <[e-mail]>]

Hello all,

I sent the following message for 05.txt in June. But 06.txt does not
include my suggestions. To reminder, I post the message gain. I hope
my suggestions will be included in 07.txt.

--Kazu

--- Begin Message ---

Hello all,

I have several comments on Section 5.5.3 (Secret Key Packet Formats)
of 2440bis-05. 

>     - [Optional] If secret data is encrypted, Initial Vector (IV) of
>       the same length as the cipher's block size.

The following might be more easy to understand.

      - [Optional] If secret data is encrypted(string-to-key usage
        octet was not 0), Initial Vector (IV) of the same length as
        the cipher's block size.

>     - Encrypted multi-precision integers comprising the secret key
>       data. These algorithm-specific fields are as described below.

If string-to-key usage octet was 0, this field is not encrypted. So,
this should be:

      - Plain or encrypted multi-precision integers comprising the
        secret key data. These algorithm-specific fields are as
        described below.

>     - If the string-to-key usage octet was 255, then a two-octet
>       checksum of the plaintext of the algorithm-specific portion (sum
>       of all octets, mod 65536). If the string-to-key usage octet was
>       254, then a 20-octet SHA-1 hash of the plaintext of the
>       algorithm-specific portion. This checksum or hash is encrypted
>       together with the algorithm-specific fields.

This does not corver the other values than 254 and 255. According to
RFC 2440, a two-octet checksum is necessary for the other values.

>   The 16-bit checksum that follows the algorithm-specific portion is
>   the algebraic sum, mod 65536, of the plaintext of all the
>   algorithm-specific octets (including MPI prefix and data).  With V3
>   keys, the checksum is stored in the clear.  With V4 keys, the
>   checksum is encrypted like the algorithm-specific data.  This value
>   is used to check that the passphrase was correct. However, this
>   checksum is deprecated; an implementation SHOULD NOT use it, but
>   should rather use the SHA-1 hash denoted with a usage octet of 254.
>   The reason for this is that there are some attacks on the private
>   key that can undetectably modify the secret key. Using a SHA-1 hash
>   prevents this.

"16-bit checksum" should be "two-octet checksum".

This paragraph should cover V2. Actually, old PGP commands produce
Secret Key Packet with V2.

Combination of string-to-key usage octet and format version is
unclear.

2440bis-05 is read like:

		V3			V4
  0 
254		encrypted sha1 hash	encrypted sha1 hash
255		clear checksum		encrypted checksum
others

But I think this matrix should be:

		V2/V3			V4
  0		clear checksum		clear checksum
254		clear checksum		encrypted sha1 hash
255		clear checksum		encrypted checksum
others		clear checksum		encrypted checksum

If this is correct, I hope improvement of this section will be made in
the next draft.

Thanks.

--Kazu

--- End Message ---