2

(And more generally, is there a site listing which various algorithms are still considered secure, so I wouldn't have to ask that here? Wikipedia's "known best attack" is not particularly clear.)

I noticed our email system, IceWarp, supports S/MIME in its webmail app. (Which itself is probably not a very good idea considering it requires uploading the private key, even if it's a corp-issued one. But that's beside the point.)

Anyway, when sending S/MIME messages, IceWarp uses RC2-CBC [this does not seem to be configurable anywhere]. How secure is that in 2015?

(Is it better, or worse, than 3DES-EDE-CBC which apps like Thunderbird use?)

4

RC2 is a currently "unbroken" block cipher; the best known attack is a "related-key attack", i.e. something which does not really apply in practice (related-key attacks are about specific properties when the victim uses two distinct keys, that the attacker does not know, but with a difference between them that the attacker knows).

RC2 still has some suboptimal properties:

  • It uses 64-bit blocks. This makes it unsuitable to processing large data sets, the cut-off being around 2n/2 blocks when blocks consist in n bits. For a 64-bit block cipher, this amounts to about 30 gigabytes with a single key, which is large but not unattainable in some contexts. Encrypting more data than that implies a risk of revealing part of the plaintext. Note that 3DES suffers from exactly the same limitation. For encrypted emails, you should be OK with that.

  • Its performance sucks. About as much as that of 3DES; on my (underpowered) laptop, OpenSSL's implementation achieves about 10 MB/s with 3DES, 12 MB/s with RC2. There again, for emails, this should not be an issue.

  • RC2, in its description, uses a lot of data-dependent lookup tables. In that sense, it would be very difficult to make an implementation that is "constant-time" (i.e. does not leak information to attackers that can run their own code on the same hardware, through cache-induced timing differences); at least, it would be very difficult to make one without a massive slowdown (like a 100x slowdown factor). Note that classic 3DES implementations are not constant-time either, but that can be done with only a "moderate" (relatively) slowdown (about 3.5x with my own code).

    Since email sending is asynchronous, and moreover since email encryption and decryption tends to happen on the user's desktop computer, not on a shared server, this kind of side-channel leakage should not be a big concern anyway. Unless you decide to upload private keys on a server, in which case the concerns may come back -- make sure, at least, that the server is not hosted in a cloud that shares the very same hardware with outsiders.

  • RC2 has a configurable key length, between 1 and 128 bytes (i.e. 8 to 1024 bits, and multiple of 8). Thus, while RC2 itself can be a tolerably fine algorithm, it can still be used with a key which is way too short for ensuring a decent level of security. RC2 also includes an additional parameter (called "effective key length") that can be used to limit the brute-force resistance. Historically, RC2 has been much used in setups meant to comply with the pre-2000 US crypto export rules, with a typical strength equivalent to 40 bits (i.e. not strong at all).

The fourth point is, in my opinion, your biggest risk when using RC2. You do not really know how large the actual encryption key is; if the software you use does not document that information, then you do not really know how strong the encryption will be. Moreover, software that uses RC2 might be a bit lacking in maintenance...

To sum up, there is nothing really wrong in RC2 itself for encrypting emails, but the implementation still has ample room for doing stupid things that annihilate security.

| improve this answer | |
  • Thanks. Do you know perhaps why S/MIME clients tend to limit themselves to these two ciphers even though they do upgrade to modern signature algorithms? Just compatibility with all recipients? (I know Thunderbird uses SHA256 when signing, which OE cannot verify, and yet it uses 3DES to encrypt.) – user1686 Jul 14 '15 at 19:36
  • 1
    Well, for emails, there is no return path. SSL clients and server can negotiate cipher suites, but when you send an email it should work first time. Theoretically, people can send "S/MIME preferences" that contain their public key (certificates) and supported algorithms, but I am not sure I really saw that work even once. – Tom Leek Jul 14 '15 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.