Skip to content

Commit 6c812ce

Browse files
xrissoulaaryanjassal
authored andcommitted
feat: update and lint encryption documentation
1 parent 913033c commit 6c812ce

File tree

8 files changed

+550
-8
lines changed

8 files changed

+550
-8
lines changed

docs/reference/DES.md

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
# Symmetric Data Encapsulation Scheme (DES)
2+
3+
Polykey’s state is completely stored in the database. This means everything critical to the system's function—keys, metadata, and configurations—is written to disk. To ensure the security and integrity of this data, we encrypt the database using a **32-byte Data Encryption Key (DB Key)** and the **XChaCha20-Poly1305-IETF** symmetric encryption algorithm, provided by **libsodium**.
4+
5+
## Why We Use Symmetric Encryption
6+
7+
Encryption is non-negotiable for a system like Polykey, where data security is a core priority. Symmetric encryption is used for:
8+
9+
- **Confidentiality** - Ensuring database contents are only accessible to the rightful owner.
10+
- **Integrity** - Preventing unauthorized tampering by detecting any modifications.
11+
- **Performance** - Symmetric encryption is significantly faster than asymmetric encryption for large datasets.
12+
13+
## Database Encryption Key (DB Key)
14+
15+
### **How the DB Key Works**
16+
17+
The DB Key is a **randomly generated 32-byte key** that encrypts all database content. This key is stored on disk, but never in plaintext—it is always encrypted before being written to storage.
18+
19+
The DB Key is used to encrypt and decrypt the entire database, meaning that without it, **all data in the system is inaccessible**.
20+
21+
### **Why the DB Key is Not Derived from the Root Key**
22+
23+
A common approach in cryptographic systems is to derive all keys from a single root key. However, this is not how Polykey manages database encryption. The DB Key is independent from the root key for the following reasons:
24+
25+
1. **Key Rotation & Flexibility**
26+
If the root key were used to derive the DB Key, changing the root key would require re-encrypting the entire database. This would be a **catastrophic** operation in terms of efficiency and usability. Instead, by keeping the DB Key separate, the database can remain encrypted even when the root key is changed.
27+
28+
2. **Minimizing Attack Surfaces**
29+
If an attacker compromises the root key, they still cannot access the database contents without the DB Key. This adds an extra layer of security.
30+
31+
3. **Persistence Across Keypair Changes**
32+
In Polykey, root keypairs can be swapped out periodically for security reasons (like how passwords should be rotated). By decoupling the DB Key, the database encryption remains stable across key rotations.
33+
34+
## Encryption Algorithm: XChaCha20-Poly1305-IETF
35+
36+
Polykey uses **XChaCha20-Poly1305-IETF**, a widely respected symmetric encryption scheme known for its:
37+
38+
- **256-bit key size** - Strong encryption without performance tradeoffs.
39+
- **192-bit nonce** - Ensures nonce reuse attacks are virtually impossible.
40+
- **Authenticated encryption** - Includes integrity checks, so any unauthorized modifications are detected.
41+
42+
### **Why XChaCha20-Poly1305?**
43+
44+
1. **Nonce Misuse Resistance**
45+
Unlike AES-GCM, which has strict nonce reuse requirements, XChaCha20 allows for random nonce generation with no risk of catastrophic failures.
46+
47+
2. **High Performance**
48+
Stream ciphers like XChaCha20 are significantly faster than block ciphers like AES in many scenarios, making them well-suited for encrypting large datasets.
49+
50+
3. **Compatibility with Libsodium**
51+
Libsodium is a battle-tested cryptographic library that provides a simple and secure implementation of XChaCha20-Poly1305, reducing the risk of implementation errors.
52+
53+
## Key Rotation & Secure Storage
54+
55+
### **Key Rotation Strategy**
56+
57+
Regular key rotation is a fundamental security practice. However, since re-encrypting an entire database is computationally expensive, Polykey manages key rotations in a way that minimizes disruption:
58+
59+
1. **The DB Key is swapped periodically** - This reduces long-term key exposure.
60+
2. **New keys are securely generated and encrypted using KEM (Key Encapsulation Mechanism)** - This ensures a smooth transition without exposing old encrypted data.
61+
3. **Polykey handles the transition automatically** - Users do not need to worry about database re-encryption when keypairs are rotated.
62+
63+
### **How the DB Key is Stored**
64+
65+
The DB Key is **never stored in plaintext**. Instead, it is encrypted and saved as a **JWE (JSON Web Encryption) file**. This file is securely managed to ensure that only authorized nodes can decrypt and use it.
66+
67+
## Security Considerations
68+
69+
- **Loss of the DB Key = Complete Data Loss**
70+
If the encrypted DB Key is lost, **all data within Polykey is permanently inaccessible**. Users must ensure backups are properly managed.
71+
72+
- **Frequent Key Rotation is Good Practice**
73+
Regularly rotating the DB Key prevents long-term exposure and mitigates risks from potential future cryptographic weaknesses.
74+
75+
- **Secure Backup Management is Critical**
76+
Since Polykey does not store plaintext recovery keys, **users must securely back up their 24-word recovery code** to ensure they can regain access if needed.
77+
78+
## Conclusion
79+
80+
The **Symmetric Data Encapsulation Scheme (DES)** is a critical component of Polykey's security model. By leveraging XChaCha20-Poly1305-IETF for high-speed encryption and ensuring the **DB Key remains independent from the root key**, Polykey maintains a **balance between security, performance, and usability**.

docs/reference/ecis.md

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
# Elliptic Curve Integrated Encryption Scheme (ECIES)
2+
3+
## Overview
4+
5+
Polykey's security model is built around **Elliptic Curve Integrated Encryption Scheme (ECIES)**. ECIES is a hybrid cryptosystem that combines the efficiency of symmetric encryption with the security of asymmetric encryption, making it ideal for key exchange and encrypted communication.
6+
7+
At its core, ECIES allows secure communication between parties without requiring them to share a secret key in advance. Instead, it uses elliptic curve cryptography (ECC) to derive a shared secret dynamically, ensuring both confidentiality and authenticity.
8+
9+
## Why Polykey Uses ECIES
10+
11+
Polykey leverages ECIES because it provides:
12+
13+
* **Strong security**: ECC-based key exchange ensures forward secrecy.
14+
* **Efficient performance**: ECC is computationally faster than RSA at equivalent security levels.
15+
* **Hybrid encryption**: Uses symmetric encryption for bulk data and asymmetric encryption for key exchange.
16+
* **Secure key encapsulation**: Keys are encrypted in a way that prevents exposure during transmission.
17+
18+
## How ECIES Works
19+
20+
ECIES works by using Elliptic Curve Diffie-Hellman (ECDH) for key exchange and a symmetric cipher for encryption.
21+
22+
The encryption process follows these steps:
23+
24+
1. **Key Exchange**:
25+
26+
* The sender generates a temporary ephemeral key pair.
27+
* The sender derives a shared secret using their ephemeral private key and the recipient's public key.
28+
29+
2. **Key Derivation**:
30+
31+
* The shared secret is used to generate encryption keys through a Key Derivation Function (KDF).
32+
33+
3. **Encryption**:
34+
35+
* A symmetric encryption algorithm (e.g., XChaCha20-Poly1305 ) encrypts the plaintext.
36+
* An authentication tag is generated to prevent tampering.
37+
38+
4. **Transmission**:
39+
40+
* The ciphertext, ephemeral public key, and authentication tag are sent to the recipient.
41+
42+
5. **Decryption**:
43+
44+
* The recipient uses their private key to derive the shared secret.
45+
* The symmetric key is reconstructed using the same KDF.
46+
* The ciphertext is decrypted, and authenticity is verified.
47+
48+
## ECIES in Polykey
49+
50+
Polykey uses ECIES as the foundation for secure communication, storage, and key management. Specifically, it is used for:
51+
52+
* **Key Encapsulation Mechanism (KEM)**: Encapsulating encryption keys for secure storage.
53+
* **Node-to-Node Communication**: Establishing secure tunnels between Polykey nodes.
54+
* **Key Exchange**: Securely transferring symmetric encryption keys for encrypted storage.
55+
56+
### Key Encapsulation and Secure Storage
57+
58+
Polykey encrypts sensitive keys using ECIES-based encapsulation. This means:
59+
60+
* The Data Encryption Key (DB Key) is never stored in plaintext.
61+
* The DB Key is wrapped using ECIES before being saved.
62+
* Only an authenticated node with the correct private key can unwrap the DB Key and decrypt the database.
63+
64+
### Secure Messaging Between Nodes
65+
66+
When Polykey nodes communicate, they exchange keys using ECIES. This allows them to:
67+
68+
* Establish a secure session without pre-sharing a secret key.
69+
* Prevent man-in-the-middle attacks by ensuring only authorized nodes can decrypt messages.
70+
* Authenticate each other using their public-private key pairs.
71+
72+
## Why ECIES is Preferred Over RSA
73+
74+
Historically, RSA-based encryption was the standard for key exchange, but ECIES provides several advantages:
75+
76+
| Feature | ECIES (ECC) | RSA |
77+
|---------|------------|-----|
78+
| **Key Size (bits)** | 256 | 2048 |
79+
| **Security Level** | Stronger | Weaker at equivalent key size |
80+
| **Performance** | Faster | Slower |
81+
| **Key Exchange** | Supported | Not ideal for key exchange |
82+
83+
Because ECIES achieves the same level of security as RSA with much smaller key sizes, it is the preferred choice for modern cryptographic systems like Polykey.
84+
85+
## Future-Proofing Against Quantum Attacks
86+
87+
Polykey is designed to evolve with cryptographic advancements. While ECIES is secure today, quantum computers could potentially break ECC in the future. When quantum-resistant encryption becomes practical, Polykey will migrate to a Post-Quantum Integrated Encryption Scheme (PQIES).
88+
89+
## Conclusion
90+
91+
ECIES is at the heart of Polykey's encryption model, providing secure, efficient, and scalable key exchange. By combining elliptic curve cryptography with hybrid encryption techniques, Polykey ensures strong security, efficient performance, and forward secrecy.
92+
93+
Polykey's implementation of ECIES allows:
94+
95+
* Secure key exchange without pre-shared secrets.
96+
* Confidential and authenticated communication between nodes.
97+
* Safe and efficient key storage using encapsulated encryption.
98+
99+
As cryptographic standards evolve, Polykey remains committed to using the most secure and performant encryption schemes available.
Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
# Encryption Algorithms and Security Considerations
2+
3+
## Overview
4+
5+
Polykey's security model is built on modern cryptographic principles to ensure confidentiality, integrity, and authentication across all operations. This document outlines the encryption algorithms Polykey employs, their strengths, and key security considerations for maintaining a secure system.
6+
7+
## Encryption Algorithms Used in Polykey
8+
9+
Polykey integrates a hybrid cryptosystem, combining symmetric and asymmetric cryptographic algorithms for optimal security and performance.
10+
11+
### Symmetric Encryption
12+
13+
* **AES-GCM (Advanced Encryption Standard - Galois/Counter Mode)**
14+
* Used for encrypting data at rest and in transit.
15+
* Provides both encryption and authentication in a single step.
16+
* 256-bit key length for strong security.
17+
* Resistant to padding oracle attacks due to its authenticated encryption structure.
18+
19+
### Asymmetric Encryption
20+
21+
* **X25519 (Elliptic Curve Diffie-Hellman)**
22+
* Used for key exchange and secure session establishment.
23+
* Based on Curve25519, which is efficient and resistant to side*channel attacks.
24+
* Provides forward secrecy by generating ephemeral session keys.
25+
26+
* **Ed25519 (Elliptic Curve Digital Signature Algorithm)**
27+
* Used for signing and verifying messages and transactions.
28+
* Strong resistance to side-channel attacks.
29+
* Deterministic signatures prevent nonce-related vulnerabilities.
30+
31+
### Key Encapsulation Mechanism (KEM)
32+
33+
* **ECIES (Elliptic Curve Integrated Encryption Scheme)**
34+
* Facilitates secure encryption of symmetric keys during key exchange.
35+
* Uses elliptic curve cryptography for efficient and secure key wrapping.
36+
* Ensures confidentiality and authenticity of the exchanged key.
37+
38+
## Security Considerations
39+
40+
### 1. Key Management
41+
42+
* **Recovery Codes:** Users must securely store their 24-word recovery code, as Polykey does not store private keys.
43+
* **Key Rotation:** Regular key rotation mitigates the risk of long-term key exposure.
44+
* **Secure Storage:** Encrypted key material must be stored in a secure environment to prevent unauthorized access.
45+
46+
### 2. Forward Secrecy
47+
48+
* Polykey ensures forward secrecy through ephemeral key exchange using X25519.
49+
* If a private key is compromised, past communications remain secure.
50+
51+
### 3. Authentication & Integrity
52+
53+
* Digital signatures (Ed25519) ensure data authenticity and prevent tampering.
54+
* Authenticated encryption (AES-GCM) guarantees data integrity.
55+
56+
### 4. Resistance to Quantum Threats
57+
58+
* While current encryption methods are secure, future quantum computing advancements may break classical cryptography.
59+
* Polykey's roadmap includes exploring post-quantum cryptographic alternatives.
60+
61+
### 5. Attack Surface Reduction
62+
63+
* Minimizing reliance on outdated cryptographic algorithms.
64+
* Eliminating common cryptographic pitfalls such as RSA-based key exchanges, which are vulnerable to decryption with modern computing power.
65+
66+
## Conclusion
67+
68+
Polykey employs a combination of AES-GCM, X25519, Ed25519, and ECIES to ensure strong security across all cryptographic operations. By following best practices in key management, forward secrecy, and attack surface reduction, Polykey maintains a robust security posture. Future updates may incorporate post-quantum cryptographic schemes to address emerging threats.
Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
# Hybrid Cryptosystem
2+
3+
Polykey's security model is built on a Hybrid Cryptosystem, which combines both symmetric and asymmetric encryption to achieve secure communication, storage, and identity management.
4+
5+
## Why Hybrid Encryption?
6+
7+
Encryption is necessary to protect sensitive data, but different encryption methods serve different purposes. A hybrid cryptosystem merges the strengths of both:
8+
9+
**Asymmetric Encryption** (Public and Private Key Pairs)
10+
11+
* Used for securely exchanging encryption keys
12+
* Allows verification of signatures
13+
* Ensures secure communication without prior key exchange
14+
15+
**Symmetric Encryption** (Shared Secret Keys)
16+
17+
* Used for encrypting large amounts of data efficiently
18+
* Faster than asymmetric encryption
19+
* Requires a secure method to exchange keys
20+
21+
By combining these two, Polykey ensures security in transit, at rest, and in use.
22+
23+
## Polykey's Implementation of Hybrid Cryptography
24+
25+
Polykey's hybrid cryptosystem is based on the Elliptic Curve Integrated Encryption Scheme (ECIES) and consists of two primary mechanisms:
26+
27+
1. **Key Encapsulation Mechanism (KEM)**
28+
29+
* Uses symmetric encryption to securely exchange a symmetric key.
30+
* This ensures that even if an attacker intercepts the communication, they cannot derive the encryption key without access to the private key.
31+
32+
2. **Data Encapsulation Scheme (DES)**
33+
34+
* Uses symmetric encryption (XChaCha20-Poly1305) to encrypt all Polykey data.
35+
* This ensures that once the symmetric key is established, encryption is fast and efficient.
36+
37+
### How This Works in Polykey
38+
39+
* The sender encrypts data using a symmetric key.
40+
* This symmetric key is then encrypted using the recipient's public key.
41+
* The recipient decrypts the symmetric key using their private key.
42+
* Once the symmetric key is obtained, it is used to decrypt the original data.
43+
44+
This method keeps encryption fast and secure, reducing computational overhead while maintaining strong security guarantees.
45+
46+
## Why Not Just Use One Type of Encryption?
47+
48+
Each encryption method has limitations:
49+
50+
**Asymmetric encryption is slow**
51+
52+
* Encrypting large amounts of data with public-private key pairs is inefficient.
53+
* It is only practical for encrypting small pieces of data, like symmetric keys.
54+
55+
**Symmetric encryption needs secure key exchange**
56+
57+
* If a secret key is leaked or intercepted, the encrypted data is compromised.
58+
* It requires a secure way to distribute and manage encryption keys.
59+
60+
A **hybrid cryptosystem** provides the best of both worlds:
61+
62+
* **Asymmetric encryption** protects the key exchange.
63+
* **Symmetric encryption** handles bulk data encryption efficiently.
64+
65+
## Future-Proofing with Post-Quantum Cryptography
66+
67+
Polykey currently uses Elliptic Curve Cryptography (ECC) for its hybrid system, specifically **Ed25519**. However, quantum computing could break ECC in the future. When quantum-safe encryption becomes more practical, Polykey will upgrade to a Post-Quantum Integrated Encryption Scheme to maintain long-term security.
68+
69+
## Conclusion
70+
71+
A hybrid cryptosystem is essential for balancing security, efficiency, and scalability. By leveraging symmetric encryption for key exchange and symmetric encryption for data protection, Polykey ensures robust security while keeping performance high.
72+
73+
Polykey's use of ECIES, KEM, and DES provides a secure foundation for encrypted communication, identity management, and data storage. This hybrid approach ensures that data remains protected, both now and in the future.

0 commit comments

Comments
 (0)