|
search / subscribe / upload / contact |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| RSS-Feed Depeschen |  |
|
|
||
|
||
Date: 2000-04-18
Crypto: Nachfolge von DES-.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- der Algorithmus sein, der den antiken DES ablöst? Bruce Schneier [Mitautor von Twofish] zählt Vor- und Nachteile der Kandidaten auf. -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- The Advanced Encryption Standard (AES) is the forthcoming encryption standard that will replace the aging DES. In 1996, the National Institute of Standards and Technology (NIST) initiated this program. In 1997, they sent out a call for algorithms. Fifteen candidates were accepted in 1998, whittled down to five in 1999. This past week was the Third AES Candidate Conference in New York. Attendees presented 23 papers (in addition to the 7 AES-related papers presented at Fast Software Encryption earlier in the week) and 12 informal talks (more papers are on the AES website), as NIST prepares to make a final decision later this year. Several of the algorithms took a beating cryptographically. RC6 was wounded most seriously: two groups were able to break 15 out of 20 rounds faster than brute force. Rijndael fared somewhat better: 7 rounds broken out of 10/12/14 rounds. Several attacks were presented against MARS, the most interesting breaking 11 of 16 rounds of the cryptographic core. Serpent and Twofish did best: the most severe Serpent attack broke 9 of 32 rounds, and no new Twofish attacks were presented. (Lars Knudsen presented an attack at the FSE rump session, which he retracted as unworkable two days later. Our team also showed that an attack on reduced-round Twofish we presented earlier did not actually work.) It's important to look at these results in context. None of these attacks against reduced-round variants of the algorithms are realistic, in that they could be used to recover plaintext in any reasonable amount of time. They are all "academic" attacks, since they all show design weaknesses of the ciphers. If you were using these algorithms to keep secrets, none of these attacks would cause you to lose sleep at night. If you're trying to select one of five algorithms as a standard, all of these attacks are very interesting. As the NSA saying goes: "Attacks always get better; they never get worse." When choosing between different algorithms, it's smarter to pick the one that has the fewest and least severe attacks. (This assumes, of course, that all other considerations are equal.) The worry isn't that someone else discovers another unrealistic attack against one of the ciphers, but that someone turns one of those unrealistic attacks into a realistic one. It's smart to give yourself as large a security margin as possible. Many papers discussed performance of the various algorithms. If there's anything I learned, it's that you can define "performance" in all sorts of ways to prove all sorts of things. This is what the trends were: In software, Rijndael and Twofish are fastest. RC6 and MARS are also fast, on the few platforms that have fast multiplies and data-dependent rotates. They're slow on smart cards, ARM chips, and the new Intel chips (Itanium and beyond). They're fast on Pentium Pro, Pentium II, and Pentium III. Serpent is very slow everywere. In hardware, Rijndael and Serpent are fastest. Twofish is good. RC6 is poor, and MARS is terrible. The only two algorithms that had such implementation problems that I would categorically eliminate them were Mars and RC6. MARS is so bad in hardware that it would be a disaster for Internet applications, and RC6 is close. And both algorithms just don't fit on small smart cards. (The RC6 team made a comment about being suitable for cheap--$5-- smart cards. I am talking about $0.25 smart cards.) I would increase the number of rounds in Rijndael to give it a safety margin similar to the others. Either Serpent, Twofish, and 18-round Rijndael would make a good standard, but I think that Twofish gives the best security to performance trade-off of the three, and has the most implementation flexibility. So I support Twofish for AES. The deadline for comments is May 15. I urge you to comment. As many of the papers and comments indicate, this decision is more about suitability than security. NIST needs to know what is important to you: efficiency on cheap 8-bit smart cards, key agility in hardware, bulk encryption speed, gate count in hardware, etc. If you like the idea of multiple algorithms, tell them. If you don't, tell them. Once NIST chooses an AES we're all going to be stuck with it; customers will demand that products be "AES compatible." Now's your chance to influence how onerous that demand will be. NIST AES website: <http://www.nist.gov/aes> For the record, I am one of the creators of Twofish: <http://www.counterpane.com/twofish.html> -.- -.-. Connectivity statt Isolierung http://o5.or.at -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- edited by Harkank published on: 2000-04-18 comments to [email protected] subscribe Newsletter - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- 
|
|
|
 |
CURRENTLY RUNNING |
q/Talk 1.Juli: The Danger of Software Users Don't Control
|
|
|
!WATCH OUT! |
bits4free 14.Juli 2011: OpenStreetMap Erfinder Steve Coast live in Wien
|
|