Is there a mailing list that I can ask Rijndael-specific questions?
On Sat, Mar 16, 2013 at 3:25 AM, Ewen Chan <chan.e...@gmail.com> wrote: > Interesting... > > Does this necessarily implicitly implies that the Rijndael cipher was > selected as the AES "winner" because it was also "simple" enough to be > fast, while meeting the security and protection requirements when they > initiated the open call for proposals? > > I didn't realize that the AES and also modern processors were so fast > already. I always thought that AES was going to be a fairly slow and > compute-intensive process; and so that's why I was trying to make sure > that the AES-NI was working. Turns out, I might not even need it. #FML > > (And I'm pretty sure that some of you guys were probably telling me > that, but I didn't realize it then. Now I see the light.) > > On Sat, Mar 16, 2013 at 1:29 AM, Matthew Hall <mh...@mhcomputing.net> wrote: >> On Sat, Mar 16, 2013 at 01:16:23AM -0400, Ewen Chan wrote: >>> Okay then, here's another one of my infamous dumb questions. >>> >>> If that's the case, then why do we need the AES-NI instruction set? >> >> It's far from the first accelerated instruction set of dubious utility. ;) >> >> Marketing... etc. >> >> Actually, SSL / TLS performance is much more greatly increased by an RSA >> accelerator. If I were Intel I would have made that first, before AES-NI, >> because RSA signs and verifies consume a lot more resources and are a lot >> more >> vulnerable to DoS than AES. But, of course, RSA is more complex. >> >> The tech companies are not trying to make the best possible product, but the >> best product that's economically feasible, which is a slightly different >> goal. >> >>> If it's likely going to be storage and/or network bandwidth limited; >>> wouldn't the improvements made by introducing and incorporating the >>> AES-NI instruction set be kind of "wasted" in the sense that you can't >>> really use it to the fullest potential anyways? >> >> Amdahl's Law: the amount of overall improvement of performance by improving >> an >> area is proportional to the amount that area is executed. >> >>> If the storage/network I/O is going to be your bottleneck/limiting >>> factor, then regardless of whether you have AES-NI or not; you're >>> likely going to get the same answer in terms of speed. >> >> Yes! >> >>> Also, is that why (besides the fact that CBC can't be parallelized) >>> why it doesn't make sense or people really haven't spent too much time >>> or effort into trying to run AES encryption/decryption on GPGPUs? >>> Because it's already faster than anything else is capable of at the >>> moment? >> >> Like Erwann said, the memory transfers would likely cost more time than using >> AES-NI. >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
