On 23/02/12 13:00, Johan Wevers wrote: > No. The files are compressed before encrypting (after encrypting they > should not be compressible so it has te be before) and the results > vary.
But isn't there a worst-case overhead for the compression algorithm used? There most likely is. >From <http://zlib.net/zlib_tech.html>: > In the worst possible case, where the other block types would expand > the data, deflation falls back to stored (uncompressed) blocks. zlib, with default settings, avoids increasing the size of the compressed text. That web page also gives detailed information on overhead. And *if* (big if) there isn't an acceptable worst-case overhead for a compression algorithm, there is probably a cut-off in GnuPG, or it would become a DoS attack vector: get someone to encrypt a specially crafted file that will fill his filesystem when the compression algorithm is run on it. IIRC, there's a cut-off for /de/compression like that. Furthermore: the ciphertext is enciphered with a streaming mode cipher, so the ciphertext is as big as the plaintext (after compression). But obviously there is overhead from the rest of the OpenPGP message. And if the size of the plaintext is not known beforehand, you get some extra headers for blocks of ciphertext in the OpenPGP message. At least, I believe that is the case. I didn't check now. The total overhead is small for big files, though. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
