From nobody Tue Oct 15 05:16:43 2019 Return-Path: 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 887EE12000F for ; Tue, 15 Oct 2019 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jyFdN9ze_yE for ; Tue, 15 Oct 2019 05:16:36 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [IPv6:2001:8d8:1801:86::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4637B12008A for ; Tue, 15 Oct 2019 05:16:35 -0700 (PDT) Received: from [10.137.0.12] (ip-178-203-234-118.hsi10.unitymediagroup.de [178.203.234.118]) by cloud.kuix.de (Postfix) with ESMTPSA id 1F35B1858E6 for ; Tue, 15 Oct 2019 12:16:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1571141792; bh=WRi0PGY5sift6IruWxjAL4qvw+TYJRUdmVAbIP548DQ=; h=From:Subject:To:Date:From; b=EbCBhS5Ew38W8PeYJcAzsB02ESUBfymmDNC4tzdtfjQV67tPa3kG25b71ZG7SfJ7o Oo39VgEFLM0QxnN0wGe091bkXxalx5elPZP5Uv/NI89G1h4OxlQqoTzZfleJIYAR6K KP4pksKmMdeGqUGMSiMCDifK6asGzeOECdJqiZZkMfMvZOXVhp50d9fXaT9czL/8rZ V6VrteE1l1H/4SiLdfNWmMRbq/lQGq2ELrDFFZY1SImpwr7EFx3nMkfYYSwRYuSqwk I9mwwV9gyxlneyKUztWfuIg+zjgi3jWkCYrxuRA90Cq3RDSbdyPusX+t2wUe+Kuhqk Xm61XK2DpiD3g== From: Kai Engert Autocrypt: addr=kaie@kuix.de; keydata= xsFNBE8oE/UBEAC/Vx4tHVkfPdGf0BFMGcidXzAXKQ4+gI2F5rPBoV9fEtYngLHzm7+a6DL2 v5Jl5b4by9KtUbfIJysR1iniLWMJVPXZcyC4ovGouZ4MGK5cD9kMy+JdwebCs5/tj51vcvrS 08dP7r9Q0f0H7tsqhtVWuPFt+ZZEj8fIxjMgE3Z5BcyoGT1mXQ544RA0vr0fB9MngvfteD3L /wL2miDnYVtwB+VHC6kEB75Pte/yz1kFc/TDqKT8F45M3invhccY8Zwe7F88+uS+tgR5B3Ga RMc9WChZr5ed5vRxSLrGqBGSWBKomKuWXNFVMrZAOaq+W/+kOdNSXLdJSvXIAgV4Gywf1D0r ZTi8V+UoiTY8eDfT4OlBJrbbkge92/lrqaorAsuo/DVmfv7ARk7q2jvbSZD39zkWpLNsAulz gZOr+ffEHKy0f9fNwzenHpKvNtTUWGChEyDf7a6EtTBZsxAYco0xAtFOoQVwx5UzZk4tMVhv lrATrvmFdK5SLroDuwtSLUBJ5MhICyaB1kN7YSatQs33D+M5oPKVC+mn1WB/nznU475cssBW Asw+/K4VtXN08HxVFEvpV5MtpoYGe/cqsV87aVr/Igg45DVKtMMK8W5AmJDdGru3caxdVkkW fis9F1GBkk7ZPgip4cprh3KicuKsXhVrjk2mC/kCR+mrlY8ncQARAQABzSNLYWkgRW5nZXJ0 IChhdCB3b3JrKSA8a2FpZUBrdWl4LmRlPsLBegQTAQIAJAIbAwIeAQIXgAIZAQUCVdbtjAUL CQgHAwUVCgkICwUWAgMBAAAKCRAcJ0I3JQB3JEoOEAC9YaJFZCdCFXMb9HkQ4TS1z813EgTO lDFQwQ9vF26edvBjm80xcLQYUN5iRr6RNcHpx6FZLUX+AwAB5Cf2swVjvZB3LycwlKyKVuwd bXoLHPgq0XVu2l/ZbEKKmIR70UGAL/CKmZZm5rimicD1B5P+VXrnSl8uA7MjQFNnWnDuDHGk 9A/dl7RAEAenAiFlRFR5lwu9U/4TG0OrACgp7OIls3/jcszRRMJrc5OiTGWPq4d+Bo3a1yqA fdS2VjMObO8+zO7+4tact5uVFxrbMIRULKP0xJC/X77koUyn6ZSFIyFjJR2I/p4PCCLD0soJ 06e1e9bKUsKowFGwrvMnXqGEA4lij22R80paRH7VQ0QKQW9RDSqlF1YUafHpCt9D5i7HG2Ft ZgYz7VlfS27YMvG6Np+fN5Devh9Hap6fK5+SBTcs8v0Tgf8Ljx7OlajRHNtBxqRcPghnCZTJ oQpAJup5TYeqSGyp/Q2VT80h9iySGfBnn30qhcTr5lqOg/2NvQeu9wNVKBPmr8QpCfYb7ENZ CBifohzqBV8D6HaoBFeNts37kugcMWTw4C/RCtYI8TnjR18caDkc3kDh5p6anLnnQhCnGSVu LFj52lazHkj3FE+Ijg8ir95hm0d4PWZqk5UNfEPUa6ltBkHZstdpBvtqN+HxXpovqf8agBaZ ol2vXc7BTQRPKBP1ARAA54JU09VzBOPw44IYINiuQAEeyikO5sLT+Ixee8MM+T8tXk0Z9RSw UVctu8DwM+f8NjRI+dvmGSgezsiNL1ZkVuN37GM4dg7ZJ8oZCB5/YQQCCx1z7q4d68XsEfTs edl+Y2GcggbR6EpN4RbR38N6uhwKFZw0meuP6m1NaRCnihciJrXdoKxXcoHAxy3balGTPAbv OUmQaqI7dY5DVFPOT5I2wl1cWbkkTcx4wu8190sSMeW/IbwIg7inC/nqXCSKL633+Hv/2GcV zvBNK8JxO5YaHuHl+GBwP6cHlotHd2qr/BSyhYCt3CcMDHXR+vwSwawC+/zUpR5THrVLT6E/ hlpAZX5HQsY9BMrllI0Ap7MClj+kvRlkukNfc3/CKpAL1RjDV5+sr91ffBNXbZgpsp3/uCI6 QuJpFdUY8js5aYNwHCFbX8xkzdFqG95vt+uNoq/F7p7dEQi3BE0H2b0c4kuJX4G9MrAKdyfY r1KiPX513AQeIXZCE9UogON5jvKF6PBTTuzomsCZBa9ExbkLv+uCm7Q+EC4WwvvpbUaaLpmu t+oqnsSrYehg4ydm5NRhgfJy+Ris1sKAptyA7AlDWWsP5fFZE0rxeoDrTdbX6JVjxT509DtW a4rI0qgGTt625J6irm6nfbF8M1V5ZaBmSstWC/PDdggsfl35abQHxk8AEQEAAcLBXwQYAQIA CQUCTygT9QIbDAAKCRAcJ0I3JQB3JA5FEACCSZIzygwTFoOcFciojcbY3uvNamflJ0fMAv+h wO/Blprd1cHBmI0dQoTbpQ4NX33f9PVh4X9eCrxMCzUKB8RBS5ZNk5P0PYhJNooqKTmM3JIl coyvTruz9/Q2nbPA6z+0c7KJpmdJKn60vZfR4UDfwIOEqYvrZRbld3Bv1XXUQ6NHWvX6x2Ft vmASNON5m7ml4zwH6qSASJ0JZo0CuLwSOanmc5r+rDwtHHGqEpp6VwXpcPyF6ZUG5i0rU4OT H2y0kOb+7igK25LmjiXFNqbQb+K4lchVpxIGV6MvW6GAd3L0ei8cnYccZhAoPNCbKgEIA7qW 8g93U6Wf+P0yu9DbOqz2ETXoEqRJVDNLTrrvKyRYBDNpqvleUJtBHMnpU1Oqhf+ddCT292Ux fK9CoQe+st1QD5Mazlrnw4PuH7etS/Y2na7rXwqvop/IIu6Ba90/nddv/0cqvaRaDFYVN6HU GATLienjv0yS0QVTf/2x7B2NCtyT3lqRHrFByzm0FPAFxbr1HFJgE5CPGrmCn6ToR77gNBkL KUU3MVTGTRe35JHc5QVFuUwcrRBT/EcK8A3u0wmORswNnDylisYhzrw0RuS6WSvhAvuVQ0yF uh6SYw72DFmbX/h1A9BBMZ50tJtgqbD4Q+74J44SP8RD7qspTk6NNBa6D835NLx652yXwQ== To: openpgp@ietf.org Message-ID: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> Date: Tue, 15 Oct 2019 14:16:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 12:16:40 -0000 Today, saving a backup of an OpenPGP secret key usually requires storing a file. It could be useful to standardize an an additional recovery mechanism, that doesn't require the secure storage of a file, but is based on a list of words written to paper. The high level idea is: - key generation requires a source of entropy - instead of using the entropy directly, the entropy could be used to seed a CSPRNG (like HMAC_DRBG), which is then used to obtain the random data that is needed for key generation. - the entropy, plus any meta data required to generate the key, could be encoded as a list of words, which the user can write down. - at a later time, the user could recover by using OpenPGP key generation software that supports this recovery mechanism, could provide the word list, which is decoded to obtain the original entropy bits. - after creating the initial key, if additional keys need to be generated (e.g. a subkey), the CSPRNG is used to fetch all additional random numbers that are required. During the OpenPGP summit last weekend it was mentioned that having this kind of mechanism available could be useful, without going into detail. Tobias Müller pointed me to an existing implementation of a similar idea for creating OpenPGP keys : https://github.com/skeeto/passphrase2pgp A definition of such an approach exists for the kind of private keys that are used in the Bitcoin world, and IIUC several applications implement it: https://en.bitcoin.it/wiki/BIP_0039 (For creating additional child keys, an additional standard exists for creating them, just for completeness, I don't know (yet) if the OpenPGP mechanism might require (or could use) something similar for sub keys: https://en.bitcoin.it/wiki/BIP_0032 ) Would you be interested to discuss how to standardize such a recovery mechanism, and would you be interested to implement it in your applications? Besides the raw entropy, what other meta information would we have to be included, to ensure that key generation can be repeated? I see the primary purpose for this recovery mechanism as desaster recovery: - ensure the recovered primary key can be used to decrypt an archive of old data, like the encrypted emails in a sent folder - allow the use of the recovered primary key to create a revocation statement If the guts of the BIP_0039 specification is considered equivalent to the needs of a mechanism for OpenPGP secret keys, maybe it could be a useful shortcut to use the same approach. It uses lists with 2048 words, and encodes each word as 11 bits. A seed of 128 bits with a checksum of 4 bits is encoded into 12 words. Potentially the metadata required to encode a public key could be encoded into additional words. Here's a result of some initial brainstorming, but I'm unsure if I've identified all the meta information that would be necessary to repeat the key generation, but as a starting point for discussion, we could encode the following meta/descriptor information into 33 bits, which could then be encoded into three additional words. 1 bit Version of this descriptor prefix, always 0. 7 bits Number of entropy bytes that will be encoded as a mnemonic. Encoded as a multiple of 32 minus 1. Smallest value possible is 32, encoded as 0: (0 + 1) * 32 = 32 Largest value possible is 4096, encoded as 127: ((127 + 1) * 32) = 4096 (Maybe 4096 is unnecessarily large, and we could use a smaller amount of bits for this.) 7 bits Identifier of the public key algorithm, as defined in RFC 4880 section 9.1 (Assumption that this implies the usual associated sub key algorithm. If not possible, we'd need additional bits to encode the sub key algorithm.) 18 bits Key size plus 1 Smallest value possible, encoded as 0: 1 Largest value possible, encoded as 262143: 262144 (Maybe again that's unnecessarily large and we could use the bits for something else.) A full recovery mnemonic based on a 128 bit seed could consist of 15 words, 3 bytes for the descriptor prefix and 12 bytes for the seed. I hope some of this message makes sense. Regards Kai From nobody Tue Oct 15 05:23:40 2019 Return-Path: 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 02430120072 for ; Tue, 15 Oct 2019 05:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHqxp78Eolxj for ; Tue, 15 Oct 2019 05:23:36 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [IPv6:2001:8d8:1801:86::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0D812000F for ; Tue, 15 Oct 2019 05:23:36 -0700 (PDT) Received: from [10.137.0.12] (ip-178-203-234-118.hsi10.unitymediagroup.de [178.203.234.118]) by cloud.kuix.de (Postfix) with ESMTPSA id BCEBC1858E2 for ; Tue, 15 Oct 2019 12:23:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1571142212; bh=fLjLPf1JlJbTIPdrr14CQpBiko2UsF6MPRaNmnrrcI0=; h=Subject:From:To:References:Date:In-Reply-To:From; b=jM8zP8a6Pq7CE4c9WhDNkq/FuOG5529gnCw7/3FjSjzc/TWdZ6uh42qCP2cAI0XdY hlJ6LILiZMZAYSirZEHObgR9krPgJuB38nxY2oNxHC81HnoEo+OBsD/6uOhvBgS/kh ruL20tbC2VIJaF2FWuk+EP8AaOCmRDWIH29xMeF2hteV4HNrT4IW5IZF+UOrW2sCQC FFMN+TSi+Hnh4kmOp46v2OzL7mc8t8+xlOmCQ1qoeEd1GcI/85Svk81QxbFjqKigBP N7RHbfR7zn1f9Zpa61OCSl13zMUEwf1SE3MBeF9uZavVPRFOECEyI63HGiWz4ls7II KZ7Wn41tUeOIw== From: Kai Engert To: openpgp@ietf.org References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> Autocrypt: addr=kaie@kuix.de; keydata= xsFNBE8oE/UBEAC/Vx4tHVkfPdGf0BFMGcidXzAXKQ4+gI2F5rPBoV9fEtYngLHzm7+a6DL2 v5Jl5b4by9KtUbfIJysR1iniLWMJVPXZcyC4ovGouZ4MGK5cD9kMy+JdwebCs5/tj51vcvrS 08dP7r9Q0f0H7tsqhtVWuPFt+ZZEj8fIxjMgE3Z5BcyoGT1mXQ544RA0vr0fB9MngvfteD3L /wL2miDnYVtwB+VHC6kEB75Pte/yz1kFc/TDqKT8F45M3invhccY8Zwe7F88+uS+tgR5B3Ga RMc9WChZr5ed5vRxSLrGqBGSWBKomKuWXNFVMrZAOaq+W/+kOdNSXLdJSvXIAgV4Gywf1D0r ZTi8V+UoiTY8eDfT4OlBJrbbkge92/lrqaorAsuo/DVmfv7ARk7q2jvbSZD39zkWpLNsAulz gZOr+ffEHKy0f9fNwzenHpKvNtTUWGChEyDf7a6EtTBZsxAYco0xAtFOoQVwx5UzZk4tMVhv lrATrvmFdK5SLroDuwtSLUBJ5MhICyaB1kN7YSatQs33D+M5oPKVC+mn1WB/nznU475cssBW Asw+/K4VtXN08HxVFEvpV5MtpoYGe/cqsV87aVr/Igg45DVKtMMK8W5AmJDdGru3caxdVkkW fis9F1GBkk7ZPgip4cprh3KicuKsXhVrjk2mC/kCR+mrlY8ncQARAQABzSNLYWkgRW5nZXJ0 IChhdCB3b3JrKSA8a2FpZUBrdWl4LmRlPsLBegQTAQIAJAIbAwIeAQIXgAIZAQUCVdbtjAUL CQgHAwUVCgkICwUWAgMBAAAKCRAcJ0I3JQB3JEoOEAC9YaJFZCdCFXMb9HkQ4TS1z813EgTO lDFQwQ9vF26edvBjm80xcLQYUN5iRr6RNcHpx6FZLUX+AwAB5Cf2swVjvZB3LycwlKyKVuwd bXoLHPgq0XVu2l/ZbEKKmIR70UGAL/CKmZZm5rimicD1B5P+VXrnSl8uA7MjQFNnWnDuDHGk 9A/dl7RAEAenAiFlRFR5lwu9U/4TG0OrACgp7OIls3/jcszRRMJrc5OiTGWPq4d+Bo3a1yqA fdS2VjMObO8+zO7+4tact5uVFxrbMIRULKP0xJC/X77koUyn6ZSFIyFjJR2I/p4PCCLD0soJ 06e1e9bKUsKowFGwrvMnXqGEA4lij22R80paRH7VQ0QKQW9RDSqlF1YUafHpCt9D5i7HG2Ft ZgYz7VlfS27YMvG6Np+fN5Devh9Hap6fK5+SBTcs8v0Tgf8Ljx7OlajRHNtBxqRcPghnCZTJ oQpAJup5TYeqSGyp/Q2VT80h9iySGfBnn30qhcTr5lqOg/2NvQeu9wNVKBPmr8QpCfYb7ENZ CBifohzqBV8D6HaoBFeNts37kugcMWTw4C/RCtYI8TnjR18caDkc3kDh5p6anLnnQhCnGSVu LFj52lazHkj3FE+Ijg8ir95hm0d4PWZqk5UNfEPUa6ltBkHZstdpBvtqN+HxXpovqf8agBaZ ol2vXc7BTQRPKBP1ARAA54JU09VzBOPw44IYINiuQAEeyikO5sLT+Ixee8MM+T8tXk0Z9RSw UVctu8DwM+f8NjRI+dvmGSgezsiNL1ZkVuN37GM4dg7ZJ8oZCB5/YQQCCx1z7q4d68XsEfTs edl+Y2GcggbR6EpN4RbR38N6uhwKFZw0meuP6m1NaRCnihciJrXdoKxXcoHAxy3balGTPAbv OUmQaqI7dY5DVFPOT5I2wl1cWbkkTcx4wu8190sSMeW/IbwIg7inC/nqXCSKL633+Hv/2GcV zvBNK8JxO5YaHuHl+GBwP6cHlotHd2qr/BSyhYCt3CcMDHXR+vwSwawC+/zUpR5THrVLT6E/ hlpAZX5HQsY9BMrllI0Ap7MClj+kvRlkukNfc3/CKpAL1RjDV5+sr91ffBNXbZgpsp3/uCI6 QuJpFdUY8js5aYNwHCFbX8xkzdFqG95vt+uNoq/F7p7dEQi3BE0H2b0c4kuJX4G9MrAKdyfY r1KiPX513AQeIXZCE9UogON5jvKF6PBTTuzomsCZBa9ExbkLv+uCm7Q+EC4WwvvpbUaaLpmu t+oqnsSrYehg4ydm5NRhgfJy+Ris1sKAptyA7AlDWWsP5fFZE0rxeoDrTdbX6JVjxT509DtW a4rI0qgGTt625J6irm6nfbF8M1V5ZaBmSstWC/PDdggsfl35abQHxk8AEQEAAcLBXwQYAQIA CQUCTygT9QIbDAAKCRAcJ0I3JQB3JA5FEACCSZIzygwTFoOcFciojcbY3uvNamflJ0fMAv+h wO/Blprd1cHBmI0dQoTbpQ4NX33f9PVh4X9eCrxMCzUKB8RBS5ZNk5P0PYhJNooqKTmM3JIl coyvTruz9/Q2nbPA6z+0c7KJpmdJKn60vZfR4UDfwIOEqYvrZRbld3Bv1XXUQ6NHWvX6x2Ft vmASNON5m7ml4zwH6qSASJ0JZo0CuLwSOanmc5r+rDwtHHGqEpp6VwXpcPyF6ZUG5i0rU4OT H2y0kOb+7igK25LmjiXFNqbQb+K4lchVpxIGV6MvW6GAd3L0ei8cnYccZhAoPNCbKgEIA7qW 8g93U6Wf+P0yu9DbOqz2ETXoEqRJVDNLTrrvKyRYBDNpqvleUJtBHMnpU1Oqhf+ddCT292Ux fK9CoQe+st1QD5Mazlrnw4PuH7etS/Y2na7rXwqvop/IIu6Ba90/nddv/0cqvaRaDFYVN6HU GATLienjv0yS0QVTf/2x7B2NCtyT3lqRHrFByzm0FPAFxbr1HFJgE5CPGrmCn6ToR77gNBkL KUU3MVTGTRe35JHc5QVFuUwcrRBT/EcK8A3u0wmORswNnDylisYhzrw0RuS6WSvhAvuVQ0yF uh6SYw72DFmbX/h1A9BBMZ50tJtgqbD4Q+74J44SP8RD7qspTk6NNBa6D835NLx652yXwQ== Message-ID: <3dbdbec0-e420-c064-1808-0226aa155a73@kuix.de> Date: Tue, 15 Oct 2019 14:23:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 12:23:38 -0000 On 15.10.19 14:16, Kai Engert wrote: > > A full recovery mnemonic based on a 128 bit seed could consist of 15 > words, 3 bytes for the descriptor prefix and 12 bytes for the seed. 3 words and 12 words (not bytes) From nobody Tue Oct 15 06:52:15 2019 Return-Path: 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 C7D9112004C for ; Tue, 15 Oct 2019 06:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbxXoV57XByj for ; Tue, 15 Oct 2019 06:52:10 -0700 (PDT) Received: from mailpile.is (mailpile.is [139.162.218.203]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7CD120043 for ; Tue, 15 Oct 2019 06:52:10 -0700 (PDT) Received: from mailpile.local (104.ip-144-217-164.net [144.217.164.104]) by mailpile.is (Postfix) with ESMTPSA id E12E69CDA3; Tue, 15 Oct 2019 13:52:07 +0000 (UTC) Content-Type: multipart/mixed; boundary="==9DFobxFHdfyJkpkPI52grnATD6pSiP==" MIME-Version: 1.0 From: Bjarni Runar Einarsson To: User-Agent: Mailpile Message-Id: Date: Tue, 15 Oct 2019 13:50:56 -0000 Autocrypt: addr=bre@mailpile.is; prefer-encrypt=mutual; keydata=xsFNBE4tgKYBEA DI8ULBJPw1a4h/D9Re5AZZ7xBtI9hIljUKz/bBovBGmRsrG6+IjKZ4um1kkJDhwiY0SzrzqE4L1hr cPRA46WbX0/aUuxL7LWbNDl6i7GBP28eU4I+mQcri2oS/rMfx3rnqe2dF85KKdTvS/9SsGAYNwK49 a+DMdsgDT3xMTf1JMrV5lRI7JCzop7v0AVbt9pyJAySJvQWcmkiWEZCWGpQxlYn/CnBVhv3iKToFt oIYKfcWLK/ADZ5CikwF7jDQM30mHovY4Ui31gVWnlhOw+UKpNviwbH7lr6flo2wFuaiD1jutKwqnG s6gH5A/tF6RtUCt6KzYoXpNochk8DGzm3G//sMDdreyUZeiXsF665IdUZ1V8OxU+S17MrxNiGjvY5 gRlD6a4oMsEZQPLQia4j7mCX/kTRsm5Xo+NqBMigNIvH7BJ+DcAqYnMT3kCbLyM3cAPhPn6zrSlXA mSsjAYk0bSLV9Ow0CITVcfrLB+2k+KFPFLl0ewXD75tspRk3wNBJ6GbhekOwzZE7xjrqWgR9Tfmlg DWArZT6oxqtKTiYnwiuQqPixONsc1jdR8bhqDZaJh7HkrZcY7yMDKQWe+1MxwBTV/DbbkrTmTT4ff RWCKi0Dv1do3NDgFXDC/3XpvFD2h2HPMs6pu8rG3CqS8YRJeE+p8TV7RJePSrb50rx4wARAQABzTB CamFybmkgUi4gRWluYXJzc29uIChNYWlscGlsZSkgPGJyZUBtYWlscGlsZS5pcz7CwY8EEwECADkC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEEYaAVdj0o1BCoexlzKBkdmztBmbQFAl0X+KQAC gkQKBkdmztBmbT72hAAit87DtuEM74doeqYa2nYj5iba7wgnnZVnSLK/tN1g0mLYMrXX/nsI8elFM lB4o/qw/y3SlSvXSe2+MJ3OImIjSR2t7yeQuA3rNcZE1wTN9+FL+OVtOzNzAHvI/+2A7NQAgxOd83 nDOe1N6g4lzJZgNbWyvlUUpqGe1uRJwCxrVAW0BnxQuFLmUM+ypx+Ht5lX05JYzJh2lt05g2QBgNg GHZ2iMSl+uTaq1K5Y62jIFeP5PutPXwDFtKgUg2zY30SLYdp/SVl19fH4SSTTgXuYj9nACZ/UKy8l h7t5liUOmTi8QjlVLXQUJflgEwm8OJhnuWODNZQwAx0msqG5AsHI9nv48fTSnBACpGq58GxSmnWUv yO4Eqrbi+2HKzoRymDyzuPLwrPNyTJITxhhj5g0613isttdiM9+vX73jpWOilyKbyKfmCdOoUliEB Vt/+QGD9lt6iUfotgvgGpS/JkBi+X9otEN+wb1vJBCzK1Dfy7CrEHx7tD3+5FJi8mrSlaKeUqjLkR UbdWbBIc+kfVFpkqDzJmz6QoKWAevTk+GwETbD2aFTjX37M9EWkk3sDaEXSYFIT1X6++ykOl7bX+4 Sm2kRaBr8O8B1+26T+ZeVKvg14nYvr4Ck92/y/cPUgrW6meE1WC/9bXqrsMR1pY9Y7N8cw8h6GIpk ehy+XiuYrOwE0EVbaWEQEIAM0AUqE7vyJSdoCpKVMydXcnpzGSv+NUeTPxYObfjcQiAjeSDVgbhRQ eb8jRmhMpTY8mwd7o1soJlJ71JewXmLw7/u2ixYOWUtdLU6w8C2bXTWqq5gTJFMtUvq+Lt2AcWgcQ WCyVbzSjVvHR+Djy6qGiO1Tf90K9fYpdEOQKJrcFCVL88gz3qpP6H5vm29xNUZQWb3E6F6cSRiGYW QZ4mTmJFE1hOKGHsmLaFFeJy6sVMOE62y4FejA5p2R9lQ/u2sGkgKfQ0OfOCk778w07u6XtYHX/7X zRA0ma4PWL4/nXt7bjOqSC119+yLYYL6f/qQeMbJIX3qOIDxsfqxm+6/UAEQEAAcLBfAQYAQIAJgI bDBYhBGGgFXY9KNQQqHsZcygZHZs7QZm0BQJdF/kZBQkLI8oHAAoJECgZHZs7QZm0yfQP/0K9lm6C m6s2Q5Z3e0AevmZOaGIOVIq4UK+GoRTyKGC0gzya5oXlDQGsefS+I5iAZiwlFfQPwZ0TCujXawrwq OKpNjaoUiMMLaRMNP17yVcfvrNN23YWMAOFZoxJyczXveVDgEC/VDRWVguV6LbRv3ovIb9VlsbJ9R WvdzmZEtOWJ+PK0yeBaM2EmH7B3Liq6WKEv+PwPTt1giwB20Lf5wgUGROF2hBF9spd2J1p0ZzWarx keuMDGEh8djVSBqwP2pqrTQWArPvONRGcl/pOgfCyx6fVdrUMTW79KuWTyK+Re9zctpwCKAURCikD qFAupFh2kJmbobOE2miYZ50YdhmoejHK3iBzdEijfPiOqWoStapd44q3o8s+KEWvRymMfp7tQiTEH OxNga9hIomntAqYT/6F5En0RhnVjK3ZRaxoI2VPWa5AA878k9GpqfFO9h5z7e18b+4ukVl1PY4S4w FV+lqqq/ODbWiZS+lKXkcVQoVCFhDEhenV8uuKSMfZR/PrjShaMI/AjP6ESHowlEdDaus6TeiJWfI P5QQViZAQg/tWtwPq2YzMVCS/S1rK+EjZp4Db55N4VxDAE5N0jSV+2LsJhFg+57UW9genrOAzkZZE DRQLjVPAPmR2uUx5A13TTX7TNM07D6j+5I9FnLGd/sW3wcyxlMWwN4IMY1bt OpenPGP: id=61A015763D28D410A87B197328191D9B3B4199B4; preference=signencrypt Archived-At: Subject: [openpgp] Shared OpenPGP keys for use in test corpuses X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 13:52:13 -0000 --==9DFobxFHdfyJkpkPI52grnATD6pSiP== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello OpenPGP! One of the workgroup outcomes at the OpenPGP e-mail summit, was a common desire for more shared test data. As a first step towards this, dkg and juga and I sat down and put together a minimal Internet Draft which specifies a couple of OpenPGP certificates and keys (one Ed25519, another RSA-3072), which we would like to propose people use when testing. The draft: - https://datatracker.ietf.org/doc/draft-bre-openpgp-samples/ The gitlab where we welcome improvements: - https://gitlab.com/openpgp-wg/openpgp-samples We hope this proves useful, - Bjarni -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2lzrQACgkQjgA3FgDP lJGTnwf/YeDpEgjgkPTKohvVHqNOLwHnZ8WIRW0rAO5lCaUQTcjBmW0CCpobr7a8 gck7BBe2cplW5Yg8tHH0dM5dL6Jjev2kXfrck4BTdQPZOXdBb4SrrPVgNoQwbn0S lV5cjQdfAkc2wp4zIzGifJBduESgSyNABIG4pafNabcoZCvGYUW2iukC53q2KbWr HXiuBtQMNKn670lWpU/z/dMZ+0gGevsXboumf+Roy2Xgjjco+YXEB4+W54NNB4RF StUuwTc6yjy4Ds+Xgo9ivz7N3WfgKRY+l3bvzC4rgp241xtGJbGDuGgfZG/Rl/1B NChZUluaISi91KZ3sdLu2NG0Ga0ArA== =jtT8 -----END PGP SIGNATURE----- --==9DFobxFHdfyJkpkPI52grnATD6pSiP==-- From nobody Tue Oct 15 09:21:07 2019 Return-Path: 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 DB1F512010E for ; Tue, 15 Oct 2019 09:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJh6cBc6Rtdi for ; Tue, 15 Oct 2019 09:21:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68F4120033 for ; Tue, 15 Oct 2019 09:21:02 -0700 (PDT) Received: from dooku.sandelman.ca (214-137-20-31.ftth.glasoperator.nl [31.20.137.214]) by relay.sandelman.ca (Postfix) with ESMTPS id B87441F455; Tue, 15 Oct 2019 16:21:00 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8437BFD2; Tue, 15 Oct 2019 18:21:53 +0200 (CEST) From: Michael Richardson To: Kai Engert cc: openpgp@ietf.org In-reply-to: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> Comments: In-reply-to Kai Engert message dated "Tue, 15 Oct 2019 14:16:31 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 15 Oct 2019 18:21:53 +0200 Message-ID: <23498.1571156513@dooku.sandelman.ca> Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 16:21:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Kai Engert wrote: > The high level idea is: > - key generation requires a source of entropy > - instead of using the entropy directly, the entropy could be used to > seed a CSPRNG (like HMAC_DRBG), which is then used to obtain the rand= om > data that is needed for key generation. PHB's MMM offers a similar mechanism. Might as well have a single solution. See draft-hallambaker-mesh-* and=20 https://mailarchive.ietf.org/arch/msg/mathmesh/GF1d5X4F0eqAk6x7T9qQu6kh= AIw > I see the primary purpose for this recovery mechanism as desaster > recovery: - ensure the recovered primary key can be used to decrypt an > archive of old data, like the encrypted emails in a sent folder - all= ow > the use of the recovered primary key to create a revocation statement A secondary use is for keys that are generally kept offline. Instead of bringing them back from the "cold storage", the key is just renegerated each time from a printed piece of paper. My original PGPv3 root@sandelman.ca went through five kinds of media (5.25" floppy,=20 3.5" floppy, CDROM, DVD, USB key...)...=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2l8iEACgkQlUzhVv38 QpCAsQf/fBmrAa2kug7Rmft1yEqJJwxTAVONV/hDYgQ3zC2W6lXqm76pBHHU6T66 1w6/Z+zDw881kflDmequAQNM972ORKuqxD7blaA1KbRYsmJysCx9YOTNzDHSbkrE hffe65up3lr1p6LJxL4GAsns7uswlErXV9TEVLB8L6QUDiVGB3kWxJ8OXjuccMNH YPtdYHzUnwLQEzfL8Ukf5kY6ttpJ9TctTS9bogoWcPAWt1rJAFDH5vOHjnYAVJdF 9S6AUQmkdwJllhYnfZDWhKOoLpjtK1Rl/bkAQS/IjwS/cmd/3L2JhpTj8A+BS8JA DbxA7b0w0i2v7UdHs8+mlmHLoFSOXw== =KbLW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 15 10:25:09 2019 Return-Path: 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 1C6F412010F for ; Tue, 15 Oct 2019 10:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65XZnzR0nWN8 for ; Tue, 15 Oct 2019 10:25:03 -0700 (PDT) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B27120046 for ; Tue, 15 Oct 2019 10:25:03 -0700 (PDT) Received: by mail-oi1-f176.google.com with SMTP id w6so17465268oie.11 for ; Tue, 15 Oct 2019 10:25:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LzCVXtYJ8WrNmzl5ZRCbRv5/rY5h8ixB4EtgWThz2CQ=; b=PYwnYkG/zlh/buc4ljwYNrpVyj54h6MxzBlewL17BJj7Pf9Wscjf6JuSYvOEHuWfqz FFSLODrXUYKckSlCnI+15CIIeaCkcEFKbrOhrLQwhlqDRlr+fHWavQexAe6QCCHrGELA pR5ob04eSxkaAtxr+a4yXzd2gtYncyEzTPEKI3dHknzH2tr5eQBekAPy9z0ydRD17ws0 jF+vkmotMxw6VmaPLgJM/VJGiSsF/QuU2mj9rwIjIT98mJzWLplyejzgZE97A/ZOI90J zPxF0Hap8lmaSgk++4tvMgMPX+PGM/4i2FSSUbzlZJhBxjc4XgpG07O91JQZ17a6H9J0 0CPA== X-Gm-Message-State: APjAAAVSYTgqiK7zQRDbRdN/1/5qqxT07PvQRnFXVoiQhBM/QxM7dyS5 hqRO1mS2myW1+njHXi4V5d/IAO6QsaggRjBZl3LtDDE3B2w= X-Google-Smtp-Source: APXvYqyBu96v0DLTMM7JaXLBmg90+kYNBrBhanIuJQWWrXuULWwRu4sGlNHHMLskPENg0AN7D78SQEo7EPoLmOciJig= X-Received: by 2002:aca:af41:: with SMTP id y62mr31108821oie.100.1571160302465; Tue, 15 Oct 2019 10:25:02 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> In-Reply-To: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> From: Phillip Hallam-Baker Date: Tue, 15 Oct 2019 13:24:54 -0400 Message-ID: To: Kai Engert Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="000000000000b6b8fd0594f643b1" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:25:07 -0000 --000000000000b6b8fd0594f643b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have been thinking on very similar lines after being prompted by Michael Richardson. I don't have that mechanism specified in the draft yet but already proposed a scheme to do exactly this sort of thing as part of UDF. http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html The basic idea is to add a KeyGen UDF type (200) with an initial character Z. So a key generation identifier will look something like: ZAAA-DJUY-H7TF-SFLK-CWAW-TKC4-O5HQ The breakdown I see is Byte 0 =3D 200 Byte 1-2 =3D a 16 bit key type identifier Byte 3-n =3D the KDF master secret. I suggest using only 15 bits of the key type identifier giving 32K possible 2 byte keys and extension to 4 bytes should it prove necessary So lets say the keyid above is 12 and that is for an Ed25519 key. To derive the private key from that, Private =3D KDF, ( UnBase32 (DJUY-H7TF-SFLK-CWAW-TKC4-O5HQ), UDF-Z-12, 256) That is the master secret is whatever the binary blob part of that string is, the kdf salt is "UDF-Z-12" (or something unique) and we want 256 bits of output. This obviously requires a bit more effort for RSA keys etc. Note that since we are using a KDF, the UDF does not need to be as long as the generated key. It only needs to be long enough to present a sufficiently difficult work factor to prevent a brute force attack. So 256 bits is sufficient for an Ed 448 key. This construction has some interesting security advantages that I haven't fully mapped out yet. It enforces a rigid construction for a start. The scope for the type of games Moti Yung likes to play are greatly reduced because they are forced to work forward from a random value. The advantages of building on UDF are 1) It is designed to be generic so someone can use the same key generator for SSH, OpenPGP, S/MIME, their own stuff. 2) There are bindings for URIs and QR codes already defined. 3) We can make use of Shamir Secret sharing to split the key into 2/3 or 3/5 shares already defined. 4) There is a BOF on the MathMesh already planned for Singapore. Besides using Shamir secrets for splitting a random key, we can use them for generation. So lets start off by generating two random shares: Everything after the first two bytes is random noise: Share 0: SAQG-A7BL-6YQ6-G5K3-HYKQ-I54D-VWHG-C Share 1: SAQZ-2TRR-KQB6-BENB-CIKI-PBK6-72SX-G We can now 'recover' the key: Key: EAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ We need at least as many seed shares as our quorum of course. In this case it is 2. If we require more than 2 shares, we can generate the additional shares in the normal fashion: Share 2: SARN-UIBW-WHS5-3LPG-4YKA-VEZ2-J66I-K Why is this useful? Well lets say you want to be really sure that your key has randomness from more than one original source. This approach lets you do it without recourse to the meta-cryptography used in Mesh device key provisioning. While the Mesh makes use of UDF, it is not necessary to implement the whole of the Mesh just to use the UDF piece. But the Mesh does bring a lot more to the table. In particular, the Mesh provides a single point of management for all of Alice's keys across all her devices. So if she loses her device or she has it confiscated in an airport, she can shut down ALL her apps with a single message to her Mesh Service. The Mesh is also using some crypto that is not in the regular canon of industry crypto like threshold cryptography and key combination. These allow for much tighter control of crypto across devices. Using the Mesh to manage her keys, Alice can prevent her phone being able to decrypt any of her data while she is travelling through an airport and only re-enable those capabilities under very specific conditions. On Tue, Oct 15, 2019 at 8:16 AM Kai Engert wrote: > Today, saving a backup of an OpenPGP secret key usually requires storing > a file. > > It could be useful to standardize an an additional recovery mechanism, > that doesn't require the secure storage of a file, but is based on a > list of words written to paper. > > The high level idea is: > > - key generation requires a source of entropy > > - instead of using the entropy directly, the entropy could > be used to seed a CSPRNG (like HMAC_DRBG), which is then used > to obtain the random data that is needed for key generation. > > - the entropy, plus any meta data required to generate the key, > could be encoded as a list of words, which the user can write down. > > - at a later time, the user could recover by using OpenPGP key > generation software that supports this recovery mechanism, > could provide the word list, which is decoded to obtain the original > entropy bits. > > - after creating the initial key, if additional keys need to be > generated (e.g. a subkey), the CSPRNG is used to fetch all additional > random numbers that are required. > > During the OpenPGP summit last weekend it was mentioned that having this > kind of mechanism available could be useful, without going into detail. > > Tobias M=C3=BCller pointed me to an existing implementation of a similar = idea > for creating OpenPGP keys : https://github.com/skeeto/passphrase2pgp > > A definition of such an approach exists for the kind of private keys > that are used in the Bitcoin world, and IIUC several applications > implement it: > https://en.bitcoin.it/wiki/BIP_0039 > > (For creating additional child keys, an additional standard exists for > creating them, just for completeness, I don't know (yet) if the OpenPGP > mechanism might require (or could use) something similar for sub keys: > https://en.bitcoin.it/wiki/BIP_0032 ) > > Would you be interested to discuss how to standardize such a recovery > mechanism, and would you be interested to implement it in your > applications? > > Besides the raw entropy, what other meta information would we have to be > included, to ensure that key generation can be repeated? > > I see the primary purpose for this recovery mechanism as desaster recover= y: > - ensure the recovered primary key can be used to decrypt an > archive of old data, like the encrypted emails in a sent folder > - allow the use of the recovered primary key to create a revocation > statement > > If the guts of the BIP_0039 specification is considered equivalent to > the needs of a mechanism for OpenPGP secret keys, maybe it could be a > useful shortcut to use the same approach. > > It uses lists with 2048 words, and encodes each word as 11 bits. > A seed of 128 bits with a checksum of 4 bits is encoded into 12 words. > > Potentially the metadata required to encode a public key could be > encoded into additional words. > > Here's a result of some initial brainstorming, but I'm unsure if I've > identified all the meta information that would be necessary to repeat > the key generation, but as a starting point for discussion, we could > encode the following meta/descriptor information into 33 bits, which > could then be encoded into three additional words. > > 1 bit > Version of this descriptor prefix, always 0. > > 7 bits > Number of entropy bytes that will be encoded as a mnemonic. > Encoded as a multiple of 32 minus 1. > Smallest value possible is 32, encoded as 0: (0 + 1) * 32 =3D 32 > Largest value possible is 4096, encoded as 127: > ((127 + 1) * 32) =3D 4096 > (Maybe 4096 is unnecessarily large, and we could use a smaller > amount of bits for this.) > > 7 bits > Identifier of the public key algorithm, as defined in RFC 4880 > section 9.1 > (Assumption that this implies the usual associated sub key > algorithm. If not possible, we'd need additional bits to > encode the sub key algorithm.) > > 18 bits > Key size plus 1 > Smallest value possible, encoded as 0: 1 > Largest value possible, encoded as 262143: 262144 > (Maybe again that's unnecessarily large and we could use the > bits for something else.) > > A full recovery mnemonic based on a 128 bit seed could consist of 15 > words, 3 bytes for the descriptor prefix and 12 bytes for the seed. > > I hope some of this message makes sense. > > Regards > Kai > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --000000000000b6b8fd0594f643b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I h= ave been thinking on very similar lines after being prompted by Michael Ric= hardson. I don't have that mechanism specified in the draft yet but alr= eady proposed a scheme to do exactly this sort of thing as part of UDF.


The basic idea is to add a KeyGen UDF type (200= ) with an initial character Z. So a key generation identifier will look som= ething like:
ZAAA-DJUY-H7= TF-SFLK-CWAW-TKC4-O5HQ

The breakdown=C2=A0I see is=C2=A0

Byte 0 =3D 200
Byte 1-2 =3D a 16 bit key type identifier=C2=A0
Byte 3-n =3D the KDF master se= cret.

I suggest using onl= y 15 bits of the key type identifier giving 32K possible 2 byte keys and ex= tension to 4 bytes should it prove necessary

So lets say the keyid above is 12 and that is for an E= d25519 key. To derive=C2=A0the private key from that,=C2=A0

Private =3D KDF, ( UnBase32 (DJUY-H7TF-S= FLK-CWAW-TKC4-O5HQ), UDF-Z-12, 256)

That is the master secret is whatever the binary blob part of th= at string is, the kdf salt is=C2=A0 "UDF-Z-12" (or something uniq= ue) and we want 256 bits of output. This obviously requires a bit more effo= rt for RSA keys etc.=C2=A0

Note that since we are using a KDF, the UDF does not need to be as long a= s the generated key. It only needs to be long enough to present a sufficien= tly difficult work factor to prevent a brute force attack. So 256 bits is s= ufficient for an Ed 448 key.

This construction has some interesting security advantages that I haven= 't fully mapped out yet. It enforces a rigid construction for a start. = The scope for the type of games Moti Yung likes to play are greatly reduced= because they are forced to work forward from a random value.


The advantages of building on UDF are

1) It is designed to be generic so = someone can use the same key generator for SSH, OpenPGP, S/MIME, their own = stuff.

