NHS · Cookies & Privatsphäre

Du bestimmst, was wir setzen.

Notwendige Cookies brauchen wir für Login, 2FA und CSRF-Schutz. Statistik & Marketing sind optional und nur mit deiner Zustimmung aktiv.

HMAC-signiert via NHS v6

Datenschutz · Impressum · Jederzeit unten links neu öffnen

Zum Hauptinhalt springen
NHSEncryption

NHS ist die End-to-End-Verschlüsselungs-Plattform der USC Software UG. Sechs-Stufen-Versionsleiter v1 Standard bis v6 Fortress. Triple-Hybrid-Krypto (X25519 + X448 + ML-KEM-1024), post-quantum auf Tag eins, BSI-TR-02102-Empfehlungen umgesetzt (nicht BSI-zertifiziert). Hash-Chain-Audit-Log, Argon2id-API-Keys, Zero-Knowledge (Inhalte; Metadaten serverseitig sichtbar). Wir liefern keine Marketing-Versprechen, sondern Code: 118/118 Tests grün, davon 69 Adversarial-Angriffe abgewehrt.

Plattform

  • Übersicht
  • Preise
  • Sicherheit
  • Fortress · Enterprise
  • Status

Entwickler

  • Protokoll-Spec
  • Dokumentation
  • Dashboard
  • OHS · Discovery
  • Kontakt

Rechtliches

  • Impressum
  • Datenschutz
  • AGB
  • Widerruf

NHS Newsletter

Quartalsweise Updates: Suite-Releases, Audit-Befunde, Beta-Slots. Double-Opt-In via NHS-signiertem Token, jederzeit abbestellbar.

HMAC-signiert via NHS v6 · DSGVO-konform · kein Tracking ohne Statistik-Consent

©2026USC Software UG (haftungsbeschränkt)·Albrecht-Dürer-Ring 25, 67227 Frankenthal
NHS-E2E v1–v6·BSI TR-02102 (Empfehlung) konform·118/118 Tests grün·OHS verified
NHSEncryption
Preise
Sicherheit
Protokoll
Docs
Status
Anmelden
Account erstellen
ProtokollBeitreten
NHS-E2E · Sechs-Stufen-Versionsleiter · Spezifikation

Triple-Hybrid Krypto.
Bank-tauglich. Souverän.

Drei unabhängige Schlüsselaustausch-Verfahren parallel, post-quantum-fähig, ausschließlich peer-reviewte Primitive aus internationalen akademischen Quellen. BSI TR-02102 konform.

6 Suiten v1 → v6 implementiertTriple-Hybrid KEX118/118 Tests grün69 Adversarial-Angriffe abgewehrtBSI TR-02102 konform

Triple-Hybrid

3 KEX

X25519 + X448 + ML-KEM-1024. Selbst wenn zwei brechen, bleibt der Schlüssel sicher.

Symmetrische Stärke

256 Bit

ChaCha20-Poly1305. Post-quantum-relevante Stärke (Grover halbiert effektiv → 128 Bit Rest).

PQ-Niveau

Level 5

ML-KEM-1024 + ML-DSA-87 — höchstes NIST-PQC-Sicherheitsniveau.

Sechs-Stufen-
Versionsleiter.

Jede Suite fügt eine konkrete Sicherheits-Eigenschaft hinzu. Wahl nach Bedrohungsmodell und Performance-Budget — Suite-Wechsel pro Channel.

VersionCodenameZusammenfassungECPQUse-Case
v1StandardSingle-Suite Baseline — X25519 + ChaCha20-Poly1305 + Ed255191—Einfacher Privat-Use, Tests
v2Hardenedv1 + Padmé-Padding + strikte Memory-Hygiene1—Privat mit Traffic-Analysis-Bedarf
v3DualCurveDual-Hybrid X25519+X448 + Ed25519+Ed448 (klassisch)2—Mittelstand IP-Schutz, klassische Bedrohung
v4Quantum-Readyv3 + ML-KEM-1024 (PQ-Confidentiality)21Pharma, Forschung, M&A — lange Datenlebensdauer
v5Sovereignv4 + ML-DSA-87 (volles PQ-Hybrid)22Banken, Versicherungen, Behörden, KRITIS
v6Fortressv5 + Cascade-AEAD + SLH-DSA (3 Sig-Familien)23Zentralbanken, KRITIS-Hochsicherheit, Verteidigung

EC = klassische elliptische Kurven · PQ = post-quantum Komponenten (KEMs + Sigs)

Spezifikation.

Schicht für Schicht — Primitive, Standards, Begründungen.

SchichtPrimitiveStandardBegründung
Klassischer KEX 1X25519 (Curve25519)RFC 7748Designed von Daniel J. Bernstein. Kein NIST-Designprozess, weltweit auditiert, in Signal, WireGuard und OpenSSH produktiv. 128-Bit Sicherheitsniveau.
Klassischer KEX 2X448 (Goldilocks)RFC 7748Designed von Mike Hamburg. Unabhängige zweite Kurve mit 224-Bit Sicherheitsniveau. Bricht eine Kurve, hält die andere — ohne sich auf eine einzige Designschule zu stützen.
Post-Quantum KEXML-KEM-1024 (CRYSTALS-Kyber-1024)FIPS 203 / NIST PQC Level 5Gitterbasiertes Verfahren, designed von einem internationalen Team (IBM Zürich, ENS Lyon, Radboud NL u. a.). NIST PQC Level 5 — das höchste Sicherheitsniveau gegen Quanten-Angreifer. BSI-empfohlen für Migration.
SchlüsselableitungHKDF-SHA3-512RFC 5869 + FIPS 202Aus den drei KEX-Geheimnissen wird über Keccak-basiertes HKDF ein gemeinsamer Sitzungsschlüssel abgeleitet. Pro Nachricht zusätzlich frischer Key über BLAKE3-KDF — Forward Secrecy auf Nachrichtenebene.
Authenticated EncryptionChaCha20-Poly1305RFC 8439Stream-Cipher von Bernstein, MAC von Bernstein. 256-Bit Schlüssel, 128-Bit Authenticator. Konstante-Zeit-Implementierung ohne Cache-Timing-Risiken. Schneller als AES-GCM auf Hardware ohne AES-NI (Embedded, Mobile).
Klassische SignaturenEd25519RFC 8032EdDSA über Curve25519. Deterministisch (kein Risiko schlechter Zufallszahlen wie bei ECDSA), schnell, produktiv in OpenSSH, age, Bitcoin BIP-340. BSI TR-02102 zugelassen.
Post-Quantum SignaturenML-DSA-87 (CRYSTALS-Dilithium-5)FIPS 204 / NIST PQC Level 5Gitterbasierte Signatur, höchste Parameterstufe. Hybrid mit Ed25519 — beide müssen verifizieren, sonst wird abgelehnt. Schutz selbst gegen Quanten-Computer mit Shor-Algorithmus.
Hash & IntegritätBLAKE3 + SHA-3-512BLAKE3 spec / FIPS 202BLAKE3 für KDF und MAC (7× schneller als SHA-256). SHA-3-512 für Audit-Log-Hash-Chain — Keccak-Designteam war europäisch (Belgien, Italien). Komplett unabhängig von SHA-2.
Replay-SchutzSequenz-Counter + Bloom-FilterNHS-E2E-v5Pro (Sender × Empfänger × Channel) ein streng monoton wachsender 64-Bit-Counter. Zusätzlich Bloom-Filter (FPR < 10⁻⁹) über die letzten 1 Mio Message-IDs. Wiedereinspielen wird hart abgelehnt.
Schlüssel-SpeicherungArgon2id (Memory-hard)PHC Winner / RFC 9106API-Keys werden ausschließlich als Argon2id-Hash gespeichert (t=4, m=64MB, p=4). Memory-hard gegen GPU/ASIC-Angriffe. Wir können einen Key technisch nicht zurückrechnen.

Triple-Hybrid
Schlüsselaustausch.

Drei unabhängige Verfahren parallel. Sitzungsgeheimnis über HKDF-SHA3-512 aus allen drei Komponenten — selbst wenn zwei brechen, hält das dritte.

# Sender                                Empfänger
ss_classic_25  = X25519(eph_25,    pub_25)
ss_classic_448 = X448(eph_448,     pub_448)
ss_pq          = ML-KEM-1024-encap(pub_pq) ──> ct_pq

shared_secret = HKDF-SHA3-512(
    ikm  = ss_classic_25 ‖ ss_classic_448 ‖ ss_pq,
    salt = channel_id ‖ sequence,
    info = "NHS-E2E-v5/SS"
)

# Pro-Nachricht-Schlüssel
msg_key = BLAKE3-KDF(shared_secret, ctx="msg/" + sequence)
nonce   = sequence ‖ random32()
ct      = ChaCha20-Poly1305(msg_key, nonce, plaintext, aad=header)

# Hybrid-Signatur
sig_classic = Ed25519(sk_ed,     canonical(header ‖ ct_hash))
sig_pq      = ML-DSA-87(sk_dsa,  canonical(header ‖ ct_hash))
envelope    = { header, ct, sig_classic, sig_pq }
NHS-E2E v6 · Fortress · Enterprise

Quad-Hybrid + Cascade
+ Triple-Sig.

Für Banken, KRITIS, Geheimschutz und langlebige Forschungs-IP — Cascade-Symmetrik (ChaCha20 ⨯ AES-256-GCM = 512 Bit kombiniert) und Triple-Signaturen aus drei Mathematik-Familien (EC + Lattice + Hash).

Fortress-Spezifikation ansehen

Threat-
Modell.

Was wir abwehren — und wie.

BedrohungSchutz
Passives Mitlauschen heuteX25519 + X448 — selbst NSA-Niveau-Computing bricht keine 224-Bit-Kurve im Klartext.
Quanten-Computer (Shor-Algorithmus)ML-KEM-1024 + ML-DSA-87 — gitterbasiert, gegen Shor immun. Hybrid-Stack: bricht klassisch, hält PQ.
„Harvest now, decrypt later"Triple-Hybrid: alle drei KEX-Komponenten müssten gleichzeitig brechen. Forward Secrecy → kompromittierte Long-Term-Keys liefern keine Vergangenheit.
Header-/Envelope-ManipulationEd25519 + ML-DSA-87 Doppel-Signatur über kanonische Envelope-JSON. Beide müssen verifizieren.
Replay alter NachrichtenSequence-Counter (64-Bit, monoton) + Bloom-Filter über Message-IDs.
Gestohlener API-KeyArgon2id-Hash-only. Audit-Log zeigt jede Nutzung mit Hash-Chain. Sofort-Rotation auf Knopfdruck.
Kompromittierte Server-HardwareOptional: HSM-Backed Master-Key (FIPS 140-3 Level 3). BYOK auf Enterprise-Tier — Bank bringt eigenen Master-Key.
Insider mit DB-ZugriffZero-Knowledge-Architektur: Server speichert nur Ciphertext + signierte Header. Klartext nie auf NHS-Infrastruktur.
Cache-Timing / Side-ChannelKonstante-Zeit-Implementierungen über libsodium / RustCrypto. Keine Branch-/Cache-abhängige Logik im Hot-Path.

Souveränität
der Primitive.

Kein Algorithmus im kritischen Pfad stammt aus einem rein US-staatlichen Standardisierungsprozess. Alle Primitive haben akademische, internationale Designteams. Patentfrei.

AlgorithmusDesignerHerkunft
X25519Daniel J. Bernsteinakademisch (USA, kein Government-Prozess)
X448Mike Hamburgakademisch (USA, kein NIST-Prozess)
ChaCha20-Poly1305Daniel J. Bernsteinakademisch, IRTF/IETF
Ed25519Bernstein, Duif, Lange, Schwabe, Yangakademisch, international
BLAKE3Aumasson, Neves, O'Connor, Wilcox-O'Hearnakademisch, international
SHA-3 / KeccakBertoni, Daemen, Peeters, Van AsscheBelgien, Italien
ML-KEM (Kyber)CRYSTALS-TeamIBM Zürich, ENS Lyon, Radboud NL u. a.
ML-DSA (Dilithium)CRYSTALS-Teamdito
Argon2idBiryukov, Dinu, KhovratovichUniversität Luxemburg

Compliance-
Mapping.

Standard / VorschriftNHS-Erfüllung
BSI TR-02102-1Alle eingesetzten Primitive sind in der aktuellen Technischen Richtlinie als geeignet ausgewiesen.
BSI TR-03116-3Hybrid-Migration zu PQ-Krypto entspricht der BSI-Empfehlung für Hochsicherheits-Anwendungen.
eIDAS / VDGSignatur-Layer mit Ed25519 + ML-DSA ist kompatibel mit qualifizierten elektronischen Signaturen.
ISO/IEC 27001Audit-Log mit Hash-Chain liefert nachweisbare Integrität für Section A.12.4.
GDPR / DSGVO Art. 32„Stand der Technik" gemäß Triple-Hybrid + PQ. Datenminimierung: Server hält nur Ciphertext.
PCI-DSS v4.0Strong Cryptography per Anforderung 3.5 — 256-Bit symmetrisch, 224-Bit asymmetrisch erfüllt.
KRITIS / NIS-2Erfüllt „Stand der Technik" für kritische Infrastruktur. Tamper-evident Audit für Meldepflicht.

Hinweis: Aktuell besteht keine erteilte Zertifizierung. Selbst-Konformitätserklärung BSI TR-02102 mit Phase 2. Externe Zertifizierungen (ISO 27001, BSI C5, Common Criteria) ab Phase 4/5. Status-Übersicht

Disclosure-Policy

Sicherheitsschwachstellen ausschließlich an security@usc-software-ug.de. Antwort innerhalb 48 h, koordinierte Veröffentlichung möglich. PGP-Schlüssel werden auf Anfrage per E-Mail bereitgestellt.