Kryptografie verständlich erklärt

AEAD und ChaCha20-Poly1305

AEAD schützt Vertraulichkeit und Integrität von Ciphertext sowie zugeordneten, unverschlüsselten Daten. ChaCha20-Poly1305 ist eine in RFC 8439 standardisierte AEAD-Konstruktion. [1]

Geprüft 2 Primär- oder Erstanbieterquellen Verfasst von SealTask

Kernaussagen

  • AEAD verschlüsselt und authentifiziert in einer Operation.
  • Zugeordnete Daten bleiben sichtbar, sind aber integritätsgeschützt.
  • Ein Nonce darf unter demselben Schlüssel nicht wiederverwendet werden.
  • Entschlüsselter Klartext darf erst nach erfolgreicher Prüfung genutzt werden.

Definition und Umfang

ChaCha20 erzeugt einen Schlüsselstrom für die Verschlüsselung; Poly1305 berechnet einen Authentifikator über zugeordnete Daten und Ciphertext. Bei der Entschlüsselung wird zuerst das Tag geprüft, bevor Klartext als gültig akzeptiert wird. [1]

Sicherheitsgrenze

Zugeordnete Daten eignen sich für Versionen, Datensatzkennungen oder Protokollkontext, die nicht geheim sein müssen. Ihre Authentifizierung bindet sie an den Ciphertext, verschlüsselt sie aber nicht. [1]

Grenzen und Bewertung

Nonce-Wiederverwendung mit demselben Schlüssel kann Beziehungen zwischen Klartexten offenlegen und die Authentifizierung brechen. AEAD schützt außerdem weder Endpunkte noch absichtlich unverschlüsselte Metadaten. [1]

Häufige Fragen.

Was bedeutet AEAD und ChaCha20-Poly1305?

AEAD schützt Vertraulichkeit und Integrität von Ciphertext sowie zugeordneten, unverschlüsselten Daten. ChaCha20-Poly1305 ist eine in RFC 8439 standardisierte AEAD-Konstruktion. [1]

Was garantiert AEAD und ChaCha20-Poly1305 nicht?

Nonce-Wiederverwendung mit demselben Schlüssel kann Beziehungen zwischen Klartexten offenlegen und die Authentifizierung brechen. AEAD schützt außerdem weder Endpunkte noch absichtlich unverschlüsselte Metadaten. [1]

Wie ordnet SealTask AEAD und ChaCha20-Poly1305 ein?

SealTask verwendet ChaCha20-Poly1305 für geschützte Inhaltsfelder und bindet Schema- und Kontextinformationen als zugeordnete Daten. Nonce-Erzeugung und Schlüsseltrennung sind Teil des dokumentierten Clientprotokolls. [2]

Primärquellen

Definitionen stützen sich bevorzugt auf Normungsorganisationen, Behördenleitlinien und die SealTask-Sicherheitsarchitektur aus erster Hand. Die Links öffnen die vollständige Quelle.

  1. 01
    RFC 8439: ChaCha20 and Poly1305 for IETF Protocols Primär- oder Erstanbieterquelle für Definition, Protokollanforderungen, Sicherheitsgrenzen oder regulatorischen Kontext.
  2. 02
    SealTask security architecture Primär- oder Erstanbieterquelle für Definition, Protokollanforderungen, Sicherheitsgrenzen oder regulatorischen Kontext.
Gesamtes Learning Center ansehen