views:

1061

answers:

7

Triple DES or RC4?

I have the choice to employ either one.

+1  A: 

This might not be the most informative answer, but during my 4 year employment term with a very large telco, Triple DES was the encryption standard for all sensitive applications, others were simply not allowed. It was Triple DES or the application does not go live. Hope that helps.

karim79
+12  A: 

As a high level view the following comments on both should be useful.

  • It is extremely easy to create a protocol based on RC4 (such as WEP) that is of extremely low strength (breakable with commodity hardware in minutes counts as extremely weak).

  • Triple DES is not great in that its strength comes though excessive cpu effort but it is of considerably greater strength (both theoretically in real world attacks) than RC4 so should be the default choice.

Going somewhat deeper:

In the field of encryption with no well defined target application then the definition of 'best' is inherently hard since the 'fitness' of an algorithm is multi variant.

  • Ease of implementation
    • Can you run it on commodity hardware?
    • Are implementations subject to accidental flaws that significantly reduce security while still allowing 'correctness' of behaviour.
  • Cost of implementation
    • Power/silicon/time to encode/decode.
  • Effort to break
    • Brute Force resilience. Pretty quantifiable
    • Resistance to cryptanalysis, less quantifiable, you might think so but perhaps the right person hasn't had a try yet:)
  • Flexibility
    • Can you trade off one of the above for another
    • What's the maximum key size (thus upper limits of the Brute Force)
    • What sort of input size is required to get decent encryption, does it require salting.

Actually working out the effort to break itself requires a lot of time and effort, which is why you (as a non cryptographer) go with something already done rather than roll your own. It is also subject to change over time, hopefully solely as a result of improvements in the hardware available rather than fundamental flaws in the algorithm being discovered.

The core overriding concern is of course just that, is it secure? It should be noted that many older algorithms previously considered secure are no longer in that category. Some are so effectively broken that their use is simply pointless, you have no security whatsoever simply obscurity (useful but in no way comparable to real security).

Currently neither of the core algorithms of RC4 and TDES is in that category but the naive implementation of RC4 is considered extremely flawed in protocols where the message data can be forced to repeat. RC4 has several more significant theoretical flaws than TDES.

That said TDES is NOT better than RC4 in all the areas listed above. It is significantly more expensive to compute (and that expensiveness is not justified, other less costly crypto systems exist with comparable security to TDES)

Once you have a real world application you normally get one or both of the following:

  • Constrains on your hardware to do the task
  • Constraints imposed be the data you are encrypting (this is used to transmit data which needs to be kept secret only for X days... for example)

