E2EE DMs are coming to Nostr 🔒

After being nerd sniped by hearing nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 mention OTR for the millionth time on the Bitcoin Review podcast, I spent the last few weeks digging into OTR, the Signal protocol, and a grab-bag of other cryptography.

The end result is that I (am pretty sure at least) that I found a way to do E2EE (end-to-end encrypted) DMs on Nostr in a way that is both forward and post-compromise secure AND doesn't require any centralized servers.

Demo video: https://share.cleanshot.com/nMKk6cn0

Live demo app: https://drdm-demo.vercel.app

And finally, the NIP (for those of you with bikes in need of a shed): https://github.com/nostr-protocol/nips/pull/1206

Huge thanks to nostr:npub1klkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qulx3vt and nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft for the chats while I worked out the details.

Reply to this note

Please Login to reply.

Discussion

Wow, I wouldn't have expected a working prototype already, that's insane, massive progress, thanks a lot!

Honestly, I probably would have gone in circles for way longer if we hadn't talked through everything we did a few weeks back. 🙏

"speaking to the right people will safe you years of work"

One of the great lessons of SEC01

💯💯

JeffG where the G stands for Genius.

I don’t understand. Bullish.

Me about everything technical

Nice encryption you have there

CRYPTOLICENSE AND REGISTRATION PLEASE

🤣

😬

This is great and also makes me think of the xkcd standards comic. RIP NIP-44 and gift wrapped DMs?

It actually uses both. 😅

Oh wow. I just finished the video and I fully understand. This is even better. Thank you.

I’m really hoping someone doesn’t find some fatal flaw I somehow missed. 🙈

It would be okay if someone did. We want this to be as robust as possible so we can finally have a universally adopted DM spec.

🫂

I’d like to hear more about the version that syncs messages between user devices. I know it’s out of the scope of this NIP, but I wonder if that should be included before everyone rushes to implement this.

It seems fundamental and is a feature NIP-04 provided.

Group chats are an entirely different problem that can be addressed later. Afterall, Nostr never had group chats in the first place.

Thank you for doing this. What a blessing

oh fuck you’re gonna make me implement gift wraps

🔥

Nostr's DM is the most concerning and most troublesome issue. The good news is that the developers of Nostr are constantly upgrading the version of DM until it is suitable for Nostr's decentralization while ensuring the privacy of metadata and information.Respect 🫡

We are on the verge of better DMs for Nostr. This method has the potential to be widely adopted by all major clients, and not just a couple of them. Bullish.

nostr:nevent1qqswlyjp5x62407g5pztyhyhr22skkx53vfz7zx68y6muqvmd5pqr4qpz9mhxue69uhkummnw3ezuamfdejj7q3qzuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsxpqqqqqqzwh3pua

YOU ROCK!

Thank you.

Now do group chats 😬

It’s possible. Basically the same thing but a bit more complicated. You do lose some of the security properties though with groups.

But that’s the same with telegram, signal and all the others too.

https://mov.im already has it and it's opensource.

It would be nice adding Nostr to this list https://omemo.top

What security is lost by using OMEMO exactly?

Nostr isn’t XMPP.

