Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Does anyone know hos the security of the RC4 cipher compares to other ciphers, like for example des ede3.
What I do know is that I can process about 8.3MB of data using the RC4 cipher per second compared to about 0.5MB on des ede3. The closest to RC4 I have tested is blowfish cbc (2.9MB of data).
Normally they say you get a speed/security tradeoff, if this is the case, how big is the tradeoff in this case?
Hell, I ain't no crypto expert so someone correct me if I'm off my rocker, but AFAIK the security/integrity vs performance tradeoff is in the key length vs message.
If you take RC4 with a 128 bits key it'll still be performing faster encryption compared to using DES and a (say) 56 bits key, but using DES with a 128 bit key provides stronger encryption (crack yrs vs days) compared to using RC4 with a 128 bit key.
The other side of things is of course the *message* you would want to protect. AFAIK, if you want to verify who's on the other side, then using computationally intensive gizmo is OK (provided you need it only once or twice for signing a message), but if you want to ship large data streams back and forth it'll be not worth it to use large key/CPU expensive stuff. That's why SSL uses RC4.
There's a third thing in play comes to mind right now, that's the lifecycle. The difference being if an encrypted message is sposed to be *stored* or processed directly. If it's stored it should make sense to user a larger key to protect the data integrity, but if a message is processed directly then using a larger key would only make sense if the chance that encryption can be broken by MIM or brute force guessing attacks is high.
Besides algo/key length issues, look for instance at SSHv2. Here using compression and regularly computing a new master key makes guessing attacks on the streams' contents more difficult.
Btw, Google around for old AES contest (RC6, TwoFish, Rijndael) papers and you'll find some (maybe interesting) performance docs. Maybe you should test more algo's.
Btw[1], I'm *still* wondering what you're working on...
Hehe, I wrote a backup system for a company called InterExcel. (www.interexcel.co.za - no info on the program there yet, will be soon, a month or so). If you are interrested I can send you quite a bit more detail, permitting I can get the neccesary permissions from my contractor.
So I was fooling around with the openssl speed program and came up with the following using a Pentium mmx 200 machine.
For user authentication I created my own CA structure and use client certificates to authenticate both ways.
Considering the machine will probably take quite a heavy load, and the fact that the data is already encrypted using rijndael, I'll probably switch it to using RC4 for performance reasons.
The reason I was wondering was cause afaik RC4 is newer than DES. Also, des a quite a number of "weak" keys (2 or more keys that are effectively the same). As such I do not consider DES a true 56-bit encryption algorithm. Neither is 3DES a true 168-bit. Also, you might actually be surprized at how much "harder" certain algorithms are to crack based on certain properties. So I was toying with the thought that 128-bit RC4 might actually be close to, if not as, effective as 168-bit 3DES.
Last edited by koningshoed; 01-26-2003 at 03:00 PM.
Also, you might actually be surprized at how much "harder" certain algorithms are to crack based on certain properties.
I'd be interested if you've got any particular references (research docs?) you wanna share on this one? Since I'm not into crypto I'm sure it'll make a good read...
not really. but take the principle of des, it has weak keys, so I would wager that by carefull reduction it should be possible to reduce the effective key by a bit.
Also, encryption algorithms have what they call an s-box (I dunno what this means either) which apparantly have to be as big as possible. Now with the new attack against aes (don't know how it works), they found that aes only has a s-box of 8x1 or something. Meaning it is not as strong as they though. Anyway, it is still as hard as hell and probably won't be cracked anytime soon (by anything other than a luck shot). Anyway, the number of bits is still a *very* good indication as brute force is apparantly better than the new attack (well, for the next decade or so anyway).
Well, I figure that if the banks are willing to RC4, then so am I.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.