Hello all! Seems I am the first one to reply to my own post :-) I am not so much surprised however, since this stuff is kinda weird and complicated. Nevertheless I got some news for you: after replacing the gzip- with bzip2-compression filters everything worked fine!! This means there is some (very subtle) bug or incompatibility in the gzip filters, which I of course did not expect (but rather was looking in my code of course). For the protocoll: gzip_decompressor raises a gzip_error exception with internal error_ = -3 when reaching the end of the stream. Unfortunately this behaviour could not be reproduced without actual encrypting/decrypting. Simply doing a null-transformation by replacing encrypt() and decrypt() with memcpy() does not yield the error. I did some tests: reading a file, writing it to a filtering_ostream using filter X into some file, again reading through filtering_istream using Y and comparing with the original file. X = block_crypter, Y = block_crypter ok, identity X = gzip_compressor, Y = gzip_decompressor ok, identity X = block_crypter|bzip2_compressor, Y = block_crypter|bzip2_decompressor ok, identity X = block_crypter|gzip_compressor, Y = block_crypter|gzip_decompressor error, see above and now get yourself a good seat: X = gzip_compressor|block_crypter, Y = gzip_decompressor|block_crypter ok, identity Of course compressing an encrypted file is not the same as encrypting the compressed file, which is much faster and results in smaller files. So I tried this just to see what happens the other way round. Throughout the test I used file_sink and file_source in binary-mode as devices. Have fun fixing this ;-) -- Christian Pfligersdorffer Dipl.-Ing. Bakk.rer.nat. Software Engineering EOS GmbH - Electro Optical Systems Robert-Stirling-Ring 1 D-82152 Krailling / Munich Phone +49 89 893 36-229 Fax +49 89 893 36-287 christian.pfligersdorffer@eos.info http://www.eos.info