Re: [QUESTION] hash import and request initialization

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

 



On Mon, Dec 25, 2017 at 10:07:54AM +0200, Gilad Ben-Yossef wrote:
> Hi there,
> 
> I have ran into something I am unsure about regarding the ccree driver
> implementation and would love to get some guidance:
> 
> I have assumed, based on previous list correspondence, that both of
> the following sequences are legal:
> 
> Scenario A
> 1. ahash_request_alloc
> 2. ahash_import
> 
> Scenario B
> 1. ahash_request_alloc
> 2. crypto_ahash_init
> 3. ahash_import
> 
> However, I've run into the problem that since ahash_request_alloc does
> not zero the allocated request memory
> and specifically does not zero the tfm specific context part of it, I
> have no way to distinguish  between A and B and therefore
> if I have any initialization sequence that needs to happen once per
> request (DMA buffer allocation and mapping in my
> case), I cannot tell if I need to do them in ahash_import callback or not.

crypto_ahash_init is not necessary prior to an ahash_import.  If
crypto_ahash_init does any hardware initialisations, then the same
would be needed in ahash_import and crypto_ahash_digest.

> So, am I'm missing something here or is the B scenario simply not legal?

B is completely legal, just as it would be legal to do this:

1. ahash_request_alloc
2. crypto_ahash_init
3. crypto_ahash_update
4. crypto_ahash_init		// discard previous hash state

Basically you must not hold onto any permanent state at the end
of a hash operation such as init.  IOW you cannot expect a hash
state to be finalised.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



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

  Powered by Linux