Neither is irssi (it's IRC, yet it supports OMEMO encryption).

OMEMO is an encryption protocol, not a messaging protocol.

what server will Nostr use?

Relays are the server!

Let's fkn go! I am not a crypto expert, so I was experimenting with mutual cryptography (sharing a key that is never put online, anywhere, ever) in a package with a shared npub/nsec so all DMs would be hidden in just a single keypair with the actual message in .content being encrypted by the mutual key and resolving to regular DM messages.

But this is MUCH MUUUUUUCH better. Thank you for making it!

now THATS progress 👏 bravo!

This is amazing.

However, why using anything other than OMEMO? It's already supported by browser clients, like https://mov.im

https://omemo.top

nevent1qvzqqqqqqypzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqswlyjp5x62407g5pztyhyhr22skkx53vfz7zx68y6muqvmd5pqr4q4t2px9

It’s extremely similar. Same basic concept adapted to Nostr.

Wow it's amazing! Can't wait to use it! ⚡🙏

looking forward to DMs no longer being a pariah use case for this protocol

still need to have NIP-42 tho goddammit!!!!!!!

What do you mean? Do you not like Nip-42 for some reason?

the opposite! stil-waiting-skeleton.jpg meme on nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr adding it, also nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr both of them have said they will get it done but are not putting it on priority

Ahh right. Yeah, this should be another kick to get clients to add it.

yeah, i am gonna be stoked to see this get done

also, if there isn't already someone building a #golang implementation i know my way around ECDH, have a reasonable grasp of double ratchet and did plenty of fun stuff with multi-layered encryption in my previous work last year with indranet

indranet is only on hiatus tho... we hit up against a serious scaling problem with the routing that it needs to be possible for clients to create routes that nodes along the path may not know about... just here's the damn IP send it goddammit... not possible with the straight libp2p i built off... so i need to build a better p2p DHT scheme, simpler, probably, something more like bitcoin's p2p than bittorrent maybe

🙏💜🫂👏🏻👑

if it doesn't use specific relays for coordination it's not going to work, are you broadcasting these events?

Why?

🔥🔥🔥

Fwiw, otr doesn't require servers. Just 2 clients, i.e. endpoints, and a pair of long-term keys. The rest is handled by the protocol.

To be more accurare: you would need some "prework" to be available only if you cannot afford to wait for the protocol to establish the secure session. So if someone you never spoke to, isn't online, but you need to send a message *immediately*, then yes, you would need to access that "prework", e.g. a profile somewhere, for it to be the initial input for establishing the secure session immediately.

ftw

ftw

This is fucking awesome!

Thank you sir.

nostr:npub1sy70twa0vadtk8hjs6wt2hmfszduj04tw78ccs3ktmr9u99mfmqsj62srx

This looks fucking cool too!

Permissioned platforms will never be able to compete with this. 🔥🔥🔥

💯💯

Graaandeee!!!

Looks very interesting, not that I can really asses/check for flaws, but I understand what you're explaining in the video

So do us library devs stop building till y'all figure this DM encryption thing out lmao. I'm never going to have working DMs :(

😬 Sorry. But we need solid DMs. None of your work will be wasted. The new nip requires 44 and 59 to function.

Your research is appreciated, just poking fun! That's actually very encouraging to hear, it's more difficult than you think finding working cryptography primitive libraries with stable ABIs without writing sha256 all over again.

super exited

excited*

I don’t understand shit about nothing, but I really like this. Can’t wait to try it out 🤙🏼 Awesome work!

Fucking baller!

Do I understand this correctly that there is only vulnerability to eavesdropping in realtime - so since the diffie-helmann ratchet isn't created on every msg / until a response, the the window for eavesdropping is as long as the time it will take to receive that response. Therefore in any context / setup where the individual must consider there is a chance of realtime eavesdropping, the overall risk factor is affected by the probability the needed response will come quickly? Or is it just necessary that the client implement different ratchet procedure (diffie-helmann on every msg) to detach risk profile from responsetime?

If your private key gets leaked can they drain your hot wallets by zapping themselves?

🙏🫂🙏👊

lol

Damn this is exciting. Thank you for your work

Yo. Sorry but as I understand it nostr DM are already encrypted right ? So what are we talking about here, hiding metadas thes kind of things ?

Thanks

Yes. But there are varying levels of encryption and metadata protection.

NIP-04 encrypts the content in a fairly naive way and does nothing to hide metadata.

NIP-44 encrypts the content in a much more robust way but does nothing to hide metadata.

NIP-59 is about "gift-wrapping" events, which uses nip-44 encryption but also hides metadata by nesting the real events in other events.

NIP-17 combines NIP-44 and NIP-59 to get encrypted DMs that hide most metadata but don't give you any forward or post-compromise secrecy (meaning, if you lose your keys, the attacker can decrypt all your past and future messages).

NIP-104 (double ratchet) Uses a format very similar to NIP-17 but a completely different encryption scheme that uses two independent key derivation functions (ratchets) to generate encryption keys and give forward and post-compromise secrecy.

TBH, you can use any of them based on your use case. I think we've been building towards double ratchet for a while though. You also hear the double-ratchet scheme referred to as E2EE (end-to-end encrypted).

So basically what you are saying is that you are trying to apply OTR to nostr which is a bit like NIP-104 but better or different ?

NIP-104 is the new NIP I'm proposing to do the OTR like double ratchet.

Understood thank you for your time sir

does double ratchet use multiple pubkeys like gift wraps or only the user's regular pubkey?

It uses lots of keys. it does giftwraps but also uses ephemeral keys for generating new chain keys as part of the ratchet mechanism.

wow, this sounds amazing!!

Awesome 👏👏👏

sounds amazing.

I will need to watch it later

Great stuff JeffG!

I shyly suggest you booking NIP-144 and NIP-444 for the next incredible upgrades 😀

E-commerce with E2EE DM’s between buyer/seller may be the killer app.

No data leaks, no hacked 3rd parties, no selling your email to others who spam you, no worries.

Email and credit cards are work, lighting and nostr DM’s are easy, secure, and private.

💯

This plus being able to control and limit the visibility of the items/services in my storefront across different groups.

- selling chairs - all public

- renting my car - friends

- unlicensed stuff - group of closely vetted friends and family.

Basically encrypting my storefront to certain permission thresholds. Could be also good forba private price discrimination (heavy discount for the family, etc)

All of this stuff is basic web of trust! Amazing what Nostr enables.

Would be nice, but logistics is the weakest link.

I’ve been trying to think of startup ideas for private logistics or at least a blinded way to send packages around, but all of them have major trade offs (in speed or cost).

👀