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?
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.
Discussion
No replies yet.