Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I quickly read over the description of how this works. Nodes have a crypto identity which is used to establish trust between nodes, and storing data from another node gives you bandwidth "credit" to download other stuff. Transactions are cryptographically signed, but presumably this is safe because the contents of the files are unknown because they are encrypted. So how are they encrypted and then stored, and later retrieved? Content is hashed, the hash is used as the AES256 decryption key. Another hash is made of the encrypted data, and this is your lookup key. Only the crypto hash is needed to query a file, but it's useless to you unless you know the original data hash to serve as a decryption key.

I see two problems with this:

1. So, if both hashes of a file of illegal content becomes publicly known, like say on a website, I don't see how you avoid liability having it on your machine. It seems you can only avoid legal liability if someone stores stuff on your machine that is never intended to become publicly available. In any other case, the system has created a cryptographically provable trail between the data and your storage, which can be used to prosecute you.

2. The FBI can generate a SHA256 hash of every computer file of child pornography it has ever collected, and immediately be able to identify every node that contains this data. Presumably this gives them enough legal authority to shut down your node, regardless if you have plausible deniability that you are aware of the contents.



Yes, this is known as the "confirmation of file attack" and there is no feasible way for the system to operate without it.

The confirmation of file attack is actually the degenerate case of the "learn the remaining information attack", in which the majority of the plaintext is known except for some low-entropy portion.

You can imagine a standard form letter that contains your credit card number. An attacker can then generate all possible permutations of that low entropy data and find matches where those are stored.

For more information see: https://tahoe-lafs.org/hacktahoelafs/drew_perttula.html


Thanks for that information, that is extremely informative.

But what does this limitation mean for the security of Cryptosphere for its defined use cases? from the article: "If you want to store banned books or political pamphlets without attracting the attention of an oppressive government, or store pirated copies of music or movies without attracting the attention of copyright holders, then the confirmation-of-a-file attack is potentially a critical problem."

Doesn't this mean this system is DOA for its intended purposes?


No, I plan on employing the same system that Tahoe does: I will optionally incorporate a random convergence secret. This effectively disables the deduplication properties, but provides a defense against these two attacks. This convergence secret can be added to the end of every capability token, or optionally omitted (in which case I use zeroes). So you have two options: allow deduplication but be susceptible to the confirmation of file attack/learn the remaining information attack, or more security but with duplication.

Cryptographically this feeds in as a salt/initialization vector to HKDF along with the entire plaintext. HKDF is then used to generate a key and iv for use with AES


I should mention, you change one bit of a file and it will obscure the file from the "FBI test". But still, you trivially can generate the Cryptoshphere lookup for any unencrypted file you have access to, and see if anybody has it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: