Re: ABLKCIPHER

[Kim Phillips <kim.phillips@freescale.com>]

On Mon, 15 Mar 2010 15:23:36 +0000
Dimitrios Siganos <dimitris@siganos.org> wrote:

> Herbert Xu wrote:
> > Dimitrios Siganos <dimitris@siganos.org> wrote:
> >   
> >> Hi,
> >>
> >> I am trying to write an ABLKCIPHER algorithm for my hardware crypto 
> >> engine and I have a few questions:
> >>
> >> 1) In struct ablkcipher_alg, what do these fields do? I see some 
> >> implementations use them and some not. Do I need to implement them?
> >>    int (*givencrypt)(struct skcipher_givcrypt_request *req);
> >>    int (*givdecrypt)(struct skcipher_givcrypt_request *req);
> >>    const char *geniv;
> >>     
> >
> > These do not have to be implemented, unless your hardware is
> > capable of generating initial IVs (e.g., through a secure RNG).
> >   
> My hardware (Freescale i.MX51) has a random number generator. I think I 

huh, I thought that part's crypto unit would have a lot in common with
the talitos block, but public documentation for Sahara leaves a lot to
be desired...

> am confused about the giv..crypt concept in general. How is it supposed 
> to work?
> 
> Let's say I want to do the classic cbc(aes). The steps are:
> 1) allocate a tfm object
> 2) set the key
> 3) set the iv
> 4) encrypt as many times as needed
> 5) cleanup
> 
> I can do this without the giv functions. Do the giv apply in this case?

I'm going to assume that aead matches ablkcipher in this regard:

If the h/w doesn't support generating IVs, specify a .geniv string so
that software will generate the IV before the driver's .encrypt() is
called.

If the h/w is going to generate the IV, omit the .geniv string,
and implement givencrypt() such that it instructs your h/w to generate
and place a new IV at the req->giv address.

But this is assuming Sahara h/w can generate random numbers that fast.
If it's anything like the talitos parts, it may have an IPsec-specific
descriptor that allows for a pseudo-IV generation specification.

hth,

Kim