Implement STB 34.101.77-2020 bash

[makavity]

Implementation of bash-s and bash-f for AE256 and BashHash algorithms.

[newpavlov]

The linked reference can not be downloaded right now (the server returns 500 for me and it was not cached by the wayback machine), so I can not read it.

[newpavlov]

After reading the spec, I am glad that its authors did not stubbornly use BE. Note that they explicitly wrote that they use the LE convention (section 4.2.2). In other words, IIUC when they write B194BAC80A08F53B, they do not mean 0xB194BAC80A08F53B, but 0x3BF5080AC8BA94B1. You even used it in the round constant initialization step (the spec states C ← B194BAC80A08F53B and you wrote let mut c: u64 = 0x3BF5080AC8BA94B1;).

Granted, they could've used a bit less confusing notation here to better distinguish between hex-encoded byte sequences and integer literals, but at least the algorithm itself can be implemented efficiently.

[makavity]

After reading the spec, I am glad that its authors did not stubbornly use BE. Note that they explicitly wrote that they use the LE convention (section 4.2.2). In other words, IIUC when they write B194BAC80A08F53B, they do not mean 0xB194BAC80A08F53B, but 0x3BF5080AC8BA94B1. You even used it in the round constant initialization step (the spec states C ← B194BAC80A08F53B and you wrote let mut c: u64 = 0x3BF5080AC8BA94B1;).

Granted, they could've used a bit less confusing notation here to better distinguish between hex-encoded byte sequences and integer literals, but at least the algorithm itself can be implemented efficiently.

So we can use the swap_bytes externally, only in the test, am I right? The algorithm itself works correctly anyway.

[newpavlov]

So we can use the swap_bytes externally, only in the test, am I right?

Either this by using .map(|n| n.swap_bytes()) on buf and expected with a comment explaining that constants in the spec are given using LE order, or you could modify the literals themselves.

[makavity]

Either this by using .map(|n| n.swap_bytes()) on buf and expected with a comment explaining that constants in the spec are given using LE order, or you could modify the literals themselves.

Thank you for the clarifying of that. That was the my most problem, when i've implemented all other Belarus national algorithms.

[newpavlov]

Maybe we should use bash-f for the crate name instead of belt-bash?

This would be more consistent with bash-hash and bash-ae crate names for the higher-level algorithms (I am not sure about the prg suffix).

[makavity]

Also added benches, unroll loop inside bash_f and precalculated

Maybe we should use bash-f for the crate name instead of belt-bash?

This would be more consistent with bash-hash and bash-ae crate names for the higher-level algorithms (I am not sure about the prg suffix).

I was thinking about the name. I think you're right.

[makavity]

Not bad performance at all :)
Already implemented bash-hash, here is the benches:

test bash_hash256_10    ... bench:          13.52 ns/iter (+/- 0.47) = 769 MB/s
test bash_hash256_100   ... bench:         118.85 ns/iter (+/- 2.72) = 847 MB/s
test bash_hash256_1000  ... bench:       1,128.52 ns/iter (+/- 17.93) = 886 MB/s
test bash_hash256_10000 ... bench:      11,183.88 ns/iter (+/- 648.73) = 894 MB/s
test bash_hash384_10    ... bench:          16.94 ns/iter (+/- 0.52) = 625 MB/s
test bash_hash384_100   ... bench:         156.65 ns/iter (+/- 2.40) = 641 MB/s
test bash_hash384_1000  ... bench:       1,512.14 ns/iter (+/- 26.18) = 661 MB/s
test bash_hash384_10000 ... bench:      15,007.86 ns/iter (+/- 420.13) = 666 MB/s
test bash_hash512_10    ... bench:          24.37 ns/iter (+/- 1.17) = 416 MB/s
test bash_hash512_100   ... bench:         227.86 ns/iter (+/- 7.91) = 440 MB/s
test bash_hash512_1000  ... bench:       2,249.23 ns/iter (+/- 49.20) = 444 MB/s
test bash_hash512_10000 ... bench:      22,342.06 ns/iter (+/- 1,116.19) = 447 MB/s

Waiting for merge and will PR for the hash.