SeraVault Sicherheits-Whitepaper

Technische Architektur & post-quanten-kryptografische Implementierung

Version: 1.0 Datum: November 2025 Status: Produktion

1. Zusammenfassung

SeraVault ist eine Zero-Knowledge-Plattform für Ende-zu-Ende-verschlüsselte Dateispeicherung und Nachrichtenübermittlung, die darauf ausgelegt ist, Angriffen sowohl durch klassische als auch durch Quantencomputer standzuhalten. Das System verwendet ML-KEM-768 (NIST FIPS 203), einen gitterbasierten Schlüsselkapselungsmechanismus, der vom NIST für die Post-Quanten-Kryptografie standardisiert wurde, kombiniert mit AES-256-GCM für die symmetrische Verschlüsselung.

Dieses Whitepaper bietet eine umfassende technische Beschreibung der kryptografischen Architektur von SeraVault, des Sicherheitsmodells und der Implementierung. Wir erläutern im Detail unser Zero-Knowledge-Design, die Protokolle zur Schlüsselverwaltung und die post-quanten-kryptografischen Primitive.

Hinweis: Dies ist ein lebendiges Dokument. Mit der Weiterentwicklung kryptografischer Standards und dem Fortschritt der Sicherheitsforschung werden wir unsere Implementierung und diese Dokumentation entsprechend aktualisieren. Die aktuelle Version spiegelt das Produktionssystem mit Stand November 2025 wider.

2. Bedrohungsmodell

2.1 Fähigkeiten des Angreifers

SeraVault ist darauf ausgelegt, vor den folgenden Angreifern zu schützen:

2.1.1 Kompromittierung des Servers

Wir gehen davon aus, dass die Serverinfrastruktur vollständig kompromittiert werden kann. Ein Angreifer, der sich vollständigen Zugriff auf unsere Server verschafft, sollte nicht in der Lage sein, die Dateien oder Nachrichten der Nutzer zu entschlüsseln. Dies wird durch clientseitige Verschlüsselung erreicht, bei der die Verschlüsselungsschlüssel den Server niemals im Klartext erreichen.

2.1.2 Netzwerk-Angreifer

Wir gehen davon aus, dass ein Angreifer den Netzwerkverkehr zwischen Clients und Servern abfangen, verändern oder einschleusen kann. TLS bietet Sicherheit auf Transportebene, doch unsere Verschlüsselung auf Anwendungsebene stellt sicher, dass selbst eine Kompromittierung von TLS keine Klartextdaten preisgibt.

2.1.3 Quanten-Angreifer

Wir rechnen mit zukünftigen Angreifern, die Zugriff auf kryptografisch relevante Quantencomputer (CRQC) haben. Traditionelle Public-Key-Kryptosysteme wie RSA und Kryptografie auf Basis elliptischer Kurven sind anfällig für den Shor-Algorithmus. SeraVault verwendet ML-KEM-768, das auf der Schwierigkeit von Gitterproblemen beruht, die als resistent gegen Quantenangriffe gelten.

2.1.4 Staatlicher Angreifer

Wir schützen auch gegen staatliche Akteure mit erheblichen Rechenressourcen, der Fähigkeit, Dienstanbieter zu Zwangsmaßnahmen zu verpflichten, und "Harvest Now, Decrypt Later"-Fähigkeiten, bei denen verschlüsselte Daten für eine spätere Entschlüsselung gespeichert werden, sobald Quantencomputer verfügbar werden.

2.2 Vertrauensannahmen

2.3 Außerhalb des Geltungsbereichs

Die folgenden Bedrohungen liegen ausdrücklich außerhalb des Geltungsbereichs:

3. Systemarchitektur

3.1 Zero-Knowledge-Design

SeraVault implementiert eine echte Zero-Knowledge-Architektur, bei der der Server keinen Zugriff hat auf:

Alle Ver- und Entschlüsselungsvorgänge finden clientseitig im Browser oder in der Anwendung des Nutzers statt. Der Server speichert ausschließlich verschlüsselte Daten und fungiert als reine Speicher- und Synchronisationsschicht.

3.2 Komponentenübersicht

3.2.1 Client-Anwendung

3.2.2 Cloud-Backend

3.3 Datenfluss

