svn commit: r316938 - head/sbin/savecore

[Conrad Meyer]

On Fri, Apr 14, 2017 at 1:41 PM, Alan Somers <asomers at freebsd.org> wrote:
> On Fri, Apr 14, 2017 at 2:29 PM, Mark Johnston <markj at 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.