hmac(sha1)

hmac(sha1)

[Dimitrios Siganos]

Hi,

I am trying to write a hmac(sha1) algorithm and I have a few questions. 
I have a HW crypto accelerator that does the actual crypto work. I have 
already successfully implemented sha1 by creating a 
CRYPTO_ALG_TYPE_DIGEST algorithm.

1) Can I implement hmac(sha1) as a CRYPTO_ALG_TYPE_DIGEST algorithm 
(i.e. use very similar code to sha1)?

2) Do I need to create a CRYPTO_ALG_TYPE_HASH algorithm?

3) Is it possible to implement hmac(sha1) as both CRYPTO_ALG_TYPE_DIGEST 
and CRYPTO_ALG_TYPE_HASH?

4) If I use a CRYPTO_ALG_TYPE_HASH, I need to understand the scatterwalk 
api, is there any help on the subject?

Regards,
Dimitris

Re: hmac(sha1)

[Dimitrios Siganos]

Dimitrios Siganos wrote:
> Hi,
>
> I am trying to write a hmac(sha1) algorithm and I have a few 
> questions. I have a HW crypto accelerator that does the actual crypto 
> work. I have already successfully implemented sha1 by creating a 
> CRYPTO_ALG_TYPE_DIGEST algorithm.
>
> 1) Can I implement hmac(sha1) as a CRYPTO_ALG_TYPE_DIGEST algorithm 
> (i.e. use very similar code to sha1)?
>
> 2) Do I need to create a CRYPTO_ALG_TYPE_HASH algorithm?
>
> 3) Is it possible to implement hmac(sha1) as both 
> CRYPTO_ALG_TYPE_DIGEST and CRYPTO_ALG_TYPE_HASH?
>
> 4) If I use a CRYPTO_ALG_TYPE_HASH, I need to understand the 
> scatterwalk api, is there any help on the subject?
>
> Regards,
> Dimitris
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
The answer to 1) is yes because I just did it and seems to work. 
Therefore the answer is to 2) is: No, it is not needed.

I believe the answer to 3) is: yes. I believe it is possible to 
implement hmac(sha1) as both CRYPTO_ALG_TYPE_DIGEST and 
CRYPTO_ALG_TYPE_HASH.

I would like to implement hmac(sha1) as a CRYPTO_ALG_TYPE_HASH but I do 
yet understand how to convert the scatterlists into virtual addresses. 
The HW crypto api that I use, hides the DMA details from me and expects 
me to pass it virtual addresses only. I can't see any examples of 
converting scatterlists to virtual addresses in a way that is safe for 
IPsec use (i.e. safe to be called from softirq context). Any help on 
this will be appreciated.

The ultimate goal of the project is to implement a authenc(hmac(sha1), 
cbc(aes)) algorithm (for IPsec use) that will offload the work to a HW 
crypto chip. In order to understand what I am doing, I am building 
slowly upwards. I have build aes as a CIPHER, cbc(aes) as a BLKCIPHER, 
sha1 as a digest and hmac(sha1) as a digest.

My next steps are to implement cbc(aes) using ABLKCIPHER and hmac(sha1) 
using HASH and AHASH. I am using linux version 2.6.28. I can see that 
the talitos driver implements algorithms at the authenc level but I 
don't completely understand the driver and I am hoping that after going 
through the exercise of building the smaller blocks I will understand 
the operation of the talitos driver.

Any help, especially pointers to relevant documentation or examples, 
will be appreciated.

Dimitris

Re: hmac(sha1)

[Kim Phillips]

On Wed, 3 Mar 2010 20:17:04 +0000
Dimitrios Siganos <dimitris@siganos.org> wrote:

> Dimitrios Siganos wrote:
> > Hi,
> >
> > I am trying to write a hmac(sha1) algorithm and I have a few 
> > questions. I have a HW crypto accelerator that does the actual crypto 
> > work. I have already successfully implemented sha1 by creating a 
> > CRYPTO_ALG_TYPE_DIGEST algorithm.
> >
> > 1) Can I implement hmac(sha1) as a CRYPTO_ALG_TYPE_DIGEST algorithm 
> > (i.e. use very similar code to sha1)?
> >
> > 2) Do I need to create a CRYPTO_ALG_TYPE_HASH algorithm?
> >
> > 3) Is it possible to implement hmac(sha1) as both 
> > CRYPTO_ALG_TYPE_DIGEST and CRYPTO_ALG_TYPE_HASH?
> >
> > 4) If I use a CRYPTO_ALG_TYPE_HASH, I need to understand the 
> > scatterwalk api, is there any help on the subject?
> >
> The answer to 1) is yes because I just did it and seems to work. 
> Therefore the answer is to 2) is: No, it is not needed.
> 
> I believe the answer to 3) is: yes. I believe it is possible to 
> implement hmac(sha1) as both CRYPTO_ALG_TYPE_DIGEST and 
> CRYPTO_ALG_TYPE_HASH.
> 
> I would like to implement hmac(sha1) as a CRYPTO_ALG_TYPE_HASH but I do 
> yet understand how to convert the scatterlists into virtual addresses. 
> The HW crypto api that I use, hides the DMA details from me and expects 
> me to pass it virtual addresses only. I can't see any examples of 
> converting scatterlists to virtual addresses in a way that is safe for 
> IPsec use (i.e. safe to be called from softirq context). Any help on 
> this will be appreciated.

not sure I understand; scatterlists come populated with virtual
addresses at the driver entry point (e.g. aead_givencrypt).  talitos
uses a combination of dma_map_sg and sg_dma_address to map the list of
virt. addresses into dma-able addresses (because that's what the h/w
wants).

the sg_virt helper fn should be used to extract the virtual address
of each sg entry, which sounds like what you want in your case.

> The ultimate goal of the project is to implement a authenc(hmac(sha1), 
> cbc(aes)) algorithm (for IPsec use) that will offload the work to a HW 
> crypto chip. In order to understand what I am doing, I am building 
> slowly upwards. I have build aes as a CIPHER, cbc(aes) as a BLKCIPHER, 
> sha1 as a digest and hmac(sha1) as a digest.
> 
> My next steps are to implement cbc(aes) using ABLKCIPHER and hmac(sha1) 
> using HASH and AHASH. I am using linux version 2.6.28. I can see that 
> the talitos driver implements algorithms at the authenc level but I 
> don't completely understand the driver and I am hoping that after going 
> through the exercise of building the smaller blocks I will understand 
> the operation of the talitos driver.

for talitos, the hardware does the cipher+hash in one go (via in-
and out-snooping between the execution units), so it's more optimal
than splitting it into two separate operations - the only downside is
that talitos doesn't currently support IPsec AH.  wrt the crypto api,
the main difference is that the aead request comes as an overlapping
cipher and hash request.

> Any help, especially pointers to relevant documentation or examples, 
> will be appreciated.

wrt sg: Documentation/DMA-API.txt, lib/scatterlist.c,
arch/$ARCH/include/asm/scatterlist.h

wrt authenc/aead request offsets:
http://unixwiz.net/techtips/iguide-ipsec.html

Kim

Re: hmac(sha1)

[Herbert Xu]

Dimitrios Siganos <dimitris@siganos.org> wrote:
>
> 1) Can I implement hmac(sha1) as a CRYPTO_ALG_TYPE_DIGEST algorithm 
> (i.e. use very similar code to sha1)?

DIGEST exists for compatibility only.  No new code will be accepted
that implements a DIGEST algorithms.

> 2) Do I need to create a CRYPTO_ALG_TYPE_HASH algorithm?

HASH is also obsolete.  If your hardware is synchronous, you should
use SHASH which is just as simple to use as DIGEST.  If however
you need asynchronous support, you must use AHASH.

> 3) Is it possible to implement hmac(sha1) as both CRYPTO_ALG_TYPE_DIGEST 
> and CRYPTO_ALG_TYPE_HASH?

Yes but as both types are obsolete your code will not be merged.

> 4) If I use a CRYPTO_ALG_TYPE_HASH, I need to understand the scatterwalk 
> api, is there any help on the subject?

If your hardware is synchronous, you won't need SG lists at all.
Otherwise you can look at how existing drivers under drivers/crypto
do things.

Note that we don't currently have a working asynchronous hash
driver so in a way you'll need to write things from scratch.
However, we're all happy to assist you in this process.

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

Re: hmac(sha1)

[Dimitrios Siganos]

Herbert Xu wrote:
> Dimitrios Siganos <dimitris@siganos.org> wrote:
>   
> Note that we don't currently have a working asynchronous hash
> driver so in a way you'll need to write things from scratch.
> However, we're all happy to assist you in this process.
>   
I am using linux 2.6.28, and in that version, the crc32 implementation 
is of type AHASH. According to git, crc32 was converted to SHASH on 25 
Dec 2008. I am basing my AHASH implementation on the crc32 AHASH.

