Could we require that Y coords get published with "certificates" so we could do normal signature verification?
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
Discussion
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)
I was thinking strictly for the easiest way to add compatibility to existing GPG. Doesn't GPG support secp256k1?
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
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)
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.
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
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
Right I'm aware of that but how do we implement that where GPG supports signing and verifying using an secp256k1 key
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","
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
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
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
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