On Fri, Apr 14, 2017 at 1:41 PM, Alan Somers <asom...@freebsd.org> wrote: > On Fri, Apr 14, 2017 at 2:29 PM, Mark Johnston <ma...@freebsd.org> wrote: >> I've been hesitant about pushing it forward: >> - The dump_write* APIs need some simplification after the addition of >> encrypted dump support and support for dumping to 4Kn drives. >> - I'm not sure how encryption should compose with compression. It seems >> intuitively obvious that we should compress before encrypting if the >> compression is to be of any use, but I don't know enough to know >> whether the compression might somehow compromise the effectiveness of >> the encryption. >> >> If anyone has some insight on the second of these two points, I'd >> appreciate hearing it. > > I think compress then encrypt should be ok. AFAIK all attacks against > compress-then-encrypt systems have involved either incredibly short > payloads that are easy to guess, or a stream of separately compressed > blocks that can be fingerprinted. But core dumps are very long, and > they can't be fingerprinted in whole because they're unique. If you > were to encrypt each page individually then pages could be > fingerprinted, so don't do that. Instead, compress the entire core > dump as a single stream and you should be ok.
+1. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"