Fw: Secret Key Packet Formats

Kazu Yamamoto ( 山本和彦 ) <kazu@iijlab.net> Tue, 13 August 2002 03:02 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19156 for <openpgp-archive@odin.ietf.org>; Mon, 12 Aug 2002 23:02:37 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7D2pcW13721 for ietf-openpgp-bks; Mon, 12 Aug 2002 19:51:38 -0700 (PDT)
Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7D2paw13717 for <ietf-openpgp@imc.org>; Mon, 12 Aug 2002 19:51:36 -0700 (PDT)
Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA14483 for <ietf-openpgp@imc.org>; Tue, 13 Aug 2002 11:51:39 +0900 (JST)
Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA19352 for <ietf-openpgp@imc.org>; Tue, 13 Aug 2002 11:51:38 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA10577 for <ietf-openpgp@imc.org>; Tue, 13 Aug 2002 11:51:38 +0900 (JST)
Date: Tue, 13 Aug 2002 11:54:14 +0900 (JST)
Message-Id: <20020813.115414.46613679.kazu@iijlab.net>
To: ietf-openpgp@imc.org
Subject: Fw: Secret Key Packet Formats
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <kazu@iijlab.net>
X-Mailer: Mew version 3.0.60 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Aug_13_11:54:15_2002_891)--"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

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