At 01:25 PM 11/23/98 -0800, Jim McCoy wrote:
>Bill wrote:
>>The current version at EC supports three modes of crypto:
>>
>>(1) NONE has no data privacy.
>>
>>(2) BLOWFISH56 uses 56 bit Blowfish for data privacy and protecting the
>>Swiss numbers. This is the data privacy mode we think we may be able to
>>get thru the Commerce Department. The Swiss number hole is less gaping,
>>but it is still weak.
>
>
>I am curious regarding who at EC thinks that 56bit security offers any more
>protection than, for example, 40bit RC4 used in weak SSL? Why don't you
>just use the 40-bit, easily broken, known insecure cipher rather than
>pretending that a minor variant somehow offers an advantage?
I make such a claim. I can download a screen saver which will break 40 bit RC4 MIME messages in about 3 months on a single PC. I challenge you to do that with 56 bit blowfish. If you examine the key schedule for Blowfish, I think you will agree that 56 bit Blowfish is superior to 56 bit DES in resistance to brute force attacks. By my calculations, 56 Bit blowfish offers 2**27 times more protection than RC4-40. 2**16 from the extra key bits, and 2**11 from the key schedule.
As a result of these calculations, I am willing to claim that 56 bit Blowfish offers reasonable protection to Alice against her brother Bob who is running a packet sniffer on their household net. I am not willing to make such a claim for 40 bit RC4.
>At least if
>the cipher chosen was one which the whole world knew was a joke for privacy
>there would be no one who would mistakenly assume that BLOWFISH56 somehow
>gave them data privacy. There is one simple test for any cipher which I (and
>many others among the crypto-clued who will be asked to give our opinions
>regarding the "security" of such a system) would like to introduce EC to:
>
We both agree that neither RC4-40 nor Blowfish-56 is proof against a determined attacker with a large amount of resources to expend.
The reason I advocate this level of encryption over no encryption is because it will make systems like Echelon much less effective. While a large organization can break a single 56 bit key without much difficulty, if there are a million chat users, each using many different keys each week, then the situation has changed. The attacker must chose which targets to attack, instead of applying a vacuum cleaner approach and looking at everything.
Having a large amount of encrypted traffic also acts as cover traffic for those messages which are super-encrypted with strong algorithms and key lengths. Today, those messages stand out because they are the only encrypted messages being passed.
>If the U.S. Commerce Department will approve it for export, it is not strong
>encryption.
Neither EC, nor I have ever claimed it is strong encryption.
>And do I, as a user, have the easy ability to tell my system that there is
>only one pecking order: 3DES or else refuse the connection? If there is
>going to be any sort of security claims made, this is a very important
>feature.
With EC's product, you the user have no knowledge that any security is being offered to you. EC makes no security claims about the product. As long as that is true, I don't think you have any reason to complain.
If you are using E to build an application, you can change StartUpProtocol.java to enforce the level of security you need.
The cypherpunk in me agrees with Jim and many others, No compromise.
However, the engineer has to deal with marketing people who don't think any security is needed. People who give no priority to setting up a US only download for the existing version with strong encryption.
Would you build a product with weak encryption and either advertise it as such, or more honestly make no security claims. Or would you continue to ship the product with no claims and no encryption?