[VikingCoder]

I think about trying to hide the metadata of who is communicating...

I wonder about a public stream of end-to-end encrypted messages.

Anyone can add a message to the stream.

Everyone reads all of the messages, and tries to decrypt all of them.

There are lots of variants to this, lots of ways to optimize it, probably lots of ways to implement it. But that's the core idea.

One variant is that what everyone downloads is just enough of a message metadata identifier to see if they're the intended recipient (something about Bloom Filters or PGP Signatures or something, I dunno). Then, if you are the intended recipient, you request the message contents itself. To obscure which messages were for you, you also download some very large number of other messages.

Something about microtransaction fees to pay for all of it. Maybe something about distributed ledger. Mumble, mumble. Maybe messages only live for X days or something.

Thoughts?

[derefr]

I believe there is a Usenet newsgroup, somewhere under alt.binaries, that's effectively a numbers station: it's just GPG-encrypted (but not signed) blobs with no titles. Anyone can post, anyone can listen, everyone has to download everything to figure out which things they can personally decrypt.

Sadly, googling related keywords doesn't seem to pull up the name of the newsgroup. I believe I read about it during a discussion on a Tor onion-site forum, on "why people keep getting caught doing illegal things on Tor, and what real OPSEC looks like."

[kstrauser]

I think you're thinking of Mixmaster: http://mixmaster.sourceforge.net/faq.shtml

[schoen]

More likely alt.anonymous.messages, as a Usenet newsgroup.

[schoen]

Historically the newsgroup meant for this purpose was alt.anonymous.messages. I'm not sure how much use it sees nowadays.

[cgb223]

If someone could find a link to this that would be incredible

[dranov]

That sounds a lot like BitMessage.

https://bitmessage.org/bitmessage.pdf

[swirepe]

I want to like bitmessage, but the last few times I looked it wasn't ready for prime-time. It is (was?) text-only, and I can't communicate without memes.

[lukeqsee]

> something about Bloom Filters or PGP Signatures or something, I dunno

Would this not defeat the purpose? Once an individual was tied to a unique piece of data, they'd be tied to all data in the stream.

I think such a system would definitely require guaranteed expiration (impossible?). Or some sort of rotating keys or the metadata piece would still be uniquely identifying.

I like this idea, as a concept, but I have no idea how it would actually work in real life with bad actors who can and would download all messages as they appear.

I wonder if there's some way to enforce expiration?

[VikingCoder]

rickycook responded to this part with a proposal, but I have my own take on some of it:

For the "tied to a unique piece of data," that's why I want Bob to download lots of messages, hiding the fact that the person at 14.85.101.86 is the user with the recipient ID of ntULzh2AeEgPH9bKxrn3gUL. Bob should also be rotating his IDs all the time. Maybe they're single-use. And if Bob wants Alice to be able to send him messages, then he (out of band) has to give her a huge list of IDs he'll be watching for, in sequence. If they arrive out of sequence, he knows to be supremely suspicious. Also, yes, I recognize that key management is THE PROBLEM. And I'm essentially inventing dead drops. But in my defense, I'm trying to come up with a way to make it easy for a lot of people to use, thus making it easier for everyone to hide in plain sight.

For the "guaranteed expiration," I am actively assuming bad actors would download and archive all messages. I only propose a limited number of days to lessen the storage costs.

For the rotating keys, as I understand it, there's Perfect Forward Secrecy, but it's very chatty (think of it as "online"). There's also a weaker form of Perfect Forward Secrecy (think of it as "offline"), but the risk is that if the communication if broken at any moment, then you can't recover from within that channel - meaning you'd need to go back to the person out of band, and restore communication. I'm probably summarizing it very poorly, but my mental model for it is roughly, at the end of every message I send you, I tell you what new password I will use when I send you the next message. It's actually way smarter than that, as I understand it, but that gives me enough of a mental model to work with it as a lay person.

[lukeqsee]

That makes a lot of sense to me.

I wonder if there's a cryptographically secure way to build a known "stream" of one-use tokens (addresses, if you will) based on known "public key." For metadata security, you only hand that public key out to those you trust.

Another thought is the ability to attempt decoding of every message (as you already alluded to). Encode some well-known bytes at the beginning of every message and see if your key can decode and match them. I'm not certain that protects against metadata snooping, since I don't understand the cryptography enough to know if that well-known text would always be the same for a target private key.

[clarkmoody]

> wonder if there's a cryptographically secure way to build a known "stream" of one-use tokens (addresses, if you will) based on known "public key."

This is what Bitcoin's BIP-47[1] does, but you can hand that "public key" to anyone[2]. The communication layer in this case is the Bitcoin blockchain.

[1] https://github.com/bitcoin/bips/blob/master/bip-0047.mediawi...

[2] https://paynym.is/

[brownbat]

> "guaranteed expiration"

You could make the database so noisy that there's a proof-of-storage cost on anything over a day old.

No guarantee, but something.

Adversaries would want to store only those messages of interest, but that would require breaking the oblivious transfer system.

[e12e]

I recall there was a proposal to use "chaffing" as an alternative to encryption; partly motivated by cryptographic signatures not being export controlled.

The basic idea is to split a message into very small pieces, say individual bytes or even bits. And the sign each bit, and iirc add a sequence number. Then you end up with a triple: sequence number, data, signature. Then you generate random triplets - and distribute the lot: the recipient orders by sequence number and keeps the bits with valid signatures.

I'm not sure about how ordering was achieved, but it was a clever idea.

Ah, here's Wired's coverage of the Ronald Rivest's idea in 98:

https://www.wired.com/1998/03/a-work-around-for-crypto-expor...

http://people.csail.mit.edu/rivest/pubs.html#Riv98a

[WorldMaker]

It's not far from how Secure Scuttlebutt (SSB) works: https://www.scuttlebutt.nz/

[blattimwind]

You basically create a hash table over public identities (bucket = pubkey % n) with an n chosen such that you get a bunch of unrelated people in each bucket but not so many that peers are overwhelmed by the message load on their bucket. Messages can be as simple as ES-SS-DH (basically Noise_X), same properties as e.g. PGP, i.e. no forward secrecy, no KCI resistance.

(This is patented, or at least pending)

[rickycook]

use hash(best block + sender id + recipient id + sequence number) then only the senders and receivers would be able to get the metadata... though recipient would need to “check” their whole contact list to pull the data... maybe this is where the bloom filter is?