5 ms·
This appears to be an implementation of a 'One-time pad': http://en.wikipedia.org/wiki/One-time_pad http://en.wikipedia.org/wiki/One-time_pad. The difference i
by jacobkg 12y ago
This appears to be an implementation of a 'One-time pad': http://en.wikipedia.org/wiki/One-time_pad http://en.wikipedia.org/wiki/One-time_pad.
The difference is that we are using publicly available streams of data (book text, encoded youtube video bytes, etc) instead of truly random data as the key.
This scheme takes advantage of the fact that with a one-time pad you can provide a key that will decode it to any possible plaintext (of the proper length).
As for the security, using non randomly generated keys makes it harder to make any security claims about this technique. One-time pads are also subject to numerous side channel attacks, including arbitrary message modification.
- jsnell 12y agoIt's not at all an implementation of a one time pad. Though I'm not getting what extra level of plausible deniability this is supposed to add over the absurd "I can decrypt anything to anything with a one time pad, so nothing is copyright infringement" argument. Edit: IIUC, it works like this. Let's say plaintext1[1] == 'a', and plaintext2[1] =='b'. Then ciphertext[1] = i, with i chosen such that key1[i] == 'a' and key2[i] == 'b'. Of course this means that you'll be repeatedly using the same key material which is very much not how an OTP works, and will most likely be blowing up the data by a factor of 4 on encryption (each byte becomes a word).
- Buge 12y agoIt seems like it doesn't work that way >Unlike alternative plausibly deniable cryptosystems like the recently discontinued TrueCrypt—whose ciphertext size grows in proportion to the number of plaintexts (i.e., hidden volumes) it encrypts—Lenticrypt's ciphertext size is proportional to the largest plaintext it encrypts.
- jsnell 12y agoI'm pretty sure it works that way. Which part of what you quote conflicts with what I wrote? If you're objecting to the claim that the ciphertext will be blown up, please note the word 'proportional' in there. Producing a word of output for every input byte of the largest input file is still proportional. All that's saying is that the bloat factor is the same whether you're encrypting 2 files or 10. (The claim they're making here seems pretty worthless anyway, since the required key size will grow absurdly quickly as the number if input files is increased).
- fryguy 12y agoI don't feel that the claim is even correct, that the size of the output is proportional to the largest size. I mean, assume that the largest size is 1024 bytes. Then take two files that are gigabyte each into 1024 byte chunks. Make a function that encrypts each chunk into the appropriate chunk in the second file. I don't think this is possible to do without being on the order of a gigabyte (the number of documents being encrypted). If it behaves like a one-time pad, where f(d1, k) = d2, and you can find a d' such that f(d', k) = d3, then it means that d' is likely to be gibberish and I don't understand what this is doing.
- Buge 12y agoOh you're right. But the key must increase linearly with the size of the plaintext that is being decrypted. So I don't think it has any advantages over a one time pad.
- jacobkg 12y agoWhat's the advantage of this system over a one-time pad? Does it have any properties that a OTP does not have?