Dimitrios Siganos wrote:
> Hi,
>
> I have a question about the asynchronous characteristics of the crypto api.
>
> 1) crypto_alloc_hash("sha1", 0, CRYPTO_ALG_ASYNC), does this code create
> an asynchronous sha1 transform?
crypto_alloc_hash is obsolete. New code should either use shash
or ahas
Dimitrios Siganos 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 algor
Roberto Sassu wrote:
>
> when dumping the data placed pointed by the scatterlist array i noted that
> the
> assoc is always zero'ed. I investigated further and it seems that the problem
> is the static allocation of the assoc string in my test module. When using
> the
> kmalloc the dump is co
Hi Linus:
This push fixes three regressions and an older bug:
* The new padata system crashes during init on certain configurations.
* Fixed hmac(md5) broken by recent md5 update.
* Fixed authenc broken by ahash conversion.
* Fixed handling of unaligned buffers in hash API.
Please pull from
gi
Hi,
I have a question about the asynchronous characteristics of the crypto api.
1) crypto_alloc_hash("sha1", 0, CRYPTO_ALG_ASYNC), does this code create
an asynchronous sha1 transform?
2) crypto_alloc_hash("sha1", 0, 0), does this code create a synchronous
sha1 transform?
3) Is synchronous
Hello
i pulled the crypto-2.6 repo today. Issues appear to be solved for both 32-bit
and 64-bit systems. Many thanks!
I have got another trouble when compiling my test module with a 64-bit
operating system:
when dumping the data placed pointed by the scatterlist array i noted that the
assoc i
