Add SHA2 512 truncated hashes

[KayEss]

SHA2 512/224 and SHA2 512/256 are truncated versions of the SHA2 512 hash function. They are different to truncating the output of the SHA2 512 because they use different initialisation of the hash state.

This will close #5087

[CLAassistant]

All committers have signed the CLA.

[github-actions]

CT Test Results

    2 files    14 suites   7m 18s ⏱️
187 tests 173 ✔️   14 💤 0 ❌
483 runs  341 ✔️ 142 💤 0 ❌

Results for commit d595652.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• No Windows Installer found

// Erlang/OTP Github Action Bot

[sverker]

The new atoms sha512_224 and sha512_256 should be added to the appropriate type(s) in crypto.erl. I don't know if that means only the type hash_algoritm() or in sha2() which is referred in more places.

[KayEss]

I don't know if that means only the type hash_algoritm() or in sha2() which is referred in more places

I've added it to the hash algorithms as the sha2 type is used in more places than the new hashes are supported.

[sverker]

I've added it to the hash algorithms as the sha2 type is used in more places than the new hashes are supported.

Should it be supported in the other places as well?

[KayEss]

Should it be supported in the other places as well?

Well, clearly, ideally yes :-)

I did try it out with hmac using: crypto:mac(hmac, sha512_256, <<"abc">>, <<"def">>). The only third party implementation of this I found so far was in libsodium. Comparing the two, erlang gives:

<<129,232,238,148,105,116,143,92,230,74,171,12,42,135,238, 197,234,90,0,18,173,45,44,58,5,214,62,237,63,...>>

And libsodium gives the sequence:

191 147 195 222 238 30 182 102 14 192 8 32 162 133 50 123 62 139 119 95 100 31 215 242 234 50 27 106 36 26 254 123

These are clearly not the same. This is the libsodium code I used:

#include <sodium.h>

#include <array>
#include <iostream>


int main() {
    std::array<unsigned char, crypto_auth_hmacsha512256_BYTES> output{};
    std::array<unsigned char, crypto_auth_hmacsha512256_KEYBYTES> key{};
    key[0] = 'a';
    key[1] = 'b';
    key[2] = 'c';
    std::array<unsigned char, 3> msg{'d', 'e', 'f'};
    std::cout << "key length " << key.size() << '\n';
    std::cout << crypto_auth_hmacsha512256(output.data(), msg.data(), msg.size(), key.data()) << '\n';
    for (auto const c : output) {
        std::cout << int(c) << ' ';
    }
    std::cout << '\n';

    return 0;
}

There is potentially a difference in bit packing for the key argument here, but the following erlang code gives identical output: crypto:mac(hmac, sha512_256, <<"abc", 0:29/unit:8>>, <<"def">>).

I would assume that the libsodium results are correct, so I doubt we should trust the HMAC result here.

[halostatue]

It would be great to see these added because of the length-extension resistance that these provide.