Linux - Security This 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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
 |
GNU/Linux Basic Guide
This 255-page guide will provide you with the keys to understand the philosophy of free software, teach you how to use and handle it, and give you the tools required to move easily in the world of GNU/Linux. Many users and administrators will be taking their first steps with this GNU/Linux Basic guide and it will show you how to approach and solve the problems you encounter.
Click Here to receive this Complete Guide absolutely free. |
|
 |
01-25-2003, 04:53 PM
|
#1
|
|
Member
Registered: May 2002
Location: South Africa
Distribution: Gentoo
Posts: 103
Rep:
|
RC4 encryption
Hallo all
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?
koningshoed
|
|
|
|
01-26-2003, 08:02 AM
|
#2
|
|
Moderator
Registered: May 2001
Posts: 24,786
|
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...
|
|
|
|
01-26-2003, 02:55 PM
|
#3
|
|
Member
Registered: May 2002
Location: South Africa
Distribution: Gentoo
Posts: 103
Original Poster
Rep:
|
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.
Code:
The 'numbers' are in 1000s of bytes per second processed.
type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md2 171.19k 480.11k 649.90k 712.02k 729.42k
mdc2 0.00 0.00 0.00 0.00 0.00
md4 1564.37k 9124.45k 18980.56k 26317.14k 29721.34k
md5 975.80k 4897.67k 8962.47k 11342.85k 12326.36k
hmac(md5) 422.32k 2695.79k 6537.81k 10148.52k 12094.12k
sha1 672.98k 2395.01k 4329.39k 5420.03k 5821.37k
rmd160 587.47k 2691.50k 4629.25k 5730.99k 6130.35k
rc4 8324.83k 9684.27k 9886.89k 9937.24k 9928.70k
des cbc 1321.55k 1467.07k 1485.40k 1489.92k 1495.93k
des ede3 519.49k 539.22k 543.34k 542.04k 539.61k
idea cbc 0.00 0.00 0.00 0.00 0.00
rc2 cbc 1137.42k 1239.74k 1251.32k 1261.23k 1261.57k
rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00
blowfish cbc 2857.95k 3588.69k 3693.14k 3721.22k 3721.90k
cast cbc 2151.63k 2542.64k 2586.11k 2569.92k 2591.85k
sign verify sign/s verify/s
rsa 512 bits 0.0147s 0.0014s 68.1 726.3
rsa 1024 bits 0.0831s 0.0043s 12.0 233.1
rsa 2048 bits 0.5135s 0.0145s 1.9 68.9
rsa 4096 bits 3.4200s 0.0513s 0.3 19.5
sign verify sign/s verify/s
dsa 512 bits 0.0140s 0.0175s 71.6 57.1
dsa 1024 bits 0.0428s 0.0528s 23.4 18.9
dsa 2048 bits 0.1443s 0.1717s 6.9 5.8
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.
|
|
|
|
01-26-2003, 06:12 PM
|
#4
|
|
Moderator
Registered: May 2001
Posts: 24,786
|
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...
|
|
|
|
01-27-2003, 04:00 PM
|
#5
|
|
Member
Registered: May 2002
Location: South Africa
Distribution: Gentoo
Posts: 103
Original Poster
Rep:
|
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.
|
|
|
|
| Thread Tools |
Search this Thread |
|
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 03:12 PM.
|
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|