search

haskell-crypto / cryptonite

lowlevel set of cryptographic primitives for haskell
Other
226 stars 139 forks source link

Add libsecp256k1 #295

Closed ysangkok closed 3 years ago

ysangkok commented 5 years ago

I am adding the whole libsecp256k1 and bindings to ECDH and RFC6979 with HMAC SHA-256.

Bindings to other functions could be added for more speedups, in a separate PR.

Please tell me what you think, I want to work with you to get this merged.

vincenthz commented 5 years ago

I'm not sure this is a good idea to bind that much C code inline in cryptonite, and it's also going to start conflicting with existing binding for example secp256k1-haskell as all the C library doesn't have the cryptonite_ prefix.

Is there a reason why using secp256k1-haskell is not preferable ?

ysangkok commented 5 years ago

I can change the prefix if you like. The reason I add it here is because Cryptonite says that it wants to include all kinds of crypto. Cacophony already depends on Cryptonite, and if ECDH with secp256k1 were supported, it could support the Lightning protocol, since that uses a variant of the Noise protocol with secp256k1. If you like, I can also remove all the parts that are not relevant to ECDH or rfc6979, but actually I was thinking of adding bindings the other parts of libsecp256k1 too. Many features that will be supported in secp256k1 are generally applicable, like RFC6979 with SHA-256, adaptor signatures with Schnorr, Musig or bulletproofs in libsecp256k1-zkp. I don't see why a curve having its own implementation warrents being in a different dependency. There are already much curve-specific C code. There is no reason why the cryptography used in Bitcoin cannot be used for other purposes, actually I find it advantagous because it has been vetted so thoroughly. (because of the economic incentive to find weaknesses in it)

When you say "using secp256k1-haskell", are you talking about using it from Cryptonite, or using it directly from whereever I would use Cryptonite?

ysangkok commented 5 years ago

Another approach would be to prune all functionality except RFC6979 and ECDH, this would result in much less C code.

Are none of my proposed solutions acceptable to you? In that case, would you be comfortable with accepting a naive RFC6979 implementation, and some patches to offer a compatible ECDH variant of the current one?

vincenthz commented 3 years ago

sorry this has been a long time, but I don't think it make sense to pull libsecp256k1 as is in cryptonite, specially now there's potentially formally proven crypto (the fiat-crypto project), that also target haskell that could be used to bootstrap a native experience