Slashdot Mirror
PGP Moving To Stronger SHA Algorithms
PGP Corp. is moving to a stronger SHA Algorithm (SHA-256 and SHA-512) as consequence of the research conducted by the team at Shandong University in China who broke the SHA-1 algorithm. (See this earlier story for more information on the SHA-1 vulnerability.)
... who broke the SHA-1 algorithm.
They did not break it. They just found a way to reduce the number of trials needed to find a collision.
Technically, that would simply double the number of operations required to perform the decryption, which does not effectively raise its complexity..
ie. say it takes n time to crack a hash, then cracking a hash of a hash would take 2n...
O(2n) is still O(n)
Of course that's assuming they aren't doing it by "eye" and they have some sort of solid algorithm to do it.
- shazow
There's a discussion about this very subject going on on the IMC's discussion list for OpenPGP. From reading the posts, particularly the ones by PGP's Jon Callas, I don't think that PGP has officially decided to implement this change just yet. (On the list, the thread titled "SHA-1 broken" is the one you will want to follow.)
But then, I could have missed something.
IIRC, GPG already allows SHA-256 and SHA-512, but doesn't default to them.
I do see your point, but remember that you could argue the RSA is useless because if I did it over a 32 bit address space it's easy to prime-factorize any number and therefore increasing it to a 2048 bit space is "just avoiding the problem". As CPU power increases it becomes more economical to move to more complex hash/ecryption schemes over larger address spaces. And there's even good news: it's a hell of a lot cheaper for me to move my PC to a new SHA system than it will be to crack it, even with the algorithm issues.
AntiFA: An abbreviation for Anti First Amendment.
It seems like the way to fix the problem (make the encrypted data difficult enough to decode using brute force methods) is to move up to stronger algorithms. This happens continuously, it doesnt mean that the old alogorithm was initially flawed, but rather it has become obsolete due to increasing computing power. As computing power increases, this means it takes less time to decode an algorithm using a trail and error brute force process.
The user should be able to choose from several algorithms depending on their needs, their are tradeoffs for each. A stronger one will require more computing power but will be more difficult to decode using a brute force attack, and will tend to last longer agianst increasing processing power of computers. A weaker one will be much faster but also it is more trivial to decode it with a brute force attack, and as computing power increases it will become more trivial to decode via an attack. Thus there is a constant interaction between CPU speed and algorithms, as faster CPUs arise, this means stronger algorithms are needed as the older ones which were too impractical to easily attack on older CPUs have become trivial to decode on newer CPUs. However, since the CPUs have since become faster, it also means that it takes less time to encrypt the data in any particular algorithm, so while stronger algorithms are needed due to increasing CPU power, those algorithms also become more practical due to increasing CPU power.
Is there a reason to wait until someone breaks the existing algorithm before moving to a stronger one?
It seems to me that if you start working on implementing the stronger ones BEFORE your existing one is broken?
Because of the chance that someone might find a weakness in the supposedly stronger one before a weakness is found in the supposedly weaker one.
Since you don't know which algorithm is going to be broken first, you pick one based on other advantages, like wider availability and more efficient calculation.
And, BTW, SHA-1 is not cracked wide open yet; it just looks worryingly like a usable flaw will be found in the very near future. Therefore, people are moving away from it. An ounce of prevention... exactly like you said.
Just to confirm, GPG 1.4 DOES support the more-bits versions of SHA. Run GPG with the --version parameter to get something like this for your copy:
There's no fool-proof "solution" to this problem. The key (no pun intended) is to keep a high enough ratio between hash length (or key length) and the kind of processing power that potential crackers (including the NSA) can be thought to have access to.
Thus, as the processing power of the world increases, so do we increase the hash/key lengths. There's nothing strange about that, if you ask me -- especially considering how the required processing power increases exponentially with the hash/key length in use.
In short, having two different hashes doesn't add more security (at least not significantly more) than just doubling the hash length.