
Post-Quanten-Hybridverschlüsselungsbibliothek, die X25519 + ML-KEM-768 mit AES-256-GCM kombiniert
Post-Quanten-Hybrid-Verschlüsselungs- und Schlüsselverwaltungsserver.
Citadel kombiniert X25519 + ML-KEM-768 zur Schlüsselkapselung und AES-256-GCM zur Datenverschlüsselung, gemäß dem Hybridansatz von NIST für den Post-Quanten-Übergang. Anwendungen verschlüsseln und entschlüsseln Daten über eine REST-API. Citadel verwaltet die Schlüssel – Generierung, Rotation, Widerruf, Zugriffskontrolle und Prüfprotokollierung.
Status: Funktionierende Implementierung. Nicht auditiert. Keine Produktionsbereitstellungen. Siehe Sicherheit unten.
Your Application Citadel Database
| | |
|-- POST /encrypt ------->| |
| |-- hybrid KEM (X25519+ML-KEM) |
| |-- derive AES-256 key (HKDF) |
| |-- encrypt with AES-256-GCM |
|<-- encrypted blob ------| |
| |
|-- store blob ------------------------------------------>|
Ihre Anwendung berührt niemals das rohe Schlüsselmaterial. Der verschlüsselte Blob ist in sich geschlossen – er enthält den verpackten Schlüssel, Algorithmuskennungen und den Chiffrattext. Speichern Sie ihn in jeder Datenbank. Entschlüsseln Sie ihn, indem Sie ihn mit derselben AAD und demselben Kontext an Citadel zurücksenden.
citadel-envelope Hybridverschlüsselungskern (X25519 + ML-KEM-768 + AES-256-GCM)
citadel-keystore Schlüssel-Lebenszyklusverwaltung, 4-stufige Hierarchie, bedrohungsadaptive Richtlinien
citadel-api HTTP-Server, bereichsspezifische API-Schlüssel-Authentifizierung, Ratenbegrenzung, Echtzeit-Dashboard
# Klonen
git clone https://github.com/mrcord77/rust_citadel.git
cd rust_citadel
# Ihren Admin-API-Schlüssel festlegen
echo -n "your-secret-key" | sha256sum | cut -d' ' -f1
# Kopieren Sie den Hash
# Starten
CITADEL_API_KEY_HASH=<eingefügter-hash> docker compose up -d
# Prüfen
curl http://localhost:3000/health
# {"status":"ok","version":"0.2.0"}
Dashboard: http://localhost:3000
Erfordert Rust 1.75+.
cargo build --release -p citadel-api
CITADEL_API_KEY="your-secret-key" CITADEL_SEED_DEMO=true ./target/release/citadel-api
import requests
api = "http://localhost:3000"
headers = {"Authorization": "Bearer your-secret-key"}
# Verschlüsseln
r = requests.post(f"{api}/api/keys/{dek_id}/encrypt", headers=headers, json={
"plaintext": "sensitive data",
"aad": "record-001", # bindet Chiffrattext an diesen Datensatz
"context": "patient-records" # Bereichstrennung
})
blob = r.json()
# Entschlüsseln
r = requests.post(f"{api}/api/decrypt", headers=headers, json={
"blob": blob,
"aad": "record-001",
"context": "patient-records"
})
plaintext = r.json()["plaintext"]
Siehe citadel_example.py für ein vollständiges Arbeitsbeispiel mit AAD-Bindung, Schlüsselrotation und bedrohungsbewusstem Anwendungsverhalten.
# Status
curl http://localhost:3000/api/status -H "Authorization: Bearer $KEY"
# Schlüssel auflisten
curl http://localhost:3000/api/keys -H "Authorization: Bearer $KEY"
# Verschlüsseln
curl -X POST http://localhost:3000/api/keys/$DEK_ID/encrypt \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{"plaintext":"hello","aad":"test","context":"demo"}'
Root Key
└── Domain Key (pro Umgebung / Geschäftseinheit)
└── KEK — Key Encrypting Key (umhüllt DEKs)
└── DEK — Data Encrypting Key (verschlüsselt Anwendungsdaten)
Folgt NIST SP 800-57. Jede Ebene begrenzt den Schadensradius einer Kompromittierung – ein durchgesickerter DEK legt keine anderen DEKs offen, da der KEK separat ist.
| Bereich | Berechtigungen |
|---|---|
read | Schlüssel, Status, Metriken, Bedrohungsstufe anzeigen |
encrypt |
admin impliziert alle anderen Bereiche. Prinzip der geringsten Privilegien: Geben Sie Überwachungs-Dashboards read, Anwendungsdiensten read + encrypt, Verwaltungswerkzeugen admin.
Citadel überwacht Sicherheitsereignisse und passt die Schlüsselrichtlinien automatisch an:
Ereignisse, die die Bedrohungsstufe erhöhen: fehlgeschlagene Authentifizierung, Entschlüsselungsfehler, schnelle Zugriffsmuster, manuelle Eskalation. Der Wert nimmt mit der Zeit ab.
Hybride Konstruktion: Beide gemeinsamen Geheimnisse werden konkateniert und durch HKDF geführt. Die Sicherheit bleibt erhalten, wenn entweder X25519 oder ML-KEM-768 sicher bleibt.
version[1] || suite_kem[1] || suite_aead[1] || flags[1] || kem_ct_len[2] ||
x25519_ephemeral_pk[32] || mlkem768_ct[1088] || nonce[12] || aead_ct[variable]
Selbstbeschreibend, versioniert, keine Aushandlung (verhindert Downgrade-Angriffe). Siehe SPEC.md für die vollständige Spezifikation.
subtle-Kiste verhindert Timing-AngriffeZeroizing<T> eingewickelt und werden beim Löschen genulltCitadel ist nicht auditierte Software.
Die Implementierung verwendet NIST-standardisierte Primitive über etablierte Rust-Kisten (ml-kem, x25519-dalek, aes-gcm, hkdf). Sie implementiert keine kryptografischen Algorithmen. Der Wert liegt in der korrekten Zusammensetzung, nicht in neuartiger Mathematik.
Was getan wurde:
Was NICHT getan wurde:
Nicht für sensible Daten ohne unabhängige Überprüfung verwenden. Siehe SECURITY.md für die Meldung von Schwachstellen.
Abgebildet auf 34 NIST SP 800-57-Kontrollen: 26 erfüllt, 7 teilweise, 1 Lücke. Siehe COMPLIANCE_MATRIX.md für die vollständige Zuordnung.
Relevante Rahmenwerke: NIST SP 800-57 (Schlüsselverwaltung), CNSA 2.0 (PQC-Zeitplan), HIPAA (Verschlüsselung im Ruhezustand), SOC 2 (Zugriffskontrollen und Prüfung).
rust_citadel/
├── citadel-envelope/ # Kernbibliothek für hybride Verschlüsselung
│ ├── src/
│ │ ├── envelope.rs # Ver-/Entschlüsselungsvorgänge
│ │ ├── kem.rs # Hybride KEM (X25519 + ML-KEM-768)
│ │ ├── kdf.rs # HKDF-SHA256-Schlüsselableitung
│ │ ├── wire.rs # Drahtformat kodieren/dekodieren
│ │ ├── aead.rs # AES-256-GCM-Wrapper
│ │ ├── aad.rs # Zusätzliche authentifizierte Daten
│ │ ├── error.rs # Einheitliche Fehlertypen
│ │ └── sdk.rs # Hochsprachliche API
│ ├── tests/ # KAT + Roundtrip-Tests
│ └── fuzz/ # Fuzz-Ziele
├── citadel-keystore/ # Schlüssel-Lebenszyklusverwaltung
│ └── src/
│ ├── keystore.rs # Schlüssel-CRUD + Zustandsautomat
│ ├── policy.rs # Richtlinien für Kryptoperioden
│ ├── threat.rs # Adaptive Bedrohungsanalyse
│ ├── storage.rs # Dateibasierte Schlüsselspeicherung
│ ├── audit.rs # Integritätsverkettetes Prüfprotokoll
│ └── types.rs # Schlüsseltypen und -zustände
├── citadel-api/ # HTTP-Server
│ └── src/
│ ├── main.rs # API-Routen, Authentifizierung, Ratenbegrenzung
│ └── dashboard.html # Echtzeit-Sicherheitsdashboard
├── citadel_example.py # Python-Integrationsbeispiel
├── Backup-Citadel.ps1 # Sicherungs-/Wiederherstellungswerkzeug
├── docker-compose.yml # Entwicklungsumgebung
├── docker-compose-production.yml # Produktion mit TLS
├── SPEC.md # Drahtformat-Spezifikation
├── THREAT_MODEL.md # Sicherheitsziele und Angreifermodell
├── COMPLIANCE_MATRIX.md # NIST 800-57-Kontrollzuordnung
└── CITADEL_OVERVIEW.md # Kommerzieller Überblick
Dieses Projekt ist zweifach lizenziert:
Wenn Sie diese Software in einer kommerziellen Umgebung verwenden oder die AGPL-Bedingungen nicht einhalten möchten, müssen Sie eine kommerzielle Lizenz erwerben.
Siehe COMMERCIAL_LICENSE.md für kommerzielle Bedingungen.
Der vollständige Text der AGPL ist in AGPL-3.0.txt und COPYING enthalten.
Kontakt: [email protected]
Andre Cordero — [email protected]
| Endpunkt | Methode | Bereich | Beschreibung |
|---|
/health | GET | — | Health-Check |
/api/status | GET | read | Bedrohungsstufe, Schlüsselanzahl |
/api/metrics | GET | read | Sicherheitsmetriken |
/api/keys | GET | read | Alle Schlüssel auflisten |
/api/keys | POST | manage | Neuen Schlüssel generieren |
/api/keys/:id | GET | read | Schlüsseldetails abrufen |
/api/keys/:id/activate | POST | manage | Einen ausstehenden Schlüssel aktivieren |
/api/keys/:id/rotate | POST | manage | Schlüssel rotieren (neue Version) |
/api/keys/:id/revoke | POST | manage | Schlüssel dauerhaft widerrufen |
/api/keys/:id/destroy | POST | manage | Schlüsselmaterial vernichten |
/api/keys/:id/encrypt | POST | encrypt | Daten verschlüsseln |
/api/decrypt | POST | encrypt | Daten entschlüsseln |
/api/threat | GET | read | Bedrohungsinformationen im Detail |
/api/policies | GET | read | Aktive Schlüsselrichtlinien |
/api/auth/whoami | GET | read | Aktuelle API-Schlüssel-Informationen |
/api/auth/keys | GET | admin | API-Schlüssel auflisten |
/api/auth/keys | POST | admin | API-Schlüssel erstellen |
/api/auth/keys/:id | DELETE | admin | API-Schlüssel widerrufen |
| Daten verschlüsseln und entschlüsseln |
manage | Schlüssel erstellen, rotieren, widerrufen, vernichten |
admin | Alles oben Genanntes + API-Schlüssel verwalten |
| Stufe | Auslöser | Reaktion |
|---|
| LOW | Normalbetrieb | Standard-Kryptoperioden |
| GUARDED | Geringfügige Anomalien | Etwas engere Rotation |
| ELEVATED | Verdächtige Muster | Verkürzte Rotationspläne |
| HIGH | Aktive Bedrohungsindikatoren | Erzwungene Rotation, reduzierte Nutzungsbeschränkungen |
| CRITICAL | Unter Angriff | Maximale Einschränkungen |
| Komponente | Algorithmus | Standard |
|---|
| Schlüsselkapselung (klassisch) | X25519 ECDH | RFC 7748 |
| Schlüsselkapselung (post-quanten) | ML-KEM-768 | FIPS 203 |
| Datenverschlüsselung | AES-256-GCM | NIST SP 800-38D |
| Schlüsselableitung | HKDF-SHA256 | NIST SP 800-56C |
| Dokument | Zielgruppe |
|---|
| SPEC.md | Drahtformat-Spezifikation |
| THREAT_MODEL.md | Sicherheitsziele und Annahmen |
| COMPLIANCE_MATRIX.md | NIST 800-57-Konformitätszuordnung |
| CITADEL_OVERVIEW.md | Kommerzielle Positionierung |
| SECURITY.md | Meldung von Schwachstellen |
| API_FREEZE.md | API-Stabilitätsgarantien |
| DEPLOYMENT.md | Anleitung zur Produktionsbereitstellung |
| QUICKSTART.md | Erste Schritte |