Le Tue, May 17, 2022 at 08:46:42PM +0200, Niels Möller a écrit : > 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.
My crypto devices are from ARM Allwinner SoCs. Allwinner SoCs codename are sun[0-9]*i, so unrelated to Sun microsystems. So in Linux Allwinner "arch" is often called sunxi. So sun4i-ss is the Security System on sun4i SoCs and sun8i-ce is the crypto engine on sun8i SoCs. > > > 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. > Speed is not really a topic for me, I just need them for emulation. So I am totally fine with ALGONAME_compress(uint32_t *state, const uint8_t *data) But I think the compress_n version could be provided in parallel and still usefull for my case. So basicly, do you agree if I resent my patch by simply removing all nettle_ prefix ? Then a second patch adding sha_compress/md5_compress (But I dont know if you want and how to deprecate old nettle_md5_compress and such) And a third patch adding all compress_n functions. Regards _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
