24

I'm interested in updating this two pronged question for 2011:

  1. What cryptology is most appropriate for low-powered devices (such as a cellphone), and yet still effective?

  2. What cryptology is most secure for a .NET developer?

In November of '08 Rasmus Faber answered this similar Stack Overflow question with this response:

  • Symmetric cipher: AES-256

  • Asymmetric cipher: RSA with 4096 bit key (I believe that is the maximum in .NET) or ECDSA with 571 bit key (but that is only supported in .NET 3.5)

  • Hash: SHA-512

  • Message Authentication Code: HMAC with SHA-512

That being said, those are overkill for most applications, and you should do fine using AES-128, RSA with 2048 bit key, SHA-256 and HMAC with SHA-256.

Are these recommendations still true today?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • Your April update to add the chart by "RIM's encryption vendor" adds lots of confusion. It is really an ad for Certicom's ECC stuff with oversized RSA lengths added for effect. They misleading quote NSA and NIST work. As others have already clarified, even the earlier recommendations were overkill. I suggest just deleting the update, or putting it out as an answer, since updating the question also makes it unclear what previous answers were referring to unless people check the dates. – nealmcb Apr 01 '11 at 14:27
  • @nealmcb - I thought it was helpful... I removed it. Thanks for the feedback – makerofthings7 Apr 01 '11 at 14:33
  • May be worth calling out that the specific requirement of a hash for password storage is different from the requirement for a hash for message integrity (whether transmission, or signing). There are on-going arguments over what is the best approach to password hashing - scrypt/bcrypt/PBKDF2 - but plain SHA-256/SHA-512 is definitely not the right answer. – Richard Gadsden Jul 04 '11 at 13:33
  • Could anyone write the list of most current ciphers which can be used ~securely nowadays? – boleslaw.smialy Sep 08 '16 at 13:52
  • 1
    @boleslaw.smialy Rasmus Faber answer is a concise summary - see also keylength.io – makerofthings7 Sep 08 '16 at 13:55

7 Answers7

39

The recommendations you cite are kind of overkill. One point to take into account is that beyond a certain level (e.g. on key size or hash function output size), all functions are "unbreakable with foreseeable technology" and it is a bit delicate to compare them. Stating that SHA-512 is "more robust" than SHA-256 means that you are imagining that SHA-256 could be broken, which, as far as we can tell for now and the next 40 years, is not true (beyond 40 years, trying to envision what technology we could have is risky; 40 years ago, nobody was imagining the Internet as it is today, but most people assumed that by 2010 we would all drive flying cars).

AES-128 is already secure enough, and less expensive (AES-256 uses 14 rounds, while AES-128 uses 10 rounds).

The currently largest broken RSA key is a 768-bit modulus, and it took some huge effort (four years, and really big brains). 1024-bit keys are considered usable for short term security, although larger keys are encouraged. 2048-bit keys are appropriate. Using a key twice larger means 8 times more work for signing or decryption, so you do not want to overdo it. See this site for a survey of how RSA key length can be related to security.

ECDSA over a 256-bit curve already achieves an "unbreakable" level of security (i.e. roughly the same level than AES with a 128-bit key, or SHA-256 against collisions). Note that there are elliptic curves on prime fields, and curves on binary fields; which kind is most efficient depends on the involved hardware (for curves of similar size, a PC will prefer the curves on a prime field, but dedicated hardware will be easier to build with binary fields; the CLMUL instructions on the newer Intel and AMD processors may change that).

SHA-512 uses 64-bit operations. This is fast on a PC, not so fast on a smartcard. SHA-256 is often a better deal on small hardware (including 32-bit architectures such as home routers or smartphones).

Right now, cheap RFID systems are too low-powered to use any of the above (in other words, RFID systems which can are not as cheap as they could be). RFID systems still use custom algorithms of often questionable security. Cellphones, on the other hand, have ample enough CPU power to do proper cryptography with AES or RSA (yes, even cheap non-smart phones).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
11

The quoted answer is my response to what is the most secure crypto in .NET.

My recommendations (both for high- and low-powered devices):

  • Symmetric cipher: AES-128

  • Asymmetric cipher: RSA with 2048 bit key or ECDSA/ECDH with 256 bit key

  • Hash: SHA-256

  • Message Authentication Code: HMAC with SHA-256

  • Stream cipher: AES-128 in CTR-mode

