On Tue, Mar 07, 2023 at 02:55:29PM +0100, lionel.debieve@xxxxxxxxxxx wrote: > > The issue about the context management relies on a question I've get time to > ask you. There is no internal test purpose (using test manager) that really > show the need of a hash update that needs to be "self-content". We've seen Indeed this functionality is sorely missed. It shouldn't be hard to implement, because simply hashing two different requests interleaved with each other should show the problem: init(A) => update(A) => init(B) => update(B) => final(A) => final(B) > the issue using openssl use cases that is not using import/export. > I'm wondering to understand the real need of import/export in the framework > if the request must be safe itself? The hash state is normally stored in the request context. The import/export functions let you save a copy of the state for subsequent processing. The request could then be freed after the export and re-allocated prior to import, or in other contexts the request could be reused for a completely different hash in the time being (init/update/final). > >From hardware point of view, it is a penalty to wait for completion to save > the context after each request. I understand the need of multiple hash > request in // but I was wondering that it can be managed by the > import/export, but it seems I was wrong. The penalty of the context saving > will impact all hash requests where, in a runtime context is probably not > the most important use case. Oh of course we try to avoid unnecessary savings/restoring as much as we can. That's why we encourage users to use finup/digest as much as possible, in which case there may be be no need to save and restore at all. However, if the user has to do a partial update through the update function, then we have to save the state. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
