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;
2) What is a CRYPTO_ALG_TYPE_GIVCIPHER? What does it do and how does it
interface to other algorithms?
In case, it is important; we are using linux-2.6.28 but we will soon
move to linux-2.6.31. The ultimate goal is to accelerate
authenc(cbc(aes),hmac(sha1)) and I am currently implementing the simpler
algorithms as a learning exercise.
Regards,
Dimitris
Dimitrios Siganos <[email protected]> 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).
> 2) What is a CRYPTO_ALG_TYPE_GIVCIPHER? What does it do and how does it
> interface to other algorithms?
That's the type to use if you do choose to provide givencrypt
and givdecrypt.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu wrote:
> Dimitrios Siganos <[email protected]> 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
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?
You said that with the giv functions, the hardware generates the iv
automatically. So if I used the giv functions, does the sequence of
steps above, become:
1) allocate a tfm object
2) set the key
4) givencrypt
5) read the generated iv (so it can somehow passed to the decryptor)
6) encrypt as many times as needed
7) cleanup
>> 2) What is a CRYPTO_ALG_TYPE_GIVCIPHER? What does it do and how does it
>> interface to other algorithms?
>>
>
> That's the type to use if you do choose to provide givencrypt
> and givdecrypt.
>
Can you point me to a simple example, if one exists?
On Mon, 15 Mar 2010 15:23:36 +0000
Dimitrios Siganos <[email protected]> wrote:
> Herbert Xu wrote:
> > Dimitrios Siganos <[email protected]> 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
On Mon, Mar 15, 2010 at 03:23:36PM +0000, Dimitrios Siganos wrote:
>
> 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?
Why don't you just do it without givencrypt?
You can always add it alter if you wish.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt