I just wanted to clarify a couple points I was trying to make in my question.
First, I am consulting with a Federal Government body who is placing
the main computer used by several hundred users a couple hundred miles
away from all the users. Their main objective in the WAN design I am
doing for them is to minimize the cost of the WAN (moving the computer
to where the users are has already been eliminated). In fact, they have
never mentioned security as a concern of theirs.
Being concerned about security, I did not want to present them a plan that
did not also include some security considerations. Some of the Government
people came up with the idea of using a compression box to reduce the number
of required T1s. The box they recommended has V.35 ports, and would sit
between the Cisco and the CSU/DSU. To be fair, the vendor told me his
box did not do encryption, but since the data was compressed, it would not
be in plain view.
I was also looking at an encryption box from WANG. It has AUI ports and
would therefore have to go before the CISCO.
Thus, my dilema. If I encrypt before I compress, there won't be much to
compress. I am not an encryption expert. I was trying to get a general
feel from the list of the level of difficulty someone would have reading
the data if it was only compressed. I think the consensus has been:
It will keep the honest person honest, but will not deter a determined
hacker.
If someone nows of a device that does encryption as well as compression,
I would greatly like to hear it.
Thank You,
Brad Van Orden
Rapid Systems Solutions, Inc
www.rssi.com
410-312-0777
>It began with Brad VanOrden asking:
>>>
>>> I have a question regarding the level of protection I can expect from
>>> compressing traffic before it hits a WAN. That is, the compression
>>> box vendor stated that since the data is compressed, that unless a snooper
>>> has the compression key, the data is also essentially encrypted.
>>>
>>> Do you feel the "compression" encyrption is good enough, or should I look
>>> for a better encryption method?
>
>Then Chris Kostick said:
>
>>First of all, compression encryption (even in quotes) is not really a good
>>way of stating it. Nonetheless, I'd say no to this. Simply because if
>>someone has the tools and/or utilities to sniff something off of a network,
>>then the chances are really good that the tool already knows how to
>>uncompress the data stream and read everything. If you want privacy, use
>>encryption.
>
>However I'd like to qualify things on two counts.
>
>Do use compression, please. At the very least it will reduce the
>recurrent patterns in your data stream so that even if you are only
>using weak encryption the BFI decrypter will not be using this advantage.
>This isn't to say you shouldn't use strong encryption, but there may
>be constraints you are working under.
>
>A dictionary based compression algorithm can present problems
>to a receiver who doesn't have the dictionary. Strictly speaking,
>this is a 'coding' scheme. People often confuse 'codes' and 'cyphers'.
>Its not a bullet-prof way of protecting your data but it will deter,
>for example, an automatic sniffer looking for the the login-password
>sequence. But then so will XORing your packets with the first chapter
>of DuMaurier's "Rebecca" (As in "The Key to Rebecca").
>
>I view compression like I view The Club. It will deter the casual
>theft. Realistically, you have to do what I was suggesting in an
>earlier thread (cf the archives) and balance the investment in
>protection against the cost and liability of a loss. In short, stop
>thinking like a {programmer,consultant,administrator..} for a moment
>and think like an actuary.
>
>Brad, I presume you are going in to this as a "consultant". Present
>to your client the comparable costs of the different solutions.
>Involve their accountant and lawyers to get input about risk
>and liability. Find out if their insurance covers data loss.
>
>
>Please, please, please, recognise the difference between
>compression and encryption at the LINK level and at the
>NETWORK level. Make sure you use the one appropriate
>for your situation.
>
>/anton
|
|
