Kryptographie in Lyx

Dieser Guide erklärt alle kryptografischen Units der Lyx-Standardbibliothek, vergleicht ähnliche Optionen und gibt klare Empfehlungen, was wann verwendet werden sollte.

→ std.crypto (Unit-Referenz) · Welche Unit? · Standard Library

Die beiden Optionen für symmetrische Verschlüsselung unterscheiden sich fundamental:

Wann AES-CBC:

• Compliance-Anforderungen (FIPS, DO-178C, ISO 27001)
• Interoperabilität mit anderen Systemen (TLS, Dateiverschlüsselung)
• Performance kritisch
• Bekannte, auditierte Konstruktion bevorzugt

Wann DADQ-SYM / DADQ-FO:

• Authentifizierte Verschlüsselung ohne separaten MAC-Schritt gewünscht
• Kein externer Standard erforderlich
• Quantum-Aspekte relevant, aber ML-KEM nicht verfügbar/nötig
• Reine Lyx-Implementierung ohne Einschränkung durch Patente oder Lizenzfragen

Kombination: AES-CBC ist nicht authentifiziert — für Manipulationsschutz immer std.crypto.hmac (HMAC-SHA256) nachschalten:

// Encrypt-then-MAC (Standardmuster für AES-CBC)
AES256CBCEncrypt(key, iv, plain, plain_len, cipher);
HMAC_SHA256(mac_key, cipher, cipher_len, mac);
// Übertragen: iv || cipher || mac

DADQ übernimmt Verschlüsselung und MAC in einem Schritt.

DADQ hat drei Nutzungsmodi mit unterschiedlichen Sicherheitsgarantien:

Basis-Modus (dadqEnc): Verschlüsselt mit T_pub (65536-Byte-Tabelle als „öffentlicher„ Schlüssel). Geeignet wenn beide Parteien T_pub kennen. Randomisiert — unterschiedliche Ciphertexte für gleiche Klartexte.

Sym-Modus (dadqSymEnc): T_pub wird intern abgeleitet und nie weitergegeben — schützt dadurch gegen den strukturellen col_inv-Angriff auf T_pub. Empfohlen gegenüber Basis-Modus wenn keine Kompatibilität zu Basis-API nötig.

FO-Modus (dadqFOEnc): Fujisaki-Okamoto Transform — r_seed wird deterministisch aus dem Klartext via HMAC berechnet. Dadurch ist Wiederverschlüsselung möglich und CCA2-Sicherheit beweisbar. Der Dec-Check ist nicht-tautologisch (``HMAC(key_fo, m_dec) == r_seed``). Empfohlen für alle neuen Anwendungen.

// FO-Modus: einfachste sichere Variante
var sk_fo: int64 := alloc(DADQ_FO_SK_LEN);
dadqFOKeyGenRand(sk_fo);        // interner CSPRNG-Seed, wird nach Ableitung gelöscht
dadqFOEnc(sk_fo, m, m_len, c);
var rc: int64 := dadqFODec(sk_fo, c, c_len, m_out);  // -1 bei Manipulation
dadqZeroize(sk_fo, DADQ_FO_SK_LEN);

SHA-256 verwenden für: Datenintegrität, HMAC-Basis, digitale Signaturen, Schlüsselableitung, Passwort-Hashing (mit salt).

SHA-1 nur für: MySQL mysql_native_password-Authentifizierung (Protokoll erzwingt es), Git-Objektadressen (Legacy-Kompatibilität).

MD5 nur für: HTTP Digest Authentication (RFC 2617 schreibt MD5 vor), andere Protokolle die explizit MD5 verlangen.

Faustregel: Wenn das Protokoll keinen bestimmten Hash vorschreibt → immer SHA-256.

Drei Wege für Integrität und Authentifizierung:

1. HMAC-SHA256 (std.crypto.hmac):

Für Nachrichten-Authentifizierung wenn Verschlüsselung separat erfolgt oder gar nicht benötigt wird.

HMAC_SHA256(key, msg, msg_len, mac_out);  // mac_out = 32 Bytes

2. AES-CBC + HMAC (Encrypt-then-MAC):

Industriestandard-Muster. Beide Schlüssel sollten unabhängig voneinander sein.

3. DADQ-FO (integrierter Ansatz):

Ein einziger Schlüssel (sk_fo, 608 Bytes), ein Aufruf — Verschlüsselung und Authentifizierung kombiniert.

Aktuell steht in std.crypto nur secp256k1 ECDSA (std.crypto.ecc) zur Verfügung.

import std.crypto.ecc;
ECCGenKey(pk, sk);         // Schlüsselpaar erzeugen
ECDSASign(sk, hash, sig);  // hash = SHA256 des Dokuments
ECDSAVerify(pk, hash, sig); // 1 = gültig, 0 = ungültig

Hinweise:

• Immer SHA-256 des Dokuments signieren, nie den Rohtext.
• secp256k1 ist die Bitcoin-Kurve — weitverbreitet, gut auditiert.
• Kein Ed25519 oder ECDSA-P256 in std.crypto (nur secp256k1).
• Post-Quantum-Signaturen: noch nicht in std.crypto verfügbar — für PQC-Signaturen → ML-DSA (FIPS 204, extern) oder Hybrid-Schema.

Alle kryptografischen Schlüssel, IVs und Nonces müssen aus std.crypto.rand stammen:

import std.crypto.rand;
RandBytesExact(buf, n);    // genau n Bytes, blockierend (getrandom(2))
RandBytes(buf, n);         // bis zu n Bytes
var n: int64 := RandInt64();   // zufälliges int64
var u: int64 := RandU32();     // zufälliges uint32

Niemals std.math.random oder ähnliche nicht-kryptografische Zufallsgeneratoren für kryptografische Zwecke verwenden.

1. MD5 und SHA-1 nicht für neue kryptografische Zwecke — nur wenn das Protokoll es vorschreibt.
2. AES-CBC ist nicht authentifiziert — immer HMAC nachschalten, oder DADQ-FO verwenden.
3. IV muss einmalig und zufällig sein — niemals einen festen IV verwenden.
4. ECDSA-Nonces darf man nicht selbst setzen — std.crypto.ecc generiert intern.
5. DADQ ist experimentell — nicht für FIPS/DO-178C/ISO-27001-zertifizierte Projekte.
6. Schlüssel nach Verwendung löschen — dadqZeroize oder manuelle poke8-Schleife.
7. Alle kryptografischen Zufallswerte nur aus std.crypto.rand.

Letzte Aktualisierung: 2026-06-08