we should have a variant of this library that can be compiled to wasm, which probably means not using the use core::arch::x86_64::... or the assembly.

• LICENSE
• CI
• Publish crate(?)

Description of the bug

$ make
-e \e[36;1m*** Building debug target...\e[0m
    Updating crates.io index
  Downloaded failure v0.1.6
  Downloaded subtle v2.2.1
  Downloaded failure_derive v0.1.6
  Downloaded synstructure v0.12.3
  Downloaded zeroize v0.6.0
  Downloaded zeroize_derive v0.1.0
  Downloaded syn v0.15.44
   Compiling proc-macro2 v1.0.6
   Compiling proc-macro2 v0.4.30
   Compiling unicode-xid v0.2.0
   Compiling unicode-xid v0.1.0
   Compiling syn v1.0.8
   Compiling syn v0.15.44
   Compiling failure_derive v0.1.6
   Compiling subtle v2.2.1
   Compiling quote v0.6.13
   Compiling quote v1.0.2
   Compiling zeroize_derive v0.1.0
   Compiling synstructure v0.12.3
   Compiling zeroize v0.6.0
   Compiling failure v0.1.6
   Compiling deoxysii v0.2.0 (/Users/ur20980/src/deoxysii-rust)
error: The following target_feature flags must be set: +aes,+ssse3.
  --> src/lib.rs:28:1
   |
28 | compile_error!("The following target_feature flags must be set: +aes,+ssse3.");
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: could not compile `deoxysii`.

To learn more, run the command again with --verbose.
make: *** [debug] Error 101
$ 

Steps to reproduce

1. git clone https://github.com/oasislabs/deoxysii-rust.git
2. cd deoxysii-rust
3. make

Expected behavior
At the very least, a successfully built crate.

Environment

• OS: macOS Mojave 10.14.6.
• rustc 1.41.0-nightly (0f0c640e0 2019-11-17) and rustc 1.39.0 (4560ea788 2019-11-04)
• CPU: 3 GHz Intel Xeon W (CPUID flags: sse2 ssse3 sse41 sse42 avx2 avx512f rdtsc bmi1 bmi2 adx aes_ni clmul rdrand rdseed)

nit.

https://github.com/oasislabs/deoxysii-rust/blob/876f3067715b583d7dae3d09d4e1c1f021992ccc/src/lib.rs#L99

I am not sure of our rust style rules, but https://doc.rust-lang.org/1.0.0/style/ownership/constructors.html and https://doc.rust-lang.org/1.0.0/style/errors/signaling.html do not seem to show examples of ctors having to return a Result with potential Error values, but does say that when in doubt, use Option or Result. Do we envision a future when we may need to modify this to return an error, e.g., a hardware-accelerated implementation where there might be a hardware resource problem? Maybe a comment, if so?

Having all uses of DeoxysII::new() do .unwrap() seem unnecessary typing -- Vec::new() doesn't do that. Maybe the compiler can do cross-module optimization and realize the only possible return is Ok(...), but I'm guessing not.

the contract feels weird: there are no Err values for the caller to check, unlike open, so code written to the current API can only pass on the potential future error e.g. with unwrap(), or detect it and creating its own error object.

seal has the same property.

for open, the tag verification error is a string that contains "deoxysii" which means that this cannot (directly) be inside a generic AEAD interface that any authenticated encryption algorithms could implement, since in such a case one would want to have a generic tag authentication failure that all AEAD algorithm implementations can use, so that interface clients can avoid having to do string matching. of course, since there is only one error, maybe it doesn't matter.

See: https://blog.yossarian.net/2020/08/02/Writing-and-publishing-a-python-module-in-rust

It should be straightforward to create a Python module which targets 'manylinux' and can be published to PyPi.

This would form the basis of support for Oasis Sapphire calldata encryption for Web3.py

so that everyone else can finally use rust stable

Rust

    fn encrypt_something() {
        let plaintext = vec![0];
        let nonce = [0u8; 15];
        let symmetric_key = [10, 213, 217, 89, 194, 115, 57, 183, 253, 138, 189, 242, 51, 198, 244, 192, 19, 63, 91, 24, 197, 177, 66, 87, 110, 208, 215, 188, 61, 99, 193, 238];
        let d2 = deoxysii::DeoxysII::new(&symmetric_key);
        let r = d2.seal(&nonce, plaintext, vec![]);
        println!("{:?}", r);
    }

Outputs: [46, 168, 87, 159, 53, 35, 156, 67, 169, 207, 65, 189, 8, 122, 206, 71, 230]

JavaScript

  function encryptSomething() {
	let plaintext = new Uint8Array([0]);
	let nonce = new Array(15).fill(0);
	let symKey = new Uint8Array([10, 213, 217, 89, 194, 115, 57, 183, 253, 138, 189, 242, 51, 198, 244, 192, 19, 63, 91, 24, 197, 177, 66, 87, 110, 208, 215, 188, 61, 99, 193, 238]);
	let d2 = new deoxysii.AEAD(symKey);
	let encryption = d2.encrypt(nonce, plaintext, new Uint8Array([]));
	console.log("", encryption);
}

Outputs: Uint8Array([[84, 28, 78, 228, 248, 107, 218, 104, 110, 135, 55, 55, 174, 35, 31, 240, 157]])

https://github.com/oasislabs/deoxysii-rust/blob/876f3067715b583d7dae3d09d4e1c1f021992ccc/src/lib.rs#L223

We implement Zeroize for the struct, but we do not zero the XMM registers (supposed to be caller saved / scratch, depending on which would actually be used by the compiler) before returning. While this could (should) only leak info if the calling code invoked other unsafe code, it's better to clean things up.

seal and open do not use XMM registers, but the code that they call do (though those are inline'd); it's probably more natural to clear them before returning from these top-level pub functions.