Allow alternative underlying crypto libraries to be swapped in

[daviddrysdale]

The Rust port currently uses the RustCrypto crates for underlying crypto functionality. It may be useful to support alternative underlying crypto libraries, such as:

• ring
• mundane
• sodiumoxide
• openssl

TBD whether alternatives would be selected at build time (e.g. via features) or more dynamically (trait impls?).

[daviddrysdale]

Notes on algorithm availability:

Primitive	Algorithm	RustCrypto	mundane	ring	sodiumoxide	openssl
	Notes:	Mostly pure Rust implementations		Uses forked chunks of...		Low-level bindings, difficult to use
	Based on:		BoringSSL	libsodium	OpenSSL
AEAD	AES-EAX
AEAD	AES-GCM	aes-gcm		ring::aead::AES_{128,256}_GCM		openssl::symm::Cipher::aes_*_gcm
AEAD	AES-GCM-SIV	aes-gcm-siv (#12)		(#412)
AEAD	AES-CTR-HMAC	aes-ctr				openssl::symm::Cipher::aes_*_ctr
AEAD	KMS Envelope
AEAD	CHACHA20-POLY1305	chacha20poly1305::ChaCha20Poly1305		ring::aead::CHACHA20_POLY1305	sodiumoxide::crypto::aead::chacha20poly1305_ietf	openssl::symm::Cipher::chacha20_poly1305
AEAD	XCHACHA20-POLY1305	chacha20poly1305::XChaCha20Poly1305			sodiumoxide::crypto::aead::xchacha20poly1305_ietf	(Present in BoringSSL but not in the wrapper crate)
Deterministic AEAD	AES-SIV	aes-siv		(#517)
Streaming AEAD	AES-GCM-HKDF	aes-gcm		ring::aead::AES_{128,256}_GCM		openssl::symm::Cipher::aes_*_gcm
Streaming AEAD	AES-CTR-HMAC	aes-ctr				openssl::symm::Cipher::aes_*_ctr
PRF	HKDF-SHA2	hkdf		ring::hkdf		(Present in BoringSSL but not in the wrapper crate)
PRF	HMAC-SHA2	hmac	mundane::hmac	ring::hmac	sodiumoxide::crypto::auth::hmacsha*	openssl::pkey::PKey::hmac
PRF	AES-CMAC	aes, cmac				openssl::pkey::PKey::cmac
MAC	HMAC-SHA2	hmac	mundane::hmac	ring::hmac	sodiumoxide::crypto::auth::hmacsha*	openssl::pkey::PKey::hmac
MAC	AES-CMAC	aes, cmac				openssl::pkey::PKey::cmac
Signature	ECDSA-P256	ecdsa, p256	mundane::public::ec::P256	ring::signature::ECDSA_P256_SHA256_FIXED		(openssl::nid::Nid::X9_62_PRIME256V1)
Signature	ECDSA-P384		mundane::public::ec::P384	ring::signature::ECDSA_P384_SHA384_FIXED		(openssl::nid::Nid::SECP384R1)
Signature	ECDSA-P521		mundane::public::ec::P521			(openssl::nid::Nid::SECP521R1)
Signature	Ed25519	ed25519, ed25519-dalek	mundane::public::ed25519	ring::signature::ED25519	sodiumoxide::crypto::sign	(openssl::pkey::Id::ED25519)
Signature	RSA-SSA-PKCS1	rsa (Not yet included in Tink-Rust)	mundane::public::rsa::RsaPkcs1v15	ring::signature::RSA_PKCS1_SHA*		openssl::rsa::Rsa, (openssl::nid::Nid::PKCS1)
Signature	RSA-SSA-PSS		mundane::public::rsa::RsaPss	ring::signature::RSA_PSS_SHA*		openssl::rsa::Rsa, (openssl::nid::Nid::RSASSAPSS)
Hybrid	ECIES + AEAD + HKDF

[tarcieri]

You might also consider evercrypt-rust which provides an FFI wrapper to formally verified C implementations.

[mikedanese]

Would you be open to contribution of aws-lc-rs support as an alternative cyrpto backend? AWS-LC has some interesting benefits such has such as a FIPS 140 CMVP cert and has undergone significant formal verification.

[daviddrysdale]

Would you be open to contribution of aws-lc-rs support as an alternative cyrpto backend?

Yes in theory – but in practice I've not got much time available for crate maintenance. So a PR might languish for a long time before it got reviewed or merged.

@conradgrobler : Any thoughts? Do you have spare bandwidth?

[conradgrobler]

I think that it would be useful as a backend. I should have time to review such a PR in the new year.