[openpgp] sample v5 secret key material
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 26 November 2022 02:43 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513E9C14CF0C for <openpgp@ietfa.amsl.com>; Fri, 25 Nov 2022 18:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=QOC7uvpY; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=BlDfPAtM
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY6vYdJoC1kZ for <openpgp@ietfa.amsl.com>; Fri, 25 Nov 2022 18:43:19 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EABC14CE52 for <openpgp@ietf.org>; Fri, 25 Nov 2022 18:43:06 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1669430572; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=HsnqbcxROl/gW5QeblPo9F7fcVKcs1UPpzBnPDe3qA4=; b=QOC7uvpY7e75xAweXA7WZLC1G1vUGC64GSVdqAlaAGScTOEgH3jJlG4x3FWIMTd7O1LrR rpoL0synni+vPcbAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1669430572; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=HsnqbcxROl/gW5QeblPo9F7fcVKcs1UPpzBnPDe3qA4=; b=BlDfPAtMgOWMKQx5kUlk8tD63yvLlGz/OD/Ki/sNf35zikWWKHhVlXpP8y+tlLFa6lzRB 52RIssbtr1TPIGSZgpvgvSUR7N+2Zv+1XqrMb5LIU7/Mdo+OctudmwxIJOsydZDgECWMP8n zUQkzHAzFxd0scVPf+JxowQtXmsSGivlrbDc75cBSjcyaJgbGBRmSCfz1xlkrxV6jTRkfZa 9KdrOLGqdCRUKWRfodus/bzszo9D62bgUUnM42O0BAF5iLg0J5zwKTx7mK+wV1sQez/aB3k srDY9YF4W3SnYCjb+m+QjBYS06E/DdP4mIvst/2BKsqGV0jE2firJUa3WU8g==
Received: from fifthhorseman.net (unknown [202.77.124.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D9A68F9AD for <openpgp@ietf.org>; Fri, 25 Nov 2022 21:42:51 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id CEA1F208AA; Fri, 25 Nov 2022 15:56:42 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: openpgp@ietf.org
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Fri, 25 Nov 2022 15:56:41 -0500
Message-ID: <87v8n2u512.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/rl1wEWE6tiqNp8wKi5iVECsACik>
Subject: [openpgp] sample v5 secret key material
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Nov 2022 02:43:23 -0000
Hi folks-- As i continue to try to parse the sample material in the current crypto-refresh draft, i'm now confused by the content of the sample secret key. in the section "Sample v5 Secret Key", we have this: ``` -----BEGIN PGP PRIVATE KEY BLOCK----- xV0FYiDQVxYAAAAtCSsGAQQB2kcPAQEHQLVQ/UIL3goq8tqYyAhqx19AG5YH uMyAHjCOTyUpVKtRAAABAKmpvxTlZ9KQ6j+aOEk8fYe/h0L8K5pJsuAYhvSV mL28EbTCqAUfFgoAAAAjBQJiINBXAxUICgQWAAIBAhsDAh4JDScJAwcDCQEH AQkCBwIAAAAjIiEFG0Qp1bb6aZvkyAjPu144TzcWImHyXX8XATjOLTAM30sB 7pA8lWNbgXg9Vz8ycZZWkAEBAMgjsE34EtEpjM06Ftw+99gXjPV5Xy/1mmes oG3JTZV6AQDggGhEkEgG6nOspcvj3tnX8fi3/Naw07DH0aT81A3tBsdiBWIg 0FcSAAAAMgorBgEEAZdVAQUBAQdA7CroMU0EnbnPxn9YpED3YEaXAFCd8mcZ gEXuE8EyXX8DAQgHAAAA/1b9bxwV0acRUcifrLiKHd0VVifoISz2PSVd4q5I c1+gD+HCjgUYFggAAAAJBQJiINBXAhsMAAAAIyIhBRtEKdW2+mmb5MgIz7te OE83FiJh8l1/FwE4zi0wDN9Ldr1SIqrSExx7c5q6FNdJMKZVAQDa5KRNk91w jai2JxRH6Y9PnsjY1A1+C2cnuJOUiAnCJAD8DRX76sMoO6y1fll5Rtu2e0to DabdVW2UgbOiMY81wAY= -----END PGP PRIVATE KEY BLOCK----- ``` If i base64-decode it and just look at the first packet (secret key), i think there's an extra octet in the secret key material, just after the s2k usage octet. I think this is being supplied in contravention to the text in the "Secret-Key Packet Formats" section, where it says: "Only for a version 5 packet where the secret key material is encrypted (that is, where the previous octet is not zero), a one-octet scalar octet count of the cumulative length of all the following optional string-to-key parameter fields." Details of how i came to this conclusion are in subsections of the message below. If i'm wrong, please help me understand what i've been confused by (and maybe we can figure out some textual improvements so that other people don't make the same mistake). If my analysis is correct, though, then either we need to update the sample v5 secret key, or we need to change the specification to drop the clause "where the secret key material is encrypted (that is, where the previous octet is not zero)". What do you think? --dkg ## Binary Evaluation Details In particular, that's at position 0x3a, marked with "???" in the breakdown here. ``` 0000 c5 Packet tag 5 (Secret Key) 0001 5d Packet length 0002 05 version number 0003 62 20 d0 57 Key creation time (2022-03-03T14:27:35Z) 0007 16 Pubkey Algorithm (EdDSA) 0008 00 00 00 2d Pubkey material length 000c 09 OID length 000d 2b 06 01 OID (Ed25519) 0010 04 01 da 47 0f 01 0016 01 07 MPI length 0018 40 prefix octet 0019 b5 50 fd 42 0b de 0a x coordinate 0020 2a f2 da 98 c8 08 6a c7 0028 5f 40 1b 96 07 b8 cc 80 0030 1e 30 8e 4f 25 29 54 ab 0038 51 0039 00 S2K Usage Octet (unencrypted) 003a 00 ??? 003b 01 00 MPI length for Ed25519 secret 003d a9 a9 bf Ed25519 secret 0040 14 e5 67 d2 90 ea 3f 9a 0048 38 49 3c 7d 87 bf 87 42 0050 fc 2b 9a 49 b2 e0 18 86 0058 f4 95 98 bd bc 005d 11 b4 checksum of secret 005f ``` ## Textual Details in the "Secret-Key Packet Formats" section of crypto-refresh.md, it says the packet contains: > - The fields of a Public-Key or Public-Subkey packet, as described above. > > - One octet indicating string-to-key usage conventions. > Zero indicates that the secret-key data is not encrypted. > 255, 254, or 253 indicates that a string-to-key specifier is being given. > Any other value is a symmetric-key encryption algorithm identifier. > A version 5 packet MUST NOT use the value 255. > > - Only for a version 5 packet where the secret key material is > encrypted (that is, where the previous octet is not zero), a one-octet > scalar octet count of the cumulative length of all the following > optional string-to-key parameter fields. […several other fields only relevant for non-zero s2k usage…] > - Plain or encrypted multiprecision integers comprising the secret key data. > This is algorithm-specific and described in {{algorithm-specific-parts-of-keys}}. It also has this handy table: > +=======+==============================+======================+ > | First | Encryption parameter fields | Encryption | > | octet | | | > +=======+==============================+======================+ > | 0 | - | cleartext secrets || | > | | | check(secrets) | > +-------+------------------------------+----------------------+ > | 253 | params-length, cipher-algo, | AEAD(S2K(password), | > | | AEAD-mode, S2K-specifier- | secrets, pubkey) | > | | length, S2K-specifier, nonce | | > +-------+------------------------------+----------------------+ > | 254 | params-length, cipher-algo, | CFB(S2K(password), | > | | S2K-specifier-length, S2K- | secrets || | > | | specifier, IV | SHA1(secrets)) | > +-------+------------------------------+----------------------+ > > Table 3: Version 5 Secret Key protection details
- [openpgp] sample v5 secret key material Daniel Kahn Gillmor
- Re: [openpgp] sample v5 secret key material Daniel Huigens
- Re: [openpgp] sample v5 secret key material Daniel Huigens
- Re: [openpgp] sample v5 secret key material Daniel Huigens