ietf-openpgp
[Top] [All Lists]

Re: Agenda for OpenPGP Working Group

2004-02-24 22:50:19
Hello Derek,

* draft-ietf-openpgp-rfc2440bis
  Document Status
  Open Issues

I will not be there. But would you consider my comments below?  The
situation is the same for rfc2440bis-09.

--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 ---
<Prev in Thread] Current Thread [Next in Thread>