ncryptf-rs

Rust bindings for ncryptf

The rust ncryptf bindings are intended to be API similar to other language bindings for ease of readability.

Installing

You can add ncryptf to your project via cargo: cargo add ncryptf

HMAC+HKDF Authentication

HMAC+HKDF Authentication is an Authentication method that allows ensures the request is not tampered with in transit. This provides resiliance not only against network layer manipulation, but also man-in-the-middle attacks.

At a high level, an HMAC signature is created based upon the raw request body, the HTTP method, the URI (with query parameters, if present), and the current date. In addition to ensuring the request cannot be manipulated in transit, it also ensures that the request is timeboxed, effectively preventing replay attacks.

The library itself is made available by importing the following struct:

Supporting API's will return the following payload containing at minimum the following information.

json { "access_token": "7XF56VIP7ZQQOLGHM6MRIK56S2QS363ULNB5UKNFMJRQVYHQH7IA", "refresh_token": "MA2JX5FXWS57DHW4OIHHQDCJVGS3ZKKFCL7XM4GNOB567I6ER4LQ", "ikm": "bDEyECRvKKE8w81fX4hz/52cvHsFPMGeJ+a9fGaVvWM=", "signing": "7v/CdiGoEI7bcj7R2EyDPH5nrCd2+7rHYNACB+Kf2FMx405und2KenGjNpCBPv0jOiptfHJHiY3lldAQTGCdqw==", "expires_at": 1472678411 }

With this token you can authorized requests to supporting APIs as follows:

```rust use ncryptf::*;

match Token::fromjson(json) { Err() => {}, Ok(token) => { let auth = Authorization::from( "POST".tostring(), "/api/v1/test".tostring(), token, chrono::offset::Utc::now(), None, None );

// make a reqwest with Authorization: auth.get_header()

} } ```

Review the crate documentation and other ncryptf libraries for Version 1 header information

Encrypted Requests & Responses

This library enables clients to establish and trusted encrypted session on top of a TLS layer, while simultaniously (and independently) providing the ability authenticate and identify a client via HMAC+HKDF style authentication.

The rationale for this functionality includes but is not limited to:

1. Necessity for extra layer of security
2. Lack of trust in the network or TLS itself (see https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/)
3. Need to ensure confidentiality of the Initial Key Material (IKM) provided by the server for HMAC+HKDF authentication
4. Need to ensure confidentiality of user submitted credentials to the API for authentication

The primary reason you may want to establish an encrypted session with the API itself is to ensure confidentiality of the IKM to prevent data leakages over untrusted networks to avoid information being exposed in a Cloudflare like incident (or any man-in-the-middle attack). Encrypted sessions enable you to utilize a service like Cloudflare should a memory leak occur again with confidence that the IKM and other secure data would not be exposed.

Review the test/integration.rs file for a full example of making requets and encrypting and decrypting responses.

V2 Encrypted Payload

Verison 2 works identical to the version 1 payload, with the exception that all components needed to decrypt the message are bundled within the payload itself, rather than broken out into separate headers. This alleviates developer concerns with needing to manage multiple headers.

The version 2 payload is described as follows. Each component is concatanated together.

| Segment | Length | |---------|--------| | 4 byte header DE259002 in binary format | 4 BYTES | | Nonce | 24 BYTES | | The public key associated to the private key | 32 BYTES | | Encrypted Body | X BYTES | | Signature Public Key | 32 BYTES | | Signature or raw request body | 64 BYTES | | Checksum of prior elements concatonated together | 64 BYTES |