factoring out the mode code and more

[Anthony Scarpino]

mark powers wrote:
> 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 think putting it in kcf is a good idea too..  With respect to 
userland, there are two places i can think of, metaslot or softtoken. 
Assuming the kernel library will receive all the modes from the kernel, 
metaslot can remain the same.

With softtoken, i would think it could be handled in a similar way as 
kcf.  Link in a modes object file and have all the algorithm operations 
run through it..

But I like, if possible, that we could keep the ability create a 
self-sustaining module where we could recreate an aes module by sticking 
the module object and algorithm object together.. My rational for this 
is focused on how future hardware accelerators would be designed and how 
best to take advantage of that.  I don't think we know the answer to 
this yet.. just want to cover our bases and not have to go backwards..

> 
>> 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
> 
> _______________________________________________
> crypto-discuss mailing list
> crypto-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crypto-discuss