Security of the SHA Family of Hash Functions
Good article on the insecurity of SHA-1 and the need to replace it sooner rather than later.
Entries Tagged "security standards"
Page 2 of 3
How NIST Develops Cryptographic Standards
This document gives a good overview of how NIST develops cryptographic standards and guidelines. It’s still in draft, and comments are appreciated.
Given that NIST has been tainted by the NSA’s actions to subvert cryptographic standards and protocols, more transparency in this process is appreciated. I think NIST is doing a fine job and that it’s not shilling for the NSA, but it needs to do more to convince the world of that.
Will Keccak = SHA-3?
Last year, NIST selected Keccak as the winner of the SHA-3 hash function competition. Yes, I would have rather my own Skein had won, but it was a good choice.
But last August, John Kelsey announced some changes to Keccak in a talk (slides 44-48 are relevant). Basically, the security levels were reduced and some internal changes to the algorithm were made, all in the name of software performance.
Normally, this wouldn’t be a big deal. But in light of the Snowden documents that reveal that the NSA has attempted to intentionally weaken cryptographic standards, this is a huge deal. There is too much mistrust in the air. NIST risks publishing an algorithm that no one will trust and no one (except those forced) will use.
At this point, they simply have to standardize on Keccak as submitted and as selected.
CDT has a great post about this.
Also this Slashdot thread.
EDITED TO ADD (10/5): It’s worth reading the response from the Keccak team on this issue.
I misspoke when I wrote that NIST made “internal changes” to the algorithm. That was sloppy of me. The Keccak permutation remains unchanged. What NIST proposed was reducing the hash function’s capacity in the name of performance. One of Keccak’s nice features is that it’s highly tunable.
I do not believe that the NIST changes were suggested by the NSA. Nor do I believe that the changes make the algorithm easier to break by the NSA. I believe NIST made the changes in good faith, and the result is a better security/performance trade-off. My problem with the changes isn’t cryptographic, it’s perceptual. There is so little trust in the NSA right now, and that mistrust is reflecting on NIST. I worry that the changed algorithm won’t be accepted by an understandably skeptical security community, and that no one will use SHA-3 as a result.
This is a lousy outcome. NIST has done a great job with cryptographic competitions: both a decade ago with AES and now with SHA-3. This is just another effect of the NSA’s actions draining the trust out of the Internet.
Good Summary of Potential NSA Involvement in a NIST RNG Standard
Kim Zetter has written the definitive story—at least so far—of the possible backdoor in the Dual_EC_DRBG random number generator that’s part of the NIST SP800-90 standard.
Ed Felten on the NSA Disclosures
Ed Felten has an excellent essay on the damage caused by the NSA secretly breaking the security of Internet systems:
In security, the worst case—the thing you most want to avoid—is thinking you are secure when you’re not. And that’s exactly what the NSA seems to be trying to perpetuate.
Suppose you’re driving a car that has no brakes. If you know you have no brakes, then you can drive very slowly, or just get out and walk. What is deadly is thinking you have the ability to stop, until you stomp on the brake pedal and nothing happens. It’s the same way with security: if you know your communications aren’t secure, you can be careful about what you say; but if you think mistakenly that you’re safe, you’re sure to get in trouble.
So the problem is not (only) that we’re unsafe. It’s that “the N.S.A. wants to keep it that way.” The NSA wants to make sure we remain vulnerable.
PCI Lawsuit
This is a first:
…the McCombs allege that the bank, and the payment card industry (PCI) in general, force merchants to sign one-sided contracts that are based on information that arbitrarily changes without notice, and that they impose random fines on merchants without providing proof of a breach or of fraudulent losses and without allowing merchants a meaningful opportunity to dispute claims before money is seized.
It’s the first known case to challenge the heart of the self-regulated PCI security standards a system that requires businesses accepting credit and debit card payments to implement a series of technological steps to secure data. The controversial system, imposed on merchants by credit card companies like Visa and MasterCard, has been called a “near scam” by a spokesman for the National Retail Federation and others who say it’s designed less to secure card data than to profit credit card companies while giving them executive powers of punishment through a mandated compliance system that has no oversight.
The PCI standards are probably the biggest non-government security standard. It’ll be interesting to see how this turns out.
Dilbert on Security Standards
So true (the predecessor).
EDITED TO ADD (10/13): XKCD makes the sam point.
Problems with Twitter's OAuth Authentication System
Interesting case study.
FIPS 140-2 Level 2 Certified USB Memory Stick Cracked
Kind of a dumb mistake:
The USB drives in question encrypt the stored data via the practically uncrackable AES 256-bit hardware encryption system. Therefore, the main point of attack for accessing the plain text data stored on the drive is the password entry mechanism. When analysing the relevant Windows program, the SySS security experts found a rather blatant flaw that has quite obviously slipped through testers’ nets. During a successful authorisation procedure the program will, irrespective of the password, always send the same character string to the drive after performing various crypto operations—and this is the case for all USB Flash drives of this type.
Cracking the drives is therefore quite simple. The SySS experts wrote a small tool for the active password entry program’s RAM which always made sure that the appropriate string was sent to the drive, irrespective of the password entered and as a result gained immediate access to all the data on the drive. The vulnerable devices include the Kingston DataTraveler BlackBox, the SanDisk Cruzer Enterprise FIPS Edition and the Verbatim Corporate Secure FIPS Edition.
Nice piece of analysis work.
The article goes on to question the value of the FIPS certification:
The real question, however, remains unanswered how could USB Flash drives that exhibit such a serious security hole be given one of the highest certificates for crypto devices? Even more importantly, perhaps what is the value of a certification that fails to detect such holes?
The problem is that no one really understands what a FIPS 140-2 certification means. Instead, they think something like: “This crypto thingy is certified, so it must be secure.” In fact, FIPS 140-2 Level 2 certification only means that certain good algorithms are used, and that there is some level of tamper resistance and tamper evidence. Marketing departments of security take advantage of this confusion—it’s not only FIPS 140, it’s all the security standards—and encourage their customers to equate conformance to the standard with security.
So when that equivalence is demonstrated to be false, people are surprised.
Sidebar photo of Bruce Schneier by Joe MacInnis.