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; 
MIME-Version: 1.0
In-Reply-To: <CAAS2fgQGF2d98ciMKkE70bqy01mANPhDtamYroeHOZrfML7rMQ@mail.gmail.com>
References: <CAPg+sBiTURdRAZbyk3guF5YzAAQebo8yY_TuXHUKYDEdLjDUdQ@mail.gmail.com>
	<CANEZrP3fA3gZ5u6yViBZpdTYxyFvZT=uOTDEnL797OueXf-16g@mail.gmail.com>
	<CA+s+GJAd00ba7SzoUYeGvTOoHRiysXtYmx4Cnq8xQLXZx_VwyQ@mail.gmail.com>
	<CACq0ZD6BmTB_jwE9L0_zrWgVckb=LFL61fow1kuTSnjurbsq9A@mail.gmail.com>
	<CAAS2fgSwzx7M9NLjoOgfAgQT2cHmUWYD8hBmwHRRhgG9UgmmhA@mail.gmail.com>
	<CACq0ZD4GwDZbEK4oE_BJxN-nDTb_4+hhDFZ0T7xGAi8v3G349A@mail.gmail.com>
	<CAAS2fgQGF2d98ciMKkE70bqy01mANPhDtamYroeHOZrfML7rMQ@mail.gmail.com>
Date: Sat, 19 Jul 2014 12:08:13 -0700
Message-ID: <CACq0ZD73OsGjZgVnvW_vqabwpaXon3=XN30JVXTMimH1-JtWDA@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Small update to BIP 62
Precedence: list

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 <gmaxwell@gmail.com> wrot=
e:
> On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine <voisine@gmail.com> 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).