On Tue, Apr 3, 2018 at 3:22 PM, Milan Broz <gmazyl...@gmail.com> wrote:
> On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote:
>>> Are there other crypto drivers doing this?
>> I thought the exact same thing until I ran into a presentation about the s390
>> secure keys implementation. I basically imitated their use (or abuse?)
>> of the Crypto API
>> assuming it is the way to go.
>> Take a look at arch/s390/crypto/paes_s390.c
>> The slide for the presentation describing this is here:
>> And they seem to even have support for it in the DM-Crypt tools, which at
>> the time they claimed to be in the process of getting it up-streamed.
> It is "in the process", but definitely not accepted.
> We are just discussing how to integrate paes wrapped keys in cryptsetup and
> it will definitely not be the way presented in the slides above.
> If you plan more such ciphers, I would welcome some unified way in crypto API
> how to handle these HSM keys flavors.
That would be good. Note however the fine difference - the s390 usage
is a wrapped key.
Ours is a token for a key (a slot number really). Probably makes no
difference for any
practical sense, but I thought it is worth mentioning it.
> For kernel dm-crypt, there is no change needed (dmcrypt just treats it as a
> normal cipher key).
> (I would say that it is not the best idea either, IMHO it would be better to
> kernel keyring reference instead and somehow handle hw keys through keyring.)
I am all for the keyring approach. In fact, that was the way I wanted
to to go to introduce this feature
for cryptocell when I discovered that was already upstream code using
a different approach.
Any suggestion how this would work vis a vis the crypto API usage?
e.g. - have a parallel setkey variant added to crypto APi that takes a
kernel keyring object rather than actual key?
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru