search

nostr-protocol / nips

Nostr Implementation Possibilities
2.41k stars 585 forks source link

NIP-04 considered harmful #107

Open adiabat opened 1 year ago

adiabat commented 1 year ago

Hi - just nostr seems promising, and end to end encrypted communication is a very important part of it, but the NIP-04 spec as written should not be implemented.

There is another issue here: https://github.com/nostr-protocol/nips/issues/72 pointing out the non-uniform AES key. That issue has been closed but probably shouldn't be -- the spec still has the unhashed / truncated result of the DH as the AES key.

Another, I think more severe problem is that protocol as described uses aes-256-cbc with no message authentication. This means that messages can be undetectably altered in transit. Anyone relaying the message can change the message, and the receiver can't tell that it was changed. I would remove NIP-04 before people start trying to use it.

There are other encryption protocols that are used with the secp256k1 keys used in nostr that could be adapted for direct messages, such as BIP324 (https://github.com/bitcoin/bips/pull/1378) or lightning's bolt 8 (https://github.com/lightning/bolts/blob/master/08-transport.md). There are also ratcheting protocols which have forward secrecy like the one used by signal, but those have other trade-offs.

The BIP324 and bolt 8 protocols aren't for discrete messages; they are for encrypted & authenticated communication channels. That means it doesn't directly replace NIP-04; the bolt 4 (https://github.com/lightning/bolts/blob/master/04-onion-routing.md) onion messages would be a closer fit. But encrypted transport between nodes is also important.

The code from BIP324 and LN is available in different languages and open licenses so I think that's the best bet for getting some code that's been used and tested.

paulmillr commented 1 year ago

then we can make an NIP for the "generic encrypted message" layer, and then mention, in there, that group chat and other encrypted systems should, ideally, use this instead.

I don't think it's possible with nostr, a public tool.

earonesty commented 1 year ago

wut? of course it is. you can use the blinded encrypted direct send as an invitation, and then all the members have the privkey of the group, and can chat. you can revoke by rolling a new group and sending a message indicating revocation. this is how NIP38 works

paulmillr commented 1 year ago

No, not really. Secure messaging is a complicated problem. Nostr will always leak metadata. There is no way to prevent metadata leakage.

earonesty commented 1 year ago

"leaking metadata" is by design. nostr is "encrypted storage of group information". not "encrypted messaging". forward secrecy is meaningless when you want to be able to load up a new client and see your old messages. "leaking metadata" is meaningless in that context. also, nostr leaks very little if we use a scheme like above. lets list what's leaked:

paulmillr commented 1 year ago

IPs and sender machine information are always leaked.

earonesty commented 1 year ago

that's a separate problem, imo. sender can use tor or similar. that data is leaked in other systems too. no guarantee that signal or telgram servers discard ip's. perfect is the enemy of the good here. we need to make solid building blocks and fix the base layer instead of continually throwing our hands up and saying it's hard. we've done good work here. lets make incremental progress, draw up an NIP and move on to the next problem. NJ will always beat MIT in the end.

paulmillr commented 1 year ago

Can we move towards a discussion to wrap up our concrete proposals? We're getting close, but there are a few points i'd like to clarify. It is not comfortable to discuss it in the issue with 107 comments.

https://github.com/nostr-protocol/nips/discussions/570

Can the current issue be closed-down?

earonesty commented 1 year ago

yes, lets!

earonesty commented 1 year ago

proposal from discussion. https://github.com/nostr-protocol/nips/pull/572/files

it's not like we "rolled our own crypto", we just forgot to hash and salt the key.

paulmillr commented 1 year ago

I have opened pull request for (allegedly) NIP-44 Encrypted Direct Message (Versioned): https://github.com/nostr-protocol/nips/pull/574

It uses versioning, XChaCha20 and hashed shared secret. Algorithm choice rationale is described in the pull request. New Versioning feature explicitly requires non-compatible versions to throw user-visible errors.

AES-GCM is NOT used.

Please take a look at it! Any comments are welcome.

paulmillr commented 1 year ago

Opened a discussion about SimpleX integration in https://github.com/nostr-protocol/nips/discussions/658

@fiatjaf could we close this issue?

staab commented 1 year ago

If you guys don't mind, I'd like to hijack this issue to continue the conversation about NIP-44 and downstream use cases (wrapping, DMs, chat, groups).

I've put together a survey of all the proposals and implementations of new-style encrypted messaging here. The goal is to decouple different use cases and create a solid foundation for cryptography, wrapping, and key-rotation that can be used in different configurations as we work on nailing down the UX of various features. The gist is open to comments and corrections.

@paulmillr @earonesty @v0l @vitorpamplona

References (for auto-backlinking):

ferantivero commented 10 months ago

It is probably better to make a parallel protocol that reuses Nostr's key aspects but optimized for direct communication. It could be basically the same relay infrastructure, but the event format would be an encrypted binary blob that only the receiver would be able to read, relays would be programmed to not leak anything except to the intended receiver, senders would not be identifiable at all and receivers would only be identifiable by a temporary decoy id.

@fiatjaf if I am not mistaken you recently exposed once again that this should be a different protocol rather than just an innovative NIP (i.e. NIP-44 v\<next>), so any desire to share: Why?

jb55 commented 10 months ago

On Tue, Jan 16, 2024 at 01:41:08PM -0800, Fernando Antivero wrote:

It is probably better to make a parallel protocol that reuses Nostr's key aspects but optimized for direct communication. It could be basically the same relay infrastructure, but the event format would be an encrypted binary blob that only the receiver would be able to read, relays would be programmed to not leak anything except to the intended receiver, senders would not be identifiable at all and receivers would only be identifiable by a temporary decoy id.

@fiatjaf if I am not mistaken you recently exposed once again that this should be a different protocol rather than just a innovative NIP (i.e. NIP-44 v\<next>), so any desire to share: Why?

fwiw I've been rallying crying for this as well. We just need a relay extension that adds specific features for private dms that don't leak metadata. We don't have the right primitives to express private DMs on vanilla-nostr unless you really hack it with giftwraps. nip-44 is still useful for the encryption stuff of course.