2) There are bindi= ngs for URIs and QR codes already defined.

3) We can make use of Shamir Secret sharing to split the = key into 2/3 or 3/5 shares already defined.

4) There is a BOF on the MathMesh already planned for = Singapore.

=
Besides using = Shamir secrets for splitting a random key, we can use them for generation.<= /div>

So lets start off by gene= rating two random shares: Everything after the first two bytes is random no= ise:

=
Share 0: SAQG-A7BL-6= YQ6-G5K3-HYKQ-I54D-VWHG-C
Share 1: SAQZ-2TRR-KQB6-BENB-CIKI-PBK6-72SX-G= =C2=A0=C2=A0

We can n= ow 'recover' the key:

Key: =C2=A0 =C2=A0 EAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ

We need a= t least as many seed shares as our quorum of course. In this case it is 2. = If we require more than 2 shares, we can generate the additional shares in = the normal fashion:

Share 2: SARN-UIBW-WHS5-3LPG-4YKA-VEZ2-J66I-K

Why is this useful? Wel= l lets say you want to be really sure that your key has randomness from mor= e than one original source. This approach lets you do it without recourse t= o the meta-cryptography used in Mesh device key provisioning.


While the Mesh makes use of UDF, it is not neces= sary to implement the whole of the Mesh just to use the UDF piece. But the = Mesh does bring a lot more to the table.

In particular, the Mesh provides a single point of manageme= nt for all of Alice's keys across all her devices. So if she loses her = device or she has it confiscated in an airport, she can shut down ALL her a= pps with a single message to her Mesh Service.

The Mesh is also using some crypto that is not in the= regular canon of industry crypto like threshold cryptography and key combi= nation. These allow for much tighter control of crypto across devices. Usin= g the Mesh to manage her keys, Alice can prevent her phone being able to de= crypt any of her data while she is travelling through an airport and only r= e-enable those capabilities under very specific conditions.=C2=A0


On Tue, Oct 15= , 2019 at 8:16 AM Kai Engert <kaie@kuix.= de> wrote:
https://github.com/skeeto/passph= rase2pgp

A definition of such an approach exists for the kind of private keys
that are used in the Bitcoin world, and IIUC several applications
implement it:
https://en.bitcoin.it/wiki/BIP_0039

