Re: Security Implications of Using the Data Encryption Standard (DES)
Leichter, Jerry wrote: | 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. The IETF/IESG refused to publish the ESP DES-XEX3-CBC Transform submitted as draft-ietf-ipsec-ciph-desx-00 (1997) and draft-simpson-desx-01 and draft-simpson-desx-02 (1998). Of course, they also refused to publish draft-simpson-des-as-00 (1998) and draft-simpson-des-as-01 (1999) that deprecated DES -- despite strong votes of support at SAAG and PPP meetings. There was an Appeal of IESG inaction, decisions of 13 Oct 1999 and 16 Feb 1999. http://www1.ietf.org/mail-archive/web/ietf/current/msg11160.html The NSA and Cisco folks that were involved in IKE/ISAKMP advocated DES, refusing to assign code points for DESX. Gosh, I wonder why - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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]
