From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X8ZzY-0005cg-5J for bitcoin-development@lists.sourceforge.net; Sat, 19 Jul 2014 19:08:20 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.52 as permitted sender) client-ip=209.85.219.52; envelope-from=voisine@gmail.com; helo=mail-oa0-f52.google.com; Received: from mail-oa0-f52.google.com ([209.85.219.52]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X8ZzW-0003kD-RQ for bitcoin-development@lists.sourceforge.net; Sat, 19 Jul 2014 19:08:20 +0000 Received: by mail-oa0-f52.google.com with SMTP id o6so5293325oag.39 for ; Sat, 19 Jul 2014 12:08:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.147.229 with SMTP id tn5mr10540769oeb.11.1405796893380; Sat, 19 Jul 2014 12:08:13 -0700 (PDT) Received: by 10.60.169.109 with HTTP; Sat, 19 Jul 2014 12:08:13 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 Jul 2014 12:08:13 -0700 Message-ID: From: Aaron Voisine To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 (voisine[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: 1X8ZzW-0003kD-RQ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Small update to BIP 62 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: Sat, 19 Jul 2014 19:08:20 -0000 Thanks g.maxwell, your explanation of *why* you can't just generate k in a way that the verifier can duplicate is really helpful. This also servers as a great illustration why engineers should never try to designing their own crypto protocols! I knew enough to know not try that at least. Aaron Voisine breadwallet.com On Fri, Jul 18, 2014 at 11:56 PM, Gregory Maxwell wrot= e: > On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine wrote: >> Well, you could always create a transaction with a different signature >> hash, say, by changing something trivial like nLockTime, or changing >> the order of inputs or outputs. Is that what you're talking about? Or >> is there some sophistry I'm ignorant of having to do with the elliptic >> curve math in the signature itself? > > No, though thats true too. I was talking about the properties of the DSA = nonce: > > An attacker is not obligated to follow your protocol unless you can > prevent him. You can _say_ use derandomized DSA all you like, but he > can just not do so, there is no (reasonable) way to prove you're using > a particular nonce generation scheme without revealing the private key > in the process. The verifier cannot know the nonce or he can trivially > recover your private key thus he can't just repeat the computation > (well, plus if you're using RFC6979 the computation includes the > private key), so short of a very fancy ZKP (stuff at the forefront of > cryptographic/computer science) or precommiting to a nonce per public > key (e.g. single use public keys), you cannot control how a DSA nonce > was generated in the verifier in a way that would prevent equivalent > but not identical signatures. > > (I believe there was some P.O.S. altcoin that was vulnerable because > of precisely the above too=E2=80=94 thinking specifying a deterministic s= igner > would prevent someone from grinding signatures to improve their mining > odds... there are signature systems which are naturally > randomness-free: most hash based signatures and pairing short > signatures are two examples that come to mind... but not DSA, schnorr, > or any of their derivatives).