Re: hmac(sha1)

[Herbert Xu]

Dimitrios Siganos <dimitris@siganos.org> wrote:
>
> I am using linux 2.6.28, and in that version, the crc32 implementation 
> is of type AHASH. According to git, crc32 was converted to SHASH on 25 
> Dec 2008. I am basing my AHASH implementation on the crc32 AHASH.

Unless you're implementing a software async driver, I don't think
crc32c is going to be of that much help.

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

Re: hmac(sha1)

[Dimitrios Siganos]

Herbert Xu wrote:
> Dimitrios Siganos <dimitris@siganos.org> wrote:
>   
>> I am using linux 2.6.28, and in that version, the crc32 implementation 
>> is of type AHASH. According to git, crc32 was converted to SHASH on 25 
>> Dec 2008. I am basing my AHASH implementation on the crc32 AHASH.
>>     
>
> Unless you're implementing a software async driver, I don't think
> crc32c is going to be of that much help.
>
> Cheers,
>   
Yes, it looks like crc32 is a synchronous implementation masquerading as 
an asynchronous one, so it doesn't help me very much.

Can you please answer the following questions with regards to an 
ahash_alg implementation:

1) Do I need to implement .digest?

2) Please confirm that .init should setup a context in the req->ctx to 
be used by .update and .final and that .final should destroy that context.

3) Can the .init request carry data?

4) Can the .final request carry data?

5) If any of  the functions (.init, .update, .final) completes the work 
scheduled synchronously, it should return 0 and not call the complete 
function of the request.

6) If any of  the functions (.init, .update, .final) returns without 
completing the work scheduled, it should return -EINPROGRESS and call 
the complete function (if not NULL) of the req when the work is completed.

7) When calling the complete function, what context should it be called 
from? For example, can it be interrupt context? Should I take any 
precautions/locks before calling the complete function callback?

8) Could you say a few words about the threading model that is in 
effect? For example, if I move the context in the req struct, do I need 
any kind of locking? Can I assume that the tfm, will not be changing 
under my feet, when inside a init/update/final call?

9) Is there a concept of a default key for a hash? For example, could 
.init be called calling set_key prior to it? If yes, what should the key 
be in that case?

I hope it is not too many questions :-)

Dimitris

Re: hmac(sha1)

[Herbert Xu]

Dimitrios Siganos <dimitris@siganos.org> wrote:
> 
> Can you please answer the following questions with regards to an 
> ahash_alg implementation:
> 
> 1) Do I need to implement .digest?

Yes.

> 2) Please confirm that .init should setup a context in the req->ctx to 
> be used by .update and .final and that .final should destroy that context.

Yes to an extent.  You should not store anything in a request
between operations other than the hash state.  IOW, you should
not leak memory if someone calls init and then never invokes
final.

> 3) Can the .init request carry data?

No.

> 4) Can the .final request carry data?

No.

Please keep in mind that unless your hardware supports exporting
the partial hash state, you must use a software fallback to
implement init/update.

> 5) If any of  the functions (.init, .update, .final) completes the work 
> scheduled synchronously, it should return 0 and not call the complete 
> function of the request.

Right.

> 6) If any of  the functions (.init, .update, .final) returns without 
> completing the work scheduled, it should return -EINPROGRESS and call 
> the complete function (if not NULL) of the req when the work is completed.

Yes.

> 7) When calling the complete function, what context should it be called 
> from? For example, can it be interrupt context? Should I take any 
> precautions/locks before calling the complete function callback?

It must be called with hard IRQs on and soft IRQs off.  IOW it
should be in done in BH context, or process context with BH
disabled.

> 8) Could you say a few words about the threading model that is in 
> effect? For example, if I move the context in the req struct, do I need 
> any kind of locking? Can I assume that the tfm, will not be changing 
> under my feet, when inside a init/update/final call?

You can assume that setkey will not occur, or that the tfm will not
be freed.  You must not however modify the tfm in anyway without
locking as operations can be issued in parallel (via different
reqeust structures).

> 9) Is there a concept of a default key for a hash? For example, could 
> .init be called calling set_key prior to it? If yes, what should the key 
> be in that case?

That depends on your algorithm.  For SHA there is no key so this
is not an issue.  For HMAC(SHA) setkey is required.  But you
may provide a default key, that is, you're not required to indicate
an error if setkey was never invoked.

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