On Sat, 17 Jan 2004, Adam Olsen wrote:
> Which should encrypt the file... and it does to a point. The last few
> characters of the file are either not decrypted or decrypted incorrectly.
Block ciphers take standard size inputs and map them to standard size outputs
- in this case, 64 bits. So you're properly feeding it 8 bytes at a time, but
in the last block you're only saving the first n bytes of output to disk.
Without the complete last block, you can't decrypt properly.
Welcome to the world of block cipher padding. One standard thing to do is to
write "1", "22", "333", "4444", ... "88888888" as padding to the last block so
you know how much to chop off. Notice that this means for 8 bytes of
plaintext you need to save an entire extra block of "88888888", because
otherwise if the plaintext ended in "55555" for example, you'd have an
ambiguity problem.
You could also use length embedding, where the first 4 (or 8) bytes of the
file indicates the plaintext length. Or you could use something that doesn't
require padding - a stream cipher like RC4, or a block cipher like Blowfish
used in a stream cipher like mode: OFB or CTR (go with CTR if it's an option -
it's about 8 times faster).
If you go with stream-type encryption, though, you should note that you have
even less of a guarantee against modification: an enemy could flip bits in
your plaintext at will, although he wouldn't actually know what the plaintext
*said*. At least with ECB he has to mess with 8 bytes at a time. The
suprising rule is that *integrity* is usually more important than
*confidentiality*.
ECB, of course, also leaks information about your plaintext - if the same 8
byte sequence repeats a lot, it may show up as patterns in the ciphertext.
CBC is better about this.
Consider using something higher-level like GPGME (although I haven't much
experience with it).
Finally, you may just want to come to CS465 on Wednesday and Friday (noon in
171 JSB), since we'll be discussing just these topics. Thanks for bringing up
a lot of the questions I need to answer in the lecture... :)
-J
____________________
BYU Unix Users Group
http://uug.byu.edu/
___________________________________________________________________
List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
