From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VA9kO-0003m0-31 for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 02:26:40 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.52 as permitted sender) client-ip=209.85.215.52; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f52.google.com; Received: from mail-la0-f52.google.com ([209.85.215.52]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VA9kK-00077Z-B0 for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 02:26:39 +0000 Received: by mail-la0-f52.google.com with SMTP id ev20so1019772lab.25 for ; Thu, 15 Aug 2013 19:26:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.28.37 with SMTP id y5mr15509180lag.0.1376619989603; Thu, 15 Aug 2013 19:26:29 -0700 (PDT) Received: by 10.112.89.72 with HTTP; Thu, 15 Aug 2013 19:26:29 -0700 (PDT) Date: Thu, 15 Aug 2013 19:26:29 -0700 Message-ID: From: Gregory Maxwell To: Bitcoin Development , Pieter Wuille Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VA9kK-00077Z-B0 Subject: [Bitcoin-development] BIP 32.5 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 02:26:40 -0000 I am wondering if we shouldn't have a BIP32 addendum which makes the following signing related recommendations: (1) Recommend a specific deterministic DSA derandomization procedure (a deterministic way to generate the DSA nonce), presumably one based on HMAC-SHA512 (since BIP32 uses that construct) or SHA256 in the style of RFC 6979. DSA systems being compromised due to poor randomness at runtime is not new. It effected other systems before it effected Bitcoin systems, it's not a new problem and it's not going away. It's difficult to tell if an implementation is correct or not. Use of a fully deterministic signature would allow for complete test vectors in signing and complete confidence that there is no random number related weakness in a signing implementation. In particular, with relevance to our ecosystem a maliciously modified difficult to audit hardware wallet could be leaking its keys material via its signatures. Even without producing insecure K values it could use the choice of K to leak a couple bits of an encrypted root key with every signature, and allow the malicious party to recover the keys by simply observing the network. Making the signatures deterministic would make this kind of misbehavior practically discoverable. We wouldn't be alone in making this change, in general industry is moving in this direction because it has become clear that DSA is a hazard otherwise. The primary arguments in most spaces against derandomizing DSA are FIPS conformance (irrelevant for us) and reasonable concerns about the risks of using a (less) reviewed cryptographic construct. With widespread motion towards derandomized DSA this latter concern is less of an issue. Libcrypt has also implemented derandomized DSA in git. The ed25519 signature system of DJB, et. al. also uses a similar derandomization. An alternative is implementing a still random construct where K is some H(message||key||random) which should remain secure even where the randomness is poor, but this loses the advantage of being able to externally verify that an implementation is not leaking information. OpenSSL development has implemented a form of this recently. See also: http://tools.ietf.org/rfc/rfc6979.txt (2) Recommends a procedure for using only even S values in signatures, eliminating this source of mutability in transactions. This can be accomplished via post-processing of existing signatures, but since it requires bignum math it is usually preferable to implement it along with signing. I believe someday this will become a network requirement for Bitcoin, but regardless it makes sense to implement it as a best practice sooner rather than later. Thoughts?