2 releases (1 stable)

1.0.0 Sep 18, 2024
0.5.0 Apr 25, 2024

#1974 in Cryptography

Download history 28/week @ 2024-08-25 24/week @ 2024-09-01 40/week @ 2024-09-08 145/week @ 2024-09-15 63/week @ 2024-09-22 68/week @ 2024-09-29 14/week @ 2024-10-06 29/week @ 2024-10-13 258/week @ 2024-10-20 1105/week @ 2024-10-27 423/week @ 2024-11-03 860/week @ 2024-11-10 407/week @ 2024-11-17 667/week @ 2024-11-24 628/week @ 2024-12-01 919/week @ 2024-12-08

2,630 downloads per month
Used in 8 crates (7 directly)

Custom license

230KB
10K SLoC

Bitwarden Crypto

This is an internal crate for the Bitwarden SDK do not depend on this directly and use the bitwarden crate instead.

This crate does not follow semantic versioning and the public interface may change at any time.


lib.rs:

Bitwarden Cryptographic primitives

This crate contains the cryptographic primitives used throughout the SDK. The general aspiration is for this crate to handle all the difficult cryptographic operations and expose higher level concepts to the rest of the SDK.

Generally you should not find yourself needing to edit this crate! Everything written here requires additional care and attention to ensure that the cryptographic primitives are secure.

Example:

use bitwarden_crypto::{SymmetricCryptoKey, KeyEncryptable, KeyDecryptable, CryptoError};

async fn example() -> Result<(), CryptoError> {
  let key = SymmetricCryptoKey::generate(rand::thread_rng());

  let data = "Hello, World!".to_owned();
  let encrypted = data.clone().encrypt_with_key(&key)?;
  let decrypted: String = encrypted.decrypt_with_key(&key)?;

  assert_eq!(data, decrypted);
  Ok(())
}

Development considerations

This crate is expected to provide long term support for cryptographic operations. To that end, the following considerations should be taken into account when making changes to this crate:

  • Limit public interfaces to the bare minimum.
  • Breaking changes should be rare and well communicated.
  • Serializable representation of keys and encrypted data must be supported indefinitely as we have no way to update all data.

Conventions:

  • Pure Functions that deterministically "derive" keys from input are prefixed with derive_.
  • Functions that generate non deterministically keys are prefixed with make_.

Differences from clients

There are some noteworthy differences compared to the other Bitwarden clients. These changes are made in an effort to introduce conventions in how we name things, improve best practices and abstracting away internal complexity.

  • CryptoService.makeSendKey & AccessService.createAccessToken are replaced by the generic derive_shareable_key
  • MasterKey operations such as makeMasterKey and hashMasterKey are moved to the MasterKey struct.

Crate features

  • no-memory-hardening - Disables memory hardening which ensures that allocated memory is zeroed on drop. This feature primarily exists in case you do not want to use the standard allocator, and we advise to still define a global_allocator using the ZeroizingAllocator.

Dependencies

~9MB
~175K SLoC