Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY
Hello,
I have stumbled across a flag defined in include/crypto/internal/hash.h : CRYPTO_AHASH_ALG_BLOCK_ONLY.
To get more information about what exact behavior this flag do, I read the crypto_ahash_update function.
From the looks of it, it seems that the API will call the tfm update if there is enough bytes (and by enough I mean at least a block size), from the internal buffer and the incoming ahash_request. In this case, I find the BLOCK_ONLY naming a bit of a misnomer, since it only guarantee you than req->nbytes will be at least a block size.
I initially though that the API would only give a request that are a multiple of the block size.
This flag, among others, are relatively recent.
I think adding documentation about these flags would be a great idea.
Regards,
Paul.
Signature · 3 lines
Paul Louvel, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Hello,
I forgot to include the maintainers in the initial e-mail.
Additional link to the source code :
https://elixir.bootlin.com/linux/v7.0-rc1/source/crypto/ahash.c#L467
Thank you,
Paul.
Quoted 14 lines · Paul Louvel
Hello,
I have stumbled across a flag defined in
include/crypto/internal/hash.h:CRYPTO_AHASH_ALG_BLOCK_ONLY.
To get more information about what exact behavior this flag do, I read thecrypto_ahash_updatefunction.
From the looks of it, it seems that the API will call the tfm update if there is enough bytes (and by enough I mean at least a block size), from the internal buffer and the incomingahash_request. In this case, I find theBLOCK_ONLYnaming a bit of a misnomer, since it only guarantee you thanreq->nbyteswill be at least a block size.
I initially though that the API would only give a request that are a multiple of the block size.This flag, among others, are relatively recent.
I think adding documentation about these flags would be a great idea.Regards,
Paul.
Signature · 3 lines
Paul Louvel, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Herbert Xu
maintainerQuoted 15 lines · Paul Louvel
Quoted 14 lines
Hello,
I have stumbled across a flag defined in
include/crypto/internal/hash.h:CRYPTO_AHASH_ALG_BLOCK_ONLY.
To get more information about what exact behavior this flag do, I read thecrypto_ahash_updatefunction.
From the looks of it, it seems that the API will call the tfm update if there is enough bytes (and by enough I mean at least a block size), from the internal buffer and the incomingahash_request.
In this case, I find theBLOCK_ONLYnaming a bit of a misnomer, since it only guarantee you thanreq->nbyteswill be at least a block size. I initially though that the API would only give a request that are a multiple of the block size.
Quoted 2 lines
Quoted 2 lines
This flag, among others, are relatively recent.
I think adding documentation about these flags would be a great idea.
This flag is meant to be temporary in nature.
Historically, crypto API hash drivers processed partial blocks at the end directly and the API played no role in it.
This has resulted in complexities in the drivers and associated bugs.
The API is now able to handle partial blocks for the drivers and the flag is an indication of the driver's preference for it.
For a reference, see the aspeed driver which has been converted to the new way of handling partial block data.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi,
Quoted 1 line
This flag is meant to be temporary in nature.
What does that mean ? The flag will be subject to changes in the near future ?
Quoted 4 lines
Historically, crypto API hash drivers processed partial blocks at the end directly and the API played no role in it.
This has resulted in complexities in the drivers and associated bugs.
I agree. I am currently working on the talitos crypto driver, which includes code to handle partial blocks. The SEC1 (currently supported by the talitos driver) is older hardware that only accepts data with a length that is a multiple of the underlying hashing algorithm's block size. Would it make sense for the crypto API to have a flag to handle such limitations automatically?
Quoted 2 lines
The API is now able to handle partial blocks for the drivers and the flag is an indication of the driver's preference for it.
Understood.
Quoted 2 lines
For a reference, see the aspeed driver which has been converted to the new way of handling partial block data.
Ok.
Thank you,
Quoted 31 lines · Herbert Xu
Quoted 15 lines · Paul Louvel
Quoted 14 lines
Hello,
I have stumbled across a flag defined in
include/crypto/internal/hash.h:CRYPTO_AHASH_ALG_BLOCK_ONLY.
To get more information about what exact behavior this flag do, I read thecrypto_ahash_updatefunction.
From the looks of it, it seems that the API will call the tfm update if
there is enough bytes (and by enough I mean at least a block size), from the internal buffer and the incomingahash_request.
In this case, I find theBLOCK_ONLYnaming a bit of a misnomer, since it only guarantee you thanreq->nbyteswill be at least a block size. I initially though that the API would only give a request that are a multiple of the block size.Quoted 2 lines
Quoted 2 lines
This flag, among others, are relatively recent.
I think adding documentation about these flags would be a great idea.This flag is meant to be temporary in nature.
Historically, crypto API hash drivers processed partial blocks at the end directly and the API played no role in it.
This has resulted in complexities in the drivers and associated bugs.
The API is now able to handle partial blocks for the drivers and the flag is an indication of the driver's preference for it.
For a reference, see the aspeed driver which has been converted to the new way of handling partial block data.
Cheers,
Signature · 3 lines
Paul Louvel, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Herbert Xu
maintainerQuoted 7 lines · Paul Louvel
I agree. I am currently working on the talitos crypto driver, which includes code to handle partial blocks. The SEC1 (currently supported by the talitos driver) is older hardware that only accepts data with a length that is a multiple of the underlying hashing algorithm's block size. Would it make sense for the crypto API to have a flag to handle such limitations automatically?
Yes it should be fairly easy to handle this if you use the BLOCK_ONLY interface. If you have a last partial block you could either feed it to a software fallback, or manually generate the padding data and feed it to the hardware with no finalisation.
The aspeed driver is an example using the second method to generate the final block by hand.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt