Secret Key Packet Formats
Kazu Yamamoto ( 山本和彦 ) <kazu@iijlab.net> Thu, 27 June 2002 10:36 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 GAA08725 for <openpgp-archive@odin.ietf.org>; Thu, 27 Jun 2002 06:36:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RANYT26888 for ietf-openpgp-bks; Thu, 27 Jun 2002 03:23:34 -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 g5RANWw26876 for <ietf-openpgp@imc.org>; Thu, 27 Jun 2002 03:23:32 -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 TAA17942; Thu, 27 Jun 2002 19:23:31 +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 TAA28787; Thu, 27 Jun 2002 19:23:31 +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 TAA04034; Thu, 27 Jun 2002 19:23:31 +0900 (JST)
Date: Thu, 27 Jun 2002 19:25:57 +0900
Message-Id: <20020627.192557.125129914.kazu@iijlab.net>
To: ietf-openpgp@imc.org
Cc: stefan@epy.co.at
Subject: Secret Key Packet Formats
From: Kazu Yamamoto <kazu@iijlab.net>
X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
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>
Content-Transfer-Encoding: 7bit
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
- Secret Key Packet Formats Kazu Yamamoto ( 山本和彦 )
- Fw: Secret Key Packet Formats Kazu Yamamoto ( 山本和彦 )