Skip to content
/ everrs Public

Rust bindings for HACL* / EverCrypt (high assurance crypto)

License

Notifications You must be signed in to change notification settings

rot256/everrs

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

15 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Stable Rust CI Status Nightly Rust CI Status

Everrs

Everrs provides safe bindings for the formally verified HACL*/EverCrypt crypto library: EverCrypt formally verifies that the implementation is consistent with the specification and that the implementations are constant time.

Despite these guarantees the performance of EverCrypt is very competitive.

Warning: Everrs is still early work-in-progress and the API is still subject to change.

Primitives

Eventually bindings for all EverCrypt primitives will be provided. Currently the following primitives are supported:

  • X25519
  • ChaCha20Poly1305

For X25519, the API is (almost) a drop-in alternative to x25519-dalek library.

Below is a simple example of how to encrypt and authenticate a buffer using Everrs:

use everrs::chacha20poly1305::{seal, open};

...

let mut ct : Vec<u8> = vec![0; pt.len()];
let mut tag : [u8; 16] = [0; 16];
seal(&key, &nonce, &ad[..], &pt, &mut ct, &mut tag);
open(&key, &nonce, &ad[..], &mut ptt, &ct, &tag).expect("authentication failure");

API Philosophy

Panics vs Results

Most (all?) cryptographic functions are pure functions, hence there are essentially two classes of errors/failures:

  1. The developer provides invalid arguments (essentially the type system is not sufficiently expressive to stop him), e.g. the size of the result buffer is insufficient to hold the decrypted ciphertext, or a key is to short for the scheme.
  2. Failures from authentication failures.

Everrs adopts the philosophy that errors should be meaningful signals at runtime, not indicators of bad programming. Hence we believe that the first type of error is best dealt with by causing a 'panic', rather than return a 'Result' which could potentially be handled, but would never occur when the library is used correctly. This is consistent with e.g. the behavior when accessing elements out-of-bounds in a slice.