-   Linux - Security (
-   -   RC4 encryption (

koningshoed 01-25-2003 04:53 PM

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?


unSpawn 01-26-2003 08:02 AM

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...

koningshoed 01-26-2003 02:55 PM

Hehe, I wrote a backup system for a company called InterExcel. ( - 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.


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.

unSpawn 01-26-2003 06:12 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...

koningshoed 01-27-2003 04:00 PM

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.

All times are GMT -5. The time now is 07:27 PM.