(For creating additional child keys, an additional standard exists for
creating them, just for completeness, I don't know (yet) if the OpenPGP=
mechanism might require (or could use) something similar for sub keys:
https://en.bitcoin.it/wiki/BIP_0032 )

Would you be interested to discuss how to standardize such a recovery
mechanism, and would you be interested to implement it in your applications= ?

Besides the raw entropy, what other meta information would we have to be included, to ensure that key generation can be repeated?

I see the primary purpose for this recovery mechanism as desaster recovery:=
- ensure the recovered primary key can be used to decrypt an
=C2=A0 archive of old data, like the encrypted emails in a sent folder
- allow the use of the recovered primary key to create a revocation
=C2=A0 statement

If the guts of the BIP_0039 specification is considered equivalent to
the needs of a mechanism for OpenPGP secret keys, maybe it could be a
useful shortcut to use the same approach.

It uses lists with 2048 words, and encodes each word as 11 bits.
A seed of 128 bits with a checksum of 4 bits is encoded into 12 words.

Potentially the metadata required to encode a public key could be
encoded into additional words.

Here's a result of some initial brainstorming, but I'm unsure if I&= #39;ve
identified all the meta information that would be necessary to repeat
the key generation, but as a starting point for discussion, we could
encode the following meta/descriptor information into 33 bits, which
could then be encoded into three additional words.

1 bit
=C2=A0 =C2=A0 Version of this descriptor prefix, always 0.

7 bits
=C2=A0 =C2=A0 Number of entropy bytes that will be encoded as a mnemonic. =C2=A0 =C2=A0 Encoded as a multiple of 32 minus 1.
=C2=A0 =C2=A0 Smallest value possible is 32, encoded as 0: (0 + 1) * 32 =3D= 32
=C2=A0 =C2=A0 Largest value possible is 4096, encoded as 127:
=C2=A0 =C2=A0 =C2=A0 ((127 + 1) * 32) =3D 4096
=C2=A0 =C2=A0 (Maybe 4096 is unnecessarily large, and we could use a smalle= r
=C2=A0 =C2=A0 =C2=A0amount of bits for this.)

7 bits
=C2=A0 =C2=A0 Identifier of the public key algorithm, as defined in RFC 488= 0
=C2=A0 =C2=A0 section 9.1
=C2=A0 =C2=A0 (Assumption that this implies the usual associated sub key =C2=A0 =C2=A0 =C2=A0algorithm. If not possible, we'd need additional bi= ts to
=C2=A0 =C2=A0 =C2=A0encode the sub key algorithm.)

18 bits
=C2=A0 =C2=A0 Key size plus 1
=C2=A0 =C2=A0 Smallest value possible, encoded as 0: 1
=C2=A0 =C2=A0 Largest value possible, encoded as 262143: 262144
=C2=A0 =C2=A0 (Maybe again that's unnecessarily large and we could use = the
=C2=A0 =C2=A0 =C2=A0bits for something else.)

A full recovery mnemonic based on a 128 bit seed could consist of 15
words, 3 bytes for the descriptor prefix and 12 bytes for the seed.

I hope some of this message makes sense.

Regards
Kai

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--000000000000b6b8fd0594f643b1-- From nobody Tue Oct 15 13:15:24 2019 Return-Path: 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 DD6F1120044 for ; Tue, 15 Oct 2019 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0AREQvzpTrZ for ; Tue, 15 Oct 2019 13:15:20 -0700 (PDT) Received: from mr85p00im-hyfv06021401.me.com (mr85p00im-hyfv06021401.me.com [17.58.23.190]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE3612004A for ; Tue, 15 Oct 2019 13:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1571170519; bh=/zLRgz1RLVy+lZ85tiZVJzjUjm2HsRd3i0v4RZQfmkU=; h=Content-Type:Subject:From:Date:Message-Id:To; b=ZHI7Q6E15tcl6NOVaGOnkPbtpOh8SrS3taykRBgtIdj+sHH205VIMlBZ1Za9RjejA OvsIYwGEKZxErBmpzBiBKHl7efO32/kYLsZeIHVixJOgCCy+Ec2loESseyY8J4RPuV vFKWmuwGCk8GcpXhMus6lWQakM4iTnp6riI6W65mDJ8JwHAmh+9AwzLG+o3IZdiitz mH6GYYs7k1/ObuegML4L80VGTDF3Crhmb8ZfTBFw5iFRJwahno6bdFRPhg3KQtZ4wN rD/FJW0lOPLJYXqKKD8VU9NR95SYlC67J+hWldl6U3iHZh63iK7CobmWhJN+38okCH GyHhD+cpil0IQ== Received: from [10.125.12.170] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-hyfv06021401.me.com (Postfix) with ESMTPSA id B77489C0B95; Tue, 15 Oct 2019 20:15:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> Date: Tue, 15 Oct 2019 13:15:15 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> To: Kai Engert X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-15_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=610 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1910150173 Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 20:15:22 -0000 >=20 > I hope some of this message makes sense. >=20 I think it makes sense. You're looking at having a way to seed a DRBG = (PRNG), so that that seed can be used to deterministically generate a = key, and that seed being reasonably small, and can be encoded in a way = that's easy to store on paper as well as use for generating the same key = later. This sounds like a good idea, but as others have said, it's more general = than OpenPGP. Really what you want is a standardized, loadable DRBG, and = then that DRBG could be bolted into some OpenPGP implementation for key = generation. That latter part is software issue and really ought to be generalized = beyond OpenPGP, and then some implementation of OpenPGP could have the = feature of creating a key from such a loadable seed. It sounds useful to some people, but outside the scope of OpenPGP = documents, just as the design of other RNGs is beyond the scope of = OpenPGP documents. Jon From nobody Wed Oct 16 18:46:42 2019 Return-Path: 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 BEE72120047 for ; Wed, 16 Oct 2019 18:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.757 X-Spam-Level: X-Spam-Status: No, score=-2.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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=Mw2MbT+I; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=J/1AhjIj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h6Smwzwjr0o for ; Wed, 16 Oct 2019 18:46:38 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF9B120019 for ; Wed, 16 Oct 2019 18:46:38 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1571276797; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=hyWXz4a6xLINvVt64RDYdSzUojXG32BMY0ebL4kEHeA=; b=Mw2MbT+I4RwUry5mdM7W2yALyD4ds9ToD/eRFMgOZj7eU7UDYhT3Y7Eb eLZUP1q0jfDAZaPWWdya/0Lhfj2tBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1571276797; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=hyWXz4a6xLINvVt64RDYdSzUojXG32BMY0ebL4kEHeA=; b=J/1AhjIjxvujULgks5mSxhV4HQq/Hay7aQTnWVLT+STKLRtCIcZ1eqoG xnWd6h5RF8HaUZ8Eae0GKvlhBVGMYohAftauhQcW9embHcwecYPkWNsOEH GnFv7Yww1CFWtHIbs3WxKUuabg5rUZUaf/pqbe8bguwNzVVCcOCuSBZmq0 S29PlHEmCVk1x2mnjKZ66qNvM9NUyJ8QnF0/sLrvLtygdWQ7tAQqr1vTiZ Y02lYT3qIPh9CSKpmG7nxVOD+dGAnAnfrYckiPazv+/UYHVZlKzfqq9xWb uCoxzCbHPwhvUXGODMexTeS3tT8DlfP+aCSPpQMnnXR4NwhBuGJlQg== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 1FC1FF9A7; Wed, 16 Oct 2019 21:46:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A02B2206F8; Wed, 16 Oct 2019 15:27:51 -0400 (EDT) From: Daniel Kahn Gillmor To: Kai Engert , openpgp@ietf.org In-Reply-To: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 16 Oct 2019 15:27:51 -0400 Message-ID: <8736fs7ao8.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 01:46:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for writing this up, Kai! On Tue 2019-10-15 14:16:31 +0200, Kai Engert wrote: > 7 bits > Number of entropy bytes that will be encoded as a mnemonic. > Encoded as a multiple of 32 minus 1. > Smallest value possible is 32, encoded as 0: (0 + 1) * 32 =3D 32 > Largest value possible is 4096, encoded as 127: > ((127 + 1) * 32) =3D 4096 > (Maybe 4096 is unnecessarily large, and we could use a smaller > amount of bits for this.) > > 7 bits > Identifier of the public key algorithm, as defined in RFC 4880 > section 9.1 > (Assumption that this implies the usual associated sub key > algorithm. If not possible, we'd need additional bits to > encode the sub key algorithm.) > > 18 bits > Key size plus 1 > Smallest value possible, encoded as 0: 1 > Largest value possible, encoded as 262143: 262144 > (Maybe again that's unnecessarily large and we could use the > bits for something else.) I'm not sure i see the value of any of the above fields for such a seed. If they're needed for OpenPGP, i think they're incomplete (lacking key creation timestamp at least) -- but i don't think they're needed. For initial secret key generation, these parameters -- key algo, key size, creation timestamp, etc -- can be made at key creation time and don't need to be recorded in the phrase. For secret key recovery, presumably the user has the OpenPGP certificate ("transferable public key") available to them already, which contains all the above information already. I'd imagine that the recovery process in the OpenPGP context would take the certificate and the mnemonic, deriving all of the above fields from the certificate. I think there are at least three ideas in this e-mail: a) The general idea of a loadable seed to a well-defined, well-known DRBG. This requires declaring the size of the seed, and choosing the DRBG algorithm. This might also include "stretching" (e.g. argon2) needed to make the seed resistant to large-scale automated attack when parts of the seed are accidentally revealed (e.g. imagine muttering memorized words/phrases while sleeping). b) The (bi-directional?) mapping between that seed and a string that humans can handle (record easily? commit to and recall from memory? replay without ambiguity?). This requires defining the goals of the mapping (is it for recovery? daily use? verification?), and a (language-specific?) vocabulary list that offers the relevant properties. (this sounds a little like p=E2=89=A1p's "Trust Words" proposal, except that that proposal isn't bi-directional and the vocabulary lists don't appear to have any analysis for dealing with phonetic or orthographic ambiguity) c) The use of such a DRBG to generate OpenPGP secret key material, given baseline parameters (or deriving those parameters from a certificate, in the case of recovery) I'm not personally very convinced about this general approach -- it's the equivalent of an unchangeable password that you've committed to publicly (so anyone who thinks they have a good guess at your password can verify it offline against your public key fingerprint). I know it's something that some folks are excited about, though, and part (c) might be in-scope for this mailing list, particularly the OpenPGP-specific parameters. I'd encourage anyone excited about this work to try to write down how to do (c) alone in a way that could be interoperably implemented. It sounds like Phil's UDF draft outlines the general idea for raw cryptographic objects, but doesn't have a mechanism specified yet, or a mapping between them and OpenPGP. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXadvNwAKCRB2GBllKa5f +OWaAP9kWUfq03ESPNfXRsZ4fm+mt459uUybHOcgUwg4NeyDDgD9F1MKdApNvIe3 7nhk8R+5wSppzzNcgkXRKPFlPrMVdQE= =trjM -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 17 02:02:07 2019 Return-Path: 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 870E5120851 for ; Thu, 17 Oct 2019 02:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LUiAp3EonUl for ; Thu, 17 Oct 2019 02:02:02 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [93.90.207.85]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44598120855 for ; Thu, 17 Oct 2019 02:02:01 -0700 (PDT) Received: from [10.137.0.12] (ip-178-203-234-118.hsi10.unitymediagroup.de [178.203.234.118]) by cloud.kuix.de (Postfix) with ESMTPSA id ED639185981; Thu, 17 Oct 2019 09:01:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1571302920; bh=cmGS2eQHzwr3o49NRotgx3g6ZOMLmZgnhAAWYka3mQ0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YbxZEh5MUzdx17LagfLEzn6qm+7PBC37Dsc0ihHvme/jQTEG2vIc1UyNtOd2DR3AW holod5qBG3RshsTQsK8QNCXr5WdwPi6MCFKBwXplnVXCvatW3E4TxGI8r7i3i0Nbgs FvRKZ4QZvWm6JlAuasi/Q0g1837tstnBKeLPIq5LsY1v2UUuxbYIRhci9WBhhRSKE4 JSX7vUAXAtexEekgW3X/yWHiTK4vOcwANoRrp3LfPcayoOGAtaPfxntBtazGm3FXqK 5sKDI0YaXC85xgvWb2Sud76hyshoLsSwCyNd/bys50Zf903eE1ModTu+3gBUNIxEv3 Im1zEcFXBDBVg== To: Daniel Kahn Gillmor , openpgp@ietf.org References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <8736fs7ao8.fsf@fifthhorseman.net> From: Kai Engert Autocrypt: addr=kaie@kuix.de; keydata= xsFNBE8oE/UBEAC/Vx4tHVkfPdGf0BFMGcidXzAXKQ4+gI2F5rPBoV9fEtYngLHzm7+a6DL2 v5Jl5b4by9KtUbfIJysR1iniLWMJVPXZcyC4ovGouZ4MGK5cD9kMy+JdwebCs5/tj51vcvrS 08dP7r9Q0f0H7tsqhtVWuPFt+ZZEj8fIxjMgE3Z5BcyoGT1mXQ544RA0vr0fB9MngvfteD3L /wL2miDnYVtwB+VHC6kEB75Pte/yz1kFc/TDqKT8F45M3invhccY8Zwe7F88+uS+tgR5B3Ga RMc9WChZr5ed5vRxSLrGqBGSWBKomKuWXNFVMrZAOaq+W/+kOdNSXLdJSvXIAgV4Gywf1D0r ZTi8V+UoiTY8eDfT4OlBJrbbkge92/lrqaorAsuo/DVmfv7ARk7q2jvbSZD39zkWpLNsAulz gZOr+ffEHKy0f9fNwzenHpKvNtTUWGChEyDf7a6EtTBZsxAYco0xAtFOoQVwx5UzZk4tMVhv lrATrvmFdK5SLroDuwtSLUBJ5MhICyaB1kN7YSatQs33D+M5oPKVC+mn1WB/nznU475cssBW Asw+/K4VtXN08HxVFEvpV5MtpoYGe/cqsV87aVr/Igg45DVKtMMK8W5AmJDdGru3caxdVkkW fis9F1GBkk7ZPgip4cprh3KicuKsXhVrjk2mC/kCR+mrlY8ncQARAQABzSNLYWkgRW5nZXJ0 IChhdCB3b3JrKSA8a2FpZUBrdWl4LmRlPsLBegQTAQIAJAIbAwIeAQIXgAIZAQUCVdbtjAUL CQgHAwUVCgkICwUWAgMBAAAKCRAcJ0I3JQB3JEoOEAC9YaJFZCdCFXMb9HkQ4TS1z813EgTO lDFQwQ9vF26edvBjm80xcLQYUN5iRr6RNcHpx6FZLUX+AwAB5Cf2swVjvZB3LycwlKyKVuwd bXoLHPgq0XVu2l/ZbEKKmIR70UGAL/CKmZZm5rimicD1B5P+VXrnSl8uA7MjQFNnWnDuDHGk 9A/dl7RAEAenAiFlRFR5lwu9U/4TG0OrACgp7OIls3/jcszRRMJrc5OiTGWPq4d+Bo3a1yqA fdS2VjMObO8+zO7+4tact5uVFxrbMIRULKP0xJC/X77koUyn6ZSFIyFjJR2I/p4PCCLD0soJ 06e1e9bKUsKowFGwrvMnXqGEA4lij22R80paRH7VQ0QKQW9RDSqlF1YUafHpCt9D5i7HG2Ft ZgYz7VlfS27YMvG6Np+fN5Devh9Hap6fK5+SBTcs8v0Tgf8Ljx7OlajRHNtBxqRcPghnCZTJ oQpAJup5TYeqSGyp/Q2VT80h9iySGfBnn30qhcTr5lqOg/2NvQeu9wNVKBPmr8QpCfYb7ENZ CBifohzqBV8D6HaoBFeNts37kugcMWTw4C/RCtYI8TnjR18caDkc3kDh5p6anLnnQhCnGSVu LFj52lazHkj3FE+Ijg8ir95hm0d4PWZqk5UNfEPUa6ltBkHZstdpBvtqN+HxXpovqf8agBaZ ol2vXc7BTQRPKBP1ARAA54JU09VzBOPw44IYINiuQAEeyikO5sLT+Ixee8MM+T8tXk0Z9RSw UVctu8DwM+f8NjRI+dvmGSgezsiNL1ZkVuN37GM4dg7ZJ8oZCB5/YQQCCx1z7q4d68XsEfTs edl+Y2GcggbR6EpN4RbR38N6uhwKFZw0meuP6m1NaRCnihciJrXdoKxXcoHAxy3balGTPAbv OUmQaqI7dY5DVFPOT5I2wl1cWbkkTcx4wu8190sSMeW/IbwIg7inC/nqXCSKL633+Hv/2GcV zvBNK8JxO5YaHuHl+GBwP6cHlotHd2qr/BSyhYCt3CcMDHXR+vwSwawC+/zUpR5THrVLT6E/ hlpAZX5HQsY9BMrllI0Ap7MClj+kvRlkukNfc3/CKpAL1RjDV5+sr91ffBNXbZgpsp3/uCI6 QuJpFdUY8js5aYNwHCFbX8xkzdFqG95vt+uNoq/F7p7dEQi3BE0H2b0c4kuJX4G9MrAKdyfY r1KiPX513AQeIXZCE9UogON5jvKF6PBTTuzomsCZBa9ExbkLv+uCm7Q+EC4WwvvpbUaaLpmu t+oqnsSrYehg4ydm5NRhgfJy+Ris1sKAptyA7AlDWWsP5fFZE0rxeoDrTdbX6JVjxT509DtW a4rI0qgGTt625J6irm6nfbF8M1V5ZaBmSstWC/PDdggsfl35abQHxk8AEQEAAcLBXwQYAQIA CQUCTygT9QIbDAAKCRAcJ0I3JQB3JA5FEACCSZIzygwTFoOcFciojcbY3uvNamflJ0fMAv+h wO/Blprd1cHBmI0dQoTbpQ4NX33f9PVh4X9eCrxMCzUKB8RBS5ZNk5P0PYhJNooqKTmM3JIl coyvTruz9/Q2nbPA6z+0c7KJpmdJKn60vZfR4UDfwIOEqYvrZRbld3Bv1XXUQ6NHWvX6x2Ft vmASNON5m7ml4zwH6qSASJ0JZo0CuLwSOanmc5r+rDwtHHGqEpp6VwXpcPyF6ZUG5i0rU4OT H2y0kOb+7igK25LmjiXFNqbQb+K4lchVpxIGV6MvW6GAd3L0ei8cnYccZhAoPNCbKgEIA7qW 8g93U6Wf+P0yu9DbOqz2ETXoEqRJVDNLTrrvKyRYBDNpqvleUJtBHMnpU1Oqhf+ddCT292Ux fK9CoQe+st1QD5Mazlrnw4PuH7etS/Y2na7rXwqvop/IIu6Ba90/nddv/0cqvaRaDFYVN6HU GATLienjv0yS0QVTf/2x7B2NCtyT3lqRHrFByzm0FPAFxbr1HFJgE5CPGrmCn6ToR77gNBkL KUU3MVTGTRe35JHc5QVFuUwcrRBT/EcK8A3u0wmORswNnDylisYhzrw0RuS6WSvhAvuVQ0yF uh6SYw72DFmbX/h1A9BBMZ50tJtgqbD4Q+74J44SP8RD7qspTk6NNBa6D835NLx652yXwQ== Message-ID: <70fb51f6-86ec-a4e3-9641-07f69630ee70@kuix.de> Date: Thu, 17 Oct 2019 11:01:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <8736fs7ao8.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Or258krH0FcM0JbB7LIauxUWIgWY8hmoJ" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 09:02:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Or258krH0FcM0JbB7LIauxUWIgWY8hmoJ Content-Type: multipart/mixed; boundary="xVyMQkPrXWxI0gbpVr5QyHmSn2dPTVtmi" --xVyMQkPrXWxI0gbpVr5QyHmSn2dPTVtmi Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 16.10.19 21:27, Daniel Kahn Gillmor wrote: > I'm not sure i see the value of any of the above fields for such a seed= =2E > If they're needed for OpenPGP, i think they're incomplete (lacking key > creation timestamp at least) -- but i don't think they're needed. We could add the creation timestamp. To save bits, we could introduce a new epoch, that starts in october 2019. This new recovery mechanism wouldn't support older keys. With a 33 bit unsigned integer, we get 272 years. To compute, calculate the regular 64bit unix epoch (since 1970). Then substract the new epoch start timestamp (e.g. 1572000000 for 2019-10-25). Encode that as a 33 bit unsigned integer. Will work until year 2272. > For initial secret key generation, these parameters -- key algo, key > size, creation timestamp, etc -- can be made at key creation time and > don't need to be recorded in the phrase. >=20 > For secret key recovery, presumably the user has the OpenPGP certificat= e > ("transferable public key") available to them already, which contains > all the above information already. I'd imagine that the recovery > process in the OpenPGP context would take the certificate and the > mnemonic, deriving all of the above fields from the certificate. What about a user who owns just a single computer, it breaks, and they've lost all their files, and only the IMAP mail archive is left? Maybe the user never uploaded their key to a key server, there's no backu= p. Maybe the user has an email with the attached public key somewhere, but can it be found reliably? If we don't record any key information in the Mnemonic, the user must perform some bootstrap action, prior to being able to regenerate the key:= - look at existing encrypted email, an extract the key ID, to understand which key needs to be recovered. But that might be a subkey ID, so further searching is required to identify the ID of the master key? - search through existing email, in the hope that the full public key is attached somewhere, either regular attachment, or maybe an outgoing autocrypt header (only if user's client had autocrypt headers enabled). Maybe there's no such email? - contact one of the correspondents, and ask them to send the public key back. Maybe the user doesn't want to do that? It might be useful if recovery didn't depend on the above. > I'm not personally very convinced about this general approach -- it's > the equivalent of an unchangeable password that you've committed to > publicly Why do you consider it equivalent, if the seed was randomly generated, and the list of words isn't influenced by the user? Thanks Kai --xVyMQkPrXWxI0gbpVr5QyHmSn2dPTVtmi-- --Or258krH0FcM0JbB7LIauxUWIgWY8hmoJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEIdFuZ+GDmMjand8uHCdCNyUAdyQFAl2oLgcACgkQHCdCNyUA dyQr8w/+KFsPo6pJpdkoa6p2n3AaCgM5LiFT3DimhcGvoqpFGP0IMyyORYKquFHb drU6EAnnJ+nLpxUWKK41CmLFoyRT7t7kcD+L6TAiu76Geq9H96jB3LtBCF3Gl5bU T83P9JMsaDeCj9Ms/qQG+a7azLCvTZAfYBAWo5+nG0HtaDHQ5m6Ft0YTV9XMPujs NMqC5AEImGwhW4feumJe6xenyA+4fKpUofTAGczhtJltoCkji5nx3e/u5xe52d/V 3erXGBus515dY1rYBrgwbjCFmSjTO+2Zas3BcsYtQFLPiliqaisgETTuELax3b6w yq1Z4x3s5Igo2X15mtlv6Os85m38yrRtZZOmobF0SdEDgpNfpzAhiozwQm1mXU+P 9aO414EUjHYSCfF9D/5UnAaEWz0R/ZEcupVNyznazF2jJdMcilF51DtC4Ri6/feM w/zMzgauzz4wad5jZJZKPlVSzLi6fefus6+27VfEMybef1xmbcxpir82jmE51zy8 QiGB4slAuWzEqp73guSwJx7nQTlxC3+wpT4lMILtVAEfk4mTXjZHtY/h5sMQGucl Wb5RL01sMe60nnJWyT/JxEMh1I3NNCeuS2teR5W9LouVMg5AHYN66ITiMkUZY/oF WjNdMcBFi+hcgzykvYm/OzErwWZ789s8pDJT+a3f+l6RQ3162ps= =JBEn -----END PGP SIGNATURE----- --Or258krH0FcM0JbB7LIauxUWIgWY8hmoJ-- From nobody Thu Oct 17 02:13:11 2019 Return-Path: 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 58237120099 for ; Thu, 17 Oct 2019 02:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfLzgw7q7SuX for ; Thu, 17 Oct 2019 02:13:07 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [IPv6:2001:8d8:1801:86::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8847012008C for ; Thu, 17 Oct 2019 02:13:07 -0700 (PDT) Received: from [10.137.0.12] (ip-178-203-234-118.hsi10.unitymediagroup.de [178.203.234.118]) by cloud.kuix.de (Postfix) with ESMTPSA id 53943185986; Thu, 17 Oct 2019 09:13:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1571303583; bh=Rss8ibc+Z0ljeCmTnj0Ib0uR8m6OqX5GSIhSibGbbh0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GE2Rch3EBysYqcvUgkVm6/av9Qh13GuGXcRspuYl5Ctx5/IMkIp8zSWOGIoKDSqng ymfM+DTKkT6RpX+aSv6TmoBBBTR8waW1sFEov/r/oTKsyFMA604X0mLeo8YDa7svWj ZzcWWcOdIIL9+M5lzmPmNF3g3Envo3Bl6xQ63thtKr0xM9yHUETpgbsCIBcxxkoWOq u114qA55X7/zeIE/v95QKZ3J+mIiisMr919sFkLWES+ufSZgCF9LNuX3yaZczCfppP HIRav0SRFD178B9+ALh1Iq4uhF+zZXiPiewi8DraJEJOB8cMBy0piY+441lIke0Emx +cvGbpp4Nx1dw== To: Jon Callas Cc: openpgp@ietf.org References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> From: Kai Engert Autocrypt: addr=kaie@kuix.de; keydata= xsFNBE8oE/UBEAC/Vx4tHVkfPdGf0BFMGcidXzAXKQ4+gI2F5rPBoV9fEtYngLHzm7+a6DL2 v5Jl5b4by9KtUbfIJysR1iniLWMJVPXZcyC4ovGouZ4MGK5cD9kMy+JdwebCs5/tj51vcvrS 08dP7r9Q0f0H7tsqhtVWuPFt+ZZEj8fIxjMgE3Z5BcyoGT1mXQ544RA0vr0fB9MngvfteD3L /wL2miDnYVtwB+VHC6kEB75Pte/yz1kFc/TDqKT8F45M3invhccY8Zwe7F88+uS+tgR5B3Ga RMc9WChZr5ed5vRxSLrGqBGSWBKomKuWXNFVMrZAOaq+W/+kOdNSXLdJSvXIAgV4Gywf1D0r ZTi8V+UoiTY8eDfT4OlBJrbbkge92/lrqaorAsuo/DVmfv7ARk7q2jvbSZD39zkWpLNsAulz gZOr+ffEHKy0f9fNwzenHpKvNtTUWGChEyDf7a6EtTBZsxAYco0xAtFOoQVwx5UzZk4tMVhv lrATrvmFdK5SLroDuwtSLUBJ5MhICyaB1kN7YSatQs33D+M5oPKVC+mn1WB/nznU475cssBW Asw+/K4VtXN08HxVFEvpV5MtpoYGe/cqsV87aVr/Igg45DVKtMMK8W5AmJDdGru3caxdVkkW fis9F1GBkk7ZPgip4cprh3KicuKsXhVrjk2mC/kCR+mrlY8ncQARAQABzSNLYWkgRW5nZXJ0 IChhdCB3b3JrKSA8a2FpZUBrdWl4LmRlPsLBegQTAQIAJAIbAwIeAQIXgAIZAQUCVdbtjAUL CQgHAwUVCgkICwUWAgMBAAAKCRAcJ0I3JQB3JEoOEAC9YaJFZCdCFXMb9HkQ4TS1z813EgTO lDFQwQ9vF26edvBjm80xcLQYUN5iRr6RNcHpx6FZLUX+AwAB5Cf2swVjvZB3LycwlKyKVuwd bXoLHPgq0XVu2l/ZbEKKmIR70UGAL/CKmZZm5rimicD1B5P+VXrnSl8uA7MjQFNnWnDuDHGk 9A/dl7RAEAenAiFlRFR5lwu9U/4TG0OrACgp7OIls3/jcszRRMJrc5OiTGWPq4d+Bo3a1yqA fdS2VjMObO8+zO7+4tact5uVFxrbMIRULKP0xJC/X77koUyn6ZSFIyFjJR2I/p4PCCLD0soJ 06e1e9bKUsKowFGwrvMnXqGEA4lij22R80paRH7VQ0QKQW9RDSqlF1YUafHpCt9D5i7HG2Ft ZgYz7VlfS27YMvG6Np+fN5Devh9Hap6fK5+SBTcs8v0Tgf8Ljx7OlajRHNtBxqRcPghnCZTJ oQpAJup5TYeqSGyp/Q2VT80h9iySGfBnn30qhcTr5lqOg/2NvQeu9wNVKBPmr8QpCfYb7ENZ CBifohzqBV8D6HaoBFeNts37kugcMWTw4C/RCtYI8TnjR18caDkc3kDh5p6anLnnQhCnGSVu LFj52lazHkj3FE+Ijg8ir95hm0d4PWZqk5UNfEPUa6ltBkHZstdpBvtqN+HxXpovqf8agBaZ ol2vXc7BTQRPKBP1ARAA54JU09VzBOPw44IYINiuQAEeyikO5sLT+Ixee8MM+T8tXk0Z9RSw UVctu8DwM+f8NjRI+dvmGSgezsiNL1ZkVuN37GM4dg7ZJ8oZCB5/YQQCCx1z7q4d68XsEfTs edl+Y2GcggbR6EpN4RbR38N6uhwKFZw0meuP6m1NaRCnihciJrXdoKxXcoHAxy3balGTPAbv OUmQaqI7dY5DVFPOT5I2wl1cWbkkTcx4wu8190sSMeW/IbwIg7inC/nqXCSKL633+Hv/2GcV zvBNK8JxO5YaHuHl+GBwP6cHlotHd2qr/BSyhYCt3CcMDHXR+vwSwawC+/zUpR5THrVLT6E/ hlpAZX5HQsY9BMrllI0Ap7MClj+kvRlkukNfc3/CKpAL1RjDV5+sr91ffBNXbZgpsp3/uCI6 QuJpFdUY8js5aYNwHCFbX8xkzdFqG95vt+uNoq/F7p7dEQi3BE0H2b0c4kuJX4G9MrAKdyfY r1KiPX513AQeIXZCE9UogON5jvKF6PBTTuzomsCZBa9ExbkLv+uCm7Q+EC4WwvvpbUaaLpmu t+oqnsSrYehg4ydm5NRhgfJy+Ris1sKAptyA7AlDWWsP5fFZE0rxeoDrTdbX6JVjxT509DtW a4rI0qgGTt625J6irm6nfbF8M1V5ZaBmSstWC/PDdggsfl35abQHxk8AEQEAAcLBXwQYAQIA CQUCTygT9QIbDAAKCRAcJ0I3JQB3JA5FEACCSZIzygwTFoOcFciojcbY3uvNamflJ0fMAv+h wO/Blprd1cHBmI0dQoTbpQ4NX33f9PVh4X9eCrxMCzUKB8RBS5ZNk5P0PYhJNooqKTmM3JIl coyvTruz9/Q2nbPA6z+0c7KJpmdJKn60vZfR4UDfwIOEqYvrZRbld3Bv1XXUQ6NHWvX6x2Ft vmASNON5m7ml4zwH6qSASJ0JZo0CuLwSOanmc5r+rDwtHHGqEpp6VwXpcPyF6ZUG5i0rU4OT H2y0kOb+7igK25LmjiXFNqbQb+K4lchVpxIGV6MvW6GAd3L0ei8cnYccZhAoPNCbKgEIA7qW 8g93U6Wf+P0yu9DbOqz2ETXoEqRJVDNLTrrvKyRYBDNpqvleUJtBHMnpU1Oqhf+ddCT292Ux fK9CoQe+st1QD5Mazlrnw4PuH7etS/Y2na7rXwqvop/IIu6Ba90/nddv/0cqvaRaDFYVN6HU GATLienjv0yS0QVTf/2x7B2NCtyT3lqRHrFByzm0FPAFxbr1HFJgE5CPGrmCn6ToR77gNBkL KUU3MVTGTRe35JHc5QVFuUwcrRBT/EcK8A3u0wmORswNnDylisYhzrw0RuS6WSvhAvuVQ0yF uh6SYw72DFmbX/h1A9BBMZ50tJtgqbD4Q+74J44SP8RD7qspTk6NNBa6D835NLx652yXwQ== Message-ID: <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> Date: Thu, 17 Oct 2019 11:13:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 09:13:10 -0000 On 15.10.19 22:15, Jon Callas wrote: > I think it makes sense. You're looking at having a way to seed a DRBG (PRNG), so that that seed can be used to deterministically generate a key, and that seed being reasonably small, and can be encoded in a way that's easy to store on paper as well as use for generating the same key later. > > This sounds like a good idea, but as others have said, it's more general than OpenPGP. Agreed. And it seems to me that BIP 0039 already specifies a generic way to record a seed as a Mnemonic, that we could reuse. However, I think it's incomplete. > Really what you want is a standardized, loadable DRBG, and then that DRBG could be bolted into some OpenPGP implementation for key generation. > > That latter part is software issue and really ought to be generalized beyond OpenPGP, and then some implementation of OpenPGP could have the feature of creating a key from such a loadable seed. The seed is insufficient for recreating the OpenPGP key. We need additional meta information. The suggestion is to specify the meta information that is required to recreate the OpenPGP key. In Daniel's response, he mentioned that as part (c). It seems that part (c) would contain information that is specific to OpenPGP. Daniel pointed out that I had missed the "key creation time" in my enumeration. So in addition to the seed, if we want a recovery mechanism that doesn't require the OpenPGP transferrable public key to be readily available, we'd have to combine: - the general seed - OpenPGP key creation time - OpenPGP key algo - OpenPGP key key size - ...? Kai From nobody Thu Oct 17 02:26:53 2019 Return-Path: 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 E9313120824 for ; Thu, 17 Oct 2019 02:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndp1_QiFZG_H for ; Thu, 17 Oct 2019 02:26:50 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [93.90.207.85]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1399912010E for ; Thu, 17 Oct 2019 02:26:49 -0700 (PDT) Received: from [10.137.0.12] (ip-178-203-234-118.hsi10.unitymediagroup.de [178.203.234.118]) by cloud.kuix.de (Postfix) with ESMTPSA id DE16A18598D; Thu, 17 Oct 2019 09:26:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1571304405; bh=u33iMY92e5xEr17zDpRhup7t+3/bk9JGAC90DmY3N9E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=w+sEq85NseVOB1htO67CXnT3KYeDzF0j5c9+lumNeexdzNbavuZkCLqdyowFjlRNH TS3kQgFG9GxhC905wF+J2SF7T6EqWjqro1ccbMu3H4cXYk09KwicArfyJDojP0kPOS G6USquFRfvBbeAq3r0XF8z6y5RXqgWw20LA36jRVs9G1jnR3qKVPcxcFSYpN1ShSEf zkm2AI5Tk30C7/iw+1e8YU2t6Op2QdSM2F8fWbQ4wA579ay7so52NRC0FQ44OwJbmd JZuXcB0C8UkWU4uPV9AO2AwFswMOZmrUvFi6l0dC4FSjm0lJ2x982zRafTpGUUR5io vI/F3sKRsK0dw== To: Peter Todd Cc: Jon Callas , openpgp@ietf.org References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191017092032.6z7lccbdgtrhmsf4@petertodd.org> From: Kai Engert Autocrypt: addr=kaie@kuix.de; keydata= xsFNBE8oE/UBEAC/Vx4tHVkfPdGf0BFMGcidXzAXKQ4+gI2F5rPBoV9fEtYngLHzm7+a6DL2 v5Jl5b4by9KtUbfIJysR1iniLWMJVPXZcyC4ovGouZ4MGK5cD9kMy+JdwebCs5/tj51vcvrS 08dP7r9Q0f0H7tsqhtVWuPFt+ZZEj8fIxjMgE3Z5BcyoGT1mXQ544RA0vr0fB9MngvfteD3L /wL2miDnYVtwB+VHC6kEB75Pte/yz1kFc/TDqKT8F45M3invhccY8Zwe7F88+uS+tgR5B3Ga RMc9WChZr5ed5vRxSLrGqBGSWBKomKuWXNFVMrZAOaq+W/+kOdNSXLdJSvXIAgV4Gywf1D0r ZTi8V+UoiTY8eDfT4OlBJrbbkge92/lrqaorAsuo/DVmfv7ARk7q2jvbSZD39zkWpLNsAulz gZOr+ffEHKy0f9fNwzenHpKvNtTUWGChEyDf7a6EtTBZsxAYco0xAtFOoQVwx5UzZk4tMVhv lrATrvmFdK5SLroDuwtSLUBJ5MhICyaB1kN7YSatQs33D+M5oPKVC+mn1WB/nznU475cssBW Asw+/K4VtXN08HxVFEvpV5MtpoYGe/cqsV87aVr/Igg45DVKtMMK8W5AmJDdGru3caxdVkkW fis9F1GBkk7ZPgip4cprh3KicuKsXhVrjk2mC/kCR+mrlY8ncQARAQABzSNLYWkgRW5nZXJ0 IChhdCB3b3JrKSA8a2FpZUBrdWl4LmRlPsLBegQTAQIAJAIbAwIeAQIXgAIZAQUCVdbtjAUL CQgHAwUVCgkICwUWAgMBAAAKCRAcJ0I3JQB3JEoOEAC9YaJFZCdCFXMb9HkQ4TS1z813EgTO lDFQwQ9vF26edvBjm80xcLQYUN5iRr6RNcHpx6FZLUX+AwAB5Cf2swVjvZB3LycwlKyKVuwd bXoLHPgq0XVu2l/ZbEKKmIR70UGAL/CKmZZm5rimicD1B5P+VXrnSl8uA7MjQFNnWnDuDHGk 9A/dl7RAEAenAiFlRFR5lwu9U/4TG0OrACgp7OIls3/jcszRRMJrc5OiTGWPq4d+Bo3a1yqA fdS2VjMObO8+zO7+4tact5uVFxrbMIRULKP0xJC/X77koUyn6ZSFIyFjJR2I/p4PCCLD0soJ 06e1e9bKUsKowFGwrvMnXqGEA4lij22R80paRH7VQ0QKQW9RDSqlF1YUafHpCt9D5i7HG2Ft ZgYz7VlfS27YMvG6Np+fN5Devh9Hap6fK5+SBTcs8v0Tgf8Ljx7OlajRHNtBxqRcPghnCZTJ oQpAJup5TYeqSGyp/Q2VT80h9iySGfBnn30qhcTr5lqOg/2NvQeu9wNVKBPmr8QpCfYb7ENZ CBifohzqBV8D6HaoBFeNts37kugcMWTw4C/RCtYI8TnjR18caDkc3kDh5p6anLnnQhCnGSVu LFj52lazHkj3FE+Ijg8ir95hm0d4PWZqk5UNfEPUa6ltBkHZstdpBvtqN+HxXpovqf8agBaZ ol2vXc7BTQRPKBP1ARAA54JU09VzBOPw44IYINiuQAEeyikO5sLT+Ixee8MM+T8tXk0Z9RSw UVctu8DwM+f8NjRI+dvmGSgezsiNL1ZkVuN37GM4dg7ZJ8oZCB5/YQQCCx1z7q4d68XsEfTs edl+Y2GcggbR6EpN4RbR38N6uhwKFZw0meuP6m1NaRCnihciJrXdoKxXcoHAxy3balGTPAbv OUmQaqI7dY5DVFPOT5I2wl1cWbkkTcx4wu8190sSMeW/IbwIg7inC/nqXCSKL633+Hv/2GcV zvBNK8JxO5YaHuHl+GBwP6cHlotHd2qr/BSyhYCt3CcMDHXR+vwSwawC+/zUpR5THrVLT6E/ hlpAZX5HQsY9BMrllI0Ap7MClj+kvRlkukNfc3/CKpAL1RjDV5+sr91ffBNXbZgpsp3/uCI6 QuJpFdUY8js5aYNwHCFbX8xkzdFqG95vt+uNoq/F7p7dEQi3BE0H2b0c4kuJX4G9MrAKdyfY r1KiPX513AQeIXZCE9UogON5jvKF6PBTTuzomsCZBa9ExbkLv+uCm7Q+EC4WwvvpbUaaLpmu t+oqnsSrYehg4ydm5NRhgfJy+Ris1sKAptyA7AlDWWsP5fFZE0rxeoDrTdbX6JVjxT509DtW a4rI0qgGTt625J6irm6nfbF8M1V5ZaBmSstWC/PDdggsfl35abQHxk8AEQEAAcLBXwQYAQIA CQUCTygT9QIbDAAKCRAcJ0I3JQB3JA5FEACCSZIzygwTFoOcFciojcbY3uvNamflJ0fMAv+h wO/Blprd1cHBmI0dQoTbpQ4NX33f9PVh4X9eCrxMCzUKB8RBS5ZNk5P0PYhJNooqKTmM3JIl coyvTruz9/Q2nbPA6z+0c7KJpmdJKn60vZfR4UDfwIOEqYvrZRbld3Bv1XXUQ6NHWvX6x2Ft vmASNON5m7ml4zwH6qSASJ0JZo0CuLwSOanmc5r+rDwtHHGqEpp6VwXpcPyF6ZUG5i0rU4OT H2y0kOb+7igK25LmjiXFNqbQb+K4lchVpxIGV6MvW6GAd3L0ei8cnYccZhAoPNCbKgEIA7qW 8g93U6Wf+P0yu9DbOqz2ETXoEqRJVDNLTrrvKyRYBDNpqvleUJtBHMnpU1Oqhf+ddCT292Ux fK9CoQe+st1QD5Mazlrnw4PuH7etS/Y2na7rXwqvop/IIu6Ba90/nddv/0cqvaRaDFYVN6HU GATLienjv0yS0QVTf/2x7B2NCtyT3lqRHrFByzm0FPAFxbr1HFJgE5CPGrmCn6ToR77gNBkL KUU3MVTGTRe35JHc5QVFuUwcrRBT/EcK8A3u0wmORswNnDylisYhzrw0RuS6WSvhAvuVQ0yF uh6SYw72DFmbX/h1A9BBMZ50tJtgqbD4Q+74J44SP8RD7qspTk6NNBa6D835NLx652yXwQ== Message-ID: <4c8ad7e4-c825-9be9-dd24-256a95fe7188@kuix.de> Date: Thu, 17 Oct 2019 11:26:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191017092032.6z7lccbdgtrhmsf4@petertodd.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 09:26:52 -0000 On 17.10.19 11:20, Peter Todd wrote: > Do we really need something that doesn't require the public key? Those are > fairly widely distributed; when would you be unable to get a copy yet still > need to recover the secret key? Please see my other response to Daniel, which illustrates a scenario in which a user might no longer have that available. The scenario is an email application, which targets users that only use end-to-end-encryption because it's readily and easily available in an email application they're using, who aren't diligent with their files, but still don't want to lose their archive of old (encrypted) emails. I'm quoting from my other email from today: > What about a user who owns just a single computer, it breaks, and > they've lost all their files, and only the IMAP mail archive is left? > > Maybe the user never uploaded their key to a key server, there's no backup. > > Maybe the user has an email with the attached public key somewhere, but > can it be found reliably? > > If we don't record any key information in the Mnemonic, the user must > perform some bootstrap action, prior to being able to regenerate the key: > > - look at existing encrypted email, an extract the key ID, to understand > which key needs to be recovered. But that might be a subkey ID, so > further searching is required to identify the ID of the master key? > > - search through existing email, in the hope that the full public key is > attached somewhere, either regular attachment, or maybe an outgoing > autocrypt header (only if user's client had autocrypt headers enabled). > Maybe there's no such email? > > - contact one of the correspondents, and ask them to send the public key > back. Maybe the user doesn't want to do that? > > It might be useful if recovery didn't depend on the above. Kai From nobody Thu Oct 17 03:12:32 2019 Return-Path: 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 ADA9C1201B7 for ; Thu, 17 Oct 2019 03:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2kXqEjRvH2N for ; Thu, 17 Oct 2019 03:12:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B189120178 for ; Thu, 17 Oct 2019 03:12:29 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:64:42:5650:5f0a:e07a:7e5f]) by relay.sandelman.ca (Postfix) with ESMTPS id 8E8911F455 for ; Thu, 17 Oct 2019 10:12:26 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5CA8810B6; Thu, 17 Oct 2019 12:13:20 +0200 (CEST) From: Michael Richardson To: openpgp@ietf.org In-reply-to: <8736fs7ao8.fsf@fifthhorseman.net> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <8736fs7ao8.fsf@fifthhorseman.net> Comments: In-reply-to Daniel Kahn Gillmor message dated "Wed, 16 Oct 2019 15:27:51 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 17 Oct 2019 12:13:20 +0200 Message-ID: <22567.1571307200@dooku.sandelman.ca> Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 10:12:31 -0000 --=-=-= Content-Type: text/plain Daniel Kahn Gillmor wrote: > For secret key recovery, presumably the user has the OpenPGP certificate > ("transferable public key") available to them already, which contains > all the above information already. I'd imagine that the recovery > process in the OpenPGP context would take the certificate and the > mnemonic, deriving all of the above fields from the certificate. I think that this makes sense. And it's already signed :-) > I'm not personally very convinced about this general approach -- it's > the equivalent of an unchangeable password that you've committed to > publicly (so anyone who thinks they have a good guess at your password > can verify it offline against your public key fingerprint). That's a good point; however sometimes perfect is the enemy of good enough, and that has been the case for encrypted email for a long time. A recoverable key would be an option, not a requirement. {An interesting (mathematical, density of primes) question would be whether one would be able to determine from looking at the public key whether it was recoverable or not. That is, can one recognize some pattern in the expanded DRBG. It might still be statistically secure, yet since the amount of entropy in the key is less than the entropy in the input, it might leave a pattern} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2oPr8ACgkQlUzhVv38 QpCF7Qf7BwCp5ut+67QE+bw3NOloZWEarWvUT4LRXHTMpEFQz2zXDtdEWymnD6GY u0QBdGl+vguMDIqdTAsQl2+JNnqwS2mZjZ1Jj+AwgpnCic3syP3l+7rSYhMdFUPV b7nm8E/7lZFnCDTAzTt7Vp6YFrOLd6gnYDheI7sDx17fBnceEgta4BwKk+V70/E7 b2X21idbdQOw6+8ZX+ajV4UYu/SvWnsNI4rZ82E0l2fpEmkMMspu71bPUVqEbtTK H2qg2+4NuyqtDqcmQt0adaEAP2HgDPM+fidBM/vNOg9152eDNLgyfyBIYB2VsxMB STmEEa7lPdvgak4m0OGfBnfYYPdu4g== =mTTA -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 17 03:20:43 2019 Return-Path: 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 E824B120860 for ; Thu, 17 Oct 2019 03:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8IBXBcBNpZu for ; Thu, 17 Oct 2019 03:20:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24AF61200E7 for ; Thu, 17 Oct 2019 03:20:39 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-25-21.mtg.ripe.net [193.0.25.21]) by relay.sandelman.ca (Postfix) with ESMTPS id 98B861F455 for ; Thu, 17 Oct 2019 10:20:38 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B624810B6; Thu, 17 Oct 2019 12:21:27 +0200 (CEST) From: Michael Richardson To: openpgp@ietf.org In-reply-to: <70fb51f6-86ec-a4e3-9641-07f69630ee70@kuix.de> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <8736fs7ao8.fsf@fifthhorseman.net> <70fb51f6-86ec-a4e3-9641-07f69630ee70@kuix.de> Comments: In-reply-to Kai Engert message dated "Thu, 17 Oct 2019 11:01:58 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 17 Oct 2019 12:21:27 +0200 Message-ID: <23101.1571307687@dooku.sandelman.ca> Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 10:20:42 -0000 --=-=-= Content-Type: text/plain Kai Engert wrote: > - look at existing encrypted email, an extract the key ID, to understand > which key needs to be recovered. But that might be a subkey ID, so > further searching is required to identify the ID of the master key? Maybe they can't get access to their IMAP folder until they decrypt their backup, so I think that this is a more reasonable concern. But, I think you have over-constrained the problem space. >> I'm not personally very convinced about this general approach -- it's >> the equivalent of an unchangeable password that you've committed to >> publicly > Why do you consider it equivalent, if the seed was randomly generated, > and the list of words isn't influenced by the user? It's equivalent to a system generated password. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2oQKcACgkQlUzhVv38 QpB/Sgf9EA9KvZRcKPJg6P2qXLyJhBfqjH6J3jLDAGf6CY1rcEEtfw8ZRXqY2nDk kssdGcy1fYvcBC1vW3Zpo2Q0amXS+G1+yS0YDwdEWRIYnb2C9+NZqLgFH4LR8Ypw M9lRx3hSij1APx+pdRCqmfZGfDaouriS0oYZj4x0kjI4ea9oc1xFUcpz39i8tuWg vau3WUb0T8h5pU52OaEWoHTHdvvacRMZRbpr0JiuFo/u5XXpyGVgJc+mFHV90Yes ZX4TExrPGNP3PWrIzSAjDqpxcWCq9HGeMmpx1gxmmmaU/E8GfItN8hn2137XRGhN VWtNsebSOz2HTramIIbASxW/K4Bm0Q== =L//m -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 17 12:34:07 2019 Return-Path: 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 445C5120C16 for ; Thu, 17 Oct 2019 12:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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=3y1hEgAQ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=38VQlXx8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BU1l2rpvh39 for ; Thu, 17 Oct 2019 12:33:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B9F120C37 for ; Thu, 17 Oct 2019 12:33:57 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1571340836; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OBlidYOXdAkTk2yLAGB5EJwrkGfBwfjlMA8bhRPpA+o=; b=3y1hEgAQcWRrLhOKsgyQ/G9iqKXAUhJI28lKfvHu+rKfLo6QAF3+/yTj RLZf3GDVZKNV0HbaqYC5dRWX/G69DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1571340836; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OBlidYOXdAkTk2yLAGB5EJwrkGfBwfjlMA8bhRPpA+o=; b=38VQlXx8MEuQBBKn68fJ8yWXDj5CMPa+iAR5BeBB68z1K/DkrUS0tg9C G5ZC4ZiMaGV3jORP27Q5DOnXwB157jZJRYwAoxy49LvznEPpqJQOn3x8/X B8mf+eFhtAbKy3RL6V3Xbq/NT27tZKemcUA//NX7YJloP+hF735j9eeZU+ vIlA1UPEFVqs6LHqfKtjiJs20byhiFZ1pgu45hJ64WOhPvtiMtSDqmp50I q84mEz1s9cZXMD1RQkeSgss8LHC5lluhXl6TleSHcxViksrm97oKtVFH5p 5H311Cg9iqR10jvM2KLvJ2Z5dxJMjxwaN8llZ18nMwHQZ+uXXgiZjg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id C9FD8F9A7; Thu, 17 Oct 2019 15:33:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C3F4F201CF; Thu, 17 Oct 2019 13:42:30 -0400 (EDT) From: Daniel Kahn Gillmor To: Michael Richardson , openpgp@ietf.org In-Reply-To: <22567.1571307200@dooku.sandelman.ca> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <8736fs7ao8.fsf@fifthhorseman.net> <22567.1571307200@dooku.sandelman.ca> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 17 Oct 2019 13:42:30 -0400 Message-ID: <87r23b5kvt.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 19:34:06 -0000 --=-=-= Content-Type: text/plain On Thu 2019-10-17 12:13:20 +0200, Michael Richardson wrote: > That's a good point; however sometimes perfect is the enemy of good enough, > and that has been the case for encrypted email for a long time. > > A recoverable key would be an option, not a requirement. yep, that's why i'm trying to help think this through, even though i'm not particularly excited about it. :) > {An interesting (mathematical, density of primes) question would be whether > one would be able to determine from looking at the public key whether it was > recoverable or not. That is, can one recognize some pattern in the expanded > DRBG. It might still be statistically secure, yet since the amount of entropy > in the key is less than the entropy in the input, it might leave a pattern} Can you give an example of this? I haven't tried to prove this, but i think if the generated public key (whether a curve25519 point or an RSA modulus) is distinguishable from other public keys, there is a strong argument to be made that either the DRBG or the secret key derivation mechanism is deeply flawed. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXaioBgAKCRB2GBllKa5f +EoBAQDRvk3wpCc4VWBirj56PJaeXcntRgk2eA7GuFaG8QMtGwEAntkGxfU1rcwu tLVdBwV9VETqiPw3s85pVgZ0rW0/wA8= =kK74 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 17 18:40:42 2019 Return-Path: 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 DD77C120104 for ; Thu, 17 Oct 2019 18:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcg1fynIqgzF for ; Thu, 17 Oct 2019 18:40:28 -0700 (PDT) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E2D120BEC for ; Thu, 17 Oct 2019 18:40:27 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id e11so3622811otl.5 for ; Thu, 17 Oct 2019 18:40:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qt5VAhHBA2pFmUiSuw3+3nDKwRsNNd7C5/PbX3j1eSg=; b=YNck/+/AadcmEKh/TcPQ4Sk4CN1wJN7Dqjgbha5GMNWKrLsfwCbv0fegdsMU66ogKm VQLyYQlg+spXJswh540NkspuglfXE9qvVdp1muTZpkVMpMqEIOdZ09ewKFk3DgVk8WrS MsEGtIj9FfI2vWapYugpqfi7FSspxllG/oGKG8H/usPA4wffGmDIhqWFqYS8Xtp8j2C5 hOL2Q1hsDc/wfa43ZIBsk60KYyvggShCQ1MGlPgPvATS2huFHz3jiwHGuYiz557882Ee CvTl6O+Nh56G00djWLwcoDlkFfwYbZe4stGotWKDishPvbNNka3bUfB4Adzs4K+d20O8 61eA== X-Gm-Message-State: APjAAAWiv26+ayn9XxmJjoM17i+tySf47NG7FhlJlC6ml9IVLFF+VhfR AZ8C0Hk08wwmdnkAdfTWXDdF/43xiewQrjjotTM= X-Google-Smtp-Source: APXvYqxzuEWqJ7u3WISLsV2p14YMDfu+yekrAcfxoBr6x7By1FVoyDjtEA+XuMmqbBS4qYRLYXx5VIT8oZpXqutm+NE= X-Received: by 2002:a05:6830:22d9:: with SMTP id q25mr5310444otc.87.1571362827119; Thu, 17 Oct 2019 18:40:27 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 17 Oct 2019 21:40:14 -0400 Message-ID: To: Jon Callas Cc: Kai Engert , IETF OpenPGP , Jon Callas Content-Type: multipart/alternative; boundary="0000000000001fb2910595256bb7" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 01:40:35 -0000 --0000000000001fb2910595256bb7 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 15, 2019 at 4:15 PM Jon Callas wrote: > > > > I hope some of this message makes sense. > > > > I think it makes sense. You're looking at having a way to seed a DRBG > (PRNG), so that that seed can be used to deterministically generate a key, > and that seed being reasonably small, and can be encoded in a way that's > easy to store on paper as well as use for generating the same key later. > > This sounds like a good idea, but as others have said, it's more general > than OpenPGP. Really what you want is a standardized, loadable DRBG, and > then that DRBG could be bolted into some OpenPGP implementation for key > generation. > > That latter part is software issue and really ought to be generalized > beyond OpenPGP, and then some implementation of OpenPGP could have the > feature of creating a key from such a loadable seed. > > It sounds useful to some people, but outside the scope of OpenPGP > documents, just as the design of other RNGs is beyond the scope of OpenPGP > documents. > IETF already has such a function HMAC-KDF. RFC 5869. The current UDF document does not have the text. I am just finishing up the code and should have a new draft out tomorrow with the text. --0000000000001fb2910595256bb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 15, 2019 at 4:15 PM Jon Callas <jonc= allas=3D40icloud.com@dmarc.i= etf.org> wrote:
>
> I hope some of this message makes sense.
>

I think it makes sense. You're looking at having a way to seed a DRBG (= PRNG), so that that seed can be used to deterministically generate a key, a= nd that seed being reasonably small, and can be encoded in a way that's= easy to store on paper as well as use for generating the same key later.
This sounds like a good idea, but as others have said, it's more genera= l than OpenPGP. Really what you want is a standardized, loadable DRBG, and = then that DRBG could be bolted into some OpenPGP implementation for key gen= eration.

That latter part is software issue and really ought to be generalized beyon= d OpenPGP, and then some implementation of OpenPGP could have the feature o= f creating a key from such a loadable seed.

It sounds useful to some people, but outside the scope of OpenPGP documents= , just as the design of other RNGs is beyond the scope of OpenPGP documents= .

IETF already has such a function HMAC-KDF. RFC 5869.

The current UDF document does= not have the text. I am just finishing up the code and should have a new d= raft out tomorrow with the text.

--0000000000001fb2910595256bb7-- From nobody Thu Oct 17 19:10:12 2019 Return-Path: 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 6131B120044 for ; Thu, 17 Oct 2019 19:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l7-Ce6_VYP6 for ; Thu, 17 Oct 2019 19:10:09 -0700 (PDT) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8337A1200CC for ; Thu, 17 Oct 2019 19:10:09 -0700 (PDT) Received: by mail-oi1-f180.google.com with SMTP id w6so3886773oie.11 for ; Thu, 17 Oct 2019 19:10:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wzlIGHJZ/lHjJTyaiszkDi7PLG4Swgy02Zj+1qneHHI=; b=qkeqxV1IiCgu8t7Mt1Pz+7QQEdLfXnGz8gzPQyBhcAbs7caJNRS3J6Cir2Va05rU38 cUZVFWNM/nVB3Pbk/bB0MnaeEsac1txPgFVIdxqADgIyIXLJe+Fmz271150QNSnMIz9X ZmpjrRybUo/QPi83gcdO0EwZm3pXhcRs+GQa8ZvEeMudWcjE2NklU8RLAq70U6wJ+mpa dmBq1ZjDoj0V1Fm5pMqBPxJnO/AMPoql+jUxLXkKla3dNoBQUh7KwDca8BjG5TytaSGH wL/JyzZaq7E5Lqv9h1IFh9jKdI6w4D/qjQAX84i3aHpd6ynEaTJPl36ChNxKr4/YJL+t PsBQ== X-Gm-Message-State: APjAAAVVv87QTHvIqfyvhp5jaIv27TtrDpxdYAqVmZakoDnsMgzb6MDL 3v7QIDUmZo6FMamsnIUop9dHMrhFLnodMx0/ILfm8uBN/P0= X-Google-Smtp-Source: APXvYqxWjEjI+VfyJlD9WomkYUwPJzbtADpxoh0CjrhyrLS6CN68sRwwB3WlWYOaSKzK4IvZRroCddw4rgOwb7VJpug= X-Received: by 2002:aca:af41:: with SMTP id y62mr6081301oie.100.1571364608361; Thu, 17 Oct 2019 19:10:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 17 Oct 2019 22:09:57 -0400 Message-ID: To: Bjarni Runar Einarsson Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="0000000000004b4bc8059525d5d0" Archived-At: Subject: Re: [openpgp] Shared OpenPGP keys for use in test corpuses X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 02:10:12 -0000 --0000000000004b4bc8059525d5d0 Content-Type: text/plain; charset="UTF-8" If the generate key from specified seed work goes ahead, we get this for free. It is one of the things that made me propose this idea back in September :-) On Tue, Oct 15, 2019 at 9:52 AM Bjarni Runar Einarsson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello OpenPGP! > > One of the workgroup outcomes at the OpenPGP e-mail summit, was a > common desire for more shared test data. > > As a first step towards this, dkg and juga and I sat down and put > together a minimal Internet Draft which specifies a couple of > OpenPGP certificates and keys (one Ed25519, another RSA-3072), > which we would like to propose people use when testing. > > The draft: > > - https://datatracker.ietf.org/doc/draft-bre-openpgp-samples/ > > The gitlab where we welcome improvements: > > - https://gitlab.com/openpgp-wg/openpgp-samples > > We hope this proves useful, > - Bjarni > > -----BEGIN PGP SIGNATURE----- > > iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2lzrQACgkQjgA3FgDP > lJGTnwf/YeDpEgjgkPTKohvVHqNOLwHnZ8WIRW0rAO5lCaUQTcjBmW0CCpobr7a8 > gck7BBe2cplW5Yg8tHH0dM5dL6Jjev2kXfrck4BTdQPZOXdBb4SrrPVgNoQwbn0S > lV5cjQdfAkc2wp4zIzGifJBduESgSyNABIG4pafNabcoZCvGYUW2iukC53q2KbWr > HXiuBtQMNKn670lWpU/z/dMZ+0gGevsXboumf+Roy2Xgjjco+YXEB4+W54NNB4RF > StUuwTc6yjy4Ds+Xgo9ivz7N3WfgKRY+l3bvzC4rgp241xtGJbGDuGgfZG/Rl/1B > NChZUluaISi91KZ3sdLu2NG0Ga0ArA== > =jtT8 > -----END PGP SIGNATURE----- > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --0000000000004b4bc8059525d5d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the generate key from specified seed work goes ahead, we g= et this for free.

It is o= ne of the things that made me propose this idea back in September :-)
=

= On Tue, Oct 15, 2019 at 9:52 AM Bjarni Runar Einarsson <bre@mailpile.is> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello OpenPGP!

One of the workgroup outcomes at the OpenPGP e-mail summit, was a
common desire for more shared test data.

As a first step towards this, dkg and juga and I sat down and put
together a minimal Internet Draft which specifies a couple of
OpenPGP certificates and keys (one Ed25519, another RSA-3072),
which we would like to propose people use when testing.

The draft:

=C2=A0- https://datatracker.ietf.org/doc/= draft-bre-openpgp-samples/

The gitlab where we welcome improvements:

=C2=A0- https://gitlab.com/openpgp-wg/openpgp-samples

We hope this proves useful,
=C2=A0- Bjarni

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2lzrQACgkQjgA3FgDP
lJGTnwf/YeDpEgjgkPTKohvVHqNOLwHnZ8WIRW0rAO5lCaUQTcjBmW0CCpobr7a8
gck7BBe2cplW5Yg8tHH0dM5dL6Jjev2kXfrck4BTdQPZOXdBb4SrrPVgNoQwbn0S
lV5cjQdfAkc2wp4zIzGifJBduESgSyNABIG4pafNabcoZCvGYUW2iukC53q2KbWr
HXiuBtQMNKn670lWpU/z/dMZ+0gGevsXboumf+Roy2Xgjjco+YXEB4+W54NNB4RF
StUuwTc6yjy4Ds+Xgo9ivz7N3WfgKRY+l3bvzC4rgp241xtGJbGDuGgfZG/Rl/1B
NChZUluaISi91KZ3sdLu2NG0Ga0ArA=3D=3D
=3DjtT8
-----END PGP SIGNATURE-----
_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--0000000000004b4bc8059525d5d0-- From nobody Thu Oct 17 23:53:25 2019 Return-Path: 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 703571200CC for ; Thu, 17 Oct 2019 23:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjuOLYdvg8wB for ; Thu, 17 Oct 2019 23:53:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA67120098 for ; Thu, 17 Oct 2019 23:53:20 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [89.248.140.8]) by relay.sandelman.ca (Postfix) with ESMTPS id 180801F455; Fri, 18 Oct 2019 06:53:18 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id AA4D110B6; Fri, 18 Oct 2019 08:54:12 +0200 (CEST) From: Michael Richardson To: Daniel Kahn Gillmor , openpgp@ietf.org In-reply-to: <87r23b5kvt.fsf@fifthhorseman.net> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <8736fs7ao8.fsf@fifthhorseman.net> <22567.1571307200@dooku.sandelman.ca> <87r23b5kvt.fsf@fifthhorseman.net> Comments: In-reply-to Daniel Kahn Gillmor message dated "Thu, 17 Oct 2019 13:42:30 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 18 Oct 2019 08:54:12 +0200 Message-ID: <12393.1571381652@dooku.sandelman.ca> Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 06:53:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > yep, that's why i'm trying to help think this through, even though i'm > not particularly excited about it. :) >> {An interesting (mathematical, density of primes) question would be >> whether one would be able to determine from looking at the public key >> whether it was recoverable or not. That is, can one recognize some >> pattern in the expanded DRBG. It might still be statistically secure, >> yet since the amount of entropy in the key is less than the entropy = in >> the input, it might leave a pattern} > Can you give an example of this? I haven't tried to prove this, but i > think if the generated public key (whether a curve25519 point or an R= SA > modulus) is distinguishable from other public keys, there is a strong > argument to be made that either the DRBG or the secret key derivation > mechanism is deeply flawed. If I could prove such a thing then I'd have a Fields Medal for having discovered something new and interesting about the density of primes :-) If the input to our KDF is 120 bits and the output is 256 bits, then there must be a bunch of numbers that we can't derive from the KDF. But, as PHB says, 2^120 is a big enough work factor that it's okay. (5bits * 5 groups * 4 characters/group =3D 120) For ECDSA, any number will do, AFAIK. {When producing numbers RSA, I think we have to start with the random number and then search deterministically for a suitable prime. I was more thinking that this process might leave detectable traces} =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2pYZQACgkQlUzhVv38 QpCEewf/d2plWU/XX7yQ2ISDLGLBk7zIoOEVPycVdu7D6leSXLgpZXJp3Kc2A2VG ARYAxV9S56bJxJUsDYKAdlLyoC/lQtE9d6/moW4fCL0X8cAXt3MVRtvK+KwmP29l lwG92+LrtOnKkfhRWLsMGtb+MlGD3AT8sLWpVmpMtzx1Wcc45+tYL1X4I8VyRGiE YNJO0ohQc9zu9e6KNnHElirI7MhDhBxCYg95fSntUIpTHzb/LH7JdqU+yj2VcEJS rzfnEtGabcketZxXpCJGk9M6Ej9Uedk9vGjSY0cP4Ie891YPDJ9jTCT90M+tpOQo WHPR6SX7xSwpvG0HFlHhgcffTjzhSw== =YtEq -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 18 00:52:01 2019 Return-Path: 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 118CF12081C for ; Fri, 18 Oct 2019 00:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVN7Mnt2tU7o for ; Fri, 18 Oct 2019 00:51:57 -0700 (PDT) Received: from mailpile.is (mailpile.is [139.162.218.203]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66C12080A for ; Fri, 18 Oct 2019 00:51:57 -0700 (PDT) Received: from mailpile.local (torex2.fissionrelays.net [158.69.63.54]) by mailpile.is (Postfix) with ESMTPSA id ADE579CC0F; Fri, 18 Oct 2019 07:51:53 +0000 (UTC) Content-Type: multipart/mixed; boundary="==eMMmHUNSoEwG7zwxy7jSWnW3pNvioW==" MIME-Version: 1.0 From: Bjarni Runar Einarsson To: "Phillip Hallam-Baker" Cc: "IETF OpenPGP" In-Reply-To: References: User-Agent: Mailpile Message-Id: Date: Fri, 18 Oct 2019 07:47:53 -0000 Autocrypt: addr=bre@mailpile.is; prefer-encrypt=mutual; keydata=xsFNBE4tgKYBEA DI8ULBJPw1a4h/D9Re5AZZ7xBtI9hIljUKz/bBovBGmRsrG6+IjKZ4um1kkJDhwiY0SzrzqE4L1hr cPRA46WbX0/aUuxL7LWbNDl6i7GBP28eU4I+mQcri2oS/rMfx3rnqe2dF85KKdTvS/9SsGAYNwK49 a+DMdsgDT3xMTf1JMrV5lRI7JCzop7v0AVbt9pyJAySJvQWcmkiWEZCWGpQxlYn/CnBVhv3iKToFt oIYKfcWLK/ADZ5CikwF7jDQM30mHovY4Ui31gVWnlhOw+UKpNviwbH7lr6flo2wFuaiD1jutKwqnG s6gH5A/tF6RtUCt6KzYoXpNochk8DGzm3G//sMDdreyUZeiXsF665IdUZ1V8OxU+S17MrxNiGjvY5 gRlD6a4oMsEZQPLQia4j7mCX/kTRsm5Xo+NqBMigNIvH7BJ+DcAqYnMT3kCbLyM3cAPhPn6zrSlXA mSsjAYk0bSLV9Ow0CITVcfrLB+2k+KFPFLl0ewXD75tspRk3wNBJ6GbhekOwzZE7xjrqWgR9Tfmlg DWArZT6oxqtKTiYnwiuQqPixONsc1jdR8bhqDZaJh7HkrZcY7yMDKQWe+1MxwBTV/DbbkrTmTT4ff RWCKi0Dv1do3NDgFXDC/3XpvFD2h2HPMs6pu8rG3CqS8YRJeE+p8TV7RJePSrb50rx4wARAQABzTB CamFybmkgUi4gRWluYXJzc29uIChNYWlscGlsZSkgPGJyZUBtYWlscGlsZS5pcz7CwY8EEwECADkC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEEYaAVdj0o1BCoexlzKBkdmztBmbQFAl0X+KQAC gkQKBkdmztBmbT72hAAit87DtuEM74doeqYa2nYj5iba7wgnnZVnSLK/tN1g0mLYMrXX/nsI8elFM lB4o/qw/y3SlSvXSe2+MJ3OImIjSR2t7yeQuA3rNcZE1wTN9+FL+OVtOzNzAHvI/+2A7NQAgxOd83 nDOe1N6g4lzJZgNbWyvlUUpqGe1uRJwCxrVAW0BnxQuFLmUM+ypx+Ht5lX05JYzJh2lt05g2QBgNg GHZ2iMSl+uTaq1K5Y62jIFeP5PutPXwDFtKgUg2zY30SLYdp/SVl19fH4SSTTgXuYj9nACZ/UKy8l h7t5liUOmTi8QjlVLXQUJflgEwm8OJhnuWODNZQwAx0msqG5AsHI9nv48fTSnBACpGq58GxSmnWUv yO4Eqrbi+2HKzoRymDyzuPLwrPNyTJITxhhj5g0613isttdiM9+vX73jpWOilyKbyKfmCdOoUliEB Vt/+QGD9lt6iUfotgvgGpS/JkBi+X9otEN+wb1vJBCzK1Dfy7CrEHx7tD3+5FJi8mrSlaKeUqjLkR UbdWbBIc+kfVFpkqDzJmz6QoKWAevTk+GwETbD2aFTjX37M9EWkk3sDaEXSYFIT1X6++ykOl7bX+4 Sm2kRaBr8O8B1+26T+ZeVKvg14nYvr4Ck92/y/cPUgrW6meE1WC/9bXqrsMR1pY9Y7N8cw8h6GIpk ehy+XiuYrOwE0EVbaWEQEIAM0AUqE7vyJSdoCpKVMydXcnpzGSv+NUeTPxYObfjcQiAjeSDVgbhRQ eb8jRmhMpTY8mwd7o1soJlJ71JewXmLw7/u2ixYOWUtdLU6w8C2bXTWqq5gTJFMtUvq+Lt2AcWgcQ WCyVbzSjVvHR+Djy6qGiO1Tf90K9fYpdEOQKJrcFCVL88gz3qpP6H5vm29xNUZQWb3E6F6cSRiGYW QZ4mTmJFE1hOKGHsmLaFFeJy6sVMOE62y4FejA5p2R9lQ/u2sGkgKfQ0OfOCk778w07u6XtYHX/7X zRA0ma4PWL4/nXt7bjOqSC119+yLYYL6f/qQeMbJIX3qOIDxsfqxm+6/UAEQEAAcLBfAQYAQIAJgI bDBYhBGGgFXY9KNQQqHsZcygZHZs7QZm0BQJdF/kZBQkLI8oHAAoJECgZHZs7QZm0yfQP/0K9lm6C m6s2Q5Z3e0AevmZOaGIOVIq4UK+GoRTyKGC0gzya5oXlDQGsefS+I5iAZiwlFfQPwZ0TCujXawrwq OKpNjaoUiMMLaRMNP17yVcfvrNN23YWMAOFZoxJyczXveVDgEC/VDRWVguV6LbRv3ovIb9VlsbJ9R WvdzmZEtOWJ+PK0yeBaM2EmH7B3Liq6WKEv+PwPTt1giwB20Lf5wgUGROF2hBF9spd2J1p0ZzWarx keuMDGEh8djVSBqwP2pqrTQWArPvONRGcl/pOgfCyx6fVdrUMTW79KuWTyK+Re9zctpwCKAURCikD qFAupFh2kJmbobOE2miYZ50YdhmoejHK3iBzdEijfPiOqWoStapd44q3o8s+KEWvRymMfp7tQiTEH OxNga9hIomntAqYT/6F5En0RhnVjK3ZRaxoI2VPWa5AA878k9GpqfFO9h5z7e18b+4ukVl1PY4S4w FV+lqqq/ODbWiZS+lKXkcVQoVCFhDEhenV8uuKSMfZR/PrjShaMI/AjP6ESHowlEdDaus6TeiJWfI P5QQViZAQg/tWtwPq2YzMVCS/S1rK+EjZp4Db55N4VxDAE5N0jSV+2LsJhFg+57UW9genrOAzkZZE DRQLjVPAPmR2uUx5A13TTX7TNM07D6j+5I9FnLGd/sW3wcyxlMWwN4IMY1bt OpenPGP: id=61A015763D28D410A87B197328191D9B3B4199B4; preference=signencrypt Archived-At: Subject: Re: [openpgp] Shared OpenPGP keys for use in test corpuses X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 07:51:59 -0000 --==eMMmHUNSoEwG7zwxy7jSWnW3pNvioW== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! Phillip Hallam-Baker wrote: > If the generate key from specified seed work goes ahead, we get > this for free. > > It is one of the things that made me propose this idea back in > September :-) You're working with a very flawed definition of the concept "free". Sure, if all implementations everywhere add the same fancy feature, we can use that feature for "free" from that point in time onwards. Well, free aside from maintenance and bugfix costs... But getting there is expensive and I don't actually see consensus that we're moving in that direction. I'm not a fan, but I'll refrain from derailing this thread to pontificate on why. This approach works right now. It will still work even after people have started generating from specified seeds. And the cost is sunk, the work has been done. It would be a shame if people decided not to collaborate in this way, because they're waiting for the Next Big Thing to land. - Bjarni > > - https://datatracker.ietf.org/doc/draft-bre-openpgp-samples/ -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2pbjMACgkQjgA3FgDP lJF0Ewf7B9b5imXWTdq4NijB7ROA6DzI1FxftKn0KtzIWbiI/B9t4YeaP1Dp9yJY o/8CHZeSbXuv6elXtJcK17iU2Xr2RvYBItnlHk47raQvTM19hD5fCKVppchHpsbv R5Ctiigt51Vu5ffiS+Usk2cRoIBbgq4vpqWo9gi+d2l5gRlQf+QKUeYJId+p1gYq Qft5rTDR7UrG28b3SLT1Zoe5qjSiwSPia420sY49IRFoBkNjVK29we9B0sbu3o+G 1Ixh0KCfflV4BUtZCDGAi/kNtCD1E4ELpUFUiTDSCihG1gDk/lX2qNlDSjom4Hvj 6yKDYIsagbMrR0EIoA4vqQHYEc0gPg== =H0Un -----END PGP SIGNATURE----- --==eMMmHUNSoEwG7zwxy7jSWnW3pNvioW==-- From nobody Fri Oct 18 06:00:58 2019 Return-Path: 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 24F21120890 for ; Fri, 18 Oct 2019 06:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QRnlk_GmCCc for ; Fri, 18 Oct 2019 06:00:54 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6387A12083E for ; Fri, 18 Oct 2019 06:00:54 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id z6so4885069otb.2 for ; Fri, 18 Oct 2019 06:00:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K9TWo7cJX9ye1QDu1lcpLSVNBxQ37u10TESqh9T0TR8=; b=IwWVYQxbDP7IWzOQ6oilf9uls3nhWU8nwLzjcTTvEG8btnpXi2ir6FMyGRb0n+dw1y SdVhRhBClL7UVspXl5+yosf4Jw24eIH9SzwajimtSd1d5pqng1m7KhGn8FoKmGxWDSXk hbm2KnF1QQiMFq6Uchheq7SkLJ/Ychr59G8OcqGs226ys3jepyy64ktn2YKEiYYwgSL0 EHlmFD3IhR4lORXt2DaZckH8Xrs4hYeT5NoCJsBe3Ct+mig56w4wI+t3c2QdH5UoIj1r ZhMh2DirVLOUPjh0NBJQGFwrNCbS6I1PjskheJEkbEEivg4elq9e5Y8DpjscrmvzrrTk zM5A== X-Gm-Message-State: APjAAAXn13R5EFQCz23QIMbVgfiZHoDq1x1iyNvYTOQUsIt/SgEjGApS b+gGiQpzqdw3s2lv85VAcmSsCMaYlCvwm3EnboQ= X-Google-Smtp-Source: APXvYqypMiN/zUPc8ZC7cSI4rjBs6bHpoUwjz6fXwubAZlgiP602gdUjedHgPmg3QRFN98RE0UlyKRNPW7K+EHWzlKo= X-Received: by 2002:a9d:3a3:: with SMTP id f32mr7973734otf.231.1571403653504; Fri, 18 Oct 2019 06:00:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 18 Oct 2019 09:00:42 -0400 Message-ID: To: Bjarni Runar Einarsson Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="00000000000090e5d805952eeca0" Archived-At: Subject: Re: [openpgp] Shared OpenPGP keys for use in test corpuses X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 13:00:56 -0000 --00000000000090e5d805952eeca0 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einarsson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello! > > Phillip Hallam-Baker wrote: > > If the generate key from specified seed work goes ahead, we get > > this for free. > > > > It is one of the things that made me propose this idea back in > > September :-) > > You're working with a very flawed definition of the concept > "free". Sure, if all implementations everywhere add the same > fancy feature, we can use that feature for "free" from that point > in time onwards. Well, free aside from maintenance and bugfix > costs... But getting there is expensive and I don't actually see > consensus that we're moving in that direction. I'm not a fan, but > I'll refrain from derailing this thread to pontificate on why. > Saying that you have technical objections which you will not reveal is incredibly rude. Either state your objections so they can be responded to or don't state them at all. I proposed this idea September 28. I expect writing the draft and shipping code to take no more than a day. So I don't see a problem with implementation complexity. Nor do I see a need for this to be widely implemented to address an issue that only affects developers. The issue of test data for specifications is something that we should probably address using a mechanism other than the ID series. Documents should have illustrative examples. Test vectors are really something else. Its like the supporting data now required for certain types of academic paper. The model I think we need here is to have an interop event in which implementations demonstrate that they can generate and consume a particular corpus. And then publish a report on that interop event with the names of the tested implementations and the results. --00000000000090e5d805952eeca0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einars= son <bre@mailpile.is> wrote:
-----BEGIN PGP SI= GNED MESSAGE-----
Hash: SHA512

Hello!

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> If the generate key from specified seed work goes ahead, we get
> this for free.
>
> It is one of the things that made me propose this idea back in
> September :-)

You're working with a very flawed definition of the concept
"free". Sure, if all implementations everywhere add the same
fancy feature, we can use that feature for "free" from that point=
in time onwards. Well, free aside from maintenance and bugfix
costs... But getting there is expensive and I don't actually see
consensus that we're moving in that direction. I'm not a fan, but I'll refrain from derailing this thread to pontificate on why.

Saying that you have technical objections which you will not reveal= is incredibly rude. Either state your objections so they can be responded = to or don't state them at all.

I proposed this idea September 28. I expect writing the draft an= d shipping code to take no more than a day. So I don't see a problem wi= th implementation complexity. Nor do I see a need for this to be widely imp= lemented to address an issue that only affects developers.

<= div>
The issue of tes= t data for specifications is something that we should probably address usin= g a mechanism other than the ID series. Documents should have illustrative = examples. Test vectors are really something else. Its like the supporting d= ata now required for certain types of academic paper.=C2=A0

=
The model I thi= nk we need here is to have an interop event in which implementations demons= trate that they can generate and consume a particular corpus. And then publ= ish a report on that interop event with the names of the tested implementat= ions and the results.



--00000000000090e5d805952eeca0-- From nobody Fri Oct 18 06:14:24 2019 Return-Path: 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 366C0120C72 for ; Fri, 18 Oct 2019 06:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml0VZJ2smIaV for ; Fri, 18 Oct 2019 06:14:21 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12D9120C7A for ; Fri, 18 Oct 2019 06:14:21 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id y39so4897378ota.7 for ; Fri, 18 Oct 2019 06:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LgEedlI76YayV+L5yD3uXnVYBT+0L4kJm3Dz+QPUju0=; b=Fsz2pxfyVgOdJ+XDl4mVwbD7FGl403K33I6JNTOCHwFfy4iJ3liI0kgN4lzKguZRzD Wzy+q5JmEYPn4q4mBqhn/BGqka7zFigo6W3pk6e1LoEThkmLpC4arbxHRIB6kPs6n769 k4QFM4RuRVulCdtVT6NGcEh8cONgBVhtqJcfFS8tXj26xWjqSL5Us3UkrlUmINUuiJp7 cQoAEBE0lueJtnQSWFNYH/nMutDpL0yTEjntxAmQhuSS67GE4yjFJpFqvUVipiH4pmsQ YkjVf+TBuk6Mf65tLA3LcnnXHi1fgeJ+jpjihb/n61KxHtrZeBi6oRwWmAjGIQNE5Rkx 1FGw== X-Gm-Message-State: APjAAAU1Js85RU7jvq/G4D2GObvDMu8DOqyYL0NwqZAof5iJ9Nji7m3f Wycu1vxeWcgebrUsEUYJrzoPKi65Beam2eBZ6uSKCAbc X-Google-Smtp-Source: APXvYqz6ztwgm0bKtf/BSsjIWOx1CmR5BSa7WD2WvZ/diCjBJBsujMonzr15/+JA0amfHwHNXalPfF3bGjYDMSDRTWo= X-Received: by 2002:a05:6830:22d9:: with SMTP id q25mr7288364otc.87.1571404460846; Fri, 18 Oct 2019 06:14:20 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <8736fs7ao8.fsf@fifthhorseman.net> <22567.1571307200@dooku.sandelman.ca> <87r23b5kvt.fsf@fifthhorseman.net> <12393.1571381652@dooku.sandelman.ca> In-Reply-To: <12393.1571381652@dooku.sandelman.ca> From: Phillip Hallam-Baker Date: Fri, 18 Oct 2019 09:14:09 -0400 Message-ID: To: Michael Richardson Cc: Daniel Kahn Gillmor , IETF OpenPGP Content-Type: multipart/alternative; boundary="000000000000aff2eb05952f1c66" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 13:14:23 -0000 --000000000000aff2eb05952f1c66 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 18, 2019 at 2:53 AM Michael Richardson wrote: > > Daniel Kahn Gillmor wrote: > > yep, that's why i'm trying to help think this through, even though > i'm > > not particularly excited about it. :) > > >> {An interesting (mathematical, density of primes) question would be > >> whether one would be able to determine from looking at the public > key > >> whether it was recoverable or not. That is, can one recognize some > >> pattern in the expanded DRBG. It might still be statistically > secure, > >> yet since the amount of entropy in the key is less than the entropy > in > >> the input, it might leave a pattern} > > > Can you give an example of this? I haven't tried to prove this, but > i > > think if the generated public key (whether a curve25519 point or an > RSA > > modulus) is distinguishable from other public keys, there is a strong > > argument to be made that either the DRBG or the secret key derivation > > mechanism is deeply flawed. > > If I could prove such a thing then I'd have a Fields Medal for having > discovered something new and interesting about the density of primes :-) > > If the input to our KDF is 120 bits and the output is 256 bits, > then there must be a bunch of numbers that we can't derive from the KDF. > But, as PHB says, 2^120 is a big enough work factor that it's okay. > (5bits * 5 groups * 4 characters/group = 120) > > For ECDSA, any number will do, AFAIK. > {When producing numbers RSA, I think we have to start with the random > number > and then search deterministically for a suitable prime. I was more > thinking > that this process might leave detectable traces} > For RSA-2048, it is arguable that 112 bits are enough as that is the work factor of the key according to the best known attack. Reuse of KDF in the generation function was chosen since it is already examined and widely used so if it is hosed, the system is already compromised. We are not introducing a new vulnerability. As for the proof part... When I first started thinking about this, it was because right now my specifications generate new keypairs every time they are generated and since parts III and IV try to reference the keys generated in part I... this is confusing. So I began thinking of this as a hack. But as I have continued, I have started to think that it is actually a much better way to generate keys. A big problem testing cryptographic systems is that any system that has a hidden secret can use it to conceal a side channel attack. (See Moti Yung's kleptography schemes.) What I really like about these deterministic schemes is that they allow the random component of the system to be isolated. --000000000000aff2eb05952f1c66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 18, 2019 at 2:53 AM Michael Richardson = <mcr@sandelman.ca> wrote:
=

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
=C2=A0 =C2=A0 > yep, that's why i'm trying to help think this th= rough, even though i'm
=C2=A0 =C2=A0 > not particularly excited about it. :)

=C2=A0 =C2=A0 >> {An interesting (mathematical, density of primes) qu= estion would be
=C2=A0 =C2=A0 >> whether one would be able to determine from looking = at the public key
=C2=A0 =C2=A0 >> whether it was recoverable or not.=C2=A0 That is, ca= n one recognize some
=C2=A0 =C2=A0 >> pattern in the expanded DRBG. It might still be stat= istically secure,
=C2=A0 =C2=A0 >> yet since the amount of entropy in the key is less t= han the entropy in
=C2=A0 =C2=A0 >> the input, it might leave a pattern}

=C2=A0 =C2=A0 > Can you give an example of this?=C2=A0 I haven't tri= ed to prove this, but i
=C2=A0 =C2=A0 > think if the generated public key (whether a curve25519 = point or an RSA
=C2=A0 =C2=A0 > modulus) is distinguishable from other public keys, ther= e is a strong
=C2=A0 =C2=A0 > argument to be made that either the DRBG or the secret k= ey derivation
=C2=A0 =C2=A0 > mechanism is deeply flawed.

If I could prove such a thing then I'd have a Fields Medal for having discovered something new and interesting about the density of primes :-)
If the input to our KDF is 120 bits and the output is 256 bits,
then there must be a bunch of numbers that we can't derive from the KDF= .
But, as PHB says, 2^120 is a big enough work factor that it's okay.
(5bits * 5 groups * 4 characters/group =3D 120)

For ECDSA, any number will do, AFAIK.
{When producing numbers RSA, I think we have to start with the random numbe= r
and then search deterministically for a suitable prime.=C2=A0 I was more th= inking
that this process might leave detectable traces}

<= /div>
For RSA-20= 48, it is arguable that 112 bits are enough as that is the work factor of t= he key according to the best known attack.

Reuse of KDF in the generation function was chosen since = it is already examined and widely used so if it is hosed, the system is alr= eady compromised. We are not introducing a new vulnerability.

As for the proof part... When I first = started thinking about this, it was because right now my specifications gen= erate new keypairs every time they are generated and since parts III and IV= try to reference the keys generated in part I... this is confusing. So I b= egan thinking of this as a hack. But as I have continued, I have started to= think that it is actually a much better way to generate keys.

