This fixes the issue that overflow_add was removed. That broke the Blake2.rs module in the Octavo-Digest module.

Also have you considered breaking these into separate git repos?

SHA2-512/224 and SHA-512/256 implemented, using existing macros for sha2 functions. However, SHA2-512/224 has 224 bits, and that is not a multiple of 64. Thus, write_u64() used for writing state to resulting out slice cannot be used directly (as it would copy 4 bytes to few to out, or 4 to many).

Because of that a proxy struct _Sha512_224 which outputs 256 bits is created, and its methods are simply called by proper Sha512_224 struct. In the result() method a new vec, res is created, result is written to it, and then 28 first bytes are copied to out using a simple for loop.

SHA2-512/256 is implemented with just impl_sha!(high Sha512_256, SHA512_256_INIT, 256).

It closes #47.

Use safe initialization in fn hex_result()

fn hex_result would pass a slice of uninitialized data to Digest::result and MAC::result respectively.

Instead use vec![0; size] to produce a properly zero-initialized vector instead.

Motivation:

• Properly initializing buffers is good practice for crypto libraries
• Using unintialized buffers mean you have to audit all users (all fn result implementors).
• Using uninitialized buffers make the traits unsafe! Safe code gets acess to uninit data, which produces UB in safe rust.
• vec![0; size] compiles to good code (it will use memset).

Currently I found that using octavo::digest is quite verbose, ex.:

use octavo::digest::Digest;
use octavo::digest::sha1::Sha1;

I am thinking about making all modules private and reexport hash functions as all of them currently has unique names (some ugly as Sha3224). But I am not so sure about it. What you guys think?

There are 3 options:

• left as is
• privatize and reexport
• left as is and simplify Sha3XXX names to ShaXXX (possible name collisions between octavo::digest::sha2 and octavo::digest::sha3).

This will help with maintaining and reviewing tests.

TODO:

• [x] Move digest tests
• [x] Move crypto::asymmetric tests
• [x] Move crypto::block tests
• [x] Move crypto::stream tests
• [ ] Use external files to describe tests in human readable form (YAML or custom format)

Before:

test sha1::_1024_block_size            ... bench:       4,008 ns/iter (+/- 14) = 255 MB/s
test sha1::_16_block_size              ... bench:          76 ns/iter (+/- 9) = 210 MB/s
test sha1::_256_block_size             ... bench:       1,019 ns/iter (+/- 4) = 251 MB/s
test sha1::_64_block_size              ... bench:         262 ns/iter (+/- 1) = 244 MB/s
test sha1::_8192_block_size            ... bench:      31,975 ns/iter (+/- 123) = 256 MB/s

After:

test sha1::_1024_block_size            ... bench:       3,241 ns/iter (+/- 2,351) = 315 MB/s
test sha1::_16_block_size              ... bench:          60 ns/iter (+/- 43) = 266 MB/s
test sha1::_256_block_size             ... bench:         820 ns/iter (+/- 8) = 312 MB/s
test sha1::_64_block_size              ... bench:         214 ns/iter (+/- 3) = 299 MB/s
test sha1::_8192_block_size            ... bench:      25,816 ns/iter (+/- 5,956) = 317 MB/s

Old:

digest::ripemd::_100x_block_size  102,215 ns/iter (+/- 268,471) =  62 MB/s
digest::ripemd::_10x_block_size    10,199 ns/iter (+/- 34,334)  =  62 MB/s
digest::ripemd::_1x_block_size      1,024 ns/iter (+/- 1,477)   =  62 MB/s

New:

digest::ripemd::_100x_block_size   34,825 ns/iter (+/- 162)     = 183 MB/s
digest::ripemd::_10x_block_size     3,485 ns/iter (+/- 50)      = 183 MB/s
digest::ripemd::_1x_block_size        351 ns/iter (+/- 7)       = 182 MB/s

inlining/unrolling message scheduling and compression function

SHA3 Performance:

• Intel Xeon E5-1650 v3 (Haswell): sha3-256: 108 MB/s => 299 MB/s sha3-512: 57 MB/s => 162 MB/s
• AMD A10-7850K (Kaveri): sha3-256: 87 MB/s => 206 MB/s sha3-512: 48 MB/s => 110 MB/s

This is an implementation of the Diffie-Hellman exchange algorithm. I have a PR with the same implementation with small changes to DaGenix/rust-crypto#379. I would appreciate any feedback.

inlining/unrolling message scheduling and compression function

• Intel Xeon E5-1650 v3 (Haswell, 64bit Linux): sha256: 190 MB/s => 190 MB/s sha512: 282 MB/s => 354 MB/s
• AMD A10-7850K (Kaveri, 64bit Linux): sha256: 120 MB/s => 151 MB/s sha512: 182 MB/s => 244 MB/s

Context: redox-os error[E0658]: use of unstable library feature 'wrapping_int_impl' (see issue #32463) Solution: add #![feature(wrapping_int_impl)] to the crate attributes to enable to digest/src/lib.rs

Currently Octavo seems to pay very little attention to resisting side-channel attacks (see e.g. the use of data-dependent array indices in blowfish and the use of noncryptographic big integers in RSA). While this isn't critical for some cryptographic settings, many applications (e.g. TLS) can easily be broken by timing attacks. Octavo should probably decide what its plan is.