Rasmus Faber
  • 397
  • 2
  • 11
6

In terms of security, these recommendations are still valid and the same I would make.

For asymmetric ciphers, there are really three things you are concerned with: encryption, key exchange, and signatures. RSA can be both an encryption and signature scheme, while ECDSA is specifically a signature. However there are elliptic curve versions of encryption and key exchange as well (not sure what is in the public domain though). That said, the parameter sizes are the same for all three.

The only other cavet is that SHA-256/512 will soon be replaced but "soon" in this case will be 2012.

Regarding low-powered, it really depends on how low-powered. If by cellphone, you mean a smartphone, all of these are appropriate. For a smartcard, RFID, sensor network, etc. it is a different story. Also, most low-powered algorithms will not be in a standard library. However I would steer you toward the parameter sizes in the "not overkill" last sentence.

PulpSpy
  • 2,204
  • 15
  • 19
  • 3
    It is unclear whether SHA-3 (chosen in 2012) will "replace" SHA-2 (SHA-256 and SHA-512). The NIST certainly did _not_ claim that. It seems that SHA-3 was initiated in order to be ready if SHA-2 was to be broken, but SHA-2 turns out to be quite resilient. – Thomas Pornin Jan 19 '11 at 23:17
  • 1
    Fair enough. I believe that SHA-2's resilience may be artificially inflated from all the cryptanalysists focusing on SHA-3 candidates and not on breaking SHA-2. ;) – PulpSpy Jan 19 '11 at 23:20
  • 1
    Also the list is missing a stream cipher -- do have a recommendation @Thomas? – PulpSpy Jan 19 '11 at 23:22
  • 2
    A "stream cipher" is mostly a specific usage context; AES in CTR mode is a stream cipher. If we want something _faster_ then we can look at algorithms specifically designed for that; the smart thing is to look at the [eSTREAM Portfolio](http://www.ecrypt.eu.org/stream/). I would choose Sosemanuk, but I am slightly biased on that question. – Thomas Pornin Oct 06 '11 at 15:48
6

For security through the year 2030, the savvy folks at NIST recommend at least SHA-224, 2048 bits for RSA or DSA, 224-bit EDCSA, and AES-128 or 3-key triple-DES be used.

Based on their work, as of the end of 2010, the US government deprecates these algorithms: SHA-1, 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)

For more info, see this post and the NIST documents it references: http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation

nealmcb
  • 20,544
  • 6
  • 69
  • 116
  • 1
    TripleDES is compromised because of two small block size (64 bits). – boleslaw.smialy Sep 08 '16 at 13:54
  • I've heard that that is true, @boleslaw.smialy, e.g. for certain authenticated modes of operation, but a pointer to more information would be helpful. And I agree that in general, AES is better than any of these forms of triple DES. – nealmcb Sep 22 '16 at 19:45
5

Cryptographic Right Answers by Colin Percival in 2009 is still pretty much up to date IMHO and covers the question and more.

Bruno Rohée
  • 5,221
  • 28
  • 39
2

For symmetric ciphers, you may be better using AES-128 instead of AES-256 due to possible weaknesses in the key schedule for AES-256: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

Justin Clarke
  • 453
  • 2
  • 5
  • 2
    I completely disagree. That's a complete misinterpretation of those results. (I am knowledgeable about this area.) Those results are not applicable to most uses of AES (or indeed to any proper use of AES). Moreover, none of the results cited there apply to the full 14-round AES-256 cipher. – D.W. Apr 03 '11 at 03:30
  • 2
    http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html has more on this subject, basically if you chose your key randomly (which is good protocols do) those related key attack are of no significance whatsoever. – Bruno Rohée Apr 07 '11 at 15:50
0

What we did is to select several encryption and hashing methods and converted all output to a common hex format. Our most sensitive data is using SHA-256 and DES-3, while less sensitive data that can be guessed easily is using MD5 & RC4 and we are also using a straight XOR conversion for some things. Each symmetric cipher has it's own password and all encrypted data is keyed with a check-sum. Relying on one encryption for everything is dangerous.

Dave
  • 225
  • 1
  • 4