A big problem testing cryptographic s= ystems is that any system that has a hidden secret can use it to conceal a = side channel attack. (See Moti Yung's kleptography schemes.) What I rea= lly like about these deterministic schemes is that they allow the random co= mponent of the system to be isolated.


=C2=A0
--000000000000aff2eb05952f1c66-- From nobody Fri Oct 18 06:37:40 2019 Return-Path: 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 2F41B1201EA for ; Fri, 18 Oct 2019 06:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj8HsGKi1J0R for ; Fri, 18 Oct 2019 06:37:35 -0700 (PDT) Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:3595]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0B61200FE for ; Fri, 18 Oct 2019 06:37:34 -0700 (PDT) Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 46vnCH5Vmgz4wTQ for ; Fri, 18 Oct 2019 15:37:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1571405851; bh=WNxjOBNS4epCC77XjdEI8qaFCDzdfGisQ0lP68OeixY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=roGCfHaiG2vT4yyh2c/LeiGlYF7WV2ss7it+z/0TyIznb6JDUtyC2LoedC9MHrzvF 4fmXcrnaLcpTl8vRAicp25foQydm3kH8GVumNH217byJTHOJ+L/pPjSl002A9luRxN RNtONiNheTekhCKKLvspa4t/3mXPuSJ5UmIHMrXU= Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 46vnCH4hp8z4wnd for ; Fri, 18 Oct 2019 15:37:31 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 46vnCH4MMGz4wTQ for ; Fri, 18 Oct 2019 15:37:31 +0200 (CEST) Received: from [IPv6:2a05:3e00:9:2100:dc7:9e4a:72a5:36e1] (dyn-1e635a27a4e97cd000129000.nds.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:9:2100:dc7:9e4a:72a5:36e1]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 46vnCG00Qxzyv0 for ; Fri, 18 Oct 2019 15:37:29 +0200 (CEST) To: openpgp@ietf.org References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <8736fs7ao8.fsf@fifthhorseman.net> <22567.1571307200@dooku.sandelman.ca> <87r23b5kvt.fsf@fifthhorseman.net> From: Marcus Brinkmann Message-ID: Date: Fri, 18 Oct 2019 15:37:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <87r23b5kvt.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 13:37:38 -0000 On 10/17/19 7:42 PM, Daniel Kahn Gillmor wrote: > On Thu 2019-10-17 12:13:20 +0200, Michael Richardson wrote: >> That's a good point; however sometimes perfect is the enemy of good enough, >> and that has been the case for encrypted email for a long time. >> >> A recoverable key would be an option, not a requirement. > > yep, that's why i'm trying to help think this through, even though i'm > not particularly excited about it. :) > >> {An interesting (mathematical, density of primes) question would be whether >> one would be able to determine from looking at the public key whether it was >> recoverable or not. That is, can one recognize some pattern in the expanded >> DRBG. It might still be statistically secure, yet since the amount of entropy >> in the key is less than the entropy in the input, it might leave a pattern} > > Can you give an example of this? I haven't tried to prove this, but i > think if the generated public key (whether a curve25519 point or an RSA > modulus) is distinguishable from other public keys, there is a strong > argument to be made that either the DRBG or the secret key derivation > mechanism is deeply flawed. Svenda, et al: "The Million-Key Question – Investigating the Origins of RSA Public Keys", USENIX Security Symposium 2016. https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_svenda.pdf "We analysed over 60 million freshly generated key pairs from 22 open- and closed-source libraries and from 16 different smartcards, revealing significant leakage." Thanks, Marcus -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Fri Oct 18 08:39:54 2019 Return-Path: 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 5FAEF12000F for ; Fri, 18 Oct 2019 08:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm4isqMttWp2 for ; Fri, 18 Oct 2019 08:39:49 -0700 (PDT) Received: from mailpile.is (mailpile.is [139.162.218.203]) by ietfa.amsl.com (Postfix) with ESMTP id 51C44120896 for ; Fri, 18 Oct 2019 08:39:45 -0700 (PDT) Received: from mailpile.local (tor1.cloud-neutral.org [23.140.160.28]) by mailpile.is (Postfix) with ESMTPSA id D1F399CC0F; Fri, 18 Oct 2019 15:39:41 +0000 (UTC) Content-Type: multipart/mixed; boundary="==FRSnWH7IpTCFYgPZ85sMZmRpEhygIg==" MIME-Version: 1.0 From: Bjarni Runar Einarsson To: "Phillip Hallam-Baker" Cc: "IETF OpenPGP" In-Reply-To: References: User-Agent: Mailpile Message-Id: Date: Fri, 18 Oct 2019 15:38:47 -0000 Autocrypt: addr=bre@mailpile.is; prefer-encrypt=mutual; keydata=xsFNBE4tgKYBEA DI8ULBJPw1a4h/D9Re5AZZ7xBtI9hIljUKz/bBovBGmRsrG6+IjKZ4um1kkJDhwiY0SzrzqE4L1hr cPRA46WbX0/aUuxL7LWbNDl6i7GBP28eU4I+mQcri2oS/rMfx3rnqe2dF85KKdTvS/9SsGAYNwK49 a+DMdsgDT3xMTf1JMrV5lRI7JCzop7v0AVbt9pyJAySJvQWcmkiWEZCWGpQxlYn/CnBVhv3iKToFt oIYKfcWLK/ADZ5CikwF7jDQM30mHovY4Ui31gVWnlhOw+UKpNviwbH7lr6flo2wFuaiD1jutKwqnG s6gH5A/tF6RtUCt6KzYoXpNochk8DGzm3G//sMDdreyUZeiXsF665IdUZ1V8OxU+S17MrxNiGjvY5 gRlD6a4oMsEZQPLQia4j7mCX/kTRsm5Xo+NqBMigNIvH7BJ+DcAqYnMT3kCbLyM3cAPhPn6zrSlXA mSsjAYk0bSLV9Ow0CITVcfrLB+2k+KFPFLl0ewXD75tspRk3wNBJ6GbhekOwzZE7xjrqWgR9Tfmlg DWArZT6oxqtKTiYnwiuQqPixONsc1jdR8bhqDZaJh7HkrZcY7yMDKQWe+1MxwBTV/DbbkrTmTT4ff RWCKi0Dv1do3NDgFXDC/3XpvFD2h2HPMs6pu8rG3CqS8YRJeE+p8TV7RJePSrb50rx4wARAQABzTB CamFybmkgUi4gRWluYXJzc29uIChNYWlscGlsZSkgPGJyZUBtYWlscGlsZS5pcz7CwY8EEwECADkC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEEYaAVdj0o1BCoexlzKBkdmztBmbQFAl0X+KQAC gkQKBkdmztBmbT72hAAit87DtuEM74doeqYa2nYj5iba7wgnnZVnSLK/tN1g0mLYMrXX/nsI8elFM lB4o/qw/y3SlSvXSe2+MJ3OImIjSR2t7yeQuA3rNcZE1wTN9+FL+OVtOzNzAHvI/+2A7NQAgxOd83 nDOe1N6g4lzJZgNbWyvlUUpqGe1uRJwCxrVAW0BnxQuFLmUM+ypx+Ht5lX05JYzJh2lt05g2QBgNg GHZ2iMSl+uTaq1K5Y62jIFeP5PutPXwDFtKgUg2zY30SLYdp/SVl19fH4SSTTgXuYj9nACZ/UKy8l h7t5liUOmTi8QjlVLXQUJflgEwm8OJhnuWODNZQwAx0msqG5AsHI9nv48fTSnBACpGq58GxSmnWUv yO4Eqrbi+2HKzoRymDyzuPLwrPNyTJITxhhj5g0613isttdiM9+vX73jpWOilyKbyKfmCdOoUliEB Vt/+QGD9lt6iUfotgvgGpS/JkBi+X9otEN+wb1vJBCzK1Dfy7CrEHx7tD3+5FJi8mrSlaKeUqjLkR UbdWbBIc+kfVFpkqDzJmz6QoKWAevTk+GwETbD2aFTjX37M9EWkk3sDaEXSYFIT1X6++ykOl7bX+4 Sm2kRaBr8O8B1+26T+ZeVKvg14nYvr4Ck92/y/cPUgrW6meE1WC/9bXqrsMR1pY9Y7N8cw8h6GIpk ehy+XiuYrOwE0EVbaWEQEIAM0AUqE7vyJSdoCpKVMydXcnpzGSv+NUeTPxYObfjcQiAjeSDVgbhRQ eb8jRmhMpTY8mwd7o1soJlJ71JewXmLw7/u2ixYOWUtdLU6w8C2bXTWqq5gTJFMtUvq+Lt2AcWgcQ WCyVbzSjVvHR+Djy6qGiO1Tf90K9fYpdEOQKJrcFCVL88gz3qpP6H5vm29xNUZQWb3E6F6cSRiGYW QZ4mTmJFE1hOKGHsmLaFFeJy6sVMOE62y4FejA5p2R9lQ/u2sGkgKfQ0OfOCk778w07u6XtYHX/7X zRA0ma4PWL4/nXt7bjOqSC119+yLYYL6f/qQeMbJIX3qOIDxsfqxm+6/UAEQEAAcLBfAQYAQIAJgI bDBYhBGGgFXY9KNQQqHsZcygZHZs7QZm0BQJdF/kZBQkLI8oHAAoJECgZHZs7QZm0yfQP/0K9lm6C m6s2Q5Z3e0AevmZOaGIOVIq4UK+GoRTyKGC0gzya5oXlDQGsefS+I5iAZiwlFfQPwZ0TCujXawrwq OKpNjaoUiMMLaRMNP17yVcfvrNN23YWMAOFZoxJyczXveVDgEC/VDRWVguV6LbRv3ovIb9VlsbJ9R WvdzmZEtOWJ+PK0yeBaM2EmH7B3Liq6WKEv+PwPTt1giwB20Lf5wgUGROF2hBF9spd2J1p0ZzWarx keuMDGEh8djVSBqwP2pqrTQWArPvONRGcl/pOgfCyx6fVdrUMTW79KuWTyK+Re9zctpwCKAURCikD qFAupFh2kJmbobOE2miYZ50YdhmoejHK3iBzdEijfPiOqWoStapd44q3o8s+KEWvRymMfp7tQiTEH OxNga9hIomntAqYT/6F5En0RhnVjK3ZRaxoI2VPWa5AA878k9GpqfFO9h5z7e18b+4ukVl1PY4S4w FV+lqqq/ODbWiZS+lKXkcVQoVCFhDEhenV8uuKSMfZR/PrjShaMI/AjP6ESHowlEdDaus6TeiJWfI P5QQViZAQg/tWtwPq2YzMVCS/S1rK+EjZp4Db55N4VxDAE5N0jSV+2LsJhFg+57UW9genrOAzkZZE DRQLjVPAPmR2uUx5A13TTX7TNM07D6j+5I9FnLGd/sW3wcyxlMWwN4IMY1bt OpenPGP: id=61A015763D28D410A87B197328191D9B3B4199B4; preference=signencrypt Archived-At: Subject: Re: [openpgp] Known seed key generation X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 15:39:52 -0000 --==FRSnWH7IpTCFYgPZ85sMZmRpEhygIg== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! Phillip Hallam-Baker wrote: > On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einarsson wrote: > > I'll refrain from derailing this thread to pontificate on why. > > Saying that you have technical objections which you will not > reveal is incredibly rude. Either state your objections so they > can be responded to or don't state them at all. I apologise, I meant no offence. Just that I didn't want to get too far off topic. But since you feel strongly, I'm happy to elaborate. As I understand it, generating keys from a known seed is intended as a backup/restore/sync strategy for the secret key material. But as such, it does nothing to address all the metadata surrounding the key (or keys), which tends to be rather important. Schemes based on a shared seed are therefore (IMO) insufficient for many (most?) real world use-cases. Furthermore, generating keys from a known seed implies a lot of hidden dependencies. If people do not take care to implement the critical algorithms in exactly the same way, different implementations will generated different keys from the same seed. If using code-words, dictionaries have to be standardized and kept unchanged, across all supported languages. If there are bugs or mistakes in the scheme, you can't fix them without adding a compatibility layer that can regenerate previous generations of keys. (Consider the kind of changes people made to cryptographic algorithms to avoid timing attacks - that's the sort of work that will break known seeds. Any bugfixes or code reorg runs this risk.) Everything has to go exactly right for your restoration procedure to work; which is really not a characteristic you want in a backup system. Do you really want to attempt a restore 10 years later, discover that a security update changed the algorithms, and you need to go digging up obsolete versions of GnuPG to restore your data? Why expose yourself to that risk? The main benefit I see, is that a known seed can be very small and thus facilitate certain types of synchronization in extremely low-bandwidth environments (e.g. QR codes). If you're not bandwidth constrained, I strongly suspect known seeds are a false economy. In particular, for shared test data, there is no bandwidth constraint and there is absolutely no reason to take on all the above complexity and constraints. Just do the simple thing and copy the key material. It works. > I proposed this idea September 28. I expect writing the draft > and shipping code to take no more than a day. For openpgp.js, Sequoia, GnuPG, and PgPy? All in one day? Impressive! :-D > Nor do I see a need for > this to be widely implemented to address an issue that only > affects developers. Shared test data, by its very nature, is the sort of thing you use to test and compare different implementations. The whole point is compatibility, and the lower the bar for that, the better. > The model I think we need here is to have an interop event in > which implementations demonstrate that they can generate and > consume a particular corpus. And then publish a report on that > interop event with the names of the tested implementations and > the results. That is one of an almost infinite number of testing activities people could undertake with a shared corpus of test messages. Cheers, - Bjarni -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2p3K0ACgkQjgA3FgDP lJHnaggAgCydMNe2kngEKKKG+2Ha8ssgeR91zOXttSVNPHv2HuIXq1G+cztgdfhc XgR3Nk3AOzD0z3j8nl0CP6I3aCugu/fINFu7UDpetLwMpjUiKUTE+KV46xit3WvY rJpVexiNclyIDLtJHxWPZAOqZFZoDbRjqYrhvxJWYKIfxP22QMxew4foytve1bTd 4cYAxHGWyItMaBTZTvUiCi1BGYRHZ+AHnD2h/oC5ByaXT2Trbqfc+3z/6fcfRJYr ahhi4tMdiRsULa5r9KE3NOlLQRxhOQ+xiXGoZBIOcb508pMAL5+fSe974R4DJuNO hCHq0a8SYMwlwayzRvZzYLtstQAUfw== =Fjyb -----END PGP SIGNATURE----- --==FRSnWH7IpTCFYgPZ85sMZmRpEhygIg==-- From nobody Fri Oct 18 10:25:05 2019 Return-Path: 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 849CA1200F4 for ; Fri, 18 Oct 2019 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICwkqKSltdft for ; Fri, 18 Oct 2019 10:25:01 -0700 (PDT) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD9F12000F for ; Fri, 18 Oct 2019 10:25:01 -0700 (PDT) Received: by mail-oi1-f174.google.com with SMTP id k9so5851113oib.7 for ; Fri, 18 Oct 2019 10:25:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hlq2eJa7HH+hq2AsyH+RkNhUqVRwtAVueW6CfzSpudw=; b=FfV7kp+TclJiXI78jEZQ+twZiuXY+K9PxNhGpMJy2To3/5H8PrXxkhM4hddxnU8Ciw B20b2v9V1ob6rSWJVFUwemj8tjZx8HlO1bkGyNwMpwc1XshrMrcLwWU2qCdGmvKRt0vg e30l9r24VWTFjn88w59N+91CGEceoV+163Lz5yhATqSAzF/YAVt+lGWaseqWYeoODk3g Ecer2Qg0de+twg6fT84HmY/5jKp1B5K/aRVbMPKDiAodBXWqDGbjljkAVaIMB6B4oDSI onjNObajNW2Aqp/KkddNYImzF/1VPpBVJwRuNRKwHplTQYttKpX0uCNZYOsEXw5UP3+C MVrg== X-Gm-Message-State: APjAAAWvGg8EQLMD+pAluseAw5VcnOzH+7ayZf3YeCBhUHNl3fc216V0 51kwu8vNu/TnWcsdzb3Jd26rG+DMHMMrWUwgYw0= X-Google-Smtp-Source: APXvYqzP0gzMfM6pEEh/bBaElJkzQ0M07K1jWEzb9/HGJJ6VChD+Hvbvk0FSl1/MVxc+kpC+2sCqd8lgmVU/SjbFMzU= X-Received: by 2002:aca:1b0f:: with SMTP id b15mr9057096oib.58.1571419500853; Fri, 18 Oct 2019 10:25:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 18 Oct 2019 13:24:48 -0400 Message-ID: To: Bjarni Runar Einarsson Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="0000000000002440c70595329da8" Archived-At: Subject: Re: [openpgp] Known seed key generation X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 17:25:03 -0000 --0000000000002440c70595329da8 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einarsson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello! > > Phillip Hallam-Baker wrote: > > On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einarsson > wrote: > > > I'll refrain from derailing this thread to pontificate on why. > > > > Saying that you have technical objections which you will not > > reveal is incredibly rude. Either state your objections so they > > can be responded to or don't state them at all. > > I apologise, I meant no offence. Just that I didn't want to get > too far off topic. > > But since you feel strongly, I'm happy to elaborate. > > As I understand it, generating keys from a known seed is intended > as a backup/restore/sync strategy for the secret key material. > But as such, it does nothing to address all the metadata > surrounding the key (or keys), which tends to be rather > important. Schemes based on a shared seed are therefore (IMO) > insufficient for many (most?) real world use-cases > The metadata is generally associated with the public key rather than the private. > Furthermore, generating keys from a known seed implies a lot of > hidden dependencies. If people do not take care to implement the > critical algorithms in exactly the same way, different > implementations will generated different keys from the same seed. > If using code-words, dictionaries have to be standardized and > kept unchanged, across all supported languages. If there are bugs > or mistakes in the scheme, you can't fix them without adding a > compatibility layer that can regenerate previous generations of > keys. > Not for the new CFRG keys. They are simply random blobs. Generating the blob from a seed using a KDF is straightforward. Everything has to go exactly right for your restoration procedure > to work; which is really not a characteristic you want in a > backup system. Do you really want to attempt a restore 10 years > later, discover that a security update changed the algorithms, > and you need to go digging up obsolete versions of GnuPG to > restore your data? Why expose yourself to that risk? > I don't think this type of key management should be part of apps. It is probably something that is most useful for disk level encryption and for SSH. OpenPGP would only be using it for establishing the same key across devices. In particular, for shared test data, there is no bandwidth > constraint and there is absolutely no reason to take on all the > above complexity and constraints. Just do the simple thing and > copy the key material. It works. > > > I proposed this idea September 28. I expect writing the draft > > and shipping code to take no more than a day. > > For openpgp.js, Sequoia, GnuPG, and PgPy? All in one day? > Impressive! :-D > They can all import a P12 or PEM encoded key or they are useless. I don't think key generation or management should be part of the crypto apps that make use of the keys. It is a separate function. --0000000000002440c70595329da8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einar= sson <bre@mailpile.is> wrote:<= br>
-----BEGIN PGP S= IGNED MESSAGE-----
Hash: SHA512

Hello!

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einarsson <bre@mailpile.is> wrote: > > I'll refrain from derailing this thread to pontificate on why= .
>
> Saying that you have technical objections which you will not
> reveal is incredibly rude. Either state your objections so they
> can be responded to or don't state them at all.

I apologise, I meant no offence. Just that I didn't want to get
too far off topic.

But since you feel strongly, I'm happy to elaborate.

As I understand it, generating keys from a known seed is intended
as a backup/restore/sync strategy for the secret key material.
But as such, it does nothing to address all the metadata
surrounding the key (or keys), which tends to be rather
important. Schemes based on a shared seed are therefore (IMO)
insufficient for many (most?) real world use-cases
The meta= data is generally associated with the public key rather than the private.

=C2=A0
Furthermore, generating keys from a known seed implies a lot of
hidden dependencies. If people do not take care to implement the
critical algorithms in exactly the same way, different
implementations will generated different keys from the same seed.
If using code-words, dictionaries have to be standardized and
kept unchanged, across all supported languages. If there are bugs
or mistakes in the scheme, you can't fix them without adding a
compatibility layer that can regenerate previous generations of
keys.

Not for the new CFRG keys. They are simply random blo= bs. Generating the blob from a seed using a KDF is straightforward.

Everything has to go exactly right for your restoration procedure
to work; which is really not a characteristic you want in a
backup system. Do you really want to attempt a restore 10 years
later, discover that a security update changed the algorithms,
and you need to go digging up obsolete versions of GnuPG to
restore your data? Why expose yourself to that risk?
<= br>
I don&= #39;t think this type of key management should be part of apps. It is proba= bly something that is most useful for disk level encryption and for SSH. Op= enPGP would only be using it for establishing the same key across devices.= =C2=A0
In particular, for shared test data, there is no bandwidth
constraint and there is absolutely no reason to take on all the
above complexity and constraints. Just do the simple thing and
copy the key material. It works.

> I proposed this idea September 28. I expect writing the draft
> and shipping code to take no more than a day.

For openpgp.js, Sequoia, GnuPG, and PgPy? All in one day?
Impressive! :-D

They can all import a P12 or PEM encoded key or = they are useless. I don't think key generation or management should be = part of the crypto apps that make use of the keys. It is a separate functio= n.
--0000000000002440c70595329da8-- From nobody Fri Oct 18 11:53:27 2019 Return-Path: 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 15F31120811 for ; Fri, 18 Oct 2019 11:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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=mD/L7hav; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Kr+YYnGC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXDPvIVePvgI for ; Fri, 18 Oct 2019 11:53:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C25120800 for ; Fri, 18 Oct 2019 11:53:18 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1571424796; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=KTKbqX8/YEIrP2tmHRndl4+H7F/KGFFyicYH+zDtQAQ=; b=mD/L7hav36N+VSsMQjOlxgZizvShkoqNEd4G5vcPNep8tKOaOE2FMsPS g37KPqXbmmt4MMg1fBbVPgl5IKBbAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1571424796; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=KTKbqX8/YEIrP2tmHRndl4+H7F/KGFFyicYH+zDtQAQ=; b=Kr+YYnGCDDB5rad6G3RdcMNwHI1OYE7Xk9CxA6miNQoVlbYguG6BPXnt 5tZZCjo1h674JoX/mYgXz2NlB2W2rI2udhQOgeC90osoVLRvQmDPWnMRu6 m4NjLrABsd/Mn52maNbyewK9DD3TS5iWnAzU/+VSUuyDXBDkLi/+NKWMuM 4pIo/oNNBiFegJE8ZoobymwEhV8cr6DX1n2sIGasiITk6ho+Spn0bNLy3c 7ItxcIdcocuNzIu9ciYjHHD/HQ7SPT1XAbAvphLI+pqS6C45Q48XD5RmX/ Cue1urug6wO8WLf3jB/tiLKRdr4SyD8tB6viwuUkMjKF5tncQa49RA== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E9F28F9A5; Fri, 18 Oct 2019 14:53:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C7BCA204BB; Fri, 18 Oct 2019 14:47:27 -0400 (EDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , Bjarni Runar Einarsson Cc: IETF OpenPGP In-Reply-To: References: Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 18 Oct 2019 14:47:27 -0400 Message-ID: <87v9sl51s0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Shared OpenPGP keys for use in test corpuses X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 18:53:21 -0000 --=-=-= Content-Type: text/plain On Fri 2019-10-18 09:00:42 -0400, Phillip Hallam-Baker wrote: > Saying that you have technical objections which you will not reveal is > incredibly rude. Either state your objections so they can be responded to > or don't state them at all. Can we tone it down a bit? Bjarni's objections seem explicitly stated to me: he's objecting on the grounds of simplicity. The draft he points to (which i'm a co-author on) provides material that people can use today, without any additional effort. Phil's proposal offers a wider feature set, it's true, but requires more development of consensus about how to design the key derivation, and also requires more work on the side of implementers. Standards develoment can support both of these approaches, there's no reason to queue one behind the other. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXaoIvwAKCRB2GBllKa5f +Ft0AQDhBvAL3s+1cGXhnxHlSYnSQeK9MKcg3LVdVOz3XrxW0gD/R1P57sOqtjo1 G782zKgRF+amjj2lYo5P7jA2bC5zdwQ= =DT7P -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 18 13:48:14 2019 Return-Path: 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 4E1AA120804 for ; Fri, 18 Oct 2019 13:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjo8B22uyBqj for ; Fri, 18 Oct 2019 13:48:10 -0700 (PDT) Received: from mailpile.is (mailpile.is [139.162.218.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECFC1201E5 for ; Fri, 18 Oct 2019 13:48:10 -0700 (PDT) Received: from mailpile.local (exit1.rathhansen.com [51.158.147.12]) by mailpile.is (Postfix) with ESMTPSA id 08FA89CB4D; Fri, 18 Oct 2019 20:48:06 +0000 (UTC) Content-Type: multipart/mixed; boundary="==34TaMSEKLG84igU4bfqBLugncyIhGe==" MIME-Version: 1.0 From: Bjarni Runar Einarsson To: "Phillip Hallam-Baker" Cc: "IETF OpenPGP" In-Reply-To: References: User-Agent: Mailpile Message-Id: Date: Fri, 18 Oct 2019 20:46:43 -0000 Autocrypt: addr=bre@mailpile.is; prefer-encrypt=mutual; keydata=xsFNBE4tgKYBEA DI8ULBJPw1a4h/D9Re5AZZ7xBtI9hIljUKz/bBovBGmRsrG6+IjKZ4um1kkJDhwiY0SzrzqE4L1hr cPRA46WbX0/aUuxL7LWbNDl6i7GBP28eU4I+mQcri2oS/rMfx3rnqe2dF85KKdTvS/9SsGAYNwK49 a+DMdsgDT3xMTf1JMrV5lRI7JCzop7v0AVbt9pyJAySJvQWcmkiWEZCWGpQxlYn/CnBVhv3iKToFt oIYKfcWLK/ADZ5CikwF7jDQM30mHovY4Ui31gVWnlhOw+UKpNviwbH7lr6flo2wFuaiD1jutKwqnG s6gH5A/tF6RtUCt6KzYoXpNochk8DGzm3G//sMDdreyUZeiXsF665IdUZ1V8OxU+S17MrxNiGjvY5 gRlD6a4oMsEZQPLQia4j7mCX/kTRsm5Xo+NqBMigNIvH7BJ+DcAqYnMT3kCbLyM3cAPhPn6zrSlXA mSsjAYk0bSLV9Ow0CITVcfrLB+2k+KFPFLl0ewXD75tspRk3wNBJ6GbhekOwzZE7xjrqWgR9Tfmlg DWArZT6oxqtKTiYnwiuQqPixONsc1jdR8bhqDZaJh7HkrZcY7yMDKQWe+1MxwBTV/DbbkrTmTT4ff RWCKi0Dv1do3NDgFXDC/3XpvFD2h2HPMs6pu8rG3CqS8YRJeE+p8TV7RJePSrb50rx4wARAQABzTB CamFybmkgUi4gRWluYXJzc29uIChNYWlscGlsZSkgPGJyZUBtYWlscGlsZS5pcz7CwY8EEwECADkC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEEYaAVdj0o1BCoexlzKBkdmztBmbQFAl0X+KQAC gkQKBkdmztBmbT72hAAit87DtuEM74doeqYa2nYj5iba7wgnnZVnSLK/tN1g0mLYMrXX/nsI8elFM lB4o/qw/y3SlSvXSe2+MJ3OImIjSR2t7yeQuA3rNcZE1wTN9+FL+OVtOzNzAHvI/+2A7NQAgxOd83 nDOe1N6g4lzJZgNbWyvlUUpqGe1uRJwCxrVAW0BnxQuFLmUM+ypx+Ht5lX05JYzJh2lt05g2QBgNg GHZ2iMSl+uTaq1K5Y62jIFeP5PutPXwDFtKgUg2zY30SLYdp/SVl19fH4SSTTgXuYj9nACZ/UKy8l h7t5liUOmTi8QjlVLXQUJflgEwm8OJhnuWODNZQwAx0msqG5AsHI9nv48fTSnBACpGq58GxSmnWUv yO4Eqrbi+2HKzoRymDyzuPLwrPNyTJITxhhj5g0613isttdiM9+vX73jpWOilyKbyKfmCdOoUliEB Vt/+QGD9lt6iUfotgvgGpS/JkBi+X9otEN+wb1vJBCzK1Dfy7CrEHx7tD3+5FJi8mrSlaKeUqjLkR UbdWbBIc+kfVFpkqDzJmz6QoKWAevTk+GwETbD2aFTjX37M9EWkk3sDaEXSYFIT1X6++ykOl7bX+4 Sm2kRaBr8O8B1+26T+ZeVKvg14nYvr4Ck92/y/cPUgrW6meE1WC/9bXqrsMR1pY9Y7N8cw8h6GIpk ehy+XiuYrOwE0EVbaWEQEIAM0AUqE7vyJSdoCpKVMydXcnpzGSv+NUeTPxYObfjcQiAjeSDVgbhRQ eb8jRmhMpTY8mwd7o1soJlJ71JewXmLw7/u2ixYOWUtdLU6w8C2bXTWqq5gTJFMtUvq+Lt2AcWgcQ WCyVbzSjVvHR+Djy6qGiO1Tf90K9fYpdEOQKJrcFCVL88gz3qpP6H5vm29xNUZQWb3E6F6cSRiGYW QZ4mTmJFE1hOKGHsmLaFFeJy6sVMOE62y4FejA5p2R9lQ/u2sGkgKfQ0OfOCk778w07u6XtYHX/7X zRA0ma4PWL4/nXt7bjOqSC119+yLYYL6f/qQeMbJIX3qOIDxsfqxm+6/UAEQEAAcLBfAQYAQIAJgI bDBYhBGGgFXY9KNQQqHsZcygZHZs7QZm0BQJdF/kZBQkLI8oHAAoJECgZHZs7QZm0yfQP/0K9lm6C m6s2Q5Z3e0AevmZOaGIOVIq4UK+GoRTyKGC0gzya5oXlDQGsefS+I5iAZiwlFfQPwZ0TCujXawrwq OKpNjaoUiMMLaRMNP17yVcfvrNN23YWMAOFZoxJyczXveVDgEC/VDRWVguV6LbRv3ovIb9VlsbJ9R WvdzmZEtOWJ+PK0yeBaM2EmH7B3Liq6WKEv+PwPTt1giwB20Lf5wgUGROF2hBF9spd2J1p0ZzWarx keuMDGEh8djVSBqwP2pqrTQWArPvONRGcl/pOgfCyx6fVdrUMTW79KuWTyK+Re9zctpwCKAURCikD qFAupFh2kJmbobOE2miYZ50YdhmoejHK3iBzdEijfPiOqWoStapd44q3o8s+KEWvRymMfp7tQiTEH OxNga9hIomntAqYT/6F5En0RhnVjK3ZRaxoI2VPWa5AA878k9GpqfFO9h5z7e18b+4ukVl1PY4S4w FV+lqqq/ODbWiZS+lKXkcVQoVCFhDEhenV8uuKSMfZR/PrjShaMI/AjP6ESHowlEdDaus6TeiJWfI P5QQViZAQg/tWtwPq2YzMVCS/S1rK+EjZp4Db55N4VxDAE5N0jSV+2LsJhFg+57UW9genrOAzkZZE DRQLjVPAPmR2uUx5A13TTX7TNM07D6j+5I9FnLGd/sW3wcyxlMWwN4IMY1bt OpenPGP: id=61A015763D28D410A87B197328191D9B3B4199B4; preference=signencrypt Archived-At: Subject: Re: [openpgp] Known seed key generation X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 20:48:13 -0000 --==34TaMSEKLG84igU4bfqBLugncyIhGe== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello again, Phillip Hallam-Baker wrote: > On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einarsson wrote: > > > > As I understand it, generating keys from a known seed is intended > > as a backup/restore/sync strategy for the secret key material. > > But as such, it does nothing to address all the metadata > > surrounding the key (or keys), which tends to be rather > > important. Schemes based on a shared seed are therefore (IMO) > > insufficient for many (most?) real world use-cases > > The metadata is generally associated with the public key rather > than the private. I think you're missing the point. I'm contending that if you need a backup of your secret key material, it's because you've used it for something of value. Which means you probably also need backups for that "something", whatever it may be. I have little use for a scheme which only lets me restore/sync private key material and nothing else. This is the crux of my "not a fan" comment from earlier. This is an important difference between the world of OpenPGP and the world of Bitcoin. In the world of Bitcoin, all that data you're interacting with is in the public block-chain, so the world backs it up for you. That's why keys like this are useful there. These conditions do not hold in the world of OpenPGP and probably never will. > > Furthermore, generating keys from a known seed implies a lot of > > hidden dependencies. If people do not take care to implement the > > critical algorithms in exactly the same way, different > > implementations will generated different keys from the same seed. > > If using code-words, dictionaries have to be standardized and > > kept unchanged, across all supported languages. If there are bugs > > or mistakes in the scheme, you can't fix them without adding a > > compatibility layer that can regenerate previous generations of > > keys. > > Not for the new CFRG keys. They are simply random blobs. > Generating the blob from a seed using a KDF is straightforward. Not what? Which of my points are you responding to here? I don't see any of my points addressed by this response. > > Everything has to go exactly right for your restoration procedure > > to work; which is really not a characteristic you want in a > > backup system. Do you really want to attempt a restore 10 years > > later, discover that a security update changed the algorithms, > > and you need to go digging up obsolete versions of GnuPG to > > restore your data? Why expose yourself to that risk? > > I don't think this type of key management should be part of > apps. It is probably something that is most useful for disk > level encryption and for SSH. OpenPGP would only be using it > for establishing the same key across devices. I don't understand this response either. I don't think we're communicating. > > For openpgp.js, Sequoia, GnuPG, and PgPy? All in one day? > > Impressive! :-D > > They can all import a P12 or PEM encoded key or they are > useless. I don't think key generation or management should be > part of the crypto apps that make use of the keys. It is a > separate function. All of those libraries/tools are used to generate and manage keys. Apps are built on top of them. If your vision is that someone create a totally separate tool for generating keys from human readable seeds, I have no problem with that (hasn't this already been done?). In fact, I think it's probably a good idea, because it minimizes the amount of code that has to be kept stable and unchanging so key (re)generation can be trusted long term. But... I still see no reason to make my test suites depend on that tool, when I can just import a pre-published key. Kind regards, - Bjarni -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2qJKYACgkQjgA3FgDP lJHiowgAhKvqQi7QV+VovSf2ZCDfNooH06cuvvg/lvzjTLVVpNxIjA4Gr+++qhDQ 4WK7Z3q6hurlqoSyU9aVNBD3PnILyYEeyfrA5w0W6H97aLIoHnrZHLhUfHvk/8gL OIka77BNitSIN+/MbsTMOlr+BFUZvVagwbw8oLS02QnS7SdNvLxKHbI1ot0xyu86 q0PmHieGmy1T0SH2STJQqv37sunoqqkvf4MFiEV8ppjqG+qC52aOcAKQg1PXrsRX VZuDW+8NNNTxMHzto6hMO8Nyce2r16DVs9K3sYtpLQx9GlDenuDj9qsbW9oh+4SK 1xhxN3xxvr6NshhCfnGgE7Vl/EMAYg== =FOHV -----END PGP SIGNATURE----- --==34TaMSEKLG84igU4bfqBLugncyIhGe==-- From nobody Fri Oct 18 15:51:20 2019 Return-Path: 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 5FC8212092A for ; Fri, 18 Oct 2019 15:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHv2fEu0q3Bo for ; Fri, 18 Oct 2019 15:51:07 -0700 (PDT) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854F31209A8 for ; Fri, 18 Oct 2019 15:51:06 -0700 (PDT) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:b610:a2f0:36c1:12e3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 56A5E60459 for ; Fri, 18 Oct 2019 22:51:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1571439065; bh=iR3voCb9D105Fo25Q/0FIuMP6YKpCPSiR4FmTqrKzw0=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=mb8tLg8AXhiLWPh+vuqJdECCGynLXuWA2OP0uEl6dlABKMc5d5G8UWPnNs5PYaQjC F/fqd3x88z2d3r0ExXPWQdHOorOoceBAsQt0rw8mzE1XvU84UqJ4rzVvtPbTzAyLOM m5nSWRQkFrbM35bj7G9N+qthkFQUNH3GOHlMG5J5w9zCiHtGa58XuJ5VuO4NbfSm0A 3oczzTKPO7fs3UHDoOcoBaiHO4TZ0mWrsSTe/EVgKJWWQ4Eefsjv3g2CU6fT/b/6IR Ijz1uj355npRub0Ndj9SVP/8u+2xfqQj9QzXEQRsK6xB1kHO++8GO3Lt8eZSMp7qv6 hzRup64/JwxKBcPhFWZmGwtyHkVzWyZ9d8HdbmBENwnTW5HEE4etwDfhDcgtHLtoxD JfkY+/T0FXN6u8G+QJ7eNYHnbk31vnOoKu+RSRH3S3UG6iZnPitUVcKaN2vGW1QSlp I08UzLfHT9yJirLlJ+UnqQKfhQVTlYjy/KKUbUsY/2U/Gzp/mQ3 Date: Fri, 18 Oct 2019 22:51:00 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lqo4fjxrbid6vqwt" Content-Disposition: inline In-Reply-To: <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> X-Machine: Running on camp using GNU/Linux on x86_64 (Linux kernel 5.3.0-trunk-amd64) User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 22:51:18 -0000 --lqo4fjxrbid6vqwt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-10-17 at 09:13:02, Kai Engert wrote: > The seed is insufficient for recreating the OpenPGP key. We need > additional meta information. >=20 > The suggestion is to specify the meta information that is required to > recreate the OpenPGP key. In Daniel's response, he mentioned that as > part (c). >=20 > It seems that part (c) would contain information that is specific to > OpenPGP. >=20 > Daniel pointed out that I had missed the "key creation time" in my > enumeration. >=20 > So in addition to the seed, if we want a recovery mechanism that doesn't > require the OpenPGP transferrable public key to be readily available, > we'd have to combine: > - the general seed > - OpenPGP key creation time > - OpenPGP key algo > - OpenPGP key key size > - ...? In addition, you require a deterministic key generation process. This is straightforward for EC keys (generate a random byte string of the appropriate length as the secret key), but it's trickier for RSA and DSA keys. If the random number you pick for p is not prime, should you pick another random one? Increase it by two and try again? What random numbers are you going to pick for Miller-Rabin and how do you extract those from the DRBG? How many times do you iterate Miller-Rabin? For DSA keys, how do you pick the generator? For RSA keys, what values of e do you allow? If p is not less than q, do you swap them, or do you generate a new q? And yes, the Miller-Rabin numbers matter, because it's a probabilistic technique, and it is possible to generate keys based off pseudoprimes, which you would want to be able to reproduce, even if they are insecure. Or you'd have to tell people that the process might produce a totally different key if their original one was not really secure. In order to get this right for non-EC keys, you really need a separate document that defines things down the details, much like RFC 6979 does for deterministic signatures. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --lqo4fjxrbid6vqwt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.17 (GNU/Linux) iQIzBAEBCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAl2qQdQACgkQv1NdgR9S 9otGvQ//Y9jEUBjR8Nuc1xW8yQuBgFq6Qp99flh6y7PHi64FoLyzhMDCpqqS5He/ NsO20TQ/fQvfbzU0FvhdYeFcBjf0VBM2Fu/nim0VJO9XnCv8vzF2sE5BbtN6X5Ic RxcRhVd2xT9Y8V1SOIqym3hF3BK5cNbwes5jaRDtL1P+YScCKB8yEKTBswIgV43+ 31mO1qgJ/4i4nYxzdjP7JiHHM+xwE2u8fFtuCk5XTqKmNhOhT7sKqg62xzdzpFgO 1i/dSLuL+2uyPLsCrxBkwCClIBkGzV9EXUDf/nu2UV/K2ocEcHgc2kYTjtLNDeN3 FP2AUh3mUbtRgFlAVAFfZbMh2fJMm9GVT2VH4ibojuCC8Dqvz6NV7Pl7yrD5Qr3z dFee/26cD6C9XvKxL2EVotKWy7+xHSRJZU55mqEsslyYh90z5GenQrzFt8Mo+l/H la1drtCTFlZhcNks2tBb/wCCisu+m+R8/ZsIvIYPkwb3wGrb4M4VMSI0ojPsZL5D /jn8p9LqequZt8uzH1tORNMoaB46YgLJb7jmA5veixQfquPSH2ySb6YB6/UpwJwR RQnm7ihsFV/ubnuEbELKQN2Ri+M73xjOTf9//fXc+Zwqfb4AmHjzhngZIDdPgyHI m91VK+GByA9Wrs2nUCBRBEdYL/1QRw883EH7n+ptw93g03MXEcs= =JTWn -----END PGP SIGNATURE----- --lqo4fjxrbid6vqwt-- From nobody Fri Oct 18 20:40:11 2019 Return-Path: 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 93201120104 for ; Fri, 18 Oct 2019 20:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSEJzWgllwXw for ; Fri, 18 Oct 2019 20:40:09 -0700 (PDT) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58001200F6 for ; Fri, 18 Oct 2019 20:40:08 -0700 (PDT) Received: by mail-ot1-f51.google.com with SMTP id c10so6642492otd.9 for ; Fri, 18 Oct 2019 20:40:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xsXR0SPz1bk9bsP5iumQ0gw0KfnRreGp6O44Ylg9uOw=; b=MH7zaU2CYXdWHis0TUk7OSPU8AyZKJRImSSgNPYKZB1ziZPdsYRwRXdAs+swbwv9v2 UkDhw1jBhqbaCOD6/8xRaZm3r4P00VcnOiyGOsA0IrcMjJgggyaCmSczVoz+s8bbSrUj 0EGHHNhUkoMU2HdbbppPx+cotG5+Gp1uRf3xIAtjjrEhF6OxV4OhUtjS3Uz0SWFWTvo4 +A3o3Z7TCpqzp+zmnCcB0WaZ9OgdzVMNazvTTwwiXdeKlOUl83Yi6koYEfhINthBeAcD mK452mBY2uWeHSBcO2/eS1Gy+0GTEH9hXrrNUPjaXQoZwNQXuyCCPiOedcsToizvYArn kpww== X-Gm-Message-State: APjAAAVSb1DtzZgtFY4HOlYugyCj7x/Dtg0OgwMZ61jAcOQplFkJKm9N Dq6Knf15nUrURRydtxv7zXrM/TS5WKKRdcgXcpMvye2kM3o= X-Google-Smtp-Source: APXvYqw1J0JIwQhmYQPTicUw3YpW9Oamd7tLcqXZM+Hqwxuyk2bOz76Jk3iHdOJQNI3+T9DTWsWdIRwMrGVbJ0O/u6k= X-Received: by 2002:a9d:7d92:: with SMTP id j18mr10378739otn.37.1571456408163; Fri, 18 Oct 2019 20:40:08 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> In-Reply-To: <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> From: Phillip Hallam-Baker Date: Fri, 18 Oct 2019 23:40:03 -0400 Message-ID: To: "brian m. carlson" Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="000000000000fd1b3805953b34ed" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 03:40:11 -0000 --000000000000fd1b3805953b34ed Content-Type: text/plain; charset="UTF-8" Someone just said we need a spec. Here is a spec: https://www.ietf.org/id/draft-hallambaker-mesh-udf-07.txt It is in the new format which is intended to be read as HTML. Until the tools catch up, you can read it here: http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html The draft does not specify the value of e which it should but I am pretty sure we have standardized on 65537. I see no reference to p being greater than q and it is a mystery to me why we would care when the RSA parameters are the modulus and the private exponent d. Knowledge of p and q is only used to determine d, they are not req --000000000000fd1b3805953b34ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Som= eone just said we need a spec. Here is a spec:
https://www.ietf.org/id/draft-hallambaker-mesh-u= df-07.txt=C2=A0=C2=A0

It is in the new format which is intended to be read as HTML. Until th= e tools catch up, you can read it here:
http://mathmesh.com/Documents/draft-hallambaker-mes= h-udf.html
=
The draft = does not specify the value of e which it should but I am pretty sure we hav= e standardized on 65537. I see no reference to p being greater than q and i= t is a mystery to me why we would care when the RSA parameters are the modu= lus and the private exponent d. Knowledge of p and q is only used to determ= ine d, they are not req

--000000000000fd1b3805953b34ed-- From nobody Fri Oct 18 20:51:05 2019 Return-Path: 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 E567B120104 for ; Fri, 18 Oct 2019 20:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yCCDSNuP22l for ; Fri, 18 Oct 2019 20:51:01 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F82120168 for ; Fri, 18 Oct 2019 20:51:01 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id z6so6687453otb.2 for ; Fri, 18 Oct 2019 20:51:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=46Z6IZUWDE2L00Z/gOK5N3DdZJrWZ0QwZlLZvPWz0qc=; b=W+3ylMh8qn/+j5uPKm1xPki+mfRskvaC1bpdHPDCJzvOvwJYiFLrrY3SDNQwv4Lgr1 +4Vf0e0gOjzua+YQmZTTpKJAjsxMSqRFoaakyxGvmBArCYXYTPHkyPYethFE16INJJ7h SzC0oVFdZPCXzPbh8bMNkhVLsLH8FuQvLcFFvst9YcC9tnIt6hYhrnyhswxSntwCIqdk N7u3zKDFDB2ssRZ7ZFH7eU6+y5gPOaGvMzftX3+CgKWtwwPZjH9Dz+mvsl07P8PFFIgs kkx1AMMiNUg8a/QLtvA7gGG4kJ7tDAbCj8um6nWiw7KDgKY2mSCmBj+XvhrP+NW/geXy Ktgw== X-Gm-Message-State: APjAAAX4jq/cU714ZuakrXbo9VU/5y2E0Fdn+gBED0LQFE+e/xS1gBvP 2UshuClF7G5Jb3vrx9drjRWNzqHQgFELuLS1dM0= X-Google-Smtp-Source: APXvYqwOCIx8KrvqVoksAWK9R0DMW7sYR3GbH5jPAJ2oWRCHH0yRaqQ+PGg8wnyKVlB5+Licf7WddiyhCRs8kPAV9wc= X-Received: by 2002:a9d:4591:: with SMTP id x17mr8199549ote.112.1571457061016; Fri, 18 Oct 2019 20:51:01 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 18 Oct 2019 23:50:57 -0400 Message-ID: To: "brian m. carlson" Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="000000000000e6d92d05953b5bdb" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 03:51:04 -0000 --000000000000e6d92d05953b5bdb Content-Type: text/plain; charset="UTF-8" Carrying on after gmail sent the message before I wanted to... On Fri, Oct 18, 2019 at 11:40 PM Phillip Hallam-Baker wrote: > Someone just said we need a spec. Here is a spec: > https://www.ietf.org/id/draft-hallambaker-mesh-udf-07.txt > > It is in the new format which is intended to be read as HTML. Until the > tools catch up, you can read it here: > http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html > > The draft does not specify the value of e which it should but I am pretty > sure we have standardized on 65537. I see no reference to p being greater > than q and it is a mystery to me why we would care when the RSA parameters > are the modulus and the private exponent d. Knowledge of p and q is only > used to determine d, they are not req > As I was saying, I am not aware of a requirement to know p or q after d is calculated let alone sort them. There are requirements to do with co-primes being of particular lengths. But NIST states these are optional so I am thinking of simply saying that to generate a key pair you use the derivation mechanism specified until you arrive at a pair you like. Given the density of prime numbers and given that the smallest keys we are using are 1024 bits, the work factor for any schemes based on guessing the prime parameters is going to be above 2^1000 which is more than a google. I did not bother with DSA. But that could be added. It has serious problems at this point and is probably just better deprecated. --000000000000e6d92d05953b5bdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Carrying on after gmail sent the message before I wanted to..= .

On Fri, Oct 18, 2019 at 11:40 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
Someone just said we need a spec. Here is a spec:<= /div>

It is in the new form= at which is intended to be read as HTML. Until the tools catch up, you can = read it here:

The draft doe= s not specify the value of e which it should but I am pretty sure we have s= tandardized on 65537. I see no reference to p being greater than q and it i= s a mystery to me why we would care when the RSA parameters are the modulus= and the private exponent d. Knowledge of p and q is only used to determine= d, they are not req

As I was saying, I am not aware of = a requirement to know p or q after d is calculated let alone sort them. The= re are requirements to do with co-primes being of particular lengths. But N= IST states these are optional so I am thinking of simply saying that to gen= erate a key pair you use the derivation mechanism specified until you arriv= e at a pair you like.

Giv= en the density of prime numbers and given that the smallest keys we are usi= ng are 1024 bits, the work factor for any schemes based on guessing the pri= me parameters is going to be above 2^1000 which is more than a google.

I did not bother with DSA. Bu= t that could be added. It has serious problems at this point and is probabl= y just better deprecated.
--000000000000e6d92d05953b5bdb-- From nobody Fri Oct 18 21:40:17 2019 Return-Path: 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 852AB12022D for ; Fri, 18 Oct 2019 21:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLK0f9IbPei5 for ; Fri, 18 Oct 2019 21:40:14 -0700 (PDT) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966BF120019 for ; Fri, 18 Oct 2019 21:40:14 -0700 (PDT) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:b610:a2f0:36c1:12e3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 185F360458 for ; Sat, 19 Oct 2019 04:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1571460013; bh=s/oaNYZbQN8xvADhVP12nyO+lMWa86ozJvpHxyzf+6k=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=t9bDF0k+Vhw5lqRNvtCGvksJwttGPw5qmpTdhzB2w+JNYYDWOQ5BwrxdabxeCDw3+ AXKoWM4LM+uxN/DBBUpU93MeoVTmThmC5bgjjSBuAcgc4osY9XVut8mFymD+1ARbVk WT8m9Dcqb8X29BSxdN0bwlvbQ4+5qHC+xovxYUKIxYf24UdQgmPO7ClXsod318gXou 5l6mnAkVMM072ZK81ocaX0iNM4ij0B1QfzTpdylafY8eHfvVX5MFa/mIiUrTNQf5Bz LTIGpVXZ5KXMXz+9jBjFzU50yScSLHr85fUHn+jC+VXHdg7qBaGYEyi1mhdLh0Xbfb twRXSTLIex51Ir/8vTykPShrVONp/5SNGH5LL3XBw5Nafr/EEpWUti6NiPWVfWjb52 APHDGrE/+5xT44MY41jx1x8j+6PS5pavUJ0DVgoUah3lpwX0B57flu9GYPlLeotvBs l7cfoB3S37Uu1N4EcYby5pL9AyuOCg6jYuBo3iBx7p5z2LiYKDN Date: Sat, 19 Oct 2019 04:40:08 +0000 From: "brian m. carlson" To: IETF OpenPGP Message-ID: <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gjxvs7vxqlafnh4w" Content-Disposition: inline In-Reply-To: X-Machine: Running on camp using GNU/Linux on x86_64 (Linux kernel 5.3.0-trunk-amd64) User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 04:40:17 -0000 --gjxvs7vxqlafnh4w Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-10-19 at 03:40:03, Phillip Hallam-Baker wrote: > Someone just said we need a spec. Here is a spec: > https://www.ietf.org/id/draft-hallambaker-mesh-udf-07.txt >=20 > It is in the new format which is intended to be read as HTML. Until the > tools catch up, you can read it here: > http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html This doesn't specify any method of primality testing which means different implementations can produce different values[0] (and is therefore not deterministic), unless you literally interpret the text "smallest prime integer" as requiring an actual prime. That could be implemented by using the Miller test instead of Miller-Rabin, but that would be much, much slower. In this particular case, the approach to invalid keys (where p and q are unsuitable) is "try again with a different seed", which is probably okay in terms of RSA, because the number of retries necessary will be low. It also doesn't specify DSA keys, which, while uncommon, are still a part of the spec. The "try again" approach will probably be a little more difficult here. > The draft does not specify the value of e which it should but I am pretty > sure we have standardized on 65537. I see no reference to p being greater > than q and it is a mystery to me why we would care when the RSA parameters > are the modulus and the private exponent d. Knowledge of p and q is only > used to determine d, they are not req The OpenPGP secret key contains u, the multiplicative inverse of p mod q, which is used along with p and q for the Chinese Remainder Theorem. RFC 4880 specifically mentions that p must be less than q, which is required for u to exist. (This is backwards from most other specs, which require the opposite and define u as the multiplicative inverse of q mod p.) It is, of course, possible to retain only n and d and eat the performance penalty, but that would not produce a valid OpenPGP secret key. [0] Yes, people should pick a suitable number of iterations for primality testing, but there are people that pick 1 iteration for PBKDF2, which is a demonstration of why we can't have nice things. We actually have to tell people how to write things in an interoperable and secure way. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --gjxvs7vxqlafnh4w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.17 (GNU/Linux) iQIzBAEBCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAl2qk6gACgkQv1NdgR9S 9otrFA//f6IulRD22QEnm9Z3qHrFEC4AKwxf8fDEqlcEKgQBL0uZUVAnkSCmYqS+ ilZffqhbNB74Z7NX1UYo9W6BW6cGsafJRVSlD87/N9Axb0fH14seOA+XOGUJdgPu srU7gWLnLvoyiAOf4G3vxmH28JxYS3o0Hgk+WTdKhnV67k7ccice3rDTxrgI1E9Q lJeWLpOfoZs2clo1/4dUsJsXX/BFC1euFtXo5VrydWCt3xuvDe9SsS5J2Od7wv5i NWuuMjQERHcVQ+H+uwgOhlF+pxqCGcsm5ZIHXHCDgZrcEX/lJbejWhgXkU9erU90 rAec0j1e6ObIAinLtPlG1q4RJYJLx756spNd+tpmp7GQy0uM8JimM2dGMnaFa4sb /QtnCp2nW5fD1xV6UXLKfsPxFYP8x6j4320SazAVmuhdb4TeDa/wZlJWP231d6kK JqEjd6IH55/DJnrGfoQJW4scHYfTpZabEk/QlGKEKdDWTEAd4wjOT2nmgdze2Dwq 0s3ZqcEhFMtMrL/hBWR53FZIUpNloQicgRyTBjLJBHHCmdW58qmx9zkDFdpgdh8S tVGImEnyTb2RfN08vqLVWnx7LEDRBLtwATHGs1y/zlOYj9sZoJ4fvuwrvAglTbUk 3U1+40xKdu+KdJw/1HAf6QB1COjGqKnsCX43MMjq38kNMJoG8TE= =LB2i -----END PGP SIGNATURE----- --gjxvs7vxqlafnh4w-- From nobody Fri Oct 18 22:44:47 2019 Return-Path: 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 11A3312012E for ; Fri, 18 Oct 2019 22:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH5V_szspEvd for ; Fri, 18 Oct 2019 22:44:43 -0700 (PDT) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33BE120024 for ; Fri, 18 Oct 2019 22:44:42 -0700 (PDT) Received: by mail-oi1-f176.google.com with SMTP id 83so7047918oii.1 for ; Fri, 18 Oct 2019 22:44:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FtN3wYO/c58G8jIzF7NHhdwAcqbvCvixhFqRBW2UPu4=; b=Z3rrk5Y+6IFMlOMtwY5519mpz/fAM7wyQ1w5yRnkEPMjwllFZYb0e9hD7YhYquX6hY /pf+TmcorFtCRI39jeEnJMxlmfuopZLCnLvcwbOg0M/PGhMxKzEW+mqqSXSbwm0dFiHO OTM2KHtsnZ56gr+0CaRsw0VS7dyX5g6t2wA19+H1k/64t86rXta2QiCDLUPoJ6kBwcVR R7DPkxfwEo3svnzZcD1PBAEdK+dcoS3+yyp+DY7dJoZm3ZP0fc99sHfQ801uXMU2ALXX VypO8+papaz97Jebz4T6gtkez2UNRWLrvpzkCpUYF1NQ8kp02oaeIjFmsFjQpzggJR8l xMJQ== X-Gm-Message-State: APjAAAVK/KLv9Vcq7Vw3nczZ6F0stKQexuTpgTx0nxzCClAE5xdvApcc IsCmHBLlWAOu+D3qk/SQF5ilvYIOi6NlUPlFxEU= X-Google-Smtp-Source: APXvYqzmPwZmSJPBkm4W1zZHPiyrUdRw+YvfIcIo+VwJIFvJzgnrRhqlOA5YBAlf8/KX5iPgr5TmKb3Ld2W6WfETN1c= X-Received: by 2002:aca:4a49:: with SMTP id x70mr11054882oia.17.1571463882111; Fri, 18 Oct 2019 22:44:42 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> In-Reply-To: <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> From: Phillip Hallam-Baker Date: Sat, 19 Oct 2019 01:44:37 -0400 Message-ID: To: "brian m. carlson" Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="000000000000787f3705953cf2c2" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 05:44:45 -0000 --000000000000787f3705953cf2c2 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 19, 2019 at 12:40 AM brian m. carlson < sandals@crustytoothpaste.net> wrote: > On 2019-10-19 at 03:40:03, Phillip Hallam-Baker wrote: > > Someone just said we need a spec. Here is a spec: > > https://www.ietf.org/id/draft-hallambaker-mesh-udf-07.txt > > > > It is in the new format which is intended to be read as HTML. Until the > > tools catch up, you can read it here: > > http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html > > This doesn't specify any method of primality testing which means > different implementations can produce different values[0] (and is > therefore not deterministic), unless you literally interpret the text > "smallest prime integer" as requiring an actual prime. That could be > implemented by using the Miller test instead of Miller-Rabin, but that > would be much, much slower. > I am trying to work out what the necessary criteria should be. It is certainly something to think about. If someone is using a random primality test with 128 rounds, there is an infinitesimal chance it isn't a prime, 2^-128. The work factor for picking such a prime is 2^128 so it should not happen by accident either. Right now, my feeling is that if someone is going to use a broken primality test, the risk of not recovering their key might be the least of their concerns... I think I might have a solution though... In this particular case, the approach to invalid keys (where p and q are > unsuitable) is "try again with a different seed", which is probably okay > in terms of RSA, because the number of retries necessary will be low. > The only problem with that approach is that it prevents generating RSA keys from shared secrets... > It also doesn't specify DSA keys, which, while uncommon, are still a > part of the spec. The "try again" approach will probably be a little > more difficult here. > I can add them. Which DSA key sizes are still relevant? > The draft does not specify the value of e which it should but I am pretty > > sure we have standardized on 65537. I see no reference to p being greater > > than q and it is a mystery to me why we would care when the RSA > parameters > > are the modulus and the private exponent d. Knowledge of p and q is only > > used to determine d, they are not req > > The OpenPGP secret key contains u, the multiplicative inverse of p mod > q, which is used along with p and q for the Chinese Remainder Theorem. > RFC 4880 specifically mentions that p must be less than q, which is > required for u to exist. (This is backwards from most other specs, > which require the opposite and define u as the multiplicative inverse of > q mod p.) > OK, so I will rework that part and merely specify that it outputs two primes X and Y which implementations are free to use for either p or q as they please. So long as the resulting value of d is the same... [0] Yes, people should pick a suitable number of iterations for > primality testing, but there are people that pick 1 iteration for > PBKDF2, which is a demonstration of why we can't have nice things. We > actually have to tell people how to write things in an interoperable > and secure way. > Absolutely. And there are folk who have calculated their RSA parameters by setting the upper n bits of their RSA modulus to be the encrypted value of their seed value, choosing a random p and then working out what their q should be. Then sold the result to a foreign adversary... There are two possible situations. 1) User generates a strong key, recovery fails on a bad implementation with insufficient testing. 2) User generates a broken key due to insufficient testing, cannot recover it. The first is the least worst. We can still recover the key on a good implementation. The second is trickier. But since we have specified the search pattern, we can still recover the key provided that we know the fingerprint. In either case, we can blame and shame the bad implementation! --000000000000787f3705953cf2c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Sat, Oct 19, 2019 at 12:40 AM brian m. ca= rlson <sandals@crustytoothpaste.net> wrote:
On 2019-10-19 at 03:40:03, Phillip Hallam-Bake= r wrote:
> Someone just said we need a spec. Here is a spec:
> https://www.ietf.org/id/draft-hallamba= ker-mesh-udf-07.txt
>
> It is in the new format which is intended to be read as HTML. Until th= e
> tools catch up, you can read it here:
> http://mathmesh.com/Documents/draf= t-hallambaker-mesh-udf.html

This doesn't specify any method of primality testing which means
different implementations can produce different values[0] (and is
therefore not deterministic), unless you literally interpret the text
"smallest prime integer" as requiring an actual prime.=C2=A0 That= could be
implemented by using the Miller test instead of Miller-Rabin, but that
would be much, much slower.

I am trying to work out what the necessary criteria should be. It is cert= ainly something to think about.
=
If someone is using a random primality test with 128 rounds, ther= e is an infinitesimal chance it isn't a prime, 2^-128.

The work factor for picking such a pri= me is 2^128 so it should not happen by accident either.

Right now, my feeling is that if someone = is going to use a broken primality test, the risk of not recovering their k= ey might be the least of their concerns...

I think I might have a solution thoug= h...


In this particular case, the approach to invalid keys (where p and q are unsuitable) is "try again with a different seed", which is probab= ly okay
in terms of RSA, because the number of retries necessary will be low.

The only problem with that approach is that it prevents generati= ng RSA keys from shared secrets...
=C2=A0
It also doesn't specify DSA keys, which, while uncommon, are still a part of the spec.=C2=A0 The "try again" approach will probably be= a little
more difficult here.

I can add them. Which DSA key sizes ar= e still relevant?

> The draft does not specify the value of e which it should but I am pre= tty
> sure we have standardized on 65537. I see no reference to p being grea= ter
> than q and it is a mystery to me why we would care when the RSA parame= ters
> are the modulus and the private exponent d. Knowledge of p and q is on= ly
> used to determine d, they are not req

The OpenPGP secret key contains u, the multiplicative inverse of p mod
q, which is used along with p and q for the Chinese Remainder Theorem.
RFC 4880 specifically mentions that p must be less than q, which is
required for u to exist.=C2=A0 (This is backwards from most other specs, which require the opposite and define u as the multiplicative inverse of q mod p.)

OK, so I will rework that part and merely specify= that it outputs two primes X and Y which implementations are free to use f= or either p or q as they please.

So long as the resulting value of d is th= e same...

[0] Yes, people should pick a suitable number of iterations for
primality testing, but there are people that pick 1 iteration for
PBKDF2, which is a demonstration of why we can't have nice things.=C2= =A0 We
actually have to tell people how to write things in an interoperable
and secure way.

Absolutely. And there are folk who have cal= culated their RSA parameters by setting the upper n bits of their RSA modul= us to be the encrypted value of their seed value, choosing a random p and t= hen working out what their q should be. Then sold the result to a foreign a= dversary...
There are two= possible situations.

1) = User generates a strong key, recovery fails on a bad implementation with in= sufficient testing.

2) Us= er generates a broken key due to insufficient testing, cannot recover it.

