From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 22501C0177 for ; Mon, 24 Feb 2020 04:26:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0C49B85955 for ; Mon, 24 Feb 2020 04:26:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q46DWUlPkYR5 for ; Mon, 24 Feb 2020 04:26:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 3513783507 for ; Mon, 24 Feb 2020 04:26:30 +0000 (UTC) Received: by mail-oi1-f181.google.com with SMTP id i1so7738440oie.8 for ; Sun, 23 Feb 2020 20:26:30 -0800 (PST) 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=8+jDGxs2THA/IPnQ6sIPkCZa8R+UGMO19W8gepHzsWU=; b=stKcgI6XVLRolHNCld9InNdMWlzGfozNuWTAFAlgnUp8srCCGvjtAZMMJFmpcYHjRY thBby0fzhY8EXjzY7HTokEoKHjrOe0mFlMpbfgWguVKsjRSfoAbyC6rM8e+Hv5HJF17y AUvs8GAx2ibzK3Cy119V3GIULW4GWpbaSS0c5P72d9jz14oIXYTu1bQYJXBnDZwnrGud CKtruE8JaZM0iHzKBYk21LcJOLlgJG54KoZeGFlbpYpCvm1hSi5b6mZFroJAMv0kQlP4 wrOlyk9xyvTkiwuMNvBhkmQOJzYGZnbDa3DRJNdGKrYTuvkLLHfeQj7MHZFE4Gz5GGGP wXEQ== 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=8+jDGxs2THA/IPnQ6sIPkCZa8R+UGMO19W8gepHzsWU=; b=GBVZZeLNgrpKMzksqzavZ1jKIJigcg32MWnOYKcQldHLYDlz8U7rQ0go/l6E65FbRk 8+HvoTvmbWdxP+m0vcxvKvw9GmXV+oXQzX+DHrmR0f4OAvwvL3xW3zHl0fYnHE55J6Sk GxJncyeta5Gl6EbOPhe3UQuLiWbXMlerscuwz3Zf2l9gpuXm9TYmL/yRsMeHYQb26SIu rVjVBSOrZGVHdV1RSLfccuBZcKzN+C9NKDorDYBzCIRWgPiEQkDnB63+24u22sz2LXWc DZ+g4p8t8xT8EN1Ednx2CJHSq+KaCz5plf6KTH4w3RXVY+gL9S/CpaFk63kQJRH/kUJR PWag== X-Gm-Message-State: APjAAAXhrUWtHDN/RE61OESY1H1Ssr0QRDfpy2McPflj8b1ZB3Uense9 ZoJlRFEJNG19B/s5YSFzj8UgDFaCYe41VxHJ6Zk5hyzHlk0= X-Google-Smtp-Source: APXvYqxjY7C3vFqp4yFMZ2d6J6cCCiZ8Cwq1XTQJgOeez+iZq4Og6VgWRqFdf1CRcGray8V6bhoV2KK7dz9JiyUF83g= X-Received: by 2002:a05:6808:aac:: with SMTP id r12mr11236476oij.59.1582518388982; Sun, 23 Feb 2020 20:26:28 -0800 (PST) MIME-Version: 1.0 From: Pieter Wuille Date: Sun, 23 Feb 2020 20:26:17 -0800 Message-ID: To: Bitcoin Dev Content-Type: text/plain; charset="UTF-8" Subject: [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 04:26:33 -0000 Hello list, Despite saying earlier that I expected no further semantical changes to BIP 340-342, I've just opened https://github.com/bitcoin/bips/pull/893 to make a number of small changes that I believe are still worth making. 1. Even public keys Only one change affects the validation rules: the Y coordinate of 32-byte public keys is changed from implicitly square to implicitly even. This makes signing slightly faster (in the microsecond range), though also verification negligibly slower (in the nanosecond range). It also simplifies integration with existing key generation infrastructure. For example BIP32 produces public keys with known even/oddness, but squaredness would need to be computed separately. Similar arguments hold for PSBT and probably many other things. Note that the Y coordinate of the internal R point in the signature remains implicitly square: for R the squaredness gives an actual performance gain at validation time, but this is not true for public keys. Conversely, for public keys integration with existing infrastructure matters, but R points are purely internal. This affects BIP 340 and 341. 2. Nonce generation All other semantical changes are around more secure nonce generation in BIP 340, dealing with various failure cases: * Since the public key signed for is included in the signature challenge hash, implementers will likely be eager to use precomputed values for these (otherwise an additional EC multiplication is necessary at signing time). If that public key data happens to be gathered from untrusted sources, it can lead to trivial leakage of the private key - something that Greg Maxwell started a discussion about on the moderncrypto curves list: https://moderncrypto.org/mail-archive/curves/2020/001012.html. We believe it should therefore be best practice to include the public key also in the nonce generation, which largely mitigates this problem. * To protect against fault injection attacks it is recommended to include actual signing-time randomness into the nonce generation process. This was mentioned already, but the update elaborates much more about this, and integrates this randomness into the standard signing process. * To protect against differential power analysis, a different way of mixing in this randomness is used (masking the private key completely with randomness before continuing, rather than hashing them together, which is known in the literature to be vulnerable to DPA in some scenarios). 3. New tagged hash tags To make sure that any code written for the earlier BIP text fails consistently, the tags used in the tagged hashes in BIP 340 are changed as well. What do people think? -- Pieter