> 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