Then you can state, with tolerances and assumptions, what can achieve this (or if you simply can't) and go with that.

In the absence of any such constraints we can only give you the following:

Ease of implementation

Both have publicly available secure free implementations for almost any architecture and platform available. RC4 implementations may not be as secure as you think if the message can be forced to repeat (see the WEP issues). Judicious use of salting may reduce this risk but this will NOT have been subject to the rigorous analysis that the raw implementations have been and as such should be viewed with suspision.

Cost of implementation

I have no useful benchmarks for RC4 (it is OLD) http://www.cryptopp.com/benchmarks.html has some useful guides to put TDES in context with RC5 which is slower than RC4 (TDES is at least an order of magnitude slower than RC4) RC4 can encrypt a stream at approximately 7 cycles per byte in a fast implementation on modern x86 processors for comparison.

Effort to break

Brute Force resilience of TDES is currently believed to be high, even in the presence of many encryption outputs. RC4 brute force resilience is orders of magnitude lower than TDES and further is extremely low in certain modes of operation (failure to discard initial bits of stream)

Resistance to cryptanalysis, There are publicly known flaws for Triple DES but they do not reduce the effectiveness of it to realistic attack in the next decade or two, the same is not true for RC4 where several flaws are known and combined they have produced reliable attacks on several protocols based on it.

Flexibility

TDES has very little flexibility (and your library may not expose them anyway) RC4 has a lot more flexibility (the key used to initialize it can be arbitrarily long in theory, though the library may limit this.

Based on this and your statement that you must use one or the other you should consider the RC4 implementation only if the CPU cost of TripleDES makes it unrealistic to implement in your environment or the low level of security provided by RC4 is still considerably higher than your requirements specify.

I should also point out that systems exist which are empirically better in all areas than RC4 and TDES. The eSTREAM project is evaluating various stream cyphers in the order of 5 or less cycles per byte though the cryptanalysis work on them is not really complete. Many faster, stronger block cyphers exist to compete with TDES. AES is probably the best known, and would be a candidate since it is of comparable (if not better) security but is much faster.

ShuggyCoUk
The problem with WEP is not RC4 but the WEP itself.
muerte
yes, but the weakness stems from a poor, though correct implementation of it. TripleDES does not have those weaknesses in it's default implementation.
ShuggyCoUk
Not talking WEP here... but Shaggy's point is still valid. It's apparently easier to screw up an RC4 implementation than 3DES. So it comes down to whether I trust the RC4 implementation in the product I'm using. For an intranet-only application, the risk doesn't seem excessive.
robmandu
I agree, that's a good explanation: "...easier to screw up an RC4 implementation than 3DES.". The same RC4 in WPA with TKIP is much better, but still, nothing comparable to AES. If it were up to me, like i said, I'd wage on the speed vs increased security.
muerte
+1 - Very nice answer.
Mark Brittingham
Insanely awesome answer.
NilObject
+1  A: 

Both are secure, well... enough. RC4 is faster so if that's important to you...

After reading other peoples answers (which are all correct), it's clear that it really depends on your context. There are so many other questions that could influence your decision. If it just needs to be fool proof, if it's not really something sensitive and you have a lot of data and speed is the factor, go for RC4.

Otherwise, if you need something a bit more secure and easier to implement or as you say "tougher to screw up" :) then go for 3DES, which is, as far as I remember, secure enough (!) till 2020-2030, or something like that.

muerte
Speed is definitely a factor. Not the only one, of course. For an intranet-only app, speed can carry more weight in the decision process.
robmandu
I didn't have enough space in the comments, so i clarified in the answer :)
muerte
+7  A: 

Sorry - triple DES is no longer considered best practices. AES is simply a better algorithm so if you can use it then you should. For an easy implementation, go here.

I strongly suggest that you learn more by reading up on TDES on Wikipedia. The money quote is:

"TDES is slowly disappearing from use, largely replaced by the Advanced Encryption Standard (AES)."

RC4 is, honestly, just not an acceptable option for any application where security is important.

Mark Brittingham
AES is definitely the way to go, but unfortunately, robmandu must choose between RC4 and 3DES.
muerte
That is a shame. Honestly, though, the number of folks competent enough to decrypt TDES is pretty small and he'd probably be fine. I just wanted to make sure that the "best practices" perspective was there on the table.
Mark Brittingham
Yah, I wish AES was a supported option, too.
robmandu
Learning by reading on wikipedia??? Uh-oh :-)
stevenvh
Lol - well you've got to be careful out there...but the Wiki entry on encryption's pretty good. The one thing that did give me a double-take was that caveat that financial services isn't abandoning TDES. True - but they are the main users of TDES so it isn't really "disappearing" overall.
Mark Brittingham
+3  A: 

Agreed -- DES is largely outdated, so unless there is a good reason to use it, go with AES. If that's not an option, TDES would be the better choice, unless you're dealing with streaming data (ie, data which cannot be broken into blocks), then RC4 is the way to go (out of the given options).

Of course, I feel like I should mention... Cryptography is really, really hard to get right, and even the strongest algorithm can be broken easily if you get something even a little wrong (see, eg, older Kerberos or WEP).

David Wolever
A: 

Are those your only two options? If you can use AES (also known as Rijndael) then use it instead. DES is slow, and now considered obsolete (AES is the replacement for it). RC4 sucks, don't use it. It's a stream cipher but you can use a block cipher instead, just pad the final block of data (Google PKCS#5 padding scheme). Lately I've only seen DES being used in embedded devices (firmware), because the implementation is simple and it uses very little memory. Even in JavaME you can use AES.

Chochos
+1  A: 

One factor in deciding between 3DES and RC4 is language support. Java doesn't natively support RC4 and you would need to grab an open source library such as BouncyCastle to implement. MS doesn't have this same challenge.

jm04469