Ablauf des Datei-Uploads

  1. Der Nutzer wählt eine Datei im Browser aus
  2. Der Client generiert einen zufälligen symmetrischen 256-Bit-Schlüssel (Dateischlüssel)
  3. Der Client verschlüsselt den Dateiinhalt mit AES-256-GCM unter Verwendung des Dateischlüssels
  4. Der Client verschlüsselt die Datei-Metadaten (Name, Größe, Typ) mit dem Shared Secret des Nutzers
  5. Der Client kapselt den Dateischlüssel für den öffentlichen Schlüssel des Nutzers mit ML-KEM-768
  6. Der Client lädt den verschlüsselten Blob in den Cloud-Speicher hoch
  7. Der Client schreibt die verschlüsselten Metadaten und den gekapselten Schlüssel in die Backend-Datenbank

Ablauf des Datei-Downloads

  1. Der Client ruft die verschlüsselten Metadaten aus der Backend-Datenbank ab
  2. Der Client entschlüsselt die Metadaten mit dem Shared Secret des Nutzers
  3. Der Client entkapselt den Dateischlüssel mit ML-KEM-768 unter Verwendung des privaten Schlüssels des Nutzers
  4. Der Client lädt den verschlüsselten Blob aus dem Cloud-Speicher herunter
  5. Der Client entschlüsselt den Dateiinhalt mit AES-256-GCM unter Verwendung des Dateischlüssels
  6. Der Client präsentiert dem Nutzer die Datei im Klartext

4. Kryptografische Primitive

4.1 ML-KEM-768 (NIST FIPS 203)

Module-Lattice-Based Key-Encapsulation Mechanism (auf modularen Gittern basierender Schlüsselkapselungsmechanismus) ist unsere primäre post-quanten-kryptografische Primitive, die vom NIST im August 2024 als FIPS 203 standardisiert wurde.

Parameter

Parameter Wert
Sicherheitsniveau NIST Level 3 (entspricht AES-192)
Größe des öffentlichen Schlüssels 1.184 Bytes
Größe des privaten Schlüssels 2.400 Bytes
Größe des Chiffretexts 1.088 Bytes
Größe des Shared Secret 32 Bytes

Warum ML-KEM-768?

4.2 AES-256-GCM

Advanced Encryption Standard mit 256-Bit-Schlüsseln im Galois/Counter-Modus bietet authentifizierte Verschlüsselung für Dateiinhalte.

Eigenschaften

4.3 ChaCha20-Poly1305

ChaCha20-Poly1305 ist ein authentifizierter Hochgeschwindigkeits-Verschlüsselungsalgorithmus, der zum Schutz von sensiblem Schlüsselmaterial (wie Ihrem privaten Schlüssel) im Ruhezustand verwendet wird.

4.4 Argon2id

Argon2id zum Ableiten von Verschlüsselungsschlüsseln aus Nutzer-Passphrasen. Gewinner der Password Hashing Competition (2015).

Warum Argon2id: Argon2id ist speicherintensiv (memory-hard) und macht dadurch GPU- und ASIC-Angriffe teuer. Es kombiniert datenunabhängige (Argon2i) und datenabhängige (Argon2d) Ansätze für Seitenkanalresistenz und maximalen Schutz gegen parallele Knackversuche.

5. Protokoll zur Dateiverschlüsselung

5.1 Schlüsselerzeugung

Wenn ein Nutzer erstmals sein Konto erstellt und seine Verschlüsselungsschlüssel generiert:

// ML-KEM-768-Schlüsselpaar generieren (publicKey, privateKey) = ML-KEM-768.KeyGen() // Verschlüsselungsschlüssel aus der Passphrase ableiten salt = CSPRNG(32 bytes) encryptionKey = Argon2id(passphrase, salt, t=3, m=64MiB, p=4, 32 bytes) // Privaten Schlüssel mit dem aus der Passphrase abgeleiteten Schlüssel verschlüsseln nonce = CSPRNG(12 bytes) encryptedPrivateKey = ChaCha20-Poly1305.Encrypt(encryptionKey, nonce, privateKey) // Verschlüsselten privaten Schlüssel in der Backend-Datenbank speichern // Öffentlicher Schlüssel in der Backend-Datenbank gespeichert (im Klartext, da öffentlich)

5.2 Dateiverschlüsselung

Für jede hochgeladene Datei:

