factoring out the mode code and more

[mark powers]

Darren J Moffat wrote:
> This is wonderful.
>
> I think the "gain" will be even more as we add new modes such as XTS, 
> GCM.
>
> I realise you have just prototyped CBC mode at the moment, but I want 
> to make sure you know that for ZFS Crypto Tony had to add CBC_PAD as 
> well and I believe it will benefit in a similar way.
>
> If I understand correctly what you are doing there will be common 
> "modes" code between userland and kernel as well ?  If so this is 
> great news since it means we should no longer endup with things like 
> AES_CCM supported in kernel but not in userland (subject to their 
> being the PKCS#11 mech definitions available).

Yes - common mode source shared between userland and kernel. The only 
question is where to put the binary.
For the kernel, does it belong in the kcf module or a separate module 
(like the bignum module that Ferenc
has worked on). I lean towards kcf since the mode code (and friends) has 
no applicability outside the
Solaris Cryptographic Framework. For userland, does it belong in 
softtoken, libcryoutil, or somewhere else?

>
> I'm not really concerned about the small percentage drops for DES.  
> The AES ones seem to be in the noise.  The Blowfish ones are interesting.
>
> It would be worth mapping these onto what the consumers of KCF 
> actually do.
Agreed. Measuring the impact on kernel consumers is at probably equal to 
the amount of development time. :-(

>
> For example with ZFS Crypto we only use AES and (currently I'm looking 
> at switching AES_CCM to use UIO (again)) only use RAW, we don't do 
> in-place crypto and don't currently have ctx_tmpl used (though I plan 
> to fix that).
>
> Have a look at how KSSL, IPsec, Kerberos actually call us.
>
> -- 
> Darren J Moffat