Re: Security Implications of Using the Data Encryption Standard (DES)
| note that there have been (at least) two countermeasures to DES brute-force | attacks ... one is 3DES ... and the other ... mandated for some ATM networks, | has been DUKPT. while DUKPT doesn't change the difficulty of brute-force | attack on single key ... it creates a derived unique key per transaction and | bounds the life-time use of that key to relatively small window (typically | significantly less than what even existing brute-force attacks would take). | The attractiveness of doing such a brute-force attack is further limited | because the typical transaction value is much less than the cost of typical | brute-force attack Bounds on brute-force attacks against DESX - DES with pre- and post-whitening - were proved a number of years ago. They can pretty easily move DES out of the range of reasonable brute force attacks, especially if you change the key reasonably often (but you can safely do thousands of blocks with one key). One can apply the same results to 3DES. Curiously, as far as I know there are to this day no stronger results on the strength of 3DES! I find it interesting that no one seems to have actually made use of these results in fielded systems. Today, we can do 3DES at acceptable speeds in most contexts - and one could argue that it gives better protection against unknown attacks. But it hasn't been so long since 3DES was really too slow to be practical in many places, and straight DES was used instead, despite the vulnerability to brute force. DESX costs you two XOR's - very cheap for what it buys you. Question: How does DUKPT generate its unique keys? If it's using DES on the previous key, or on a counter, or anything simple like that, at best, it's making brute force a bit more expensive - one brute forces a couple of transaction keys, then uses them to brute force the DUKPT key stream. (There are certainly ways to make this much harder, but I wonder what they actually do.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Startup to launch new random number generator from space
| >http://news.zdnet.com/2100-1009_22-6142935.html | > | >British start-up Yuzoz has announced that it will be launching its | >beta service in the next two weeks--an online random-number generator | >driven by astronomical events. | | Heh heh. Pretty amusing. I guess the founders haven't really thought | this through. One problem with such a service, of course, is total | reliance upon Yuzoz: Yuzoz learns all your secret keys -- and so does | any hacker who figures out how to break into Yuzoz's servers. That doesn't | sound like such a great deal -- especially considering that high-quality | random-number sources are not that hard to come by. | | I guess we can take ill-conceived startups like this as a sign of | increasing awareness about the security risks and the need for security | solutions, even if there is some, err, lack of sophistication about how | to distinguish good security technology from bad. (Quantum crypto seems | like another one for that camp. Oracle's "Unbreakable" marketing slogan | was another good one.) There are at least three ways this kind of thing could make sense: 1. As part of something like Rabin's Beacon protocols. For this purpose, you need a reasonable bit rate and confidence that the data really is random and cannot be seen ahead of time by anyone. The assurances that Yuzoz is giving seem to head somewhat in that direction, though I doubt they are really thinking about this. (Granted, the problems Rabin was trying to solve with beacons have since been solved using other techniques. But that doesn't make this kind of thing laughably bad.) 2. As part of a number of techniques in which one generates a long secure sequence by picking bits from a random stream using a key. I think the basic ideas picked them from a high-resolution digitized photo of the moon. The bit rate Yuzoz is proposing is too low to be useful for this purpose except in unusual circumstances. 3. For fun. I think this is clearly the market they are aiming at. Look at their comments about how they picked their own name, for example. Gambling is a big source of many on the Internet, and I can see all kinds of products based on this being sold to gamblers, for example. If you just read the quotes in the article from the CEO, it's clear that he's more concerned about marketing - and especially the connection to space - than about usage in cryptography, or likely and particular usage. How about a nice pet rock laser-inscribed with random bits from Yuzoz? Brings together light, earth, and space - a sure winner. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: gang uses crypto to hide identity theft databases
John wrote: > Once something is gone from RAM, it's really, really gone. The circuit > structure and the laws of thermodynamics ensure it. No power on earth > can do anything about that. This is not =entirely= true. A key stored in the same (non-swappable) location for a long time will burn into the memory. (I know that I am reacting beside the point of your story, to which I agree.) To understand this you have to know that semiconductor materials are filled with ions (stored particles) and that some of those also reside in the isolation layer between capacitor plates. These ions tend to be drawn towards the opposite charge. They actually move a little over time, especially if a system is hot -- this is normal degradation to which all silicon chips are subject. If the charge is consistently applied for a long time, as with long-term key storage, the ions will actually move slightly, thus altering the preferred state at switch-on ever so slightly. When the memory is switched on, this slight preference may be rounded to the bit of the key (or its opposite) because it has to round 0.4999 down or 0.5001 up to form a 0 or 1 bit out of the analog state at switch-on. A well-designed system would of course flip the key bits at regular intervals if they are stored in non-swappable memory for long periods. At least, that's what we have been doing for years :) Cheers, Rick van Rein OpenFortress - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
