full-disclosure - RE: Rijndael

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3EA328C6.8020402@info-integrity.com>
From: poirotsj at info-integrity.com (Steve Poirot)
Subject: RE: Rijndael

  There were some requirements concerning the algorithm's ability to run 
in confined environments, with regard to both memory and processing 
power.  I believe the ability or run on a smart card was one of the 
concerns.  Here's a link to a report on the selection process, including 
how the various algorithm's came out against the original evaluation 
criteria: http://csrc.nist.gov/CryptoToolkit/aes/round2/r2report.pdf


Ben Laurie wrote:

>Timmah wrote:
>
>  
>
>>>>>Yes, it was, Belgian or Indian, I think.  I didn't mention it becuse I
>>>>>couldn't remember how to spell it ;)
>>>>>
>>>>>But since it's now the US's AES standard, who knows how strong it is...
>>>>>          
>>>>>
>>>>The designers are Belgian (Flemish).  Not to denigrate them or their work,
>>>>I believe that it was not the strongest of the five AES finalists, and
>>>>this was demonstrated during the last few months before selection.  You
>>>>can interpret that however you want.
>>>>
>>>>        
>>>>
>>>There were other factors in the selection process, not just cryptographic
>>>strength. And some weaknesses have been fixed later.
>>>      
>>>
>>I maintain that the AES selection committee didn't weight factors sanely.
>>Overall security of algorithms in different modes of operation should have
>>been a deal-breaking factor and it was instead sacrificed for speed and
>>other considerations.  That is just a fact.
>>    
>>
>
>IIRC, a key criterion was key scheduling speed. Forgive me for being
>suspicious, but that sounds to me like "we'd like brute force to be
>efficient, please".
>
>Cheers,
>
>Ben.
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030420/5d7fb391/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2962 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030420/5d7fb391/smime.bin