Corentin Labbe <[email protected]> writes: > I am working on implementing crypto offloader devices I use and maintain > in Linux in qemu. > The hardware does not do full hashes offload but only their compress > part. (The driver need to do padding etc...)
Thanks for explaining the use case. > From all crypto library, only nettle provides helper for compress but > only for md5 and sha1. That's somewhat historic, I have been considering removign them from the public api (but kept them because I think I found some usage via debian code search last time I looked). > The first one device I implement (sun4i-ss) only do sha1 and md5, so its > fine. But the second (sun8i-ce) need also sha224/sha256/sha384/sha512. This is some ARM hardware, unrelated to Sun microsystems? You had me confused for a while. > So it is why I propose to export sha256/sha512 compress functions. Makes some sense. What should the api be like? The old md5 and sha1 compress functions look like void nettle_md5_compress(uint32_t *state, const uint8_t *data); void nettle_sha1_compress(uint32_t *state, const uint8_t *data); (and if we want them to be fully supported, the nettle_ prefix should be made optional). They used to be called _nettle_*_compress, to indicate their somewhat internal status. For newer internal interfaces (for assembly implementation), we've been discussing replacing the single-block compression function with functions that can process multiple blocks, e.g., something like void _sha1_compress_n (uint32_t *state, size_t nblocks, const uint8_t *data); That can be a significant improvement on architectures where the compression function is so fast (with special instructions and the like) that per-block overhead of the function call, loading constants, and loading and storing the state, becomes a significant. But should perhaps be optional, so assembly architectures where it brings no significant benefit can stay simpler. What's useful for your usecase? I would lean towards sticking to simple single-block functions in the public api, and not expose directly what's used in the assembly code. I guess it's also conceivable with archs that provide good acceleration for sha_update without directly exposing the compression function in a convenient way. Sounds a bit unlikely, but in the worst case, I guess one could have the public compress functions fall back to the plain C implementation. What about sha3? It seems Nettle exposes the sha3_permute function, but it's completely undocumented. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
