06-12-2003, 06:39 PM
Quote:mango:
But I'm still lost, though:
"Therefore, if a file longer than 1000 bits is being encrypted, the key must either repeate (generally a no no) or be updated at each iteration."
So you make the key longer. Is that correct?
no...what I did in v3.1 is to take the key and xor the file against it. When I ran out of key, I would stop encrypting, and update the key, so that it would never repete. The key update scheme involved "stepping an automata" seeded with the key on a (32-bit)word-by-word basis...I did this for speed...turns out that this is not a good method, because if someone has partial info about the file (eg they guessed it was a word doc and knew the header structure) *and* if they correctly guessed the key length, then they would be able to unencrypt portions of the rest of the file that fell under the part of the original key (and it's updated versions) that the attacker knew.
Quote:One more question: Do you actually update every single bit and expand by two bits each time? Or do you just keep adding the previous step, which would make it A LOT faster? (and still random most likely..)
yes-I updated every bit and discarded all previous info. It would be unsafe to simply add the update to the previous key...then...if an attacker knew the contents of the first little bit of the encrypted file, he could easily get the whole key...this is the basic problem with my key-update scheme. However, its not so bad since the key is pretty long...basically, you dont want an attacker's knowledge of part of the key to allow him to calculate the rest (or part of the rest) of the key...and summing the lines of the automata would allow just that...
it only takes a second or so to generate the 1000 bit key...and that is using my slow method...my current method that works in parrallel is circa 25 times faster....it's really not a problem. Try encrypting a big file (like a 1 MB jpg) with an 8-10 character password...it should take less than 10 seconds to do the encryption.
cheers