Git-Mirrors/veilid-dot-com
1
0
Fork 0
mirror of https://gitlab.com/veilid/veilid-dot-com.git synced 2024-10-01 01:05:53 -04:00
Code Issues Packages Projects Releases Wiki Activity
1ed2142524
veilid-dot-com/pages/docs/cryptography.md
Alice Rhodes 604f55ccec Reorganizing pages 
- framework pages are now under docs
- removed pages that just dupe repo content
- made the code repositories pages the download page
- docs home page advertising the documentation work push
2023-08-23 12:24:30 -04:00

5.8 KiB
Raw Blame History

title description weight layout
Cryptography An overview of the cryptography used in Veilid 23 subpage

Strong, appropriate, cryptography choices are essential to the functioning of Veilid.

Veilid provides applications guarantees about how data is handled on the wire and at rest.

Cryptosystems were chosen that work well together and provide a balance of speed and cryptographic hardness.

Current Cryptography Systems

  • Authentication is Ed25519

    Elliptic curve25519 was chosen to provide public/private key authentication and signing capabilities

  • Key Exchange is x25519

    Curve25519 has a DH function that allows nodes to generate a symmetric key to communicate privately.

  • Encryption is XChaCha20-Poly1305

    ChaCha20 with a 192-bit extended nonce is a fast authenticated stream cipher with associated data (AEAD).

  • Message Digest is BLAKE3

    BLAKE3 is a extremely fast cryptographic hash that is highly parallelizable and as strong as SHA3-256 and over 17 times faster.

  • Key Derivation is Argon2

    Password hash generation should be slow and resistant to GPU attacks Argon2 was the winner of the 2015 Password Hashing Competition.

Upgrading Cryptography Systems

Nothing lasts forever and cryptography is no exception. As computing power improves and cryptographic attacks evolve, weaknesses in cryptosystems are inevitable.

Veilid has ensured that upgrading to newer cryptosystems is streamlined and minimally invasive to app developers, and handled transparently at the node level.

  • Multiple Routing Tables

    Because changing cryptosystems changes node ids, there will be different distance measurements between nodes, necessitating a separate routing table per cryptosystem. We support this today.

  • Typed Keys

    Cryptographic keys, signatures, and hashes are all tagged with their cryptosystem to ensure that we know exactly how they were generated and how they should be used and persisted.

  • Migration Support

    Reading persisted data will automatically use the correct cryptosystem and will default to always writing it back using the newest/best cryptosystem. This allows for data to be easily migrated just by reading it and writing it back to storage.

  • Simultaneous Cryptosystems

    While transitioning cryptosystems, nodes can respond to other nodes using either the old system or the new one, or both.

Secure Storage

  • Device-level secret storage APIs are available for all platforms
  • Encrypted table store APIs are exposed to applications to make safe data storage easy
  • Device data keys can also be password protected
  • Apps never need to write anything to disk unencrypted

ProtectedStore

Device-level Secret Storage

  • MacOS / iOS Keychain
  • Android Keystore
  • Windows Protected Storage
  • Linux Secret Service
New Rust Crate: keyring-manager

TableStore

Encrypted Key-Value Database

  • SQLITE on Native
  • IndexedDB in Browser
  • Device Key can be protected from backup dumping attacks
New Rust Crate: keyvaluedb

RecordStore

Distributed Hash Table Storage

  • Encrypted + Authenticated
  • Subkey support
  • LRU distributed cache
  • Per-key multi-writer schemas

BlockStore

Content-addressable Data Distribution

  • Take What You Give model
  • Connect and share cloud storage
  • Bittorrent-like sharding
This feature is "coming soon."

On The Wire

Everything is end-to-end encrypted

Data is encrypted at rest and on the wire

Your data is protected even if you lose your device

  • All Protocols Same Encryption

    Each low-level protocol uses the same message and receipt encapsulation. No protocol is special and all protocols offer the same safety guarantees.

  • Encrypted And Signed

    Messages between nodes are signed by the sender and encrypted for only the receiver. Messages can be relayed without decryption and authentication covers the entire contents including headers.

  • Everything Is Timestamped

    Envelopes include timestamps and unique nonces and reject old or replayed messages.

  • Node Information Is Signed

    When a node publishes routing table entries they are signed. No node can lie about another node's dial info, capabilities, availability, or replay old node info when newer info is available.