Subnostr

Is anyone working on a #Nostr to GPG bridge?

Now that we’ve solved private-key based identity, bridging to other key systems seems useful.

it wouldn't be that difficult, but adding the BIP-340 x-only signatures and x-only ECDH would be the main challenge, it should otherwise be the same as the p2556 elliptic curve

there was a definite, covert, active campaign to keep secp256k1 out of both ssh and gpg that me, personally, find very suspicious, and based on unsubstantiated assessments of the bitwise security of the secp256k1 group... which is quite ridiculous because it's practically the only elliptic curve in wide use that has such a small seed parameter for the curve group that it's impossible it could be backdoored

the same cannot be said about the Edwards twisted ed25519 curve, which is faster than ECDSA but schnorr is on par with it, so, yeah

nostr:nprofile1qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgnwaehxw309ac82unsd3jhqct89ejhxtcpz4mhxue69uhkummnw3ezummcw3ezuer9wchszxthwden5te0wfjkccte9eekummjwsh8xmmrd9skctcprpmhxue69uhhyetvv9ujuurvv438xarj9e3k7mf0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qqsqxefne258ydmfgm2wfl02fsdqgs0d5wx29kweg9amxcqxew4t7kqnc5q0m has been working on a C library that packages all the "cryptology" of bitcoin/nostr and that would be at least one spot to look for parts to create this functionality in GPG

Reply to this note

Please Login to reply.

Discussion

ChipTuner 1y ago

Could we require that Y coords get published with "certificates" so we could do normal signature verification?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yes, but also you can assume they are all even and signers just subtract the secret from the curve order to make a 32 byte even ecdsa key without needing to waste that extra byte in the messages

or you can extend the public key handling of gpg to jive with bip-340 x-only keys, that would be the easiest solution because it requires no change on the nostr side, and it's just antiquated that gpg doesn't do schnorr still, yet it does ed25519 (no offense to Edwards but Koblitz > Edwards IMO)

ChipTuner 1y ago

I was thinking strictly for the easiest way to add compatibility to existing GPG. Doesn't GPG support secp256k1?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

making the schnorr bip340 key into ecdsa pubkey is just adding 2 or 3 depending on the sign/oddness of the Y coordinate

it is not important for bip340 signatures what sign it is nor for the ECDH for encryption but ecdsa needs that bit to correctly validate a signature, and the signer must produce an ECDSA signature

according to BIP-340, the Y value that is elided is *supposed to be* even (2) but what i have observed is that it is not always, mainly because the check is not necessary for nostr protocol - or taproot/musig2 - if you use an ECDH function (relevant for GPG) that needs that Y bit then the wrongly assumed keys cannot generate valid secrets for the opposite side

so, the main thing that is required, i think, is that your nostr based keychain derive the ecdsa pubkey, and if it is odd (3 prefix) it should use the negated secret to perform signatures, then gpg can assume a 2 safely without modification or extra information

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

tl;dr: the signer must negate the key if it is odd, before doing ECDSA signatures or PGP ECDH key derivation (pgp uses ECDSA ECDH as part of the message header secrets for encrypting the actual message secret of the message)

ChipTuner 1y ago

My concern is that requires a fork of GPG. I don't like forking gnu apps XD or convincing the gray beards that it's desired to play nicely with our sandbox when they are never going to trust schnorr sigs. I'm over convincing legacy institutions.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

that's why i'm saying, assume the 2 prefix, and the signer should negate the secret to sign with ecdsa/derive ecdh, that is the smallest change set required

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

strictly speaking, a key generator for BIP-340 is supposed to negate the secret if it has a 3 - but it doesn't have to for nostr so many nsecs make odd ecdsa Y coordinates

ChipTuner 1y ago

Right I'm aware of that but how do we implement that where GPG supports signing and verifying using an secp256k1 key

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

oh, going the other way?

i've mentioned this before but not actually put it to a proposal

needs a new tag, i think "s" makes sense, and it would be formatted thus:

`["s","","secp256k1-ecdsa"]`

or something like that

the PGP can't really sign correctly for nostr authentication though, that's a whole other can of worms

i've talked about this idea before, but the thing is that verifiers have to support the signature verification so it really needs to be added to a NIP if you want to enable it to replace the BIP-340 signatures outright

i'm pretty sure adding a new signature algorithm isn't that hard to do for gpg... but i don't know what's involved exactly

i would think it shouldn't be that much harder than creating helpers for git

but anyway, you are the C expert, this is part of the reason why i never got into C programming... it is a very brittle and hard to extend language

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

having said that, it would be trivial to enable a relay to accept ecdsa signatures if there was a conventional signal that was the case... maybe better to just do "S" tag with a signature identifier - `curve-signature` i wouldn't bother messing with the hash function though, there's nothing wrong with SHA256

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

that brings up the other point too... the event has to be canonical form, the array with the positional fields, and zero first value, i think you can make pgp use SHA256, but that's the event ID source so that is how it has to be presented to pgp

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

to be perfectly honest, i think it would be simpler to simply make a standard C language pgp-like program that has the json hash generation, BIP340 signatures/ecdh and simply make it a drop-in for all the required args so you can literally just give it the secret key in the same form as would be for ECDSA but it recognises the json, rearranges that, hashes it and then signs on that hash and then generates the wire format output

semisol 1y ago

signatures are incompatible

keys can be used with the secp256k1 curve as is, as there are only two y coordinates and the key for both can be computed

jimbocoin 🃏 1y ago

I guess I should specify that I’m open to a different approach wherein using Nostr keys and some other key (gpg) a user can mutually sign.

That is, the user uses Nostr to sign a message declaring ownership of the gpg key, and the gpg key to declare ownership of the Nostr identity. Only someone with both keys could do this.

Curious if anyone has written up a specification for this approach, which would allow Nostr follows to bridge into web-of-trust for, say, binary attestation with gpg.

So for example. I recently got Qubes OS. Downloaded the iso through BitTorrent, then validated against their signing key, which I had to download and install separately.

Could this process be made simpler by having a Qubes OS nostr identity which co-signed the gpg key proof? Then as long as I follow someone who transitory follows Qubes OS on Nostr, a UI could show me the trust graph and I could approve it (or something).

semisol 1y ago

There is already a spec for that with linked identities

jimbocoin 🃏 1y ago

Link to spec?