The first is the least wor= st. We can still recover the key on a good implementation.

The second is trickier. But since we hav= e specified the search pattern, we can still recover the key provided that = we know the fingerprint.=C2=A0

In either case, we can blame and shame the bad implementation!
<= br>
=C2=A0
--000000000000787f3705953cf2c2-- From nobody Sat Oct 19 04:06:24 2019 Return-Path: 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 D45EF120045 for ; Sat, 19 Oct 2019 04:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6N6nasC-gbd for ; Sat, 19 Oct 2019 04:06:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AFF12003F for ; Sat, 19 Oct 2019 04:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571483175; bh=DOOT0pILUVI8GYI1mdHcoSJHk4ot51O+6qmZlRvg/N0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=YacHmBDP6P6mtHbSNpQ4ic02RLa+RRsTFrlt/PvBCwpFUPYHwLdW7eMdLbksgds6c QAIUin4UTeRVwWu5AkSp1zKubDE9C5FabBJ5yc/m/6CXIMter84mAoFDh4NDRNkcmS Q1uwkL0YUuEYQ0o6Gd0bYYmEuhS8yfjA6fn8MEGE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([217.88.42.219]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N1wpt-1htDBO01ST-012Fk3 for ; Sat, 19 Oct 2019 13:06:15 +0200 To: openpgp@ietf.org References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> From: Heiko Stamer Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQiSGVpa28gU3Rh bWVyIDxoZWlrb3N0YW1lckBnbXgubmV0Poh4BBMRAgA4AhsDAh4BAheAFiEEdvcwETKdJ9uN fD+XT1hOuPsr4U8FAlzqvfMFCwkIBwIGFQoJCAsCBBYCAwEACgkQT1hOuPsr4U8jZQCfbz7N emwAJ2OdrBP9mmsySktb4IQAnRWJOYy4bH3R42nh6KCUkbDXQoNhuQMNBDdYKtkQDACuGU2S WXmjpoyGIX/UHze60OolxBdtKzhvDZHhy1Sz8NNrdkI3ozuYOMxkKZZLTw/iQigVNQfwy+5f AUw6KaH8OPnwInqyeguI6PwG0qQK2cWlSTZDlTW8B2D3Qpjt8sYnnjGEIGKGb7ZAUgODmWYd sS35otyEQT0Un/kRIqjyQcvWgNH++t+LypXUxu0eD0dlD/kx46TP9kqTYsr/8vWWhD2J98x0 ZFrFMN8QDCIhO9x3p+qPyfSiAdnuI4iN1RYsKtC2ikb+cIc5bYysnRots1anAy3Pd5Q8bFtj lzxPPRh90v/Yq5RM/3IgbsbS0zDI0ldznld+DInezLs/EROsITmmbXrhIAHC8TjcXtxWR3ht nFLnIgmQ3Rag0bQesNF4Y5bXSGcw/MxwWcm6EXwcbm7Uc64k8YxXMYyNy+XX/bi1o7r5JdH0 mKUFeXTF9WLrNpF4jBylHk1RNDbR6kp6M87vPJeg/nQh19ItQQxYJGYu9KBhBGhFtDUIAyLT nTcAAwUL/2tHe52rFeCVvZo7RZ5SQy/aclx7hnPsvb3yTXcvg5c7hweOL7Zfsh/XnE3acRO0 YAfGb0LxMFJlfpHgcPuTZEd5rPgJz68GccACBPw8Z8MgQEBE5H/UiAR/HM9AQmEN+wfjeDlv 6ZGElmnY59gYIuCGUVsqw5pwCCsLBs3xlMTyCiNwDHERRao3YTGhaNy9hsCdqNHQcXdSzdF6 OtvfMnXI67QGyiNcbjVwXwQHlGAsxo4O3FMOl138o1Oa00JMSk7td8bClMAp7Hu4zrw533TZ 2Avp+6OFjUAQ4U4hdEDGePNm2hbQinKnUCd30PboqIdZDmYq4SSeNMbWKwy3Etx/a0GX39F/ gnjmveBHSWGGB+wSKcrK3yfXNXMa4OW683m/aH1msS0L0SFwbm2w7XdALp0DCV031x1JoGAn c0mVcstbVM7KNUGnCOA9D4USKHrj/IoZVoapx0b+bWPFHtfLhcm2lSDlq7F140DlQVL1xZmA nPcpLyXMmEmnS2JCZYhGBBgRAgAGBQI3WCrZAAoJEE9YTrj7K+FPcRMAnige4x75lK1p7sbK sdhZb6tv4CJPAKCpDqRn9o7nfvLlouXNaIR1nri7c7kErgRPbbDUEQwA29DKEVd+djjC5B7e jHwAb2EbbVbapdz0JAftKEiTvETd8WqpRRhvhDoGJn+v3ysOp6pKzyOtCFPQoN8559cgqA+e MMrarkufk7NxyFmuq7VILm4VSouUFgDNttHB63nAT/7FnRY/ccvJClL5vrVwMiioBVmXEJTw 8Nnw36tZoerE68uG8jS/cJjypmXhWoSSVQAKjC/ErQ5z/qNzJqAsem+eV/LHUd2BLK+u7r7Q 98ksKUpmEp5xVCox8HF1JwcG7QdJndVUCHHiV2fWDdIM0P8DCbagLZ+jQWMky/BvJL04ejnh t2O1YDyKaz3PzLMKk/Sbf9tIDw1iKJL3PQNNsu3cPOORmGsZQbfX940qiqdfD0+V3gmCjKBg TtFM/lJFkcMC0H1XfwQZBADudRIqqZp6AKkznpu8fmH3ut6C7Gl7ZXib5dNSPFIWfjBxrGnb STNChlYg0AEy5Lsm80oo7ef8VymQ/Vg/EoSVJT4vke5sY669W7lshZVcKVaqUt4/AQD/DO6J 9jyHVVwvopSC9E17qd/9qIHvrY+m/wdaGEdcHwwAsP7Sqj7SdBn/BmeSLJiXqZ+OwhOEbv6B A3ZJExEuIlNm+46tuyi1hxczbZ5ZWfOCpVPTSYBIuyl31OR1S6ef1iAGY8kkFF+3tkmbu+nQ 2dpyyfw20ZnKFkWG0IhZhQZwMANrQ9nuQVEXMc3c1cybuiNTDeIA0wLwlnYkzoPYRk/aXUQj kYvaexfQsfBrbn2qU6YtE/aRybgBoGkuJn6tSwfa4LeMA5S5p8aF/pDKRNm5vt0LpxcqPrSI pzPeHD0Oucwv3ZqfDCTIOENZwBEPSyNz2XEA2b+bnKjggprFLguw5USwpca6F/eeXGArs278 WBdAmncAgdcvcDmjMJuaGke48n1zbDHYlC8NHGTUUvVpiJRZt2KLgIzIEz/5d1tiGUZqhYk2 c9o+lHjbnv4E+L+ITY8yPqyfWHV2aH3tKa7qoBX+EyGCtW9X42gATcj3ZzVBgWD5w3BnbIgW T0dLvieBFn4T25Fy80Md+cwj4yvcRgJsvZgkuR0UjoWDxgvpDACOnRYzI/WqTSBAS1T3vmfU VtjRdUCiYpptR+sNmj//nCRdy3yC8az0WHemmWmhhE4GUT6KqtD0WPBFb9L54hq5qWCzbjcR zPW8BZJAhjynhIp2ljLAskd+50dvpsOE6aL9vAlPySuRg95dFwa+425783Hvp5YIY/LloLtb YXyRH2nBLfmXGSt1JL4oOfCEWgwLENAOXel8+aet8HD7LN8OgP+971lJ5DtCSVs/Vw4I8NdV DlssId0NhoNW062Br5qmgga0fKiU4oU0SGDOWNBGp9oUW+jD0OhIiNIFLrsse8isZrQK1W5q 0zi+guiyBB7ftp5uJHSF7Y0Cc7rKSSFsMj1E+PTKDtHpcK+AFTEDiTlPmCNemNxwmm6LtM54 ybQ8R96psrbahOX2LeYhYTwXasKk9bQ6WTOt9biO9R4y/Z9Yy52LwMXCyHot+V4+TTG9iMe9 ZWYEe1bCMLBEh7E7RYVDWHpYmhW49/U23YdY/AeROldZzSduXZTgz8f64diIYAQoEQIAIBYh BHb3MBEynSfbjXw/l09YTrj7K+FPBQJZJr7xAh0DAAoJEE9YTrj7K+FPLrQAoKRZEWwU0+ME qEgFOCHIZDuFAh7mAKCVdunDvK+/J0blWkCXFNh6AgS8t4ipBBgRAgAJBQJPbbDUAhsCAGoJ EE9YTrj7K+FPXyAEGREIAAYFAk9tsNQACgkQWxEYjUGN7Fd3vwEA7Bu+0FRCGhORinzglpFz SBRAZ3kGjlLeGZI7peOLva8BALuQ6pZCXV2m1fW7HhHQWYY/IRHRgupXiq2l1kfUQ6uvwqYA nAqoUxzoiqZ0wzzBkhAQC/RbccnzAJ9ZuHUDUACXo2yW+8IpiyP6Rlgu7Q== Message-ID: Date: Sat, 19 Oct 2019 13:05:38 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:A9oYG/A28w0fgvmtNEIWfB4Iuv//lABdtiArJCHVPlrOy/0WqZU rOENE8dPnz21HQ3HNywBOf4Nb0uuY6HTklcqdjHH8us+unAvDpPJJIhHAHDIlUJVVNRrqbP wY7nreSu6hwPusg4+0/sHo6ft7a8ejYlJPX0GElGKFYwKBqSTwZu2HCIelqUIqKMPrisMtZ AUHNTR1A8N1UCUCOgjz/A== X-UI-Out-Filterresults: notjunk:1;V03:K0:0+bjPTPBbvk=:ed1ANAkUjN94h61q7BrjN2 RxzZrnRy8ixCrzSer9DrUfDQqvrT8yT6mRYQ9epK0hh5DQwtSENo4/RUFaXMGbo3uMmNwCpOb 7fouZtGt+qwNaP6Q/hUzHnFPjScGEf/7Nzx4XUdN1Yuwj6S/B78HOBaWa6N2jSNJPgoZjfZ0o vHz3OVCTKKNlt0Z+bLsqMAn2aKNnX8MANFGdxBHMGTZYaHfPfGOsujyaLswmuqASwuvyHcBLK tk7dfcimTutOU+ICZx4+oVWqOoBJ1gSMPodcGpCUOHLzdE72PyKXxLKAn7Yehag7jgXpaB4LX rzhzJ7LwcrIiMMPv6rz0zyODMLnEe1UizMrLLIZwST4mMfz71yl7YQDsAfDRZqwqCXPOdzqlP fL8/ROPf4rmEGGPI6NPRhq8DhOsJCWTnZPNt14wCKI6O7+8HCA/GPSY5sU05ZSzX/FHewNyrj PPPjfnfjMP+Taye2mLS9zGp7jdLiQTVfzN0/4g3hDMbUdjxjUyfpQacjnK9lLm79sQeO1KFvy BC7DsCztc642qKHVDUyQvrfCPH0civ6qOsbyyXintnIm/Y/PDZN3XnOBNiFuES8+OPHYBLMXj UGI9+pw1b/Lp1s8wtOFZ4coV26jiFcpOqamPno+tRzKJLF14EHUNPuEXFV6IFKh5OPfBcRWg7 XDKPGqPf5739gwJBO3IOakLpNpGj42TNXoeTjluBAyJReK2xmWSxh/5b6KsqALsQQK0pAbydK Lf55Vr4SDz1GD01Ik6OoEn1pUTcZ0vnUIQgkfAvQSGRU9vjuvBH5ek0hiQPGcZi1xlJ4wIzds /pwJE8iyUTJgvxaQKTDb/K+o+wyZY5LCexxktlGkeTyTMomYhdGSKN1Gcs2wcIHi7cKeUHAbF /hiowZqgtMC5/6TxqSEsdlRfLtILAq6IGBNxpzUaKGbp3BpLBlRnK+WTv1Pv+EC8EXAKQiKuT PFt1dbf5/NRquTHHTTdr+Jl3lWOMu+q+VsubpEJZrtZBY+59N8yi/9fTVxpQoDHFTlQl9y4Nt yKsQRmHYANzbq42i0GTVGXqGDZBeffdUxP7OiSEEp8nQvYeWGZbMi0elRFmf/3zPDmAXxA6Q4 nu5ctke8lKkJXhbQshsgyVSNpYq/3wiuCpI6y+xcp9Y0RXj435yZJRQFM6ZmarKCtRHxtK0f9 QqgrQvxgNy0qdmIqoBKCWQkmAu7ONJKeaqWM+juhqT/cDQLsWR+zMS9d1hMXiNYL0kURFHASt RZfsWx5uPOXRbKBMEjpLPx6gii/g62eyvjrkTtlfiVibcE6RXNAX4WO3B3Ac= Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 11:06:22 -0000 On Oct 19 at 07:44, Phillip Hallam-Baker wrote: > I can add them. Which DSA key sizes are still relevant? 2048/256 and 3072/256 (cf. FIPS 186-4) =2D- Heiko From nobody Sat Oct 19 06:01:52 2019 Return-Path: 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 9449D120098 for ; Sat, 19 Oct 2019 06:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t2qYZP1En3M for ; Sat, 19 Oct 2019 06:01:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1737120013 for ; Sat, 19 Oct 2019 06:01:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EA2833897A; Sat, 19 Oct 2019 08:59:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DE959B52; Sat, 19 Oct 2019 09:01:45 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker , IETF OpenPGP In-Reply-To: References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 13:01:50 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > I did not bother with DSA. But that could be added. It has serious problems > at this point and is probably just better deprecated. I think that you are right to ignore DSA. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2rCTkACgkQgItw+93Q 3WViVggAhMefWDiHz1/nfO5G+bG0cupTdguWN41Kfd4gVj9q9MpKqqgfnlxY+YF7 zjxhZGyccmc4HPehHVwS5oSorD9yRCbO87Vk7YPh5qET7eNNwyz3WKbfHXaNiF8+ MIp24DwPX/A7SjJrXMpmESrhfqx2Z983fw3T4bXkpy0Da+mzBcihBc0/c1htm00Q Z7hz7OShMzIKOP3uztm1rXni7WyZcYH/YAkjUiwCvJRfb9iUZVQ/qBgiEGZHK5zl p69O19HQunSzOcjqV7msls8j4pOfRcqP7OaqsabOaMyLJZPuF5OSTktd2tu8i2sw hyROWhkdiwOvtj5NH6slDqeEeuXWvg== =85c3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 19 06:04:13 2019 Return-Path: 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 F0490120098 for ; Sat, 19 Oct 2019 06:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m3fZhcNEyZ9 for ; Sat, 19 Oct 2019 06:04:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF85120013 for ; Sat, 19 Oct 2019 06:04:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CC5253818F; Sat, 19 Oct 2019 09:01:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C2B3CB52; Sat, 19 Oct 2019 09:04:08 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker , IETF OpenPGP In-Reply-To: References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 13:04:12 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > Right now, my feeling is that if someone is going to use a broken primality > test, the risk of not recovering their key might be the least of their > concerns... Yes, but the issue is bugs. If someone fixes (or introduces...) a bug in a primality test, then I might recover a different key. This doesn't happen if I generate and key the private key. If I lose my system and I install a new system, the odds of new/patched software compared to when I first generated is high. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2rCcgACgkQgItw+93Q 3WV9Fgf/WT3hsG91nNOrvh+XznuX/+ExKPfV0Qd7nD4RbzzDMO7X4ZhzjmQgaaxk hS4RnYGjYyFFTRzssQsRlXdVewCTyDQJ2x7JYTGhp0cIFma9AzPtANQVG67tlI0+ X9YkuStZOhbqQ84ddA+631jaboMp8U1beKbsy762eWtHwp4eKTu0exGSFBszXoNn j4iTMia42GFkASnPEwPWCLkAzYbSJuby8DZadmveA99s/2ttsPt9ZXMNqCYGAhUm /c4j+0tWjBsydKKzw6OECwcsmP+4R6LOGzcljuk9DhezGf0835OWO00DUT6NEFeN ezxAnqQRKRNjr5Gze8cB5P+7r1fJ+w== =ZD8v -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 19 11:23:03 2019 Return-Path: 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 3439C120059 for ; Sat, 19 Oct 2019 11:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt66Bml1EL1G for ; Sat, 19 Oct 2019 11:23:00 -0700 (PDT) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5013120018 for ; Sat, 19 Oct 2019 11:22:59 -0700 (PDT) Received: by mail-oi1-f178.google.com with SMTP id w6so7857522oie.11 for ; Sat, 19 Oct 2019 11:22:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ncACYY4eBH4GCRPjqVDtCI/pdubHjxadHdtoBp+5Wf8=; b=Lw322V8k2ayszrhibhLuSvarmp5oGLRqovfh1OOuDpbTbIxwU2kXnnSeuTxqhJvHxH XqDq8seE/2O2X9yKTtJDCfdz4iG/cu27syJ7dCwBLO5i4kANqNUGn3VeawOf/YBoeYHx HOT+p1/gK5e1MiNDV70NUK7ZfHX+wgvDeQt62ux9bq0LanyXDV68hjLjv3uS6NgPSYci Q3WH7MOqKC3wpmHhv4h1wp6xY8MdhE/OW24R+CvXxg5MCCOB4DzwHH2j3NwMuu9aK+zE IiFEGjgPpMF45/0zMKHU3t0MEEzA+dhEypNGEHLNo35ak1lR0kBkswUqn+azqW+LCs4f YBBA== X-Gm-Message-State: APjAAAU0XoHx8ULIBQL6NM+4JRgIB61rYGfoy3LMr3+TCPg8rWYcr+Uc HBrmgs/M28BNrgcIBKEE1uWvpLp0r1BNIn7uXXy/sH4FW9w= X-Google-Smtp-Source: APXvYqwCnpxqtSt14bfQIUyL4ibrOdk9jjbPgxgrl2WfkZgV2i2tok8hVUbbemivqyfVf5fMmoHWW/iE+KuI0Ec+LyE= X-Received: by 2002:aca:4a49:: with SMTP id x70mr13075595oia.17.1571509378867; Sat, 19 Oct 2019 11:22:58 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> <13025.1571490248@localhost> In-Reply-To: <13025.1571490248@localhost> From: Phillip Hallam-Baker Date: Sat, 19 Oct 2019 14:22:54 -0400 Message-ID: To: Michael Richardson Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="00000000000049e4860595478a4e" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 18:23:02 -0000 --00000000000049e4860595478a4e Content-Type: text/plain; charset="UTF-8" OK so I have not implemented DSA but it turns out that it the spec mandates the entire process: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf The main consequence of DSA is that it mandates the entire process including prime generation *and* provides a mechanism for validation of all the parameters. This discussion now has me thinking that we should have been validating parameters for RSA before importing them into an application all along. On Sat, Oct 19, 2019 at 9:04 AM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > Right now, my feeling is that if someone is going to use a broken > primality > > test, the risk of not recovering their key might be the least of > their > > concerns... > > Yes, but the issue is bugs. > > If someone fixes (or introduces...) a bug in a primality test, then I might > recover a different key. This doesn't happen if I generate and key the > private key. > > If I lose my system and I install a new system, the odds of new/patched > software compared to when I first generated is high. > Absolutely! And I can provide a recovery mechanism that does just that. So the set of requirements I see are: A) Generation/Import of keypairs meeting BCP criteria of NIST and IETF from fingerprint B) Identification of faulty implementations C) Recovery of mis-generated key pairs. D) Verifiable generation processes with separation of duties. It is not necessary for every implementation to do all of these. An SSH / OpenPGP / S/MIME app only needs to implement A and allow B and only if it actually implements keygen at all. I can meet the full set of requirements with the Mesh management tool. This is open source, MIT license. The code for the UDF stuff is not complicated though. Concentrating all the key management functions in a single app allows them to be done better and more comprehensively. *A) Generate* The commands for generating, exporting and importing a key from the CLI would probably look something like the following. Since I am thinking of the general case, the key fingerprints used as UDF content digests rather than OpenPGP but this is largely because it was easier to cut and paste from my docs rather than find another. > myapp generate alice@example.com --udf Generated key: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 Ready. > myapp export alice@example.com --udf ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y Ready. > myapp import alice@example.com --udf=ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y Ready. *B) Detecting a faulty key* myapp import alice@example.com --udf=ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y --check=MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-ZZZZ Error-ABEND-0243: Recovered key did not match We can get a better test of the generated key checking with a different application mesh verify ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 WARNING: Key does not match *C) Recovery of mis-generated key pairs* Recovery of a misgenerated key pair is easiest if we know the modulus. In that case we can generate the starting points for the primality search for either P or Q and then just do trial divisions until we get a exact match. So the first thing the mesh recovery tool would do is to attempt to obtain the public key parameters from the fingerprint. If we only have the fingerprint, we have to assume at least one of the parameters is prime, generate a trial key for each prime candidate in the search and test to see if it matches the fingerprint: > mesh recover ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 WARNING: Key recovered is NOT SECURE Primality testing failed. Recovered key written to MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4.p12 *D) Verifiable generation processes with separation of duties. * NB: This is not the sort of process I see many individuals performing for themselves. But it is exactly the sort of procedure I might want to use as the basis for separation of duties in a key ceremony type situation. Every one of the input shares affects every bit of the output. The splitting (but not the generated key!) is information theoretic secure. UDF gives us the ability to use Shamir secret sharing to split a secret. We can also use this in reverse to create a secret from random contributions generated on separate machines. So let us imagine we begin by generating the following nonce values on independent machines. NAQC-GKXI-6DTJ-COKM-4HBF-CZJJ-BO6G-I NAED-CRXH-IASE-5ZYS-ZS2D-PQT4-6O6P-G NCRB-6YXF-R5RA-ZFGY-W6TB-4H6Q-3O6Y-E We can combine them to form a single secret for a specific purpose. Since we need to encode some information into the first three bytes of the result and we have one type code, we have 32 bits fixed in the output: ZAAQ-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L We can now generate a set of Shamir secrets that closely resemble but are not exactly the same as our nonce inputs: SAEC-GKXI-6DTJ-COKM-4HBF-CZJJ-BO6G-I SAED-CRXH-IASE-5ZYS-ZS2D-PQT4-6O6P-G SAMB-R3XF-R5RA-ZFGY-W6TB-4H6Q-3O6Y-E Note that only the first three characters of the first two shares and the first six characters of the last changed here. We can verify that the above secrets combine to create ZAAQ-AWMQ-... and we can even generate additional shares if we so choose. We can't change the quorum unless we reshare the secret. So now imagine we are generating these from QR codes being read by a camera. We run the scheme some number of times with full observability. Then we cover one of the inputs so the observers can only see the other three and run the system some randomly chosen number of times with a different input covered on each round. --00000000000049e4860595478a4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK so I have not implemented DSA but it turns out that it the= spec mandates the entire process:
https://nvlpubs.nist.gov/nistpubs/FIPS/N= IST.FIPS.186-4.pdf

The main consequence of DSA is that i= t mandates the entire process including prime generation and=C2=A0pr= ovides a mechanism for validation of all the parameters.=C2=A0

This discussion now has me thinking t= hat we should have been validating parameters for RSA before importing them= into an application all along.


On Sat, Oct 19, 2019 at= 9:04 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > Right now, my feeling is that if someone is going to use= a broken primality
=C2=A0 =C2=A0 > test, the risk of not recovering their key might be the = least of their
=C2=A0 =C2=A0 > concerns...

Yes, but the issue is bugs.

If someone fixes (or introduces...) a bug in a primality test, then I might=
recover a different key.=C2=A0 This doesn't happen if I generate and ke= y the
private key.

If I lose my system and I install a new system, the odds of new/patched
software compared to when I first generated is high.
<= br>
Absolu= tely!

And I can provide a= recovery mechanism that does just that. So the set of requirements I see a= re:

<= div class=3D"gmail_default" style=3D"font-size:small">A) Generation/Import = of keypairs meeting BCP criteria of NIST and IETF from fingerprint
B) Identification of fa= ulty implementations=C2=A0=C2=A0
C) Recovery of mis-generated key pairs.
D) Verifiable generation pro= cesses with separation of duties.