// 1. Zufälligen Dateiverschlüsselungsschlüssel generieren fileKey = CSPRNG(32 bytes) // 2. Dateiinhalt verschlüsseln nonce = CSPRNG(12 bytes) encryptedContent = AES-256-GCM.Encrypt(fileKey, nonce, fileContent) // Ergebnis enthält ein 16-Byte-Authentifizierungs-Tag // 3. Dateischlüssel für den Eigentümer kapseln (ciphertext, sharedSecret) = ML-KEM-768.Encapsulate(ownerPublicKey) // Shared Secret wird zum Verschlüsseln des Dateischlüssels verwendet keyNonce = CSPRNG(12 bytes) encryptedFileKey = AES-256-GCM.Encrypt(sharedSecret, keyNonce, fileKey) // 4. Metadaten verschlüsseln metadata = {name, size, type, uploadDate} metadataNonce = CSPRNG(12 bytes) encryptedMetadata = AES-256-GCM.Encrypt(userSharedSecret, metadataNonce, metadata)

5.3 Dateientschlüsselung

// 1. Privaten Schlüssel mit der Passphrase entschlüsseln encryptionKey = Argon2id(passphrase, salt, t=3, m=64MiB, p=4, 32 bytes) privateKey = ChaCha20-Poly1305.Decrypt(encryptionKey, nonce, encryptedPrivateKey) // 2. Entkapseln, um das Shared Secret wiederherzustellen sharedSecret = ML-KEM-768.Decapsulate(privateKey, ciphertext) // 3. Dateischlüssel entschlüsseln fileKey = AES-256-GCM.Decrypt(sharedSecret, keyNonce, encryptedFileKey) // 4. Dateiinhalt entschlüsseln fileContent = AES-256-GCM.Decrypt(fileKey, nonce, encryptedContent) // 5. Metadaten entschlüsseln metadata = AES-256-GCM.Decrypt(userSharedSecret, metadataNonce, encryptedMetadata)

5.4 Metadaten-Verschlüsselung

Anders als viele verschlüsselte Speichersysteme verschlüsselt SeraVault die Datei-Metadaten, darunter:

Dies verhindert, dass der Server anhand von Dateinamen oder -typen ein Profil der Aktivitätsmuster des Nutzers erstellt.

Sichtbarkeit von Metadaten: Obwohl Inhalte und Namen verschlüsselt sind, kennt der Server dennoch:
  • Größen der verschlüsselten Blobs (ungefähre Dateigrößen)
  • Zeitstempel von Upload/Änderung
  • Anzahl der Dateien pro Nutzer
  • Freigabebeziehungen (Nutzer A hat etwas mit Nutzer B geteilt)
Dies ist jedem Cloud-Speichersystem inhärent und kann nicht vollständig beseitigt werden, ohne Techniken wie ORAM (Oblivious RAM) einzusetzen, die die Performance erheblich beeinträchtigen würden.

6. Schlüsselverwaltung

6.1 Schlüsselhierarchie des Nutzers

Jeder Nutzer verfügt über mehrere Schlüssel, die unterschiedlichen Zwecken dienen:

Schlüsseltyp Zweck Speicherung
Öffentlicher ML-KEM-768-Schlüssel Kapselung des Dateischlüssels (andere verschlüsseln für Sie) Backend-Datenbank (im Klartext)
Privater ML-KEM-768-Schlüssel Entkapselung des Dateischlüssels Backend-Datenbank (verschlüsselt mit aus der Passphrase abgeleitetem Schlüssel)
Shared Secret Verschlüsselung von Metadaten Abgeleitet aus dem ML-KEM-768-Schlüsselpaar
Aus Passphrase abgeleiteter Schlüssel Verschlüsselt den privaten Schlüssel Bei Bedarf abgeleitet, niemals gespeichert

6.2 Speicherorte der Schlüssel

Wichtig: SeraVault unterstützt mehrere Authentifizierungsmethoden gleichzeitig. Nutzer können Passphrasen-Authentifizierung, Hardware-Schlüssel-Authentifizierung und biometrische Authentifizierung gleichzeitig aktivieren. Jede Methode speichert eine unabhängig verschlüsselte Kopie des privaten Schlüssels an unterschiedlichen Orten und bietet so Redundanz und Flexibilität.

6.2.1 Passphrasen-Authentifizierung

Die primäre Authentifizierungsmethode, bei der der private Schlüssel mit einem aus der Passphrase abgeleiteten Schlüssel verschlüsselt und in der Backend-Datenbank gespeichert wird:

6.2.2 Hardware-Schlüssel-Authentifizierung

Nutzer können die Hardware-Schlüssel-Authentifizierung zusätzlich zur oder anstelle der Passphrasen-Authentifizierung aktivieren. Private Schlüssel werden durch einen Hardware-Sicherheitsschlüssel (YubiKey, Titan Key) mittels FIDO2/WebAuthn geschützt:

