Entries Tagged "cryptography"
Page 49 of 56
Notes from the Hash Function Workshop
Last month, NIST hosted the Second Hash Workshop, primarily as a vehicle for discussing a replacement strategy for SHA-1. (I liveblogged NIST’s first Cryptographic Hash Workshop here, here, here, here, and here.)
As I’ve written about before, there are some impressive cryptanalytic results against SHA-1. These attacks are still not practical, and the hash function is still operationally secure, but it makes sense for NIST to start looking at replacement strategies—before these attacks get worse.
The conference covered a wide variety of topics (see the agenda for details) on hash function design, hash function attacks, hash function features, and so on.
Perhaps the most interesting part was a panel discussion called “SHA-256 Today and Maybe Something Else in a Few Years: Effects on Research and Design.” Moderated by Paul Hoffman (VPN Consortium) and Arjen Lenstra (Ecole Polytechnique Federale de Lausanne), the panel consisted of Niels Ferguson (Microsoft), Antoine Joux (Universite de Versailles-Saint-Quentin-en-Yvelines), Bart Preneel (Katholieke Universiteit Leuven), Ron Rivest (MIT), and Adi Shamir (Weismann Institute of Science).
Paul Hoffman has posted a composite set of notes from the panel discussion. If you’re interested in the current state of hash function research, it’s well worth reading.
My opinion is that we need a new hash function, and that a NIST-sponsored contest is a great way to stimulate research in the area. I think we need one function and one function only, because users won’t know how to choose between different functions. (It would be smart to design the function with a couple of parameters that can be easily changed to increase security—increase the number of rounds, for example—but it shouldn’t be a variable that users have to decide whether or not to change.) And I think it needs to be secure in the broadest definitions we can come up with: hash functions are the workhorse of cryptographic protocols, and they’re used in all sorts of places for all sorts of reasons in all sorts of applications. We can’t limit the use of hash functions, so we can’t put one out there that’s only secure if used in a certain way.
Media Sanitization and Encryption
Last week NIST released Special Publication 800-88, Guidelines for Media Sanitization.
There is a new paragraph in this document (page 7) that was not in the draft version:
Encryption is not a generally accepted means of sanitization. The increasing power of computers decreases the time needed to crack cipher text and therefore the inability to recover the encrypted data can not be assured.
I have to admit that this doesn’t make any sense to me. If the encryption is done properly, and if the key is properly chosen, then erasing the key—and all copies—is equivalent to erasing the files. And if you’re using full-disk encryption, then erasing the key is equivalent to sanitizing the drive. For that not to be true means that the encryption program isn’t secure.
I think NIST is just confused.
Microsoft and FairUse4WM
If you really want to see Microsoft scramble to patch a hole in its software, don’t look to vulnerabilities that impact countless Internet Explorer users or give intruders control of thousands of Windows machines. Just crack Redmond’s DRM.
Security patches used to be rare. Software vendors were happy to pretend that vulnerabilities in their products were illusory—and then quietly fix the problem in the next software release.
That changed with the full disclosure movement. Independent security researchers started going public with the holes they found, making vulnerabilities impossible for vendors to ignore. Then worms became more common; patching—and patching quickly—became the norm.
But even now, no software vendor likes to issue patches. Every patch is a public admission that the company made a mistake. Moreover, the process diverts engineering resources from new development. Patches annoy users by making them update their software, and piss them off even more if the update doesn’t work properly.
For the vendor, there’s an economic balancing act: how much more will your users be annoyed by unpatched software than they will be by the patch, and is that reduction in annoyance worth the cost of patching?
Since 2003, Microsoft’s strategy to balance these costs and benefits has been to batch patches: instead of issuing them one at a time, it’s been issuing them all together on the second Tuesday of each month. This decreases Microsoft’s development costs and increases the reliability of its patches.
The user pays for this strategy by remaining open to known vulnerabilities for up to a month. On the other hand, users benefit from a predictable schedule: Microsoft can test all the patches that are going out at the same time, which means that patches are more reliable and users are able to install them faster with more confidence.
In the absence of regulation, software liability, or some other mechanism to make unpatched software costly for the vendor, “Patch Tuesday” is the best users are likely to get.
Why? Because it makes near-term financial sense to Microsoft. The company is not a public charity, and if the internet suffers, or if computers are compromised en masse, the economic impact on Microsoft is still minimal.
Microsoft is in the business of making money, and keeping users secure by patching its software is only incidental to that goal.
There’s no better example of this of this principle in action than Microsoft’s behavior around the vulnerability in its digital rights management software PlaysForSure.
Last week, a hacker developed an application called FairUse4WM that strips the copy protection from Windows Media DRM 10 and 11 files.
Now, this isn’t a “vulnerability” in the normal sense of the word: digital rights management is not a feature that users want. Being able to remove copy protection is a good thing for some users, and completely irrelevant for everyone else. No user is ever going to say: “Oh no. I can now play the music I bought for my computer in my car. I must install a patch so I can’t do that anymore.”
But to Microsoft, this vulnerability is a big deal. It affects the company’s relationship with major record labels. It affects the company’s product offerings. It affects the company’s bottom line. Fixing this “vulnerability” is in the company’s best interest; never mind the customer.
So Microsoft wasted no time; it issued a patch three days after learning about the hack. There’s no month-long wait for copyright holders who rely on Microsoft’s DRM.
This clearly demonstrates that economics is a much more powerful motivator than security.
It should surprise no one that the system didn’t stay patched for long. FairUse4WM 1.2 gets around Microsoft’s patch, and also circumvents the copy protection in Windows Media DRM 9 and 11beta2 files.
That was Saturday. Any guess on how long it will take Microsoft to patch Media Player once again? And then how long before the FairUse4WM people update their own software?
Certainly much less time than it will take Microsoft and the recording industry to realize they’re playing a losing game, and that trying to make digital files uncopyable is like trying to make water not wet.
If Microsoft abandoned this Sisyphean effort and put the same development effort into building a fast and reliable patching system, the entire internet would benefit. But simple economics says it probably never will.
This essay originally appeared on Wired.com.
EDITED TO ADD (9/8): Commentary.
EDITED TO ADD (9/9): Microsoft released a patch for FairUse4WM 1.2 on Thursday, September 7th.
EDITED TO ADD (9/13): BSkyB halts download service because of the breaks.
EDITED TO ADD (9/16): Microsoft is threatening legal action against people hosting copies of FairUse4WM.
Brute Forcing Combination Locks
This computerized servomotor opens combination locks by brute forcing all the combinations. This isn’t particular surprising, but it is nice to see some actually build one.
What’s more interesting is the link describing how to open a common Master brand lock in about 10 minutes. The design makes those 403 possible combinations collapse to 121. It’s a physical metaphor for bad cryptography.
The Doghouse: Sniper Flash Cards
They have a cryptanalysis contest with a $5,000 prize, but a $100 entry fee.
Sounds like a scam to me.
(My comments on cracking contests can be seen here.)
Galileo Satellite Code Cracked
Members of Cornell’s Global Positioning System (GPS) Laboratory have cracked the so-called pseudo random number (PRN) codes of Europe’s first global navigation satellite, despite efforts to keep the codes secret. That means free access for consumers who use navigation devices—including handheld receivers and systems installed in vehicles—that need PRNs to listen to satellites.
Security by obscurity: it doesn’t work, and it’s a royal pain to recover when it fails.
Privacy-Enhanced Data Mining
There are a variety of encryption technologies that allow you to analyze data without knowing details of the data:
Largely by employing the head-spinning principles of cryptography, the researchers say they can ensure that law enforcement, intelligence agencies and private companies can sift through huge databases without seeing names and identifying details in the records.
For example, manifests of airplane passengers could be compared with terrorist watch lists—without airline staff or government agents seeing the actual names on the other side’s list. Only if a match were made would a computer alert each side to uncloak the record and probe further.
“If it’s possible to anonymize data and produce … the same results as clear text, why not?” John Bliss, a privacy lawyer in IBM’s “entity analytics” unit, told a recent workshop on the subject at Harvard University.
This is nothing new. I’ve seen papers on this sort of stuff since the late 1980s. The problem is that no one in law enforcement has any incentive to use them. Privacy is rarely a technological problem; it’s far more often a social or economic problem.
The Doghouse: KRYPTO 2.0
The website is hysterical:
Why are 256 bits the technically highest coding depth at all on computers possible are ?
A computer knows only 256 different indications.
1 indication = 1 byte has 8 bits in binary the number system exactly.
1 bit knows only the switching status: on or out or 0 or 1 by the combination of these 8 bits results 256 bits.
The computation in addition: 2 switching status highly 8 bits = 256 bits these 256 bits
is addressed in decimally the number system from 0 to 255 = 256 bits.
Computers work however in in hexadecimals the number system.
There these 256 bits designated above are addressed from 00 to FF = 256 bits.
A byte cannot be thus under bits 0 or over bits 255.
Therefore 256 bits are the technically highest coding depth at all on computers
possible are.Proof of the Krypto security !
Which would be, if one would try one of Krypto coded file unauthorized to decode.
A coded file with the length of 18033 indications has therefore according to computation, 256 bits highly 18033 indications = 6,184355814363201353319227173630ë+43427
file possibilities. Each file possibility has exactly 18033 indications byte.
Multiplied by the number of file possibilities then need results in the memory.
Those are then: 1,1152248840041161000440562362208e+43432 byte.
Those are then: 1,038634110245961789082788150963è+43423 Giga byte data quantity.
That is a number with 43424 places.
I can surely maintain as much memory place give it in the whole world not never.
And the head problem now is, which is now the correctly decoded file.
Who it does not know can only say there. That does not know so exactly !
They can code naturally naturally also still successively several times, even up to
the infinity.
My head hurts just trying to read that.
University Crypto Class Materials Available Online
You can audit “Welcome to Practical Aspects of Modern Cryptography.” It was taught at the University of Washington, Winter 2006, by Josh Benaloh, Brian LaMacchia, and John Manderdelli. The course materials and videos of the lectures are online.
Sidebar photo of Bruce Schneier by Joe MacInnis.