Comment by TeMPOraL | Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Parent Full thread

Can someone explain how people are imagining protocols that do not to create / store metadata? This seems like something fundamentally impossible on a packet-switched network. After all, the data has a source and a destination, and goes through the infrastructure that's tappable (and in big part already tapped) by a state-level actor.

About the only thing that comes to my mind would be a digital equivalent to broadcasting a radio signal - a protocol, under which everyone receives all communication that's done over that protocol, but each person can only decrypt the part that's addressed to them directly. This would reduce the metadata to "who's broadcasting", without revealing the listener.

EDIT: Some back-of-the-napkin calculations on such broadcast protocol:

I took a look on my today's communication with my SO; rounding somewhat up, it would be ~100 messages of on average 50 characters, going in both directions. That gives, using 2 bytes for character and multiplying by 1.5 to account for protocol-related padding:

- 15000 bytes / user / day of a single conversation

Say this protocol has 1M user, that gives us:

(50 * 100 * 2 * 1.5 * 1000000) / (100010001000)

15 GB of data, spread over the whole day.

Seems manageable; especially if one would be to bucket it by e.g. hour by default, or less, if client is active and streaming data continously. Definitely a mobile bandwidth killer, though.

Look into verifiable shuffles, private information retrieval, and dining cryptographer networks.

By combining such techniques, it's possible to be much much better than naive broadcast, and also possible to use a client/server architecture so that low bandwidth endpoints can participate.

Have a look at systems such as Dissent and Riffle.

Thanks!

The Pynchon Gate solution boils down to private information retrieval: a number of distribution servers hold all blocks of information, and one then downloads from each server the XOR of certain blocks, such that XORing all blocks together yields the single block one is interested in.

And yes, mobile bandwidth is a killer.

One way your broadcast can be achieved is through a newsgroup. The best you can do is identify who is a member and who posts messages. But so long as the messages are encrypted, you can't tell who gets which message, since everyone in the newsgroup gets every message.

Still not perfectly metadata proof, but it carries a lot less metadata than peer-to-peer messages.

This has actually been done for decades with usenet. Every encrypted message winds up on a common list, and clients occasionally scan the list and see if they have a key to decrypt any new message. The metadata is then that you put a message there or that you asked for a list of new messages, though that can be reduced to "you used tor" which until such a message server became commonplace might be better.

In addition to all the systems and protocols mentioned by sibling posters, I'll add ricochet: https://ricochet.im/

It deals with the metadata leaks by using Tor. Every user runs a Tor hidden service, and the users identity is the address of that service. So no single point in the chain can tell who is talking to whom, without having to resort to a broadcast protocol like you describe.

A blockchain, of sorts...

Blockchains can do this. But they create relatively absurd systems of who can/can't send messages based on how much they've mined. Block chains are HORRIBLE for encrypted messaging. Since your message is PERMANENTLY part of the chain. So if a encryption is broken, or your password gets leaked. ANYONE can read your messages.

In most cases a DHT is far simpler. But naturally some nodes can be evil and log metadata. This is just a risk, but it also exists in block chains. Furthermore DHT's are lower latency then block-chains.

Blockchains aren't a magic fix all solution for network consistency/privacy models. Outside of currency transactions it is a horrible distributed system model.

This trend of proposing a blockchain to solve every problem is hilarious to me. Hammer/nail syndrome.

> Hammer/nail syndrome.

Blockchains address that problem too.

Bitcoin: the slowest, most expensive key/value store in history.

Also if you look at it in terms of the CAP Theorem:

Consistency (every read receives the most recent write or an error): Not True for block chains. All reads are dirty. The further back in time you go the higher the probability the read isn't dirty.

Availability (every request receives a response, without guarantee that it contains the most recent version of the information): 100% true.

Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures): Yes the system will continue to function. But you can suffer data loss when the partition is healed.

Sorta, but not. The only similarity would be that you download global state. But you could continously throw that state away if you don't need archiving of messages / long history.

Reply on news.ycombinator.com