Hacker News Reader

Comment by gizmo686 | Hacker News Reader

The idea of masking real content with gibberish always seems hacky to me, and in security hacky is not a good idea. While I suspect you might be able to make it work, I think a better solution is to go to more of a bitcoin approach.

Essentially, set up a new block-chain that allows transactions to contain 'large' messages (IE. large enough for long plaintext, but probably not enough to embed videos). Then, when you want to send a message, encrypt it using the intended recipients public key, then publish the cipher-text to the blockchain.

View on HN

I don' t have a list of urls right now, but papers on the lack of anonymity of bitcoin and bitmessage are not hard to find. It is a very difficult problem against NSA level attackers. Masking when content is being exchanged by exchanging something on a fixed schedule seems like one of the few things that can be done to at least mask something.

Edit: OTOH, this this does just mean they attack one or both nodes if they care when content is being sent.

I still can't speak to bitmessage. but anonymity is not part of bitcoin's design goals.

Have you heard of bitmessage? It basically does what you suggest.

Bitmessage is essentially a torrent server where everyone gets a copy of everyone elses emails, so you get your email by downloading all emails.

Unfortunately in such a system, you have to download all emails, or request what you want in order to actual get the email you want.

The system either does not scale, or will leak information in order to remove the requirement of getting everyone elses emails.

Also, the government can collect -all- of the encrypted messages easily, and potentially eventually correlate who an anonymous id is based on their knowledge of who received messages on which day.

Basically, it sucks.

I haven't checked Bitmessage's protocals, but that it is not nessasary to identify the intended recipient. If you publish the ciphertext with no meta-data, then everyone can attempt to decrypt it. Only the intended recipient would succeed, but an ease dropper would not be able to identify who successfully decrypted the message. This raises an obvious scalability question, as you need to attempt to decrypt every message that is used in the network (in addition to simply downloading it which you have to do anyway). There are probably ways to mitigate this overhead without compromising security.

If you read the wikipedia entry is says that the destination id is required. I assume these must be created somehow and communicated to the sender before being able to receive anything.

So long as this is occurring, the way the scheme works, unless you download every message, it could be determined which id belongs to whom. Once you determine that it is easy to track originating packets to that destination since it is not an onion system.

Additionally, without side channel communication ( in person or posting that address somewhere publicly ) it is impossible to anonymously communicate to an intended recipient.

Reply on news.ycombinator.com