Kompromiss bei Hardware-Schlüsseln: Wenn Sie Hardware-Schlüssel ohne Passphrasen-Authentifizierung verwenden, bedeutet der Verlust des Hardware-Schlüssels den Verlust des Zugriffs auf Ihre verschlüsselten Daten, sofern Sie keinen Ersatzschlüssel oder keine exportierte Schlüsseldatei besitzen. Der verschlüsselte private Schlüssel in der IndexedDB kann ohne den physisch vorhandenen Hardware-Schlüssel nicht entschlüsselt werden.

6.2.3 Biometrische Authentifizierung

Nutzer können die biometrische Authentifizierung (Fingerabdruck, Face ID) für einen bequemen Zugriff auf mobilen Geräten aktivieren:

6.2.4 Sicherung als Schlüsseldatei

Nutzer können ihren privaten Schlüssel verschlüsselt mit einer separaten Passphrase exportieren:

6.3 Schlüsselrotation

SeraVault unterstützt die Schlüsselrotation, um Forward Secrecy aufrechtzuerhalten:

Ablauf der Schlüsselrotation

  1. Der Nutzer generiert ein neues ML-KEM-768-Schlüsselpaar
  2. Für jede dem Nutzer gehörende Datei:
    • Dateischlüssel mit dem alten privaten Schlüssel entschlüsseln
    • Dateischlüssel mit dem neuen öffentlichen Schlüssel neu kapseln
    • Backend-Datenbank mit dem neuen gekapselten Schlüssel aktualisieren
  3. Für jede freigegebene Datei:
    • Freigabepartner über die Schlüsseländerung benachrichtigen
    • Freigegebene Schlüssel mit dem neuen öffentlichen Schlüssel neu kapseln
  4. Alter privater Schlüssel sicher gelöscht
  5. Neuer öffentlicher Schlüssel veröffentlicht
Performance-Hinweis: Die Schlüsselrotation kann bei Nutzern mit Tausenden von Dateien zeitaufwendig sein. Der Vorgang wird schrittweise im Hintergrund durchgeführt.

7. Sichere Dateifreigabe

7.1 Freigabemodell

SeraVault implementiert für die Dateifreigabe eine Schlüsselkapselung pro Empfänger:

// Der Dateieigentümer gibt die Datei für den Empfänger frei // 1. Eigentümer ruft den öffentlichen Schlüssel des Empfängers aus der Backend-Datenbank ab recipientPublicKey = Backend.getPublicKey(recipientUserId) // 2. Eigentümer entschlüsselt den Dateischlüssel für sich selbst ownerSharedSecret = ML-KEM-768.Decapsulate(ownerPrivateKey, ownerCiphertext) fileKey = AES-256-GCM.Decrypt(ownerSharedSecret, keyNonce, encryptedFileKey) // 3. Eigentümer kapselt den Dateischlüssel für den Empfänger (recipientCiphertext, recipientSharedSecret) = ML-KEM-768.Encapsulate(recipientPublicKey) recipientKeyNonce = CSPRNG(12 bytes) recipientEncryptedFileKey = AES-256-GCM.Encrypt(recipientSharedSecret, recipientKeyNonce, fileKey) // 4. Gekapselten Schlüssel des Empfängers in der Backend-Datenbank speichern Backend.grantAccess(fileId, recipientUserId, recipientCiphertext, recipientEncryptedFileKey)

7.2 Eigenschaften der Freigabe

7.3 Berechtigungsmodell

Berechtigung Beschreibung
Eigentümer Volle Kontrolle: Lesen, Ändern, Löschen, Freigeben, Entziehen
Anzeigen Kann die Datei entschlüsseln und anzeigen, jedoch nicht ändern oder freigeben

Derzeit implementiert SeraVault ein einfaches Berechtigungsmodell mit Eigentümer/Anzeigen. Nutzer, für die eine Datei freigegeben wurde, können Dateien anzeigen, sie jedoch nicht ändern oder an andere weitergeben.

7.4 Gruppenfreigabe

Um mit mehreren Nutzern zu teilen, kann der Eigentümer eine "Gruppenfreigabe" erstellen:

Speicherkosten: Für jede freigegebene Datei muss pro Empfänger ein gekapselter Schlüssel (~1 KB) gespeichert werden. Bei großflächiger Freigabe ist dies im Vergleich zum eigentlichen Dateiinhalt vernachlässigbar. Es wird nur das Speicherkontingent des Dateieigentümers verbraucht, unabhängig davon, mit wie vielen Personen die Datei geteilt wird.

