mirror of
https://github.com/spacedriveapp/spacedrive
synced 2024-07-04 13:23:28 +00:00
355ac191b8
* rebase: `crates/crypto` into current `main` * refactor: remove `mnemonic` module * feat: disable secure erase temporarily * fix: tsc * fix: tsc due to unused import * fix: remove `cli` crypto info * deps: update * chore: remove dead comment * refactor: remove `bincode` feature * refactor: give `keyring` a dedicated feature so it's not reliant on `sys` as well * fix: remove `aes-gcm` as it's no longer supported * refactor: remove dead comment * fix: update `keyring` imports * refactor: change tests to `aes-256-gcm` * feat: make `Key` a `Box<>` internally to ensure it's heap allocated (and fix tests) * chore: clippy * fix: hashing tests now that `const` keys aren't available this will be cleaned up with test vectors and `include_bytes!()` * chore: clippy * refactor: remove dead code * test: bring back `encrypt_with_invalid_nonce` test * fix: secret service keyring * fix: `zbus` build issues * doc: update comment for clearer reasoning * fix: cargo fmt * fix: use bytes directly * deps: update lockfile * fix: secret service keyring * fix: comment out windows keyring for now * fix: use session keyring if no keyring backend * fix: completely remove keyring module if no keyring is available for that OS * fix: clippy * fix: move iimport to correct conditional compilation * fix: fmt
44 lines
2.1 KiB
Markdown
44 lines
2.1 KiB
Markdown
# Crypto
|
|
|
|
This crate contains Spacedrive's cryptographic modules.
|
|
|
|
This includes things such as:
|
|
|
|
- The key manager
|
|
- Encryption and decryption
|
|
- Encrypted file header formats (with extremely fast serialization and deserialization)
|
|
- Key hashing and derivation
|
|
- Keyring interfaces to access native OS keystores
|
|
|
|
It has support for the following cryptographic functions:
|
|
|
|
- `Argon2id`
|
|
- `Balloon` hashing
|
|
- `BLAKE3` key derivation
|
|
- `XChaCha20-Poly1305`
|
|
- `AES-256-GCM-SIV`
|
|
|
|
It aims to be (relatively) lightweight, easy to maintain and platform-agnostic where possible. It does contain some platform-specific code, although it's only built if the target matches.
|
|
|
|
## Features
|
|
|
|
A list of all features can be found below (NOTE: none of these features are enabled by default)
|
|
|
|
- `serde` - provides integration with `serde` and `serde_json`
|
|
<!-- - `uuid` - enables the `uuid` crate -->
|
|
- `tokio` - provides integration with the `tokio` crate
|
|
- `specta` - provides integration with the `specta` crate
|
|
- `bincode` - provides integration with the `bincode` crate (this will likely become part of the crate)
|
|
- `keyring` - provides a unified interface for interacting with OS-keyrings (currently only supports MacOS/iOS/Linux `keyutils`). `keyutils` is not persistent, so is best used in a headless server/docker environment, as keys are wiped on-reboot. The Secret Service API is not practically available in headless environments.
|
|
- `secret-service` - enables `keyring` but also enables the Secret Service API (a persistent keyring targeted at Gnome/KDE (via `gnome-keyring` and `kwallet` respectively)). Is a pretty heavy dependency.
|
|
|
|
## Security Notice
|
|
|
|
This crate has NOT received any security audit - however, a couple of our upstream libraries (provided by [RustCrypto](https://github.com/RustCrypto)) have.
|
|
|
|
You may find them below:
|
|
|
|
- AES-GCM and XChaCha20-Poly1305 audit by NCC group ([link](https://research.nccgroup.com/wp-content/uploads/2020/02/NCC_Group_MobileCoin_RustCrypto_AESGCM_ChaCha20Poly1305_Implementation_Review_2020-02-12_v1.0.pdf))
|
|
|
|
Breaking changes are very likely! Use at your own risk - no stability or security is guaranteed.
|