2 ms·
I'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
by jsnell 12y ago
I'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.