It = is not necessary for every implementation to do all of these. An SSH / Open= PGP / S/MIME app only needs to implement A and allow B and only if it actua= lly implements keygen at all.

I can meet the full set of requirements with the Mesh management tool.= This is open source, MIT license. The code for the UDF stuff is not compli= cated though. Concentrating all the key management functions in a single ap= p allows them to be done better and more comprehensively.

A) Generate

The commands for generating, exporting and imp= orting a key from the CLI would probably look something like the following.= Since I am thinking of the general case, the key fingerprints used as UDF = content digests rather than OpenPGP but this is largely because it was easi= er to cut and paste from my docs rather than find another.

> myapp generate alice@example.com --udf
Generated key:=C2=A0 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
Ready.
>=20 myapp=20 export alice@example.com --udf
=
ZAEA-AWMQ-6Z4O= -RRMM-Y72J-CGWI-ZC7L-V5Y=C2=A0
Ready.
>=20 myapp=20 import alice@example.com --udf=3DZ= AEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y=C2=A0
Ready.

B) Detecting a faulty key

myapp=20 import alice@example.com --udf=3DZ= AEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y=C2=A0 --check=3DMB5S-R4AJ-3FBT-7NHO-T= 26Z-2E6Y-ZZZZ
E= rror-ABEND-0243: Recovered key did not match

We can get a better test of the generated key checking= with a different application

mesh verify ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI= -ZC7L-V5Y=C2=A0 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
WARNING: Key does not match

C) Recovery of mis-generated key pairs

Recovery of a misgenerated key pa= ir is easiest if we know the modulus. In that case we can generate the star= ting points for the primality search for either P or Q and then just do tri= al divisions until we get a exact match. So the first thing the mesh recove= ry tool would do is to attempt to obtain the public key parameters from the= fingerprint.
<= br>
If we only = have the fingerprint, we have to assume at least one of the parameters is p= rime, generate a trial key for each prime candidate in the search and test = to see if it matches the fingerprint:
> mesh recover ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y=C2=A0 MB5= S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
WARNING: Key recovered is NOT SECURE
Primality testing failed.
Recovered key written to = MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4.p12

D)=20 Verifiable generation processes with separation of duties.

NB: This is not t= he sort of process I see many individuals performing for themselves. But it= is exactly the sort of procedure I might want to use as the basis for sepa= ration of duties in a key ceremony type situation. Every one of the input s= hares affects every bit of the output. The splitting (but not the generated= key!) is information theoretic secure.=C2=A0=C2=A0

UDF gives us the abil= ity to use Shamir secret sharing to split a secret. We can also use this in= reverse to create a secret from random contributions generated on separate= machines.

So let us imagine we begin by generating the following nonce value= s on independent machines.
NAQC-GKXI-6= DTJ-COKM-4HBF-CZJJ-BO6G-I
NAED-CRXH-IASE-5ZYS-ZS2D-PQT4-6O6P-G
NCRB-6YXF-R5RA-ZFGY-W6TB-4H6Q-3O6Y= -E

We can combine them to form a single secret for a specific purp= ose. Since we need to encode some information into the first three bytes of= the result and we have one type code, we have 32 bits fixed in the output:=

ZAAQ-AWMQ-6Z4O-RRMM-Y72J= -CGWI-ZC7L

We can now generate a set of Shamir secrets that closely res= emble but are not exactly the same as our nonce inputs:

SAEC-GKXI-6DTJ-COKM= -4HBF-CZJJ-BO6G-I
SAED-CRXH-IASE-5ZYS-ZS2= D-PQT4-6O6P-G
<= span class=3D"gmail_default">SAMB-R3XF-R5RA-ZFGY-W6TB-4H6Q-3O6Y-E
No= te that only the first three characters of the first two shares and the fir= st six characters of the last changed here.=C2=A0

We can verify that the above secrets combine to cr= eate=20 ZAAQ-AWMQ-... and we can even generate additional shares if we so choose. W= e can't change the quorum unless we reshare the secret.

So now imagine we are generating these from QR codes b= eing read by a camera. We run the scheme some number of times with full obs= ervability. Then we cover one of the inputs so the observers can only see t= he other three and run the system some randomly chosen number of times with= a different input covered on each round.

<= /div> --00000000000049e4860595478a4e-- From nobody Sun Oct 20 10:18:50 2019 Return-Path: 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 1838712011A for ; Sun, 20 Oct 2019 10:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnU5KMOOuyB2 for ; Sun, 20 Oct 2019 10:18:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F62120119 for ; Sun, 20 Oct 2019 10:18:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B5B2E3897A; Sun, 20 Oct 2019 13:16:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 750A560; Sun, 20 Oct 2019 13:18:45 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: IETF OpenPGP In-Reply-To: References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> <13025.1571490248@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2019 17:18:49 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > *A) Generate* > The commands for generating, exporting and importing a key from the CLI > would probably look something like the following. Since I am thinking of > the general case, the key fingerprints used as UDF content digests rather > than OpenPGP but this is largely because it was easier to cut and paste > from my docs rather than find another. Being able to split off the private key generation for PGP, SSH, certificates, etc. might be a serious boon to the ecosystem I think. > *D) Verifiable generation processes with separation of duties. * > NB: This is not the sort of process I see many individuals performing for > themselves. But it is exactly the sort of procedure I might want to use as > the basis for separation of duties in a key ceremony type situation. Every > one of the input shares affects every bit of the output. The splitting (but > not the generated key!) is information theoretic secure. So, we don't do generate keys for our home networks today. But in the future we ought to, and we ought to be splitting it across a bunch of family members, neighbours, etc. Being able to leave a spare key (with some limited authority) with your trusted neighbour would remain important in the future. > NAQC-GKXI-6DTJ-COKM-4HBF-CZJJ-BO6G-I -> > SAEC-GKXI-6DTJ-COKM-4HBF-CZJJ-BO6G-I Yes, is see :-) > So now imagine we are generating these from QR codes being read by a > camera. We run the scheme some number of times with full observability. > Then we cover one of the inputs so the observers can only see the other > three and run the system some randomly chosen number of times with a > different input covered on each round. Interesting. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2slvUACgkQgItw+93Q 3WWK1ggArxDch0haJBCZ2t9cC3wLqyEz95mvk0ZW1AAzscjC2rfFbLKT/9AqABm7 o4zNd8ZEbwMkHetr8LIIynHAotdeGcuktTYHRNcLz8EJDB8r9+fQTx7kt4DGyqua YmnLfNYf7TmbTbWi6HPpyR7DGP+kndU/OiZSrY7sLHo0kctzHCosPsDT6ug7Qkjh KmeZxwCtlpoR3j1nhqtPaiXE9TJiFPYPAIBmLxNiqNCQToqzdK1ksdcBmjKK5Wq3 /RuJfMHZ+mZmZyxEpuHgxc/vOCKnf/gh6BQCT8fpVBCMKzwxxtpjo06ptS6XKSFe NdM0aRlLpoHZN2OmX8YTSkQ4aw/KFw== =ik5x -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 20 12:10:52 2019 Return-Path: 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 682F712001A for ; Sun, 20 Oct 2019 12:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85iLunjEXmFn for ; Sun, 20 Oct 2019 12:10:50 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6874120018 for ; Sun, 20 Oct 2019 12:10:49 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id 67so9181607oto.3 for ; Sun, 20 Oct 2019 12:10:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PDXoL9NvNlgF/1mlisgBVw+ghVPZTPae+5K/CYjKKN8=; b=Q34d5dqAsrbRCcSSF+tGTWQu0ooVikCqAMOgz657eih9/HVKyHu+9+XC8j6PMnXvqk hb4gFhxWOELXuyLQBqEen0QsE5V3b+wI/RTtTI0e5OTjg9NURUd70Ex+7iamjQBabRmH KVDBj9R7ehE2u0MAdI+vhb52jJNyikhC5TERlNsxU3LC/q7nC+5jIAo/N/QBTgHMVUBr fiOiAI+LYsftp9xi5U/fUkHEqKyDTejRMIjoHE4dL+mqyoWktu8qp5NjvGoAmNs5Gdxd T3lQuAxFVuZTnLGgd6hUOTjbiNFxDDSpIXELtzuE0CmIAGORHH1LO/yKubjQTmSkfSQm lMYw== X-Gm-Message-State: APjAAAXcar+L3hbXstiPE2aZXifz026sasta1yr7ZGN52Ab7hlg6J3JM hVhpTXWDHVu2xFBXzxv+1wb9faUN4L0p9FmXmOBlBW4m X-Google-Smtp-Source: APXvYqzewOT7TG7fayakxBxwwJKV+7nOZNMURpOPDWEe9TdiQSKlK8XGFLt37CVCD5hCI8xdZq6EgU70XqRib5Wbhas= X-Received: by 2002:a9d:4591:: with SMTP id x17mr13627276ote.112.1571598649004; Sun, 20 Oct 2019 12:10:49 -0700 (PDT) MIME-Version: 1.0 References: <5eb8774d-8d4f-63e3-29bc-53f3c8d21c51@kuix.de> <2efcd737-34b3-00bb-527f-725daf6e8509@kuix.de> <20191018225100.bnslptroeenuusxf@camp.crustytoothpaste.net> <20191019044008.othhw7j5fktqxdta@camp.crustytoothpaste.net> <13025.1571490248@localhost> <9906.1571591925@localhost> In-Reply-To: <9906.1571591925@localhost> From: Phillip Hallam-Baker Date: Sun, 20 Oct 2019 15:10:37 -0400 Message-ID: To: Michael Richardson Cc: IETF OpenPGP Content-Type: multipart/alternative; boundary="0000000000003419aa05955c53eb" Archived-At: Subject: Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2019 19:10:51 -0000 --0000000000003419aa05955c53eb Content-Type: text/plain; charset="UTF-8" On Sun, Oct 20, 2019 at 1:18 PM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > *A) Generate* > > > The commands for generating, exporting and importing a key from the > CLI > > would probably look something like the following. Since I am > thinking of > > the general case, the key fingerprints used as UDF content digests > rather > > than OpenPGP but this is largely because it was easier to cut and > paste > > from my docs rather than find another. > > Being able to split off the private key generation for PGP, SSH, > certificates, > etc. might be a serious boon to the ecosystem I think. > I am planning to layer in ACME support in the mesh key management tool. So it will be able to automate generation and distribution of the certs for all your embedded devices. This will use meta-cryptography. Which means that once the device has been connected up to the management system, it never needs to do additional keygen. The key presented to the CA is the composite of the device key and the cert manager key. Centralizing key management in one tool works both ways. It allows people who are managing their SSH keys with the tool can also add PGP easily. --0000000000003419aa05955c53eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 20, 2019 at 1:18 PM Michael Richardson = <mcr+ietf@sandelman.ca>= ; wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > *A) Generate*

=C2=A0 =C2=A0 > The commands for generating, exporting and importing a k= ey from the CLI
=C2=A0 =C2=A0 > would probably look something like the following. Since = I am thinking of
=C2=A0 =C2=A0 > the general case, the key fingerprints used as UDF conte= nt digests rather
=C2=A0 =C2=A0 > than OpenPGP but this is largely because it was easier t= o cut and paste
=C2=A0 =C2=A0 > from my docs rather than find another.

Being able to split off the private key generation for PGP, SSH, certificat= es,
etc. might be a serious boon to the ecosystem I think.

I am= planning to layer in ACME support in the mesh key management tool. So it w= ill be able to automate generation and distribution of the certs for all yo= ur embedded devices.

This= will use meta-cryptography. Which means that once the device has been conn= ected up to the management system, it never needs to do additional keygen. = The key presented to the CA is the composite of the device key and the cert= manager key.


<= /div>
Centralizing ke= y management in one tool works both ways. It allows people who are managing= their SSH keys with the tool can also add PGP easily.
--0000000000003419aa05955c53eb-- From nobody Tue Oct 22 08:34:44 2019 Return-Path: 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 B4EEA12089A for ; Tue, 22 Oct 2019 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxgw2yi-zRvi for ; Tue, 22 Oct 2019 08:34:37 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CF912086A for ; Tue, 22 Oct 2019 08:34:37 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id b72so4279156edf.1 for ; Tue, 22 Oct 2019 08:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rxwc3PsKYMeFtJIjLa3LyDmVcGd549tUGFEjn7CHSPg=; b=DVRp0S4GygsmBXVARajmrQ0H+bKWWm8Y1VvfxGw9yTssqfMQA2BRLZkeIn7ilcVRpu 0SI0c9oAYusS1CA/drm5seriG+RHyQ9nU59K0L80ad45+0gGlXxKUMlwoCE0d4016BWx kMcVQ4PR73jG7136XioUnZU2ye1hY9BKPsCX00PgApB7wddG43OkPv/INcuJ3bRHaLUa duZZZ+guYFJhdP/gsDJbur5hOYvFABdqW5FTMuKQI5KX6JW0WINi/7V/RiNCTAOIyTlB wBo96jnmH3hiMpywNEtLkYK++RMloD/qKObk4iUKvovNpDgZTtW35jq31lUfepC7dMCU TO6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rxwc3PsKYMeFtJIjLa3LyDmVcGd549tUGFEjn7CHSPg=; b=c4fXJxsCA5wNstszsne2/BYCytZ4+Sk58sGIKyBc74coj4Ra9qx9JMMveNoRF1ugX9 LAH5N6zgdqF3apj5X0dOz4O3DgnIdAMBUDALUJ1PcZhYfi4gHxRzDYecHAzXJSlsTy91 KCcKmmRUtqzTDq6hjN68YiM6ej2m5Cwxju438MelAzPKq1fziMpsKKUTOkbwzKRizGuf a9WpoakbsHKw28i8dv8LOkRMrcoREivof5EGIBS+g4lgGtrMLb7nBw7fiZ7b3r9NRKVc MuT4gANt/yUROKofkdWyY4m8Yr5GvqWVAGa/nPtW9sgAxSFwE+egwJD/sJ0UBxFDbdC9 2aFw== X-Gm-Message-State: APjAAAVkTtSVcMKLeTwLhp97ZXBBXe03Su0QmQPwzO9lgJNfd+UeMJn8 9rF/7e1L2WngFEMOg+FQhLrIMGI6Qbjdcc2EiKlHkK0N X-Google-Smtp-Source: APXvYqz4/HkzudhPkFqQD60Jak9+sJPAd0EDsdxCJzDd2pjgbucu6kek4JmRl5IfsKkRntnLuT+tqTxAjWU7EnIk6LI= X-Received: by 2002:aa7:db49:: with SMTP id n9mr14272653edt.105.1571758475477; Tue, 22 Oct 2019 08:34:35 -0700 (PDT) MIME-Version: 1.0 From: Justus Winter Date: Tue, 22 Oct 2019 17:34:24 +0200 Message-ID: To: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [openpgp] OpenPGP interoperability test suite X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 15:34:43 -0000 Hello, I started writing an interoperability test suite for OpenPGP. Unlike previous efforts, this test suite is not declarative, but an executable program that drives different OpenPGP implementations. The results of running the test suite are published here: https://tests.sequoia-pgp.org/ The implementation can be found here: https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite Contributions of any kind (drivers, tests, etc.) are welcome. Cheers, Justus From nobody Mon Oct 28 13:20:48 2019 Return-Path: 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 F3D4A120105 for ; Mon, 28 Oct 2019 13:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=acNyc3+N; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=pOcHghSt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSu-kJ69-D1L for ; Mon, 28 Oct 2019 13:20:45 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A89612004E for ; Mon, 28 Oct 2019 13:20:45 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1572294043; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=AXBf0IAgbb/eTkE8ihpWRKcRn1zfJhBDzW96y37QfdU=; b=acNyc3+NAjGdj6ZI6Ug7qFTTzxIVqJVco/KVhgg9JL6zPBo6zeFuLo7m 8q7HapZQbmzLiQI+2gRUy8GuyMt0Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1572294043; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=AXBf0IAgbb/eTkE8ihpWRKcRn1zfJhBDzW96y37QfdU=; b=pOcHghSt0CTbcG8ZxRVlij6Gmgb2UVcxu/jjrrWqGd3RpotTRlPm/0TI AGqtw55JDPZuhyJXE6ena3Zn5G3mM1O4qsdve1+HBT51cA423qGZ6BKQ41 aEJUp1JpKOc+4f+YI9Y1O328WvB4FR1RftGwRlTiuEIIrdEj7rwiRR72lC MhE/tfCF7KEJK6cMfnnE8SIJG5fV3OzXdM0UHEpV4FyUwUI9ClYsOyA9Ij PdN1fwcH3KCuDTMmsMgn9Je7QFR+XRQNaNtH7OxRXw4H6GahU2HK7YMfhj MxxXZy64grc4aU7uhhRefWawXnFqMw0Y7XiqOoi0R3tdYlarh2BanA== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D5970F9A5 for ; Mon, 28 Oct 2019 16:20:43 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7D44820594; Mon, 28 Oct 2019 16:20:40 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 28 Oct 2019 16:20:39 -0400 Message-ID: <87ftjck4fc.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 20:20:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi OpenPGP folks-- The recently-announced OpenPGP test suite [0] inspired me to try drafting a spec for a purely-functional, stateless OpenPGP command line interface. The idea is that different implementers could provide the same interface, focusing specifically on the object security aspect of OpenPGP (leaving aside identity management). An example (using "sop" as the command, short for "Stateless OpenPGP"): sop generate 'Alice Lovelace ' > alice.sec sop convert < alice.sec > alice.pgp sop sign --as=3Dtext alice.sec < announcement.txt > announcement.txt.asc sop verify announcement.txt.asc alice.pgp < announcement.txt sop encrypt --sign-with=3Dalice.sec --as=3Dmime bob.pgp < msg.eml > enc= rypted.asc sop decrypt alice.sec < ciphertext.asc > cleartext.out My hope is that any implementer that provides a command "foo" that meets the given spec can be interoperably tested against all other implementers. I've just published an initial draft of this specification here: https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ It's tracked as markdown source in git at: https://gitlab.com/dkg/openpgp-stateless-cli But i'd very much like other contributions or authors. If you're an implementer of an OpenPGP toolkit, and you think you might take a crack at implementing part of it, i'd love your feedback. If there's sufficient interest in the community, i'd be happy to move the `sop` spec over to https://gitlab.com/openpgp-wg/ so that it's clearly not something that i'd be a blocker on. Why do this? I want to encourage interoperability and testing, and applications that use OpenPGP tend to have a rather simple model of what they *want* out of OpenPGP, even though the spec itself is very complex. A shared spec could help us build some tools that capture that model, as closely (and as simply) as possible. In particular, traditional OpenPGP implementations are capable of many different kinds of work: * Object Security - Authenticity/Integrity - message/object signing - signature verification - Confidentiality - message/object encryption - ciphertext decryption * Identity Management - personal - creation and storage of your own secret keys - management of your own public keys/certificates - publication of certificates (e.g. keyservers, WKD) - management of hardware security tokens - peers - discovery of peer certificates (e.g. keyservers, WKD) - curation and maintenance of peer certificates - association of peer certs with application contexts - certification of peers ("key signing") - graph analysis of certifications ("web of trust") There are probably more things too that i've forgotten about=E2=80=A6 My thought was that if we could separate these things out, we can focus on interoperability of the first part ("Object Security") and treat the second part ("Identity Management") as a distinct project. Obviously, both parts are critical to a functional use of OpenPGP, but i think if we tackle them separately we can provide more plausible and efficient interoperability, which should in turn lead to the ability to drive new cryptographic primitives out into the community. Please take a look and let me know what you think! --dkg [0] id:CA+t5QVv_F7PCbTGSmF4bP66cGVxSHjRJQvawQArQCV4+Pdn4-w@mail.gmail.com --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXbdNmAAKCRB2GBllKa5f +P/DAQCPt8r5e/xtARMzmy17pCvfd5sMKGUyoOXtexylH83iUwEA5C3iHze2jV4s mp74kVu+NVWzahLuM5wZHj1CVAGgTQ4= =uweE -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 28 13:41:38 2019 Return-Path: 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 7A94A120096 for ; Mon, 28 Oct 2019 13:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIN28hgugfj5 for ; Mon, 28 Oct 2019 13:41:34 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DBA120072 for ; Mon, 28 Oct 2019 13:41:34 -0700 (PDT) Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 47267v1NXhzFcNP; Mon, 28 Oct 2019 13:41:31 -0700 (PDT) X-Riseup-User-ID: F884FB1A4840A646EF4732DD72576C4F8BE181B0812FC97C55B303121A9F7845 Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 47266p41xFzJsrf; Mon, 28 Oct 2019 13:40:34 -0700 (PDT) Date: Mon, 28 Oct 2019 16:40:33 -0400 From: Santiago Torres-Arias To: Daniel Kahn Gillmor Cc: openpgp@ietf.org Message-ID: <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> References: <87ftjck4fc.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="22z5hniabnxgprq3" Content-Disposition: inline In-Reply-To: <87ftjck4fc.fsf@fifthhorseman.net> Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 20:41:36 -0000 --22z5hniabnxgprq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 28, 2019 at 04:20:39PM -0400, Daniel Kahn Gillmor wrote: > Hi OpenPGP folks-- >=20 > The recently-announced OpenPGP test suite [0] inspired me to try > drafting a spec for a purely-functional, stateless OpenPGP command line > interface. The idea is that different implementers could provide the > same interface, focusing specifically on the object security aspect of > OpenPGP (leaving aside identity management). >=20 > An example (using "sop" as the command, short for "Stateless OpenPGP"): >=20 > sop generate 'Alice Lovelace ' > alice.sec > sop convert < alice.sec > alice.pgp >=20 > sop sign --as=3Dtext alice.sec < announcement.txt > announcement.txt.= asc > sop verify announcement.txt.asc alice.pgp < announcement.txt >=20 > sop encrypt --sign-with=3Dalice.sec --as=3Dmime bob.pgp < msg.eml > e= ncrypted.asc > sop decrypt alice.sec < ciphertext.asc > cleartext.out >=20 I think this is a *phenomenal* idea. I wonder if this could mature in a well-defined API that e.g., gpgme could adopt? =20 > I've just published an initial draft of this specification here: >=20 > https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ >=20 > It's tracked as markdown source in git at: >=20 > https://gitlab.com/dkg/openpgp-stateless-cli >=20 > But i'd very much like other contributions or authors. If you're an > implementer of an OpenPGP toolkit, and you think you might take a crack > at implementing part of it, i'd love your feedback. If there's > sufficient interest in the community, i'd be happy to move the `sop` > spec over to https://gitlab.com/openpgp-wg/ so that it's clearly not > something that i'd be a blocker on. I'll definitely take a look, as we implement bits and pieces of rfc4880/rfc4880bis on NYU's securesystemslib. Thanks! -Santiago. --22z5hniabnxgprq3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkDurc2QOttZVM+/zRo8SLOgWIpUFAl23UkAACgkQRo8SLOgW IpWZuRAAvEuLoeBWlq0opvuTpcviDWW4wEu9/u99yV6jMqRjW7jxgV+sRmJy18gt GkHBVvas/B8+0S80UHYVUD/KvgTXc/hXtS3W0pYJl+XtYiP48MnSwKooL6kzf3MY xqMRT8PWPZvmmJh3ET30ZUkErUwTq+HHOWKeOac1hwqzTR+CVvEBCnK3mHlSSpFb C6TzkEKP7xvCX5JU6YUWwV7r/f82eKy+I1PggetuM+zoDQsiXc+/IMHAsvNyD8t0 OTkgvySldCcdZLsYSnTgOaDcZajO0zp8gUniUUS2+TBPSEQB4O4F+V5oA20OYbws E0VCELtX1yZ2qN5D9fTCpib8mddpGCYyo//sRSh7sS+slSfohHa8f7QMGAiILinD cUo/0yYdN49QmIavBNiQ+bq86o5d5paIZfN5m/OCsLLZIA7GaOf3ZXnPn658m/oi CYEg5M6V4/I1jf3hxnEFlqxAXwn4U6wW2jd8/IRd7LPUBZLyRR1XbuwPJaG8+Zyr OUdw5KvYN7dYl2+uJ/QAGEm1usgCFxN7EdEKByGzoZ1O+GKcbzFDNtQQtGhj0j/F S1c6jyIEy1nF2maWtIvdBt0YqT2sD8naHw94GXKFonb0GFqdV3WN/Pize9VcqwJf NerZT4iGVYWjtEJF6WyftufKlpFFn9o55Is6uz7r7aMC7ziAkUE= =AxvI -----END PGP SIGNATURE----- --22z5hniabnxgprq3-- From nobody Mon Oct 28 19:10:48 2019 Return-Path: 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 7D13912008D for ; Mon, 28 Oct 2019 19:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34Fh2qT29g_1 for ; Mon, 28 Oct 2019 19:10:44 -0700 (PDT) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7620B120047 for ; Mon, 28 Oct 2019 19:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=83CpUDyWn07uXJxANaGmbjK+7LWSCtgprmuZYpzhZtk=; b=Yxz+vBhlJi6pB+KFiA5FfXcTQa NYXwUOc4DQCjHb8WLyVV/gEHF+PvN5KjIttCDMzP00CP6WUbtKLDtCaJyR3iQ4/3ERqZ7MERFk6yM ES+zFvBHHz5wB25Bp6psVwhrRNaasjOZmcjJR8G4TTrph/RgQ2ufuQEAaqoFDlSImJeH2cv8WCneb QTLLMRi55THKLo1esL3mB2zIAFN9jq3OKP/nwHRLaGijKvl0O9nE6VZtbwpAUVTuSkIUdk7EOCHb3 3eTSozJkTAwmOhDC9SbpdE/ZCDUXAh553RJFDBkEQN2Bt5/lXrg8IETJYCRULKgcSE3j8CRLnotO3 I17TjJlg==; Received: from 140.200.232.153.ap.dti.ne.jp ([153.232.200.140] helo=iwagami.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iPGxz-0008Tv-Ay; Tue, 29 Oct 2019 03:10:40 +0100 Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Tue, 29 Oct 2019 11:10:34 +0900 From: NIIBE Yutaka To: IETF OpenPGP Date: Tue, 29 Oct 2019 11:10:34 +0900 Message-ID: <87a79kmhd1.fsf@iwagami.gniibe.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] EdDSA problem and possible change about ECC X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 02:10:46 -0000 Hello, I'm currently considering to add ECDH X448 to OpenPGP. While I examined GnuPG and libgcrypt for that, I realized that there are some discrepancy/inconsistency and possible interoperability issues among OpenPGP implementations. Thus, I share my observations and I'd like to propose changes of OpenPGP specification. I'd like to listen from different OpenPGP implementations. The issue is about EdDSA (and possibly for ECDH X448 in future). Current implementation of GnuPG 2.2 has/does: (1) discrepancy/inconsistency * In EdDSA key, it uses the prefix 0x40 for an EC point representation. * In EdDSA signature, for R, it uses no prefix for an EC point representation. Note that: GnuPG accepts EdDSA key with no prefix in an EC point. GnuPG does _not_ accept EdDSA signature which R has the prefix 0x40. (2) Removal of zeros in MPI handling in EdDSA While the native EdDSA octet string for secret is defined as fixed-size, it is defined as an MPI (big-endian) in OpenPGP. While the native EdDSA EC point representation is defined as fixed-size little-endian, it is defined as an MPI in OpenPGP. While the native EdDSA integer representation is defined as fixed-size little-endian, it is defined as an MPI (big-endian) in OpenPGP. Because of this, * In EdDSA secret key, the zeros (least significant bytes) in native representation of the secret are removed to compose an MPI. * In EdDSA signature, the zeros (least significant bytes) in native representation of an EC point R are removed to compose an MPI. * In EdDSA signature, the zeros (least significant bytes) in native representation of an integer S are removed to compose an MPI. (3) Recovery of zeros in MPI handling in EdDSA To compensate the problem (2), it does special handling to recover zeros when it receives an EdDSA secret/signature in OpenPGP format. While we should keep support of zero-removed EdDSA secret/signature, I think that it's good to modify GnuPG so that it won't generate possibly problematic EdDSA secret/signature any more. And it's good to clarify the specification, so that EdDSA secret/signature with no-zero removal (zeros as-is) can be valid. I'm afraid that no-zero removal EdDSA secret/signature is invalid by the current draft of rfc4880bis, as ill-formed MPI. So.... here is my suggestion to OpenPGP specification. Since my language skill for specification is poor, I don't intend to fix the text by my words, but I would like to point out the place where we need to fix. In the following patch, I introduced "SOS" for "simply, octet string". I know it's not good term, it should be replaced by more relevant term soon. Please help for good term choice. The reason for SOS is that I think that it is not good for curves which have native format in fixed-size little-endian to use MPI to represent its EC point and its integer. The structure of SOS is exactly same as MPI, so that existing implementation can avoid larger changes (no change, hopefully). When we will able to define an EC point representation as SOS, we won't need to use the prefix 0x40, and we won't need to claim it as an extension of the encoding given in SEC1. While we need to support existing Ed25519 keys with the prefix 0x40, in future, for Ed448 keys and X448 keys (including ephemeral keys in ECDH), we can use no prefix cleanly. ========================== diff --git a/middle.mkd b/middle.mkd index ca73704..3e3b548 100644 --- a/middle.mkd +++ b/middle.mkd @@ -211,6 +211,15 @@ Unused bits of an MPI MUST be zero. Also note that when an MPI is encrypted, the length refers to the plaintext MPI. It may be ill-formed in its ciphertext. +## Simply, Octet String + +Simply-Octet-String (also called SOSs) are opaque octet strings. + +A SOS consists of two pieces: a two-octet scalar that is the length of +the SOS in bits followed by a string of octets. + +It should accepts SOS with unused bits in the first octet. + ## Key IDs A Key ID is an eight-octet scalar that identifies a @@ -636,7 +645,8 @@ The body of this packet consists of: Algorithm-Specific Fields for ECDH encryption: - - MPI of an EC point representing an ephemeral public key. + - SOS of an EC point representing an ephemeral public key. It + may comes with the prefix octet of 0x40. - a one-octet size, followed by a symmetric key encoded using the method described in [](#ec-dh-algorithm-ecdh). @@ -979,13 +989,13 @@ The body of a V4 or V5 Signature packet contains: Algorithm-Specific Fields for EdDSA signatures: - * MPI of EdDSA compressed value r. + * SOS of an EC point r. - * MPI of EdDSA compressed value s. + * SOS of an integer representing EdDSA value s. -The compressed version of R and S for use with EdDSA is described in -[](#RFC8032). A version 3 signature MUST NOT be created -and MUST NOT be used with EdDSA. +The format of R and S for use with EdDSA is described in [](#RFC8032). +A version 3 signature MUST NOT be created and MUST NOT be used with +EdDSA. The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive) is @@ -2301,7 +2311,7 @@ The public key is this series of values: - the octets representing a curve OID, defined in [](#ecc-curve-oid); - * a MPI of an EC point representing a public key. + * MPI of an EC point representing a public key. The secret key is this single multiprecision integer: @@ -2322,13 +2332,12 @@ The public key is this series of values: - the octets representing a curve OID, defined in [](#ecc-curve-oid); - * a MPI of an EC point representing a public key Q as described - under EdDSA Point Format below. + * SOS of an EC point representing a public key Q. It may comes with + the prefix octet of 0x40. The secret key is this single multiprecision integer: - * MPI of an integer representing the secret key, which is a - scalar of the public EC point. + * SOS representing the secret key. ### Algorithm-Specific Part for ECDH Keys @@ -2344,7 +2353,8 @@ The public key is this series of values: - the octets representing a curve OID, defined in [](#ecc-curve-oid); - * a MPI of an EC point representing a public key; + * SOS of an EC point representing a public key. It may comes with + the prefix 0x40. * a variable-length field containing KDF parameters, formatted as follows: @@ -2365,8 +2375,8 @@ fields that define an ECDSA key, plus the KDF parameters field. The secret key is this single multiprecision integer: - * MPI of an integer representing the secret key, which is a - scalar of the public EC point. + * SOS representing the secret key, which is a scalar of the public + EC point. ## Compressed Data Packet (Tag 8) @@ -4035,10 +4045,10 @@ in detail how this sequence of bytes is formed. ## ECDSA and ECDH Conversion Primitives This document defines the uncompressed point format for ECDSA and ECDH -and a custom compression format for certain curves. The point is -encoded in the Multiprecision Integer (MPI) format. +and a custom compression formats for certain curves. The point is +encoded in SOS format. -For an uncompressed point the content of the MPI is: +For an uncompressed point the content of the SOS is: B = 04 || x || y @@ -4048,17 +4058,18 @@ size. The adjusted underlying field size is the underlying field size that is rounded up to the nearest 8-bit boundary. This encoding is compatible with the definition given in [](#SEC1). -For a custom compressed point the content of the MPI is: +For a custom compressed point the content of the SOS is: B = 40 || x where x is the x coordinate of the point P encoded to the rules -defined for the specified curve. This format is used for ECDH keys -based on curves expressed in Montgomery form. +defined for the specified curve. The prefix octet 0x40 is optional. +This format is used for ECDH keys based on curves expressed in +Montgomery form. -Therefore, the exact size of the MPI payload is 515 bits for "Curve -P-256", 771 for "Curve P-384", 1059 for "Curve P-521", and 263 for -Curve25519. +Therefore, the exact bit size of the SOS payload is 515 bits for +"Curve P-256", 771 for "Curve P-384", 1059 for "Curve P-521", and 263 +for "Curve25519". For "X448", it's 448 bits with no prefix. Even though the zero point, also called the point at infinity, may occur as a result of arithmetic operations on points of an elliptic @@ -4077,17 +4088,20 @@ given recipient of a given message. ## EdDSA Point Format -The EdDSA algorithm defines a specific point compression format. To -indicate the use of this compression format and to make sure that the -key can be represented in the Multiprecision Integer (MPI) format the -octet string specifying the point is prefixed with the octet 0x40. -This encoding is an extension of the encoding given in [](#SEC1) which -uses 0x04 to indicate an uncompressed point. +The EdDSA algorithm defines a specific point compression format. In +order to the key can be interpreted in the Multiprecision Integer +(MPI) format, the octet string specifying the point may be prefixed +with the optional octet 0x40. This encoding is an extension of the +encoding given in [](#SEC1) which uses 0x04 to indicate an +uncompressed point. For example, the length of a public key for the curve Ed25519 is 263 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the native value of the public key. +The length of a public key for the curve Ed448 is 448 bit: no prefix +octet and 56 octets for the native value of the public key. + ## Key Derivation Function @@ -4230,7 +4244,7 @@ normative sources of the definition. Compute Z = KDF( S, Z_len, Param ); Compute C = AESKeyWrap( Z, m ) as per [RFC3394] VB = convert point V to the octet string - Output (MPI(VB) || len(C) || C). + Output (SOS(VB) || len(C) || C). The decryption is the inverse of the method given. Note that the recipient obtains the shared secret by calculating -- From nobody Tue Oct 29 19:04:12 2019 Return-Path: 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 D01A712009E for ; Tue, 29 Oct 2019 19:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=KPSFbvmi; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=o3JqG4wz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gI3RwVtRdR3 for ; Tue, 29 Oct 2019 19:04:08 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FC8120059 for ; Tue, 29 Oct 2019 19:04:07 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1572401046; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=gp2NCQV6YvoH+lYf3w4VVVj+23vBp71CpWvHVvjQKKk=; b=KPSFbvmi/TDWwbyOJSnTJ269Qt/vtijLNo4uSsa9WfWXlbZI97tM5XRD OxdXirmOMct5UjsewYmpzV7lvjcWAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1572401046; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=gp2NCQV6YvoH+lYf3w4VVVj+23vBp71CpWvHVvjQKKk=; b=o3JqG4wzZhifsGiOxHt9c4hNFmHGdHJO+XaNSoYHZJbeNnUiPAE3dc89 IEF+Swl0h4wEnhGiOGC4Y5YHDZqCyKJQlwerMjatoeWsiiqWUCMmQnuT4u bHChE9w37DcnYOxxh84yyx/Dx8wEAaMKVCTh9Mw6Tk0QAMUVC6TTrl/DzR m6TrjUoqp1etCywNF63j1WRhqqeOX4aUe4YO2t1EdFifT1CVUwA9SbML6J mIirE2OYfWouk2I83+3TU6JURBlqCe8Ldxv4EqvxcwVoBVFZe4pQ97gRwi +M0a0OpVOvSES+QbtnC2QyYbBNV7I7DIiZuh5DyHO+5F7pxJsFdQcg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D1EA3F9A5 for ; Tue, 29 Oct 2019 22:04:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6D5A620556; Tue, 29 Oct 2019 22:04:03 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: <87ftjck4fc.fsf@fifthhorseman.net> References: <87ftjck4fc.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 29 Oct 2019 22:04:02 -0400 Message-ID: <8736fbhtv1.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 02:04:11 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon 2019-10-28 16:20:39 -0400, Daniel Kahn Gillmor wrote: > drafting a spec for a purely-functional, stateless OpenPGP command line > interface. [=E2=80=A6] > I've just published an initial draft of this specification here: > > https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ I got a lot of very useful feedback on this draft (mostly off-list) from several people over the past day, and i've published a revised version that incorporates what I learned. substantive changes between -00 and -01: * Changed `generate` subcommand to `generate-key` * Changed `convert` subcommand to `extract-cert` * Added "Input String Types" section as distinct from indirect I/O * Made implicit arguments potentially explicit (e.g. `sop armor --label=3D= auto`) * Added `--allow-nested` to `sop armor` to make it idempotent by default * Added fingerprint of signing (sub)key to `VERIFICATIONS` output * Dropped `--mode` and `--session-key` arguments for `sop encrypt` (no pla= usible use, not needed for interop) * Added `--with-session-key` argument to `sop decrypt` to allow for sessio= n-key-based decryption * Added examples to each subcommand * More detailed error codes for `sop encrypt` * Move from `CERT` to `CERTS` (each `CERTS` argument might contain multipl= e certificates) Some things that I observed from this process: - `sop` should be simple to operate. It shouldn't ask the user any question (or offer any options) that the user doesn't already know the answer to, or that will have no effect on how the data produced will ultimately be used. - Implementers of `sop` are expected to make reasonable decisions in those corners of the spec are unclear. Hopefully interoperability test suites will help identify those corners. - While we want `sop` implementations to be robust when trying to consume weird input, sometimes being robust really should just mean a clean failure, rather than trying to make sense of non-sensible inputs. I also note that xml2rfc v3 output is substantially nicer to read than the htmlized form produced by tools.ietf.org by default right now. You can compare the forms: https://tools.ietf.org/html/draft-dkg-openpgp-stateless-cli-01 https://dkg.fifthhorseman.net/draft-openpgp-stateless-cli.html I prefer the latter, which i aim to keep updating if (as i hope) more revisions are forthcoming. I welcome further feedback on this spec, both here on-list and also via https://gitlab.com/dkg/openpgp-stateless-cli Regards, --dkg =2D----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXbjvkwAKCRB2GBllKa5f +NShAP9HD282x1xFK98EBQQz3mVjB1Ly5ASy+TBs5cJecU4MJwEAhPuvz0kYagqA r5Z4Jhvct9wMgvIcQJtqQV54HyhK9Qs=3D =3D09Dg =2D----END PGP SIGNATURE----- From nobody Wed Oct 30 09:23:58 2019 Return-Path: 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 008A812080D for ; Wed, 30 Oct 2019 09:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE6NYSQb7zKT for ; Wed, 30 Oct 2019 09:23:55 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242A412006A for ; Wed, 30 Oct 2019 09:23:55 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 22so2850545wms.3 for ; Wed, 30 Oct 2019 09:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=qku/9FEHqsEM8wUFeNDJ/92HCv8jp2jrVO9BCl8Qkq4=; b=PJsZnlqrIMlEAig04v4Yy7wbGHPM02d5gEVHC7sHv9w4S37qppRTglGalFMV+snFVA R6YMQvUQhtGcYjQ7SMi8ASrC+lFXrobKJlLjregc3T9xoMYllVeGUvIkXWcp8ko9u4tE GwpujZlA2ZmESa1Z1UmfE+5Rj+UHEAmEjWBVXiTvPsyH8YIPPuOaeuG+J6HdWAFnxFgi shO57zKNQJL1Lm3PUW9rdGY3fRndRoLMQOFaO9GPnTSPwlmkONsfz3dVKwzvaCbr5U4Z qRbQhBohtvhuyWI152F2ewu0iuUeC+66s+JCtaGcywkNzh7M0wLTsBo7fqOolg5MOuGf nsuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=qku/9FEHqsEM8wUFeNDJ/92HCv8jp2jrVO9BCl8Qkq4=; b=azHRpY+Etjc9NPcEbqEHbRC5mnKsuH5kHegFeQK3x7A/Xo8+6EQTGpcjUmvivU2Bwz mEjkef1eUy8Xt90xwr0QlbcMOmy0mf5PMbw4F3CbWErkoLjAFDTBVwFinV+f76fvZHvj M9ThE536ALd2/sylFP714Np7twRPd00OSgqBIywv9y0mLed6YEybuzFYXh+7VYggP0xX dyYTkUcQHskw6NOKptrj+GatwwX/0UtiK26S3FC6HY9BV2Wvp1tTcnKwoKqlvnrOuy/c Z9iDvCkxWy661x7svFWV6M7Qp66C0LfeRp7RYAYr7EukWmNRcZqey+WzVml/1moYxuec dGYA== X-Gm-Message-State: APjAAAUx3Bimpw3VAYTYTfluRUyv+nYcBB0zi6hyYy163BkttX7vYD6f Z1tW0rsT4+07nH1RatpjI4OpiSrq X-Google-Smtp-Source: APXvYqz/0busZFkKZDpKAJAMrCZj9wLarqJ52vsyR0yPQgiiBFVKix6XFac/Hux5Y23hMziB5HoQ0Q== X-Received: by 2002:a1c:64d4:: with SMTP id y203mr283285wmb.27.1572452633684; Wed, 30 Oct 2019 09:23:53 -0700 (PDT) Received: from [192.168.1.163] (port-92-193-84-170.dynamic.qsc.de. [92.193.84.170]) by smtp.gmail.com with ESMTPSA id t1sm825658wrn.81.2019.10.30.09.23.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2019 09:23:53 -0700 (PDT) Date: Wed, 30 Oct 2019 17:23:52 +0100 From: Justus Winter To: NIIBE Yutaka Cc: IETF OpenPGP Message-Id: <1572452632.29750.0@smtp.gmail.com> In-Reply-To: <87a79kmhd1.fsf@iwagami.gniibe.org> References: <87a79kmhd1.fsf@iwagami.gniibe.org> X-Mailer: geary/0.12.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Archived-At: Subject: Re: [openpgp] EdDSA problem and possible change about ECC X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 16:23:57 -0000 Hello, On Tue, Oct 29, 2019 at 3:10 AM, NIIBE Yutaka wrote: > While I examined GnuPG and libgcrypt for that, I realized that there > are > some discrepancy/inconsistency and possible interoperability issues > among OpenPGP implementations. Interoperability between implementations with regarad to EdDSA seems to be good: https://tests.sequoia-pgp.org/#Detached_Sign-Verify_roundtrip_with_key__Alice_ Though I agree that OpenPGP's MPI encoding has been a source of bugs. I just discovered this exact issue in dkgpg this week: https://savannah.nongnu.org/bugs/index.php?57135 > (2) Removal of zeros in MPI handling in EdDSA > > While the native EdDSA octet string for secret is defined as > fixed-size, it is defined as an MPI (big-endian) in OpenPGP. > > While the native EdDSA EC point representation is defined as > fixed-size little-endian, it is defined as an MPI in OpenPGP. > > While the native EdDSA integer representation is defined as > fixed-size > little-endian, it is defined as an MPI (big-endian) in OpenPGP. > > Because of this, > > * In EdDSA secret key, the zeros (least significant bytes) in native > representation of the secret are removed to compose an MPI. > > * In EdDSA signature, the zeros (least significant bytes) in native > representation of an EC point R are removed to compose an MPI. > > * In EdDSA signature, the zeros (least significant bytes) in native > representation of an integer S are removed to compose an MPI. > > (3) Recovery of zeros in MPI handling in EdDSA > > To compensate the problem (2), it does special handling to recover > zeros when it receives an EdDSA secret/signature in OpenPGP format. I agree with your analysis. > While we should keep support of zero-removed EdDSA secret/signature, I > think that it's good to modify GnuPG so that it won't generate > possibly > problematic EdDSA secret/signature any more. I wrote a test to see how various OpenPGP implementations react to MPIs that are not in canonical form (i.e. malformed MPIs) for S, or 0x40-padded R, and only GnuPG and PGPy accept zero-padded S: https://tests.sequoia-pgp.org/#EdDSA_signature_encodings Therefore, I'm afraid that changing what implementations emit now will introduce incompatibilities with existing implementations. Cheers, Justus From nobody Thu Oct 31 01:04:19 2019 Return-Path: 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 497B3120834 for ; Thu, 31 Oct 2019 01:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8UQzPYC8huc for ; Thu, 31 Oct 2019 01:04:13 -0700 (PDT) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A17120824 for ; Thu, 31 Oct 2019 01:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc: To:From:References:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=EHc+Ejvah18o7cU2mwJSuXNcNAv0OFSMG6u52UlkRl0=; b=pJ+m3BMFX1bIcfF46Fq4Bw8pW+ OpIp/c6LG/yrkHaZlhk32BIVaELowM+3wGBtBu5WskKixCUtvJCC2R1M4h0IR9hNnfcwXciT6xfSt eoNpGHwPSCG8p9Ek5ggyunN8/LITDOEJbeAOEl5NQ7zIlbP0ags429wlqEBAX5oGSwKIq4ESH/qVd mYkVXkkI8oj/IWvgJmARLGQJgaX7XMrNwyn6/Mo080jHcxgT8d5lp7/3QtuZtKYxM35xCFcFYftRN MiBfJAxzuzi4+9obYbEAJSV0eSJoKl5+h20wcB2mnd3WN1WsTBWF+Gy41k8DWnnLH5vwFRzs6xlbY 3wZk2DAw==; Received: from z212192.dynamic.ppp.asahi-net.or.jp ([110.4.212.192] helo=localhost) by akagi.fsij.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iQ5RB-0001hR-4e; Thu, 31 Oct 2019 09:04:09 +0100 References: <87a79kmhd1.fsf@iwagami.gniibe.org> <1572452632.29750.0@smtp.gmail.com> User-agent: mu4e 1.0; emacs 26.1 From: Niibe Yutaka To: Justus Winter Cc: IETF OpenPGP In-reply-to: <1572452632.29750.0@smtp.gmail.com> Autocrypt: addr=gniibe@fsij.org; prefer-encrypt=mutual; keydata= mDMEVcrxeBYJKwYBBAHaRw8BAQdAnMfaPVY4ldwFJr18e9ADT+T0M9U9GC4K800CrtT2QXe0Hk5J SUJFIFl1dGFrYSA8Z25paWJlQGZzaWoub3JnPoh8BBMWCAAkAhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheABQJVzIzWAhkBAAoJEOJnsFI2TwKNJUIA/0oRcUoOhkVi/rdewnuALVWcnTuUvPexVQh+ CfHgvEP1AQDQX/cPFSaydSNTzsxPBYoa/pgfF8dFKVVlnJIwy07PBbg4BFXK8XgSCisGAQQBl1UB BQEBB0BDF4eWFoYKSDGvt26As8ASzh75ZkjRqs70cxQiJAp7QAMBCAeIYQQYFggACQUCVcrxeAIb DAAKCRDiZ7BSNk8CjfVqAP9NFD+rTePZAVyWmOfzko7Y2yTGLwlqMTEuVVnEHoI6jAD9Ezv6ojRl z/47hOw32N2L2zDiE/dxT5CCm3ZVxST8GgK4MwRVyvK+FgkrBgEEAdpHDwEBB0DsZ495muN9/vr8 IJ7sVPe4n3w6jER3bIKv7tkHWPQXTIhhBBgWCAAJBQJVyvK+AhsgAAoJEOJnsFI2TwKNNhsA/2GW iUDVSAoM1SDUFLutSsM4/kJMlIhtVWy2u0svQxN5AP0VHPGkBv84mnlqxHAQa4y3lWku2ZgR5aN+ vuR5JjyUCw== Date: Thu, 31 Oct 2019 17:04:04 +0900 Message-ID: <87tv7pwdcb.fsf@jumper.gniibe.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] EdDSA problem and possible change about ECC X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 08:04:16 -0000 Justus Winter wrote: > I wrote a test to see how various OpenPGP implementations react to MPIs > that are not in canonical form (i.e. malformed MPIs) for S, or > 0x40-padded R, and only GnuPG and PGPy accept zero-padded S: > > https://tests.sequoia-pgp.org/#EdDSA_signature_encodings Thanks a lot for your information. It's very helpful. > Therefore, I'm afraid that changing what implementations emit now will > introduce incompatibilities with existing implementations. I see. So... I'm going to take conservative approach for SOS when changing GnuPG; Introduce SOS for new curve only, at first. After new curve will become common (together with SOS handling hopefully) among implementations, then, apply SOS to Ed25519 if possible/useful. FWIW: I changed libgcrypt master for similar leading-zeros problem. For GnuPG, there are many places (than I initially expected); It's not only in gpg frontend but also in data format in the protocl between gpg-agent, and in gpg-agent. When I locate all places, I change those places to support non-zero-removed full-size octet string (keeping leading zeros intact), and then, I'll generate an example OpenPGP EdDSA key with self-signature (key with leading zeros _and_ signature with leading zeros). I'd say, "save our leading zeros". :-) --