-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Aloha!

Niels Möller wrote:

That's correct. I wasn't aware of them... Are there any applications or protocols using them?

Don't have any good answer to that. the embedded SSL/TLS stack seems to use it, but afaik there are no official defined cipher suites in TLS that uses them.

http://www.oryx-embedded.com/doc/files.html

OSX command shasum supports sha-512/256 (and calls it sha51256, the horrors!).

There seems to be discussions in OpenSSL about adding support.

So no, right now there doesn't seem to be much application demand for it. OTOH as long as it is not available in libs, it is harder for applications to use them. The SHA-512/x are part of the big SHA-2 standard and the prevalence of 64-bit arch even in embedded space is increasing.

(I do also have a specific application case where SHA-512/256 will be used which is why I started checking support for it.)

If they are needed, I'd suggest adding

sha512_224_init sha512_224_digest sha512_256_init sha512_256_digest

I can take a shot at the code changes and post patches.

(and not bother with any additional aliases for context struct and _update function). Is that ok?

Very ok. As long as the H0-constants can be changed we shouldn't need to modify anything else.

- -- Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ========================================================================

Joachim Strömbergson joachim@secworks.se writes:

It wasn't really that hard. Patches will follow in two mails.

Nice. If this is to go in the upcoming release, I'd appreciate help with the documentation too.

I have not updated the H0 generation scripts used to verify the values (which you have done for SHA-384 and SHA-512).

Ideally, shadata.c should be extended to generate all tables needed for sha2. It can now use mini-gmp to get as much precision as it needs. But that's not urgent.

I think it looks a bit ugly to have separat init and digest functions but reuse the update function from sha512. I would prefer to add sha512_224_update() and sha512_256 too but still reuse the context. But since you don't do that for sha384

For sha384, there's a

#define sha384_update nettle_sha512_update

in sha2.h. We could add two more aliases for that function, if that makes application code prettier.

Minor nit: I prefer patches in unified format.

Regards, /Niels