Linux cryptographic layer development
 help / color / mirror / Atom feed
* ABLKCIPHER
@ 2010-03-12 13:36 Dimitrios Siganos
  2010-03-13 12:31 ` ABLKCIPHER Herbert Xu
  0 siblings, 1 reply; 5+ messages in thread
From: Dimitrios Siganos @ 2010-03-12 13:36 UTC (permalink / raw)
  To: linux-crypto

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ABLKCIPHER
  2010-03-12 13:36 ABLKCIPHER Dimitrios Siganos
@ 2010-03-13 12:31 ` Herbert Xu
  2010-03-15 15:23   ` ABLKCIPHER Dimitrios Siganos
  0 siblings, 1 reply; 5+ messages in thread
From: Herbert Xu @ 2010-03-13 12:31 UTC (permalink / raw)
  To: Dimitrios Siganos; +Cc: linux-crypto

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).

> 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~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ABLKCIPHER
  2010-03-13 12:31 ` ABLKCIPHER Herbert Xu
@ 2010-03-15 15:23   ` Dimitrios Siganos
  2010-03-15 17:00     ` ABLKCIPHER Kim Phillips
  2010-03-16  0:18     ` ABLKCIPHER Herbert Xu
  0 siblings, 2 replies; 5+ messages in thread
From: Dimitrios Siganos @ 2010-03-15 15:23 UTC (permalink / raw)
  To: Herbert Xu; +Cc: linux-crypto

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 
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?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ABLKCIPHER
  2010-03-15 15:23   ` ABLKCIPHER Dimitrios Siganos
@ 2010-03-15 17:00     ` Kim Phillips
  2010-03-16  0:18     ` ABLKCIPHER Herbert Xu
  1 sibling, 0 replies; 5+ messages in thread
From: Kim Phillips @ 2010-03-15 17:00 UTC (permalink / raw)
  To: Dimitrios Siganos; +Cc: Herbert Xu, linux-crypto

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ABLKCIPHER
  2010-03-15 15:23   ` ABLKCIPHER Dimitrios Siganos
  2010-03-15 17:00     ` ABLKCIPHER Kim Phillips
@ 2010-03-16  0:18     ` Herbert Xu
  1 sibling, 0 replies; 5+ messages in thread
From: Herbert Xu @ 2010-03-16  0:18 UTC (permalink / raw)
  To: Dimitrios Siganos; +Cc: linux-crypto

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~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-03-16  0:18 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-12 13:36 ABLKCIPHER Dimitrios Siganos
2010-03-13 12:31 ` ABLKCIPHER Herbert Xu
2010-03-15 15:23   ` ABLKCIPHER Dimitrios Siganos
2010-03-15 17:00     ` ABLKCIPHER Kim Phillips
2010-03-16  0:18     ` ABLKCIPHER Herbert Xu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox