White Noise – secure and private messenger(whitenoise.chat)
whitenoise.chat
White Noise – secure and private messenger
https://www.whitenoise.chat/
50 comments
There was a project called Bitmessage which solved this problem by not having a recipient field. Your client would just try to decrypt everything, and when it succeeds, that means the message is for you.
The then immediate issue is routing becomes very inefficient since every node now needs to receive and attempt to decrypt every single message. Which they solved by having channels to split up the network and only require decrypting of every message on the same channel as your address.
The then immediate issue is routing becomes very inefficient since every node now needs to receive and attempt to decrypt every single message. Which they solved by having channels to split up the network and only require decrypting of every message on the same channel as your address.
Can an adversary detect who's sending a message, though? If they can observe 2 parties alternately sending messages into the network, they can probably assume these 2 parties are talking to each other.
The next step would be nodes sending random fake messages into the network at random intervals, to obfuscate who's talking to whom.
The next step would be nodes sending random fake messages into the network at random intervals, to obfuscate who's talking to whom.
If you controlled almost the entire network you could see where a message showed up first, but you wouldn't know where it was going. And since the app was mostly desktop only and kind of slow to deliver it would be used more like email where it could be hours before you see a response.
So maybe kinda but you don't have a lot to work on. And nodes don't have persistent IDs so if they were on a VPN, CGNat, dynamic IP, you'd have a hard time tracking them over time.
So maybe kinda but you don't have a lot to work on. And nodes don't have persistent IDs so if they were on a VPN, CGNat, dynamic IP, you'd have a hard time tracking them over time.
That sounds easy to DoS.
You're right, which is why they used Proof of Work as a requirement of sending a message. Problem is it made sending messages on mobile kind of bad since any PoW which would stop a desktop GPU from spamming is too much for a phone SoC.
That article reeks of AI generation. The "author" also uses an AI generated profile picture. I struggle to trust anything this page says.
It's a sentiment that's spread for years and I first heard it on Mastodon, but don't have a link to it in my history.
What I posted is just the first link I found on DDG that talks about it.
What I posted is just the first link I found on DDG that talks about it.
This criticism of Nostr is quite outdated.
I haven't looked into the White Noise code, but Gift Wrapping is just one way this issue was solved a long time ago: https://nips.nostr.com/59
I haven't looked into the White Noise code, but Gift Wrapping is just one way this issue was solved a long time ago: https://nips.nostr.com/59
How does gift wrapping address what GP brought up? I read through and AFAICT it obscures explicit metadata in the message, but not external stuff such as source/dest ip that logging any shared relay could give you.
AFAIK the only real ways to get metadata privacy are onion routing (increase the chance of a non-compromised node) and N-anonymity (decrease the value of a discovered connection).
AFAIK the only real ways to get metadata privacy are onion routing (increase the chance of a non-compromised node) and N-anonymity (decrease the value of a discovered connection).
As for nostr layer privacy, the giftwrap is written by an anonymous key, but sent to a person's public key. So you know they received something, but you don't know who from.
IP layer privacy is left to a lower layer. VPN or Tor or whatever. Trying to re-implement onion or garlic routing in nostr is IMHO not a great idea. Why tie such functionality together in the same layer?
IP layer privacy is left to a lower layer. VPN or Tor or whatever. Trying to re-implement onion or garlic routing in nostr is IMHO not a great idea. Why tie such functionality together in the same layer?
(fwiw, I'm not the creator of this, but am a casual user of Nostr...)
tl;dr: the answer you're looking for is probably in the explainer doc [1].
At its core, Nostr is simple: it's "just" JSON over WebSockets. But there are dozens of optional proposals to add additional functionality. And a few of those proposals are related to encrypted DMs, specifically, NIP-04 [2], and NIP-17 [3]. Most of the online criticism of encrypted DMs on Nostr is about NIP-04 (which is why it's deprecated.)
White Noise is using a different encryption standard: MLS (Messaging Layer Security) [4]. They explicitly say in their docs: "White Noise is an implementation of the NIP-EE spec." [5]. The NIP-EE proposal itself is on GitHub [6]. The explainer doc [1] I first mentioned is linked to from the proposal [6].
This is all to say: given all the links I posted here, an AI chatbot could probably give you a better answer using the prompt: "How is NIP-EE (Messaging Layer Security for Nostr) different or better than NIP-04 or NIP-17?"
(I'm a little surprised that wasn't already in the FAQ for the project.)
tl;dr: the answer you're looking for is probably in the explainer doc [1].
At its core, Nostr is simple: it's "just" JSON over WebSockets. But there are dozens of optional proposals to add additional functionality. And a few of those proposals are related to encrypted DMs, specifically, NIP-04 [2], and NIP-17 [3]. Most of the online criticism of encrypted DMs on Nostr is about NIP-04 (which is why it's deprecated.)
White Noise is using a different encryption standard: MLS (Messaging Layer Security) [4]. They explicitly say in their docs: "White Noise is an implementation of the NIP-EE spec." [5]. The NIP-EE proposal itself is on GitHub [6]. The explainer doc [1] I first mentioned is linked to from the proposal [6].
This is all to say: given all the links I posted here, an AI chatbot could probably give you a better answer using the prompt: "How is NIP-EE (Messaging Layer Security for Nostr) different or better than NIP-04 or NIP-17?"
(I'm a little surprised that wasn't already in the FAQ for the project.)
[1]: https://github.com/nostr-protocol/nips/blob/001c516f7294308143515a494a35213fc45978df/EE.md
[2]: https://github.com/nostr-protocol/nips/blob/master/04.md
[3]: https://github.com/nostr-protocol/nips/blob/master/17.md
[4]: https://www.rfc-editor.org/rfc/rfc9420.html
[5]: https://github.com/parres-hq/whitenoise?tab=readme-ov-file#the-spec
[6]: https://github.com/nostr-protocol/nips/pull/1427Thanks for the detailed post with citations, I'll have to give them a look
So you wouldn't call Signal private, right? Just wanted consistency.
Signal has sealed sender. So you can tell that a phone number is a signal user but not who they message.
How does sealed sender work? I couldn't find details. The explanations I saw seemed to start from the assumption that Signal doesn't keep logs of messages moving through their system.
https://signal.org/blog/sealed-sender/
The short version is: Traditionally, Bob needed to “log in” to be able to send a message to Alice’s inbox.
With Sealed Sender, Alice gives Bob a credential that allows him to message her from now on without logging in.
Only Alice can tell that the message she received is from Bob.
There’s some subtlety around bootstrapping these credentials and preventing abuse which means that not every message can be sent as Sealed Sender, but the vast majority are. Read the blog post for the authoritative explanation.
There’s an option in the app settings to make visible which of your messages were sent without identifying your client to the server if you’re curious.
The short version is: Traditionally, Bob needed to “log in” to be able to send a message to Alice’s inbox.
With Sealed Sender, Alice gives Bob a credential that allows him to message her from now on without logging in.
Only Alice can tell that the message she received is from Bob.
There’s some subtlety around bootstrapping these credentials and preventing abuse which means that not every message can be sent as Sealed Sender, but the vast majority are. Read the blog post for the authoritative explanation.
There’s an option in the app settings to make visible which of your messages were sent without identifying your client to the server if you’re curious.
Ah thanks, okay, I'm not sure I'm missing anything in that case.
But if so, doesn't signal still know that alice and bob are communicating because it's transferring messages between them? Even if Bob doesn't log in IP B is still sending payloads that eventually get delivered to IP A, and if law enforcement later asks signal for logs they could be correlated.
But if so, doesn't signal still know that alice and bob are communicating because it's transferring messages between them? Even if Bob doesn't log in IP B is still sending payloads that eventually get delivered to IP A, and if law enforcement later asks signal for logs they could be correlated.
Indeed, at some point in time a byte has to move from point A to point B, and unless you random VPN to a different location the source and destination IPs can be identified.
Even if they can't read it, a hostile government won't care.
There is only so much you can do against a really determined adversary thats well funded. I just want a Signal that doesn't tie everything back to a phone number.
Even if they can't read it, a hostile government won't care.
There is only so much you can do against a really determined adversary thats well funded. I just want a Signal that doesn't tie everything back to a phone number.
What messages can’t be sent as sealed sender?
I arrange to tell Alice in an encrypted chat that I will be doing a drop on X url after Y time and to watch it.
Alice comes picks up the drop. Done.
PS: This is another great use for cryptocurrency. When you don’t want to use account-based charging, then you allow anyone to prepay for the resources with crypto.
I arrange to tell Alice in an encrypted chat that I will be doing a drop on X url after Y time and to watch it.
Alice comes picks up the drop. Done.
PS: This is another great use for cryptocurrency. When you don’t want to use account-based charging, then you allow anyone to prepay for the resources with crypto.
For example, before you have Alice’s sealed sender authorization credential, you cannot send Alice Sealed Sender.
This happens upon initial contact and after Alice revokes her credential (which can happens if she blocks someone).
This happens upon initial contact and after Alice revokes her credential (which can happens if she blocks someone).
No, if you're doing something sensitive that can get you or other people arrested, locked up, hurt or killed, you should not be using Signal for that. You should reconsider using a phone or computer at all. If you must, you must be desperate and I pity the situation you must be in, and I hope you really understand what your risk profile is, what technology can address actually it, and if that technology actually exists.
States can use metadata from Signal and ISPs to confirm that party A was in contact with party B and at what times, for example, in charges of criminal conspiracy. If one device on any end of the chats is compromised or confiscated, chats and identities are exposed. Once both devices are confiscated, messages are decrypted on both ends of the Signal app and authorities can grab the message content they used the metadata to get a warrant/subpoena/order for.
Similarly, Signal can be gag ordered to keep a record of phone numbers linked to identities if it already doesn't exist in their implementation. Signal and/or Google/Apple/ISPs/carriers can be compelled to follow wiretap laws and collect more data on specific users, push special updates to them, etc.
It's an app that forces the use of cell phone numbers linked to real identities in order to use it, clients have servers hardcoded, clients make direct connections to servers, etc. Just the first fact alone should be a red flag if your well-being depends on privacy.
States can use metadata from Signal and ISPs to confirm that party A was in contact with party B and at what times, for example, in charges of criminal conspiracy. If one device on any end of the chats is compromised or confiscated, chats and identities are exposed. Once both devices are confiscated, messages are decrypted on both ends of the Signal app and authorities can grab the message content they used the metadata to get a warrant/subpoena/order for.
Similarly, Signal can be gag ordered to keep a record of phone numbers linked to identities if it already doesn't exist in their implementation. Signal and/or Google/Apple/ISPs/carriers can be compelled to follow wiretap laws and collect more data on specific users, push special updates to them, etc.
It's an app that forces the use of cell phone numbers linked to real identities in order to use it, clients have servers hardcoded, clients make direct connections to servers, etc. Just the first fact alone should be a red flag if your well-being depends on privacy.
Lol, nostr metadata leak was a criticism of NIP-04 , which has long been considered obsolete NIP-17 messages addressed this long time ago, but it was not scalable to large groups. MLS solves this problem so we finally have, scalable, private, decentralized messeging on the internet, all these specs are public, the very fact that you did not understand this, means no one will be able to make you understand with a comment.
Thanks for your insight
Congratulations on the release!
As someone who used to be in the Secure Scuttlebutt community an now works on OpenMLS, I wonder how they (you?) deal with concurrency of Commit messages. I spent quite some time thinking about ways to detect and resolve forks, and the current iteration of MLS doesn't really have good answers here.
As someone who used to be in the Secure Scuttlebutt community an now works on OpenMLS, I wonder how they (you?) deal with concurrency of Commit messages. I spent quite some time thinking about ways to detect and resolve forks, and the current iteration of MLS doesn't really have good answers here.
I looked up the spec, and it seems like they just tiebreak on time and hash and throw away the losing commit:
https://github.com/nostr-protocol/nips/blob/001c516f72943081...
https://github.com/nostr-protocol/nips/blob/001c516f72943081...
Huh, that would make it easy to provoke forks by just backdating a second commit.
As much as I love the idea of these secure messaging apps, until I see how a company responds to government intimidation I am always wary of being too invested and trustworthy of the marketing.
i admit i havent looked at the app, but i assume is centrally run.
firstly: i think the only way secure p2p messaging can work is if its decentralised. no 3rd parties to communication, how this would be done i have no idea. maybe like email but without the server?
secondly: you'd need to ensure a secure os on each end that you can trust to not take screenshots and send to hq before transmission or after reception.
since its not possible to use the internet without a source ip. its almost provably insecure (in terms of privacy), no matter what protocols are dreamed up. a 3rd party will have to be trusted to distribute packets. and thats the weak point. (unless you force the source IP to be 0.0.0.0 or something before it goes out)
couldnt we just use dns to point to recipients, force zero the source ip and send udp packets directly?
what about pgp through a tor relay?
firstly: i think the only way secure p2p messaging can work is if its decentralised. no 3rd parties to communication, how this would be done i have no idea. maybe like email but without the server?
secondly: you'd need to ensure a secure os on each end that you can trust to not take screenshots and send to hq before transmission or after reception.
since its not possible to use the internet without a source ip. its almost provably insecure (in terms of privacy), no matter what protocols are dreamed up. a 3rd party will have to be trusted to distribute packets. and thats the weak point. (unless you force the source IP to be 0.0.0.0 or something before it goes out)
couldnt we just use dns to point to recipients, force zero the source ip and send udp packets directly?
what about pgp through a tor relay?
As I understand it, it's just a nostr client, so it uses nostr's decentralized network of relays.
> i admit i havent looked at the app, but i assume is centrally run.
I don't mean to be rude, but why comment then? Your core premise was incorrect, which could have been resolved within 5 seconds of reading the headings on the page linked.
I don't mean to be rude, but why comment then? Your core premise was incorrect, which could have been resolved within 5 seconds of reading the headings on the page linked.
It's not centrally run, that's the whole point.
This is decentralised as it runs on Nostr.
Nostr can run over TOR.
Nostr can run over TOR.
Austria's goverment agreed on spying messengers for the public safety.
How does white noise protects itself from getting legally hacked?
White Noise is open source, and built on Nostr, a decentralised and open protocol.
Run your own fork if you don't trust this one.
Run your own fork if you don't trust this one.
Apparently it uses a new protocol called https://en.wikipedia.org/wiki/Messaging_Layer_Security
The file/image storage concept using whats called "Blossom server" needs to be explained publicly somewhere. I don't know anything about this concept of "storing private files on public servers" and it immediately screems at me as unsafe.
I've only been able to find this coverage on the Blossom thing: https://www.nobsbitcoin.com/blossom-intro/
I've only been able to find this coverage on the Blossom thing: https://www.nobsbitcoin.com/blossom-intro/
Looks super interesting. I am waiting for the App Store release since TestFlight is full. I like the idea of not requiring a phone number - the only thing makes Signal lose some points in my eyes... well, I guess if the company goes down that might be another reason for open protocols over apps.
How is this better than Session and how it compares?
https://arxiv.org/pdf/2002.04609
https://arxiv.org/pdf/2002.04609
Wow, Nostr is back in vogue on the all time highs?
interesting but still very alpha. It doesn't have any desktop/PC clients yet, but I assume it will?
Looks like a flutter app that can build for desktop Linux https://github.com/parres-hq/whitenoise_flutter .
I started my reply thinking it was still using Tauru but apparently things change fast!
I started my reply thinking it was still using Tauru but apparently things change fast!
Heads up that you have a typo - "Unscensorable"
title: secure and private
terms: we're not responsible
Software advertising itself as "A truly secure and private messenger" raises my skepticism. It might be truly secure. Its creators might believe it is and have zero doubt that they've made no errors and there are no flaws. Or it is neither and they want me to think it's those things. The only thing definite is that it claims to be truly secure.
Oh, look, another one!
How does White Noise address criticisms surrounding Nostr's implementation[1]:
> While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.
Even assuming if metadata is encrypted, does WN's implementation broadcast messages across public relays?
If you can map out social networks based on publicly available data, can tell if one user messages another, or correlate when messages were sent to/from whom, I would not call that private.
[1] https://ron.stoner.com/nostr_Security_and_Privacy/