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
