RE: Losing the Code War by Stephen Budiansky
Ben wrote: marius wrote: ... Not quite true. Encrypting each message twice would not increase the effective key size to 112 bits. There is an attack named meet in the middle which will make the effective key size to be just 63 bits. ?? 56 bits plus a little, surely. The `meet in the middle` attack works against double encryption; that's why Triple DES is performing three DES operations with two keys. There are some attacks also against using three encryptions with two keys and against Triple DES (encryption-decryption-encryption). But the attacks I know require huge amounts of chosen plaintext or known plaintext. In particular with t known plaintext-ciphertext pairs, the known attack on triple-DES requires 2^120-log(t) operations. I think most applications can limit the amount of known plaintexts to a million; this means the complexity of attacking triple-DES is at least 2^100, which is probably sufficiently secure for most applications. Of course, using three different keys for the three DES operations (in triple DES or simply in triple encryptions by DES) is expected to considerably improve security. I think the edge of AES is mostly when improved performance (esp. in software) is needed. Cheers, Amir Herzberg See http://amir.beesites.co.il/book.html for lectures and notes (draft of chapters) on `secure communication and commerce using cryptography`; feedback welcome! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Losing the Code War by Stephen Budiansky
Amir Herzberg wrote: The `meet in the middle` attack works against double encryption; that's why Triple DES is performing three DES operations with two keys. Some variants use 3 keys, in fact. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Welome to the Internet, here's your private key
-- On 4 Feb 2002, at 3:09, Peter Gutmann wrote: It is accepted practice among security people that you generate your own private key. It is also, unfortunately, accepted practice among non-security people that your CA generates your private key for you and then mails it to you as a PKCS #12 file (for bonus points the password is often included in the same or another email). Requests to have the client generate the key themselves and submit the public portion for certification are met with bafflement, outright refusal, or at best grudging acceptance if they're big enough to have some clout. This isn't a one-off exception, this is more or less the norm for private industry working with established (rather than internal, roll-your-own) CAs. This isn't the outcome of pressure from shadowy government agencies, this is just how things are done. Be afraid. The public key infrastructure is simply not working. Ordinary mortals do not understand how it works, therefore cannot use it correctly. Certified public keys are therefore of limited value. This is in part a result of an impenetrable and incomprehensible user interface that makes what is hard to understand far harder. For example I can see no good reason why an active X control with public source cannot generate your private key -- so that as far as the normal user knows he is getting it from the authority by logging in to their web page. We had this arrangement some years ago -- what happened to it? I just learnt that Windows 2000 and Windows XP construct a key pair for every user. The interface around this seems designed to be utterly impenetrable, as though they were trying to protect against stupid users by using security by obscurity. With Windows XP, we enter a world where everyone has a key pair securing his stuff -- and is unaware of it, and unable to use it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG E2AfFWpRWRrQk9TjIHVW4PIkCIefZn7D7LUkwgdH 4144WI1nmwDQ3k7tCTyZ3dyJFywdh8RkiPnOEv0gj - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]