Re: PR for playground

On Sat, Mar 25, 2017 at 3:41 PM, Manu Sporny <msporny@digitalbazaar.com>
wrote:
>
> What would you suggest we switch to that would simultaneously keep
> compatibility with the Bitcoin community while utilizing more modern
> signature schemes? This is new work, so we have a very good opportunity
> to change things at this point.
>

I would recommend Blockstream's secp256k1 Schnorr signature algorithm,
although unfortunately I don't think there are existing standards
describing it published through any sort of standards body.

Also, we've been interested in deploying Schnorr signatures for a while
> but lack the expertise to pick the right parameters for the Signature
> Suite... would you know enough about Schnorr to help us put together a
> Schnorr Signature Suite? (we can implement, we just need someone (you?)
> to check our math).


In all of my personal and professional work we are using EdDSA, which is a
Schnorr scheme and standardized in RFC 8032.

I am not particularly interested in doing any standards work around
secp256k1 until the preliminary RFC 8032-style legwork around the secp256k1
Schnorr signature scheme is in place. That said, I don't think there's
presently any effort underway to e.g. put together an informational RFC
about this scheme and publish it through the CFRG.

secp256k1 also has the disadvantage of a multitude of twist security and
off-curve point attacks when used in an ECDH context. I feel like using it
for signatures is a slippery slope towards using it for D-H and creating
schemes with attacks other implementations are automatically hardened
against per default. This is already happening with e.g. the Lightning
Network: they are attempting to shoehorn secp256k1 into the Noise protocol.

-- 
Tony Arcieri

Received on Saturday, 25 March 2017 22:56:11 UTC