liboctavo / octavo Goto Github PK

The StreamEncrypt and StreamDecrypt traits are not public. As such ChaCha20 is unusable from outside octavo itself.

Other common traits might also be useful, such as Eq, PartialEq.

There are some minor mistakes in the README file.

Using pronto-clippy.

s/Octavio/Octavo

If you find security bug then contact me via mail [email protected] using mine PGP key

https://github.com/libOctavo/octavo/blob/master/docs/hauleth.asc is a 404.

Tests should run in order on:

1. stable
2. beta
3. nightly

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.

The ChaCha20 implementation is broken in a way that repeatedly calling ChaCha20::encrypt_stream() skips some of the input bytes. Specifically this happens if any of the calls input parameters is not a multiple of the block size.

Here is a small example demonstrating this:

extern crate octavo;

use octavo::crypto::stream::chacha20::ChaCha20;
use octavo::crypto::stream::StreamEncrypt;

fn main() {
    let mut s = ChaCha20::new(b"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", b"cccccccccccc");

    let a = [0u8; 63];
    let mut outa = [0u8; 63];
    let b = [0u8; 64];
    let mut outb = [0u8; 64];

    s.encrypt_stream(&a[..], &mut outa[..]);
    s.encrypt_stream(&b[..], &mut outb[..]);

    println!("{:?}", &outa[..]);
    println!("{:?}", &outb[..]);
}

Since there is absolutely no documentation, this could of course be intended behaviour. However, I would argue that this is a very common use-case with data received from a network connection.

Would it be possible to port libraries from the Iron Crypto framework to this library?

I'd be willing to start porting over crates.

The README.md reads:

[dependencies]
octavo = "*"

However, octavo isn't on crates.io as of writing, so this doesn't work.

We should make OpenSSL optional dependency or build it only on certain triplets to allow builds on Windows.

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).

Now SHA2 implementations do not pass all of the tests from NIST documents, they have problems with hashing messages longer than one block. Those longer test vectors can be found on:

• http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA224.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA256.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA384.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA512.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA512_224.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA512_256.pdf

Current implementation does not check those and when added, does not pass them for bigger hashes (SHA-384, SHA-512, and when added, SHA-512/224 and SHA-512/256).

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

Connected to #50