Versionen & Kompatibilität — SaQura .NET

Vor dem Update

Aktuelle Version: 1.0.15 · NuGet · SaQura (NuGet) · zur Dokumentation

• Daten aus jeder veröffentlichten Version (1.0.0.2 bis 1.0.15) werden von 1.0.15 gelesen. Einzige Ausnahme: AES-Chiffrate der byte[]-API aus 1.0.4.4 oder älter brauchen den Migrationshelfer aus 1.0.8 (siehe dort).
• Ihre Lizenzdatei bleibt gültig. Seit 1.0.13 gibt es optionale Bindungsfelder; eine Lizenz ohne diese Felder verhält sich byte-identisch wie zuvor.
• Das Paket zielt auf net8.0 sowie net10.0-android, net10.0-ios und net10.0-maccatalyst. Desktop- und Server-Projekte nutzen weiterhin das net8.0-Ziel.

Die Tabellen unter jeder Version beantworten dieselben fünf Fragen in derselben Reihenfolge. „Drop-in-Update: Ja“ heißt: Unser plattformübergreifender Testkorpus hat belegt, dass die neue Version die Daten der vorherigen liest und kein Aufruf geändert werden muss.

Optionale Module

• Keine optionalen Module. Alle Funktionen (AES, RSA, Passwort-Hashing, Quantum Gen1–Gen8, ML-DSA/SLH-DSA, SQS1-Streaming, Lizenzierung) liegen in einer Assembly.
• Abhängigkeit: BouncyCastle (transitiv über NuGet, wird automatisch mitinstalliert).
• Trimming und AOT: Die Mobil-Assemblies (net10.0-*) sind mit dem iOS-/Android-Trimmer und der AOT-Laufzeit verträglich; auf Geräten geprüft. Eigene Linker-Beschreibungen sind nicht nötig.

Lizenzen & App-Bindung

• Ungebundene Lizenzen sind von der App-Bindung nicht betroffen: kein Aufruf ändert sich, keine Neuausstellung nötig.
• Gebundene Distributions-Lizenzen (ab 1.0.13) prüfen Paket-/Bundle-ID und Signaturzertifikat, wie sie das Betriebssystem meldet: Android (Paket + Zertifikat), iOS/Mac Catalyst (Bundle-ID), Windows (Authenticode des Hosts), macOS-Desktop ab 1.0.14 (Signatur-Identifier + Zertifikat). Linux hat keine vom Betriebssystem bestätigte App-Identität: dort eine ungebundene Lizenz einsetzen.
• Ab 1.0.15 wird eine vom Lizenzserver bestätigte Sperrung einer Standard-Lizenz durchgesetzt und gespeichert. Distributions-Lizenzen und vollständig offline betriebene Installationen sind davon nicht betroffen; ihre Laufzeit endet mit dem Ablaufdatum.

1.0.15 · 2026-07-15

Lizenzsperrung wird online durchgesetzt und gespeichert; Diagnosen nach stderr

• Meldet der Lizenzserver eine Standard-Lizenz als gesperrt, wird die Lizenz deaktiviert und der Zustand gespeichert. Die Sperre gilt sofort und beim nächsten Start, auch offline. Ein nicht erreichbarer Server bleibt wie bisher unkritisch (Offline-Karenz).
• Distributions-Lizenzen und vollständig offline betriebene Installationen werden nicht online geprüft und können daher nicht gesperrt werden; ihre Laufzeit ist durch das Ablaufdatum begrenzt.
• Lizenzdiagnosen (Registrierungsfehler, Dateifehler) gehen nach stderr statt stdout. Programme, die stdout als Datenkanal nutzen (etwa ein MCP-Server über stdio), werden nicht mehr gestört.

1.0.14 · 2026-07-15

App-Bindung auch auf macOS-Desktop

• Gebundene Distributions-Lizenzen werden jetzt auch in nativen macOS-Desktop-Apps durchgesetzt. Die Bibliothek liest die eigene Code-Signatur vom Betriebssystem: Signatur-Identifier (bei signierten .app die Bundle-ID) und SHA-256 des Signaturzertifikats (für die Auslieferung das Developer-ID-Application-Zertifikat).
• Ein unsignierter macOS-Host hat keine bestätigte Identität: eine gebundene Lizenz wird dort abgelehnt, ungebundene Lizenzen laufen weiter.
• Abdeckung der optionalen Bindung damit: Android, iOS/Mac Catalyst, Windows, macOS-Desktop. Linux: keine Bindung verfügbar, ungebundene Lizenz ausliefern.

1.0.13 · 2026-07-04

App-Bindung für Distributions-Lizenzen; .NET-MAUI-Ziele

• Zwei optionale Lizenzfelder, boundPackage und boundSignature, binden eine Distributions-Lizenz an Paket-/Bundle-ID und Signaturzertifikat der App. Eine kopierte Lizenzdatei in einer fremden App wird bei der Aktivierung abgelehnt (ValidationResult.BindingMismatch). Neue Eigenschaften: LicenseInfo.BoundPackage und LicenseInfo.BoundSignature.
• Die App-Identität kommt vom Betriebssystem, nie vom Aufrufer. Eine Lizenz ohne die beiden Felder verhält sich exakt wie bisher; die Felder werden im signierten Text nach hardwareId angehängt, bestehende Lizenzen bleiben byte-identisch.
• Das Paket zielt zusätzlich auf net10.0-android, net10.0-ios und net10.0-maccatalyst; das net8.0-Ziel ist unverändert. Die native Geräte-Bindung braucht diese .NET-10-MAUI-Ziele. Eine MAUI-App auf net8.0-Basis hat keine Geräte-Identität und lehnt eine gebundene Lizenz ab; ungebundene Lizenzen laufen dort unverändert.
• Die Mobil-Assemblies sind mit dem iOS-/Android-Trimmer und der AOT-Laufzeit verträglich; Annahme und Ablehnung der Bindung wurden auf iPhone, Android und Windows geprüft.
• 1.0.11 und 1.0.12 waren Zwischenstände dieser Funktion und sind durch 1.0.13 ersetzt.

1.0.10 · 2026-06-06

Streaming-Verschlüsselung für große Dateien (SQS1)

• Neue Stream-API im Namensraum SaQura: EncryptStreamAsync / DecryptStreamAsync, EncryptFileAsync / DecryptFileAsync, ReadStreamInfoAsync und CountCompleteSegments (Wiederaufnahme). Verschlüsselt in festen Segmenten bei konstantem Speicher (etwa zweimal Segmentgröße, Standard 1 MiB), unabhängig von der Dateigröße.
• Zwei AEAD-Suiten, automatisch aus den Kopfdaten gewählt: AES-256-GCM und ChaCha20-Poly1305.
• Post-Quanten-Umschlag (Pro): Ein zufälliger Dateischlüssel wird einmal mit einem SaQura-Quantum-Schlüsselpaar (etwa Gen8) umhüllt; Ablage als Sidecar-Datei .saqkey (Standard) oder eingebettet.
• Das neue Format trägt die eigene Kennung SQS1 und ist rein additiv; kein bestehender Aufruf und kein Format hat sich geändert. Streaming ab Stufe Standard, der Umschlag ab Pro.
• Lizenzprüfung und Freistufen-Kennzeichnung gehärtet; keine Änderung an API oder Format.

1.0.9 · 2026-06-05

NIST-Post-Quanten-Verfahren: Gen8, ML-DSA, SLH-DSA

• Generation 8: hybride Schlüsselkapselung aus X25519 und ML-KEM (FIPS 203). Beide Geheimnisse werden per HKDF-SHA256 kombiniert, danach AES-256-GCM.
• Signaturen ML-DSA (FIPS 204) in den Stärken 44 / 65 / 87 und SLH-DSA (FIPS 205, SHA2) in 128f / 192f / 256f. Signieren ab Pro, Verifizieren in jeder Stufe.
• Gen8, ML-DSA und SLH-DSA sind byte-identisch mit den Swift- und Kotlin-SDKs (in beide Richtungen geprüft).

1.0.8 · 2026-05-19

Plattformübergreifende Angleichung (enthält die nicht veröffentlichten Stände 1.0.5–1.0.7)

• AES-256-GCM byte[]-API: Das Chiffrat liegt jetzt direkt im Layout [Nonce 12][Chiffrat][Tag 16], ohne die frühere zusätzliche Base64-Verpackung. Die String-API ist unverändert. Gespeicherte byte[]-Chiffrate aus 1.0.4.4 oder älter: MigrateLegacyAESByteCiphertextAsync liefert die Klartext-Bytes zurück, danach mit EncryptWithAESAsync neu verschlüsseln. Der reguläre DecryptWithAESAsync(byte[]) liest nur das neue Format.
• PBKDF2-SHA512-Passwort-Hashes: JSON-Feldnamen in Langform (algorithm, version, parameters, createdUtc), Zeitstempel ohne Sekundenbruchteile. Verify liest beide Formen; bestehende Hashes bleiben gültig.
• RSA-4096-Hybrid: Format für .NET unverändert; Swift und Kotlin haben sich in ihren parallelen Versionen daran angeglichen.
• Behoben: Quantum Generation 6 in den Stärken Mittel und Höchst (falsche Längenangabe in den Kopfdaten führte zu einem Entschlüsselungsfehler). Alle 15 Kombinationen aus Generation und Stärke laufen rund.
• Aus 1.0.5: Quantum-Operationen werfen bei internen Fehlern QuantumOperationException (mit den Untertypen QuantumKeyGenerationException, QuantumEncryptionException, QuantumDecryptionException) statt null zurückzugeben. Authentifizierungsfehler beim Entschlüsseln (falscher Schlüssel, manipulierte Daten) liefern weiterhin string.Empty. Aufrufer mit null-Prüfung ergänzen ein try/catch.
• Aus 1.0.6 und 1.0.7: interne Diagnoseschalter aus Release-Builds entfernt; die Quantum-API weist leere und mit Nullen überschriebene Schlüsselpuffer mit ArgumentException ab.

1.0.0.2 – 1.0.4.4 · 2025-12-30 – 2026-01-10

Erste Veröffentlichungen

• 1.0.0.2: Erstveröffentlichung mit AES-256-GCM, RSA-4096, Passwort-Hashing, digitalen Signaturen, Post-Quanten-Verschlüsselung (Generationen 1–7), Lizenzstufen, Offline-Aktivierung per .lic-Datei sowie iOS und Android.
• 1.0.1.2: Distributions-Lizenzen (LicenseType.Distribution) für App-Store- und Play-Store-Apps: keine Geräte-Bindung, unbegrenzte Aktivierungen, Prüfung nur der Signatur. Lizenzschlüssel akzeptieren beliebige zwei- bis vierstellige Stufen-Präfixe.
• 1.0.2.2: AES-GCM auf iOS und macOS behoben (zuvor PlatformNotSupportedException).
• 1.0.3.2: Die Registrierung am Lizenzserver läuft im Hintergrund und blockiert nicht; Ablehnungen des Servers werden dem Aufrufer gemeldet.
• 1.0.4.2: Dokumentation. 1.0.4.4: bessere Erkennung mobiler Plattformen, kein Aktivierungs-Timeout mehr auf iOS.