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