Skip to content

Latest commit

 

History

History
51 lines (32 loc) · 5.39 KB

secp256k1.md

File metadata and controls

51 lines (32 loc) · 5.39 KB
Raw

On using secp256k1 keys on ssb

Listing here a few links on this topic that i was reading up on.

ssb backlinks:

  • 'thoughts about adding new signing key types' (dominic) - pasted below
  • aljoscha's response is definately worth reading as they are somewhat critical and demand an explanation why this might be needed %6xDjaCQ1DIDvhIxqulZ6JsvxDp2LkYX/tvGWv1HL68g=.sha256
  • 'group multisig, & same-as but with people' (dominic) %D0tue88kaAOdZL7zuBbmRZUF70rBYDvnPZbE+Vd4jwQ=.sha25

Web:

Whats missing for me is a bit of imagination as to what implications this would have - what could you really do with this that you cant do right now?

and secondly, more importantly, do people want this? Asides from security/implementation concerns, what are the arguments against? I guess this could be seen as a sort of bridge between the scuttleverse and the crypto/blockchain world. Is that something people want?

thoughts about adding new signing key types (by Dominic)

Currently signing keys and identities are ed25519 keys as provided by the sodium library. there are two candidates for additional algorithms. secp256k1 as used in ethereum and bitcoin, and bls as will be used in dfinity which has interesting group signature properties. secp256k1 is just a marketing bullet point, although I'm sure it will be a big deal for some, but bls enables a really interesting new feature, however the awesome part is that bls group signatures are exactly the same as ordinary signatures, so if we implement support for ordinary bls signatures, we can implement the cool group stuff later.

Heres what I think needs to happen:

  • There are lots of modules that use ssb-ref to check whether some string is a ssb type (message, feed, blob). We could change all of those modules to call something on sbot... or we could just add a function to ssb-ref to accept additional extentions, something like ref.allowFeedExtention('secp256k1') and then @blah...blah.secp256k1 is now a valid feed id.
  • ssb-validate would need to be refactored out a bit so that you can have custom validation for different key types... or is it just the signature that needs to change?

That really seems quite simple.

Adjacent thought: perhaps the most embarrassing quirk in the signing format is that the hash takes the latin1 string of the json. This is a bug we inherited from old node.js which used 'binary' as the default string encoding for Hash.update(str) - although everything else used utf8! This is not actually a security problem, but it is silly. Also the max length is actually the utf8 count, not the byte length. If it was all the longest utf8 chars, a message could approach 32k!

What I'm thinking: the hash field, which is currently hard coded to "sha256" could be "utf8.sha256". If it's set to that, then the json is properly converted to a buffer, and then hash taken from that.

I'm thinking that '.utf8.' doesn't need to be part of the message id, just the hash field. utf8 doesn't matter until you actually get the message. Fixing this would actually be easier if you left it out of the hash.

  • when you generate the id of a hash: "utf8.sha256" message, convert it to utf8 properly. add code to do this, but continue creating messages with hash sha256, until you are sure everyone has the new code, and then switch to creating the new style messages. It's actually only a couple of line to change, but probably roll out the second part several months later.

btw, I think this isn't actually that difficult! It wouldn't be too complicated because it doesn't involve changing many parts of ssb, or any non-backwards compatible changes. I'd be very happy to advise someone who wanted to work on this!