You are reading content from Scuttlebutt
@miles

Merging ethereum secp256k1 and .ed25519 pub/private key

Please go ahead and tell me how wrong headed the following thinking is.

Basically I have an app where people can 'sign in' to their ssb (by demonstrating they control the .ed25519 private key) and then 'connect wallet' (to demonstrate they control the private key for, say, a particular ethereum public address).

This is creating a lot of confusing edge cases in the UX. What I think I want is for their to just be a single 'connect' button in the top right that - like a lot of de-fi apps - lets you use your own wallet if you have one (metamask or http://tor.us or something etc) and that creates an ssb-feed and a wallet for you if you don't.

  • One option is to have two keys and store an encrypted copy of the eth private key on the ssb chain (as a 'message to self').
  • A second option would be to algorithmically derive the ssb key/pair from an ethereum key/pair.
  • A third option (this is one place you get to tell me I'm crazy) would be to change all of our ssb stack so that the signing technology for ssb is .secp256k1 instead of .ed25519. Obviously this last option has the downside that it kicks us off of ssb main.

I think I prefer a mix of the first and second. But I don't know if it's even possible. So if someone has only got a pre-existing eth pub address we can always find (or create) create the corresponding ssb feed. But if someone comes into this with an ssb address and a pre-existing ethereum address they can publish a signed message to their feed demonstrating that they control the given ethereum address.

If you could reliably derive specific ssb keys from .secp256k1 key pairs then you would be able to go straight from those .crypto domains that people have these days to a specific ssb feed.

I dunno what do you think is the best way and what do you this would be possible?

//cc @Ari Rodriguez

@miles

So I've realised that while you can, in a predictable way work out a private key from another private key - for example to go from secp256k1 private key to an ed25519 private key. And while that means yes that you can derive a public/private key pair in a predictable way from a private key on a different chain .. what is not predictable in any way (and can't be) is the relationship between the two public keys.

That means if someone has the private key from one scheme they can in theory work out their own public/private key in the other scheme but someone external can't do that same thing. It also lowers security considerably, of course, to do that.

What exactly I can do with that info is not super clear to me ;-)

@cel

Apache Tuweni's SSB implementation supports secp256k1 feeds: https://github.com/apache/incubator-tuweni/blob/1743346742c2553817e23655df0a868bc02df6fa/scuttlebutt/src/main/java/org/apache/tuweni/scuttlebutt/SECP256K1PublicKeyIdentity.java
I don't know there is a public network using that.

@Zenna

Also, @sean and @adria0 might have some insights 🌸

@miles

Awesome thanks so much for this info @cel .. helpful, also @zelf . I think in the end its probably worth the hassle to be able to switch and change wallets and ssb feeds so perhaps its ok to have to like sign a message on your feed saying this is your public eth address (and vice versa in an eth transaction of some kind ?)

But that said could be handy and fun to be able to derive a 'default' ssb feed from an eth address in a predictable way. I wonder if that woudl be a specfication of some kind - could be a very short one pager - and if so where one would publish such a thing? Perhaps as an library beginning "ssb-xxx" or something?

Join Scuttlebutt now