> OCB support has been merged in. Closing my own ticket.
Following is not directly related to the case per se [which is why rt
doesn't get this message]. It's just that it makes nice example on why
one sometimes wants to implement encryption mode in assembly. If you
compare performance on AES-NI-capable processor, you'll see significant
differences depending on compiler used. Here is result for clang:
type... 8192 bytes
aes-128-ocb ... 909434.88k
And here is for gcc
aes-128-ocb ... 399447.38k
Thing is that hardware-assisted crypto is so fast that surrounding code
can start dominating execution time. I mean above is indication of such
case. And it also likely to mean that even former above result is
actually far from optimal, it's surely possible to improve it by several
*times*. Indeed, OCB is parallelizeable mode, and it should be close to
other parallelizeable ones. Here is CTR result from same processor:
aes-128-ctr ... 4407367.00k
Well, it's AEAD, so there would be some overhead, but it's minimal in
OCB. But let's compare to GCM anyway:
aes-128-gcm ... 2719591.59k
Once again, this is *not* some kind of objection, only a note that *if*
we decide to consider the mode in question important, it should be
possible to improve it by factor of several times on contemporary CPUs.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
