<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 11:56 AM, Henry Baker <span dir="ltr"><<a href="mailto:hbaker1@pipeline.com" target="_blank">hbaker1@pipeline.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">At 04:22 AM 1/9/2015, Stephan Neuhaus wrote:<br>
>So, does any one know what paper I might be referring to?  Or is there any other hard evidence (not personal opinion, however well-informed, please) that compression before encryption does or does not help?<br>
<br>
</span>Sometimes forgotten about compression algorithms: if something is compressed, then at some point it gets uncompressed.<div class="HOEnZb"><div class="h5"><a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank"></a></div></div></blockquote><div><br></div><div>Decompression bombs are interesting things.  Files with holes, images and more fit this space.<br>Before fail2ban and the like I once watched my error logs on a web server and when it was fashionable to look for attack a specific dir or file to hack into on like machines I tried compression bomb files to slow down the script kiddies.   Today that poke in the eye would be seen as a challenge and might backfire but since it is a reverse denial of service it is worth remembering.    Most browser and net tools know how to deal with a .gz or other compressed file when passed it in good faith.    Now that I mentioned this here the decompression side of scripted tools may well defend themselves.   </div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>