Turn the underscore "_" thingies into variables ("err") and check them with
if err != nil {
panic(err)
}
So you can get better insight of what is actually failing.
Ok I need some more help, nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp0qqsdr8lv2sp86ztsv4yz9q9wz7ng6zk40u84cta8fcj08kamrek9f9gsq8th3 nostr:nprofile1qyvhwumn8ghj7un9d3shjtndd3jkkafwdahxc6twv5hszyrhwden5te0vyhxummn9ekx7mp0qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qqsyeqqz27jc32pgf8gynqtu90d2mxztykj94k0kmttxu37nk3lrktctmwr4h nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsqgpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5zr9h9m
I'm trying to decrypt an event using nip44, but I'm getting an "invalid hmac" warning on a valid payload (at least, according to the javascript implementation). Any hints? Code below.
func getNip44ConversationKey(sk string, pk string) []byte {
sk_bytes, _ := hex.DecodeString("02" + sk)
sk_obj := secp256k1.PrivKeyFromBytes(sk_bytes)
pk_bytes, _ := hex.DecodeString("02" + pk)
pk_obj, _ := secp256k1.ParsePubKey(pk_bytes)
return nip44.GenerateConversationKey(sk_obj, pk_obj)
}
func getNip44Rumor(sk string, wrap *nostr.Event) (*nostr.Event, error) {
wrap_key := getNip44ConversationKey(sk, wrap.PubKey)
nip44.Decrypt(wrap_key, wrap.Content) // invalid hmac
...
}
Discussion
i wrote a logging library so i could get that without using panics, runtime.Caller
it fails at the error that nostr:nprofile1qyfhwumn8ghj7mmxve3ksctfdch8qatz9uqsuamnwvaz7tmwdaejumr0dshszxthwden5te0dphkgmrzdajzumn0wd68yvfwvdhk6tcqyztuwzjyxe4x2dwpgken87tna2rdlhpd02va5cvvgrrywpddnr3jyhdw0my reports - the hmac is not being calculated correctly, more likely it's not being partitioned out of the raw bytes properly
come to think of it, the way it pulls that thing out is from the last 32 bytes of it but it doesn't require a multiple of anything, just a set of boundaries on the length
the whole NIP-44 is a clown show
The spec or the implementation?
the implementation
the spec is hard to read, i could try and write it based on the spec, i may yet, it's just not a high priority for me right now
i don't quit have my head wrapped around how it works but HMACs are annoying anyway, signatures do the same thing, and if the thing inside is signed and only the receiver can unpack that then there is security, and if the client can maintain the state of that, it could turn into a chain if you sent one or more future pubkeys to reply with, since the sender can identify a reply by that
but i think it's lower priority than getting everyone to fully support NIP-42 so the relays don't hand out these messages to anyone who hasn't proved they are the valid parties to the messages
Yeah, the HMAC thing was discussed in the audit. I don't fully understand why paul went that direction, but it does work as long as it's in an event
well i'm just telling you that that the go implementation is definitely divergent from the javascript version
and the javascript version seems to not be referred to by the NIP actually, i know your codebase has it but it's not pointed to by the NIP
there really should be an interop test for this, preferably one that uses randomly generated content so it's only repeatable if it's correct
The javascript version comes from paul miller's reference implementation, it's basically copied over into nostr-tools
of course i don't know it because javascript is the most abominable language ever invented, and i curse Griesemer, he only avoids hell by helping build Go
just because you don't handle errors doesn't mean nostr:nprofile1qyfhwumn8ghj7mmxve3ksctfdch8qatz9uqsuamnwvaz7tmwdaejumr0dshszxthwden5te0dphkgmrzdajzumn0wd68yvfwvdhk6tcqyztuwzjyxe4x2dwpgken87tna2rdlhpd02va5cvvgrrywpddnr3jyhdw0my didn't take the time to learn how to write go properly and understood teh principle of fail fast
there's a lot of dumbass things you do with your go code and i'm gonna keep grilling you about it until you fix it, fight me