Add nip44 v2

[staab]

No description provided.

[staab]

@paulmillr I ported everything from your repo to nostr-tools, just want to double check that it's ready for primetime. Ok to merge this?

[paulmillr]

wait until branch gets into main and it'll be good to go.

[staab]

This is up to date with @paulmillr's library and ready to merge

[paulmillr]

perhaps we should later publish nip44 pkg separately? thoughts?

[staab]

perhaps we should later publish nip44 pkg separately

I think this would be ideal for people who want small dependencies. nostr-tools is a good place to start, and could later include the standalone as a dependency

[paulmillr]

@staab offtopic, with regards to mac stuff: it wasn’t mentioned in audits, so there was nothing to fix. it’s just something i’ve mentioned in spec - we should keep the notice there for now.

[staab]

NOS-01-009 says:

In other words, not authenticating the nonce in the Encrypt-then-MAC scheme does not produce an authenticated encryption scheme, since the MAC tag is easily forgeable. While the NIP44 specification suffers from this vulnerability, the overall NOSTR protocol manages to prevent forgeries.

This seems to be fixed based on Encryption step 6, but the spec says:

Encrypt-then-mac-then-sign instead of encrypt-then-sign-then-mac: only events wrapped in NIP-01 signed envelope are currently accepted by nostr.

Just trying to understand here, which signature is this talking about? Is encrypt-then-sign-then-mac the standard because it authenticates the signature? Are nostr event signature self-authenticating?

[fiatjaf]

This package can be imported as import { v2 } from 'nostr-tools/nip44 without including any of the other things in the library.

[paulmillr]

@staab MAC should be the last step (after signature) because calculating and verifying mac is fast. If the message has been tampered with, it would be shown immediately.

We can't use MAC as last step, because then the whole thing would need to be a bunch of bytes instead of nicely formatted JSON. MAC is calculated over ciphertext, so we'll need to encrypt full event, and we can't do that - relays won't accept it.

Also there is no standard way. Everybody cooks something for their own goal. Our current way is good enough.