Talk:Key size

From Wikipedia, the free encyclopedia

This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.

It is intended that this article be included in WikiReader Cryptography, a WikiReader on the topic of cryptography. Help and comments for improving this article would be especially welcome. A tool for coordinating the editing and review of these articles is the daily article box.

To-do list for Key size:	edit · history · watch · refresh
None listed.

[edit] Recent addition

"...As of 2003, the U.S. National Institute for Standards and Technology, NIST, is proposing that 80-bit keys be phased out by 2015. The 2005 Shandong University attack on SHA1 suggests a faster phase out."

Hmm...I'm not so sure it does. The SHA-1 attack is claimed to take 2⁶⁹ operations, less than the expected 2⁸⁰ for brute force, which is why it's being replaced. The feasibility or otherwise of performing a computation on the order of 2⁸⁰ hasn't changed. — Matt Crypto 18:01, 23 Feb 2005 (UTC)

Well, it's arguable. I think the broader point is that a cryptographic algorithm with a nominal key size of N may well have weaknesses that reduce that strength somewhat. On the other hand, I took out the recent addition: "or at least will be out of reach while technology continues along its current course. In respect of long term information security it is as well to hold that factor in mind because there are several potential leaps in computational methodology which, _when_ one of the is made, will render current key lengths laughably insecure. A currently evolving technique is that of distributed procssing, where a task is shared between a (potentially very large) network of machines. This technique already renders low to moderate keylengths brute-force breakable." Distributed processing is not, of itself a threat to 128-bit keys. There are 3.4 x 10³⁸ possible keys. There are 3.2 x 10¹⁵ microseconds in a century. Testing all possible keys at one key per microsecond per processor requires 10²³ processors working for 100 years. Even if you reduce the strength of the algorithm by 20 bits (a work factor of 10⁶) there is a fair margin of safety. --agr 11:28, 26 May 2006 (UTC)

It doesn't matter too badly why it does, if thats what they recommend, its then a factual comment.

But as background, the concern is not just the availability of processing power to crack it. It's also the speed of development of new attacks that cut down the work needed. So for example, it may be that they feel that computationally we will not have enough computing power for 70 years... but that the algorithm itself will gradually become more vulnerable to attacks with less processing power over time and therefore based on speed of mathematical analysis development they now feel it may not last more than 10 years reliably and should be replaced in 5. That's what's going on, I think. FT2 ^{(Talk | email)} 00:35, 30 May 2007 (UTC)

[edit] Error in article, needs fixing

One of the asymmetric algorithm types, elliptic curve cryptography, or ECC, appears to be secure with shorter keys than those needed by other asymmetric key algorithms. NIST guidelines state that ECC keys should be twice the length of equivalent strength symmetric key algorithms. So, for example, a 224-bit ECC key would have roughly the same strength as a 112-bit symmetric key.

If ECC is "secure with shorter keys" then the NIST recommendation would be half the length, and a 112 bit ECC key would be roughly as secure as 224 symmetric (it's given the other way around).

In other words this section should read as follows, either of these versions:

• One of the asymmetric algorithm types, elliptic curve cryptography, or ECC, appears to be secure with longer keys than those needed by other asymmetric key algorithms. NIST guidelines state that ECC keys should be twice the length of equivalent strength symmetric key algorithms. So, for example, a 224-bit ECC key would have roughly the same strength as a 112-bit symmetric key.

• One of the asymmetric algorithm types, elliptic curve cryptography, or ECC, appears to be secure with shorter keys than those needed by other asymmetric key algorithms. NIST guidelines state that ECC keys can be half the length of equivalent strength symmetric key algorithms. So, for example, a 112-bit ECC key would have roughly the same strength as a 224-bit symmetric key.

Fix? FT2 ^{(Talk | email)} 00:29, 30 May 2007 (UTC)

Very late reply, but anyway... you misread the paragraph. It says "ECC appears to be secure with shorter keys than those needed by other asymmetric key algorithms [...] So, for example, a 224-bit ECC key would have roughly the same strength as a 112-bit symmetric key." ECC needs shorter keys than (say) RSA, but longer than (say) AES. -- BenRG (talk) 21:12, 28 January 2008 (UTC)

[edit] Quantum Computing?

I am not sufficiently expert to write a suitable section, but should there be a section explaining that most current encryption algorithms are vulnerable to quantum computing techniques, when and if they are sufficiently mature? I would suggest that this branch of computing is much nearer providing routine cracking of present day encryption techniques than Moore's Law would indicate. Of course, we do not know what is happening inside organizations such as GCHQ and NSA! --APRCooper (talk) 14:26, 28 February 2008 (UTC)

I added a section. -- BenRG (talk) 13:36, 5 March 2008 (UTC)

Thanks! --APRCooper (talk) 17:25, 7 March 2008 (UTC)