8. Authentifizierungsmethoden

8.1 Mehr-Faktor-Authentifizierung

SeraVault trennt die Kontoauthentifizierung vom Zugriff auf die Verschlüsselungsschlüssel:

8.2 Passphrasenbasierte Authentifizierung

Die Standard-Authentifizierungsmethode:

8.3 Biometrische Authentifizierung

Verwendet WebAuthn mit Plattform-Authentifikatoren:

8.4 Hardware-Schlüssel-Authentifizierung (YubiKey)

Verwendet FIDO2/CTAP2 für eine hardwaregestützte Authentifizierung:

8.5 Passkey (Plattform-Authentifikator)

Moderne passwortlose Authentifizierung mit WebAuthn:

9. Verschlüsselte Nachrichten

9.1 Chat-Architektur

SeraVault umfasst Ende-zu-Ende-verschlüsselte Nachrichten und verwendet dieselben kryptografischen Primitive wie die Dateiverschlüsselung:

9.2 Austausch des Konversationsschlüssels

// Eine Konversation erstellen // 1. Der Initiator generiert einen zufälligen Konversationsschlüssel conversationKey = CSPRNG(32 bytes) // 2. Für jeden Teilnehmer (einschließlich des Initiators): (ciphertext_i, sharedSecret_i) = ML-KEM-768.Encapsulate(participant_i_PublicKey) nonce_i = CSPRNG(12 bytes) encryptedConversationKey_i = AES-256-GCM.Encrypt(sharedSecret_i, nonce_i, conversationKey) // 3. Verschlüsselte Konversationsschlüssel in der Backend-Datenbank speichern // Jeder Teilnehmer kann mit seinem privaten Schlüssel entschlüsseln

9.3 Nachrichtenverschlüsselung

// Eine Nachricht senden // 1. Der Absender entschlüsselt den Konversationsschlüssel sharedSecret = ML-KEM-768.Decapsulate(senderPrivateKey, senderCiphertext) conversationKey = AES-256-GCM.Decrypt(sharedSecret, nonce, encryptedConversationKey) // 2. Nachricht verschlüsseln messageNonce = CSPRNG(12 bytes) encryptedMessage = AES-256-GCM.Encrypt(conversationKey, messageNonce, messageContent) // 3. In die Backend-Datenbank hochladen Backend.addMessage(conversationId, encryptedMessage, messageNonce, timestamp)

9.4 Eigenschaften des Chats

Sichtbarkeit von Metadaten: Der Server kennt:
  • Wer sich in welchen Konversationen befindet
  • Zeitstempel der Nachrichten
  • Ungefähre Länge der Nachrichten
Dies ähnelt der serverseitigen Metadaten-Sichtbarkeit von Signal.

9.5 Zukünftige Verbesserungen

Mögliche Erweiterungen für künftige Versionen:

10. Implementierungsdetails

10.1 Technologie-Stack

Komponente Technologie
Frontend React + TypeScript
Krypto-Bibliothek Web Crypto API + ml-kem (WebAssembly)
Backend Cloud-Datenbank, Objektspeicher, Authentifizierungsdienst, Serverless-Funktionen
Authentifizierung WebAuthn, FIDO2, OAuth 2.0

10.2 ML-KEM-768-Implementierung

Wir verwenden die JavaScript-Bibliothek ml-kem, die Folgendes bietet:

10.3 Erzeugung von Zufallszahlen

Sämtliche kryptografische Zufälligkeit verwendet crypto.getRandomValues():

function generateRandomBytes(length: number): Uint8Array { const array = new Uint8Array(length); crypto.getRandomValues(array); return array; }

10.4 Sichere Speicherbehandlung

JavaScript bietet keine explizite Speicherkontrolle, doch wir befolgen bewährte Praktiken:

function secureWipe(array: Uint8Array): void { array.fill(0); }

10.5 Fehlerbehandlung

Kryptografische Fehler werden sorgfältig behandelt, um Informationslecks zu verhindern:

11. Sicherheitsanalyse

11.1 Bedrohungsanalyse

11.1.1 Kompromittierung des Servers

Bedrohung: Ein Angreifer erlangt vollständigen Zugriff auf die Cloud-Infrastruktur.

Auswirkung: Gering. Der Angreifer erhält verschlüsselte Dateien, verschlüsselte private Schlüssel, öffentliche Schlüssel und verschlüsselte Metadaten.

Gegenmaßnahme: Ohne Nutzer-Passphrasen oder Hardware-Schlüssel kann der Angreifer nicht entschlüsseln. Die Zero-Knowledge-Architektur begrenzt den Schaden auf das Sammeln verschlüsselter Daten.

11.1.2 Passives Mithören im Netzwerk

Bedrohung: Ein Angreifer fängt den Netzwerkverkehr ab.

Auswirkung: Gering. TLS schützt den Transport, doch selbst eine Kompromittierung von TLS legt nur verschlüsselte Daten offen.

Gegenmaßnahme: Die Verschlüsselung auf Anwendungsebene stellt sicher, dass niemals Klartext übertragen wird. Metadaten sind verschlüsselt.

11.1.3 Angriff durch einen Quantencomputer

Bedrohung: Ein zukünftiger Quantencomputer versucht, die Verschlüsselung zu brechen.

Auswirkung: Gering für durch ML-KEM-768 geschützte Daten. Die Sicherheit der symmetrischen Verschlüsselung (AES-256) ist reduziert, aber weiterhin stark.

Gegenmaßnahme: ML-KEM-768 basiert auf Gitterproblemen, die gegen bekannte Quantenalgorithmen resistent sind. AES-256 bietet 128-Bit-Sicherheit gegen Quantenangriffe (Grover-Algorithmus), was für die meisten Anwendungsfälle ausreichend ist.

11.1.4 Schwache Passphrase

Bedrohung: Der Nutzer wählt eine schwache Passphrase, der Angreifer führt einen Offline-Brute-Force-Angriff durch.

Auswirkung: Hoch, sofern erfolgreich. Der Angreifer entschlüsselt den privaten Schlüssel und erhält Zugriff auf alle Dateien.

Gegenmaßnahme:

11.1.5 Phishing

Bedrohung: Der Nutzer wird dazu verleitet, seine Passphrase auf einer bösartigen Website einzugeben.

Auswirkung: Hoch. Der Angreifer erlangt die Passphrase und kann den privaten Schlüssel entschlüsseln.

Gegenmaßnahme:

11.2 Kryptografische Stärke

Primitive Klassische Sicherheit Quanten-Sicherheit
ML-KEM-768 192 Bit 192 Bit (NIST Level 3)
AES-256-GCM 256 Bit 128 Bit (Grover)
Argon2id (64 MiB) Hängt von der Passphrase ab Hängt von der Passphrase ab

11.3 Bekannte Einschränkungen

  1. Metadaten-Leck: Dateigrößen, Zeitstempel und Freigabebeziehungen sind für den Server sichtbar
  2. Forward Secrecy: Der Chat implementiert keine Perfect Forward Secrecy (kein Ratcheting)
  3. Passphrasen-Stärke: Die Systemsicherheit wird durch die vom Nutzer gewählte Passphrasen-Stärke begrenzt
  4. Browser-Sicherheit: Verlässt sich auf das Browser-Sandboxing und die Implementierung der Web Crypto API
  5. Keine Abstreitbarkeit: Verschlüsselte Nachrichten bieten Authentifizierung, aber keine Abstreitbarkeit
  6. Verkehrsanalyse: Aktivitätsmuster (Uploads, Downloads, Anmeldungen) sind für den Server beobachtbar

11.4 Audit und Verifizierung

SeraVault ermöglicht unabhängige Sicherheitsaudits:

12. Referenzen

  1. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://csrc.nist.gov/pubs/fips/203/final
  2. NIST Post-Quantum Cryptography: Selected Algorithms 2024. https://csrc.nist.gov/projects/post-quantum-cryptography
  3. AES-GCM: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. NIST SP 800-38D.
  4. WebAuthn: Web Authentication: An API for accessing Public Key Credentials Level 2. W3C-Empfehlung.
  5. Argon2: Argon2: the memory-hard function for password hashing. Gewinner der Password Hashing Competition (2015). PHC-Gewinner
  6. Web Crypto API: W3C-Empfehlung. https://www.w3.org/TR/WebCryptoAPI/
  7. Grover-Algorithmus: A fast quantum mechanical algorithm for database search. L.K. Grover, 1996.
  8. Shor-Algorithmus: Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. P.W. Shor, 1997.
  9. Learning With Errors: On lattices, learning with errors, random linear codes, and cryptography. O. Regev, 2005.

Dokumentversion 1.0 | November 2025

Bei Fragen oder Sicherheitsmeldungen wenden Sie sich an: security@seravault.com

← Zurück zur SeraVault-Startseite