factoring out the mode code and more

[Anthony Scarpino]

mark powers wrote:
> I would like to propose the factoring out and parameterization of algorithm
> mode code, e.g. ECB and CBC, that is duplicated in softtoken as well as
> various kernel providers (both hardware and software). For example,
> aes_cbc_encrypt_contiguous_blocks() would become 
> cbc_encrypt_contiguous_blocks()
> with additional parameters for an algorithm specific block encryption 
> routine,
> a block copy routine, and a block XOR routine.

I'm all for that..

> 
> Routines that handle data formats could also be made generic by adding
> additional parameters. For example aes_cipher_update_iov() could become
> cipher_update_iov() by adding two additional parameters for a algorithm
> specific block encryption routine and block copy routine.
> 
> Cut/paste copies abound, e.g. copy_key_to_ctx().
> 
> This is not the most interesting work but it is work that needs to be done.
> Modularization is always good and duplicate routines are most always
> bad. This would result in smaller and more modular providers.

Good stuff!  hopefully this will make our lives easier in the future..

> 
> I have working code for CBC mode and have obtained the following numbers.
> Positive numbers represent a percent increase in execution time (bad);
> negative numbers represent a decrease. Tests were run on a sun4v using
> the stc2 kernel performance test, e.g.
> 'cryperf_cmd -m CKM_AES_CBC -i 1000 -s 1600'.
> 
> Test Description                         AES         Blowfish    DES
> --------------------------------------------------------------------------
> decrypt MBLK no ctx_tmpl in-place       -0.7056294  -0.155349    0.3140838
> decrypt MBLK no ctx_tmpl not in-place   -0.596724    0.8790499   1.9297353
> decrypt MBLK with ctx_tmpl in-place      0.3312157  -0.5511493  -0.1187767
> decrypt MBLK with ctx_tmpl not in-place  0.3557175   3.1672403   1.437967
> decrypt RAW no ctx_tmpl in-place        -0.6246451  -0.1557791   0.3585965
> decrypt RAW no ctx_tmpl not in-place    -0.6174762   0.8615217   2.2032619
> decrypt RAW with ctx_tmpl in-place       0.0713436  -0.5460843  -0.222882
> decrypt RAW with ctx_tmpl not in-place  -0.1375983   3.1271017   1.3236677
> decrypt UIO no ctx_tmpl in-place        -0.7118715  -0.1385048   0.270597
> decrypt UIO no ctx_tmpl not in-place    -0.3315865   0.7249463   1.8685502
> decrypt UIO with ctx_tmpl in-place       0.10926    -0.5672195   0.0704959
> decrypt UIO with ctx_tmpl not in-place   0.4491429   2.6794898   1.5629129
> encrypt MBLK no ctx_tmpl in-place       -0.0652814  -0.0782052   0.5574273
> encrypt MBLK no ctx_tmpl not in-place   -0.5442802   1.0515774   2.4623328
> encrypt MBLK with ctx_tmpl in-place     -0.1152394  -0.2715053   0.334237
> encrypt MBLK with ctx_tmpl not in-place -0.1140231   3.8085545   1.9412041
> encrypt RAW no ctx_tmpl in-place        -0.0227794  -0.0743264   0.6902638
> encrypt RAW no ctx_tmpl not in-place     0.2266514   0.944803    2.5581755
> encrypt RAW with ctx_tmpl in-place       0.0765947  -0.3225215  -0.0158841
> encrypt RAW with ctx_tmpl not in-place   0.3697104   3.3197377   1.9408673
> encrypt UIO no ctx_tmpl in-place        -0.1278967  -0.0602069   0.5402997
> encrypt UIO no ctx_tmpl not in-place     0.3321964   0.9407582   2.0355516
> encrypt UIO with ctx_tmpl in-place       0.0967105  -0.2433845   0.3593826
> encrypt UIO with ctx_tmpl not in-place   0.9618294   3.3013999   1.8216312

Know a bit about the performance tests in the stc2 gate, have you run 
them a number of times to make sure these increases and decreases are 
consistent?  Seem to remember variations performance numbers in the 
past, but that may not be specific with this particular test..

Is there any visible reason why blowfish should stuff 3% performance 
loss with ctx_tmpl not in_place consistently?  Is the current blowfish 
cbc module assuming something that makes it faster?  it seems that 
generally most of the not in-place operations performed worse that the 
in-place.

> 
> Taking this one step further, it might be possible to synthesize the 
> various
> modes totally within the kef module. The only problem is that it would 
> probably
> result in poor performance for hardware providers handling asynchronous 
> requests
> since there would be an asynchronous request/reply for every block.
> 
> _______________________________________________
> crypto-discuss mailing list
> crypto-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crypto-discuss