Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: Kent Borg [mailto:kentborg at borg.org] > Sent: Wednesday, August 14, 2013 10:25 AM > > But you don't mean AES-128 can be broken today with 2^64 operations, do > you? That sounds wrong--or theoretical. I found my book (Cryptography Engineering) and looked it up. The answer is: "Most modern block ciphers have a 128-bit block size, but they operate on 32-bit words. They build the encryption function from many 32-bit operations. This has proved to be a very successful method, but it has one side effect. It is rather hard to build an odd permutation from small operations; as a result, virtually all block ciphers only generate even permutations." "This [] has no practical significance whatsoever." So, the even/odd permutation thing is a completely unrelated red herring. The important question is regarding key length: "A 128-bit key would be great, except for one problem: collision attacks. Time and time again, we find systems that can be attacked -- at least theoretically, if not practically -- by a birthday attack or a meet-in-the-middle attack. We know these attacks exist. Sometimes designers just ignore them, and sometimes they think they are safe, but somebody finds a new, clever way of using them. Most block cipher modes allow meet-in-the-middle attacks of some form. We've had enough of this race, so here is our recommendation: For a security level of n bits, every cryptographic value should be at least 2n bits long." In other words, if you want 128 bits of security, use a 256 bit key. Uncrackable by an international superpower within a lifetime. If you use a 128 bit key, you should assume it's crackable in 2^64 operations, which can be achieved by a schmo with a laptop. Maybe not in reality, maybe not in every situation, but take it as a baseline assumption.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |