In my (admittedly limited) experience with encryption and compression, the rule
of thumb has always been to compress first (removing exploitable redundancy and
pattern repetitions) and then encrypt. It also has the advantage that you are
encrypting less volume and reducing the exploitable "surface area" of the data.
Of course, your mileage may vary, but that is the experience I have and advice
I've been given.
Don Ritchey
IT ED RTS Tech Services, Senior IT Analyst (UNIX)
-----Original Message-----
From: owner-amanda-users AT amanda DOT org [mailto:owner-amanda-users AT amanda
DOT org] On Behalf Of Chris Hoogendyk
Sent: Tuesday, October 30, 2007 4:38 PM
To: AMANDA users
Subject: Re: Encryption, compression
Brian Cuttler wrote:
> Amanda users,
>
> I may have missed it in the mailing list... I know that
> encryption came available in 2.5.0, either server side
> or client side, or the channel (though I think encrypting
> on the client provides an encrypted channel by default, true ?)
>
> Anyway, I was wondering and haven't seen... how to encryption
> and compression play against one another. Some data compresses
> very well, some doesn't, If you are encrypting, doesn't that
> tend to cause the data to be less compressable ?
>
> We are looking an encryption on the tape for one of our amanda
> servers, just want to sort of know what to expect when I upgrade
> the client and server and turn on encryption, compression is
> already enabled.
hmm, I just saw something on this. Don't remember where, and I deleted it.
It's interesting that when you google "compressing encrypted data", you
get on the first page
A wikipedia entry claiming you cannot compress encrypted data
A storagemojo guru saying that it is a mathematical faux pas to say
that encrypted data can be compressed
An EECS Berkeley and IEEE Publication detailing the mathematics of
compressing encrypted data (it works)
(7 of the 10 links on the first page were to copies of this
paper)
I think I recall that the item I saw earlier indicated significant
compression of encrypted data.
I'm going to make the wild speculation that particular results will
depend on your encryption keys and your compression methods as well as
your original data. That said, the bottom line is always real world
tests. Therefore, if no one comes up with detailed examples and data, I
would suggest just doing it and recording the results. Choose your
methods and your data and then make a results table with the size of the
original data, the size compressed, the size compressed and then
encrypted, the size encrypted, and the size encrypted and then
compressed. Send it back to the list with the algorithms, methodology
and results.
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>
---------------
Erdös 4
-----------------------------------------
**************************************************
This e-mail and any of its attachments may contain Exelon
Corporation proprietary information, which is privileged,
confidential, or subject to copyright belonging to the Exelon
Corporation family of Companies.
This e-mail is intended solely for the use of the individual or
entity to which it is addressed. If you are not the intended
recipient of this e-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation
to the contents of and attachments to this e-mail is strictly
prohibited and may be unlawful. If you have received this e-mail
in error, please notify the sender immediately and permanently
delete the original and any copy of this e-mail and any printout.
Thank You.
**************************************************
|
