Re: hmac(sha1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Herbert Xu wrote:
Dimitrios Siganos <dimitris@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux