Zum Hauptinhalt springen

5.1 Creating the Encryption Context (Erstellen des Verschlüsselungskontexts)

5.1 Creating the Encryption Context (Erstellen des Verschlüsselungskontexts)​

Die in diesem Dokument definierten HPKE-Varianten teilen einen gemeinsamen Schlüsselplan (key schedule), der die Protokolleingaben in einen Verschlüsselungskontext übersetzt. Die Eingaben des Schlüsselplans sind wie folgt:

  • mode: Ein Ein-Byte-Wert, der den HPKE-Modus angibt, wie in Tabelle 1 definiert.

  • shared_secret: Ein für diese Transaktion generiertes gemeinsames KEM-Geheimnis.

  • info: Von der Anwendung bereitgestellte Informationen (optional; Standardwert "").

  • psk: Ein vorgeteilter Schlüssel (PSK), der sowohl vom Sender als auch vom Empfänger gehalten wird (optional; Standardwert "").

  • psk_id: Eine Kennung für den PSK (optional; Standardwert "").

Sender und Empfänger MÜSSEN KEM-Eingaben und -Ausgaben wie in Abschnitt 7.1 beschrieben validieren.

Die Felder psk und psk_id MÜSSEN zusammen oder gar nicht erscheinen. Das heißt, wenn für eines von ihnen ein nicht standardmäßiger Wert bereitgestellt wird, dann MUSS das andere auf einen nicht standardmäßigen Wert gesetzt werden. Diese Anforderung ist in VerifyPSKInputs() unten kodiert.

Die Felder psk, psk_id und info haben maximale Längen, die vom KDF selbst, von der Definition von LabeledExtract() und von den konstanten Labels abhängen, die zusammen mit ihnen verwendet werden. Siehe Abschnitt 7.2.1 für genaue Grenzen dieser Längen.

Der vom Schlüsselplan berechnete key, base_nonce und exporter_secret haben die Eigenschaft, dass sie nur dem Inhaber des privaten Empfängerschlüssels und der Entität bekannt sind, die den KEM zur Generierung von shared_secret und enc verwendet hat.

In den Modi Auth und AuthPSK ist dem Empfänger zugesichert, dass der Sender den privaten Schlüssel skS besaß. Diese Zusicherung ist für die in diesem Dokument definierten DHKEM-Varianten aufgrund von Schlüsselkompromittierungs-Impersonation begrenzt, wie in den Abschnitten 4.1 und 9.1 beschrieben. Wenn in den Modi PSK und AuthPSK die Argumente psk und psk_id wie erforderlich bereitgestellt werden, ist dem Empfänger zugesichert, dass der Sender den entsprechenden vorgeteilten Schlüssel besaß. Siehe Abschnitt 9.1 für weitere Details.

Die HPKE-Algorithmusidentifikatoren, d.h. die 2-Byte-Codepunkte KEM kem_id, KDF kdf_id und AEAD aead_id, wie in den Tabellen 2, 3 bzw. 5 definiert, werden als implizit aus der Implementierung angenommen und nicht als Parameter übergeben. Der implizite suite_id-Wert, der in LabeledExtract und LabeledExpand verwendet wird, ist basierend auf ihnen wie folgt definiert:

suite_id = concat(
  "HPKE",
  I2OSP(kem_id, 2),
  I2OSP(kdf_id, 2),
  I2OSP(aead_id, 2)
)

default_psk = ""
default_psk_id = ""

def VerifyPSKInputs(mode, psk, psk_id):
  got_psk = (psk != default_psk)
  got_psk_id = (psk_id != default_psk_id)
  if got_psk != got_psk_id:
    raise Exception("Inconsistent PSK inputs")

  if got_psk and (mode in [mode_base, mode_auth]):
    raise Exception("PSK input provided when not needed")
  if (not got_psk) and (mode in [mode_psk, mode_auth_psk]):
    raise Exception("Missing required PSK input")

def KeySchedule<ROLE>(mode, shared_secret, info, psk, psk_id):
  VerifyPSKInputs(mode, psk, psk_id)

  psk_id_hash = LabeledExtract("", "psk_id_hash", psk_id)
  info_hash = LabeledExtract("", "info_hash", info)
  key_schedule_context = concat(mode, psk_id_hash, info_hash)

  secret = LabeledExtract(shared_secret, "secret", psk)

  key = LabeledExpand(secret, "key", key_schedule_context, Nk)
  base_nonce = LabeledExpand(secret, "base_nonce",
                             key_schedule_context, Nn)
  exporter_secret = LabeledExpand(secret, "exp",
                                  key_schedule_context, Nh)

  return Context<ROLE>(key, base_nonce, 0, exporter_secret)

Der ROLE-Template-Parameter ist entweder S oder R, abhängig von der Rolle des Senders bzw. Empfängers. Siehe Abschnitt 5.2 für eine Diskussion der Schlüsselplan-Ausgabe, einschließlich der rollenspezifischen Context-Struktur und ihrer API.

Beachten Sie, dass die key_schedule_context-Konstruktion in KeySchedule() äquivalent zur Serialisierung einer Struktur der folgenden Form in der TLS-Präsentationssyntax ist:

struct {
    uint8 mode;
    opaque psk_id_hash[Nh];
    opaque info_hash[Nh];
} KeyScheduleContext;
Letztes Update am