Passa al contenuto principale

5.1 Creating the Encryption Context (Creazione del contesto di cifratura)

5.1 Creating the Encryption Context (Creazione del contesto di cifratura)​

Le varianti HPKE definite in questo documento condividono una pianificazione di chiavi (key schedule) comune che traduce gli input del protocollo in un contesto di cifratura. Gli input della pianificazione di chiavi sono i seguenti:

  • mode: Un valore di un byte che indica la modalità HPKE, definito nella Tabella 1.

  • shared_secret: Un segreto condiviso KEM generato per questa transazione.

  • info: Informazioni fornite dall'applicazione (opzionale; valore predefinito "").

  • psk: Una chiave pre-condivisa (PSK) detenuta sia dal mittente che dal destinatario (opzionale; valore predefinito "").

  • psk_id: Un identificatore per la PSK (opzionale; valore predefinito "").

I mittenti e i destinatari DEVONO validare gli input e gli output KEM come descritto nella Sezione 7.1.

I campi psk e psk_id DEVONO apparire insieme o non apparire affatto. Cioè, se viene fornito un valore non predefinito per uno di essi, allora l'altro DEVE essere impostato su un valore non predefinito. Questo requisito è codificato in VerifyPSKInputs() di seguito.

I campi psk, psk_id e info hanno lunghezze massime che dipendono dal KDF stesso, dalla definizione di LabeledExtract() e dalle etichette costanti utilizzate insieme ad esse. Vedere la Sezione 7.2.1 per i limiti precisi su queste lunghezze.

La chiave (key), il base_nonce e l'exporter_secret calcolati dalla pianificazione di chiavi hanno la proprietà che sono noti solo al possessore della chiave privata del destinatario e all'entità che ha utilizzato il KEM per generare shared_secret ed enc.

Nelle modalità Auth e AuthPSK, il destinatario è assicurato che il mittente possedesse la chiave privata skS. Questa assicurazione è limitata per le varianti DHKEM definite in questo documento a causa dell'impersonificazione da compromissione di chiavi (key-compromise impersonation), come descritto nelle Sezioni 4.1 e 9.1. Se nelle modalità PSK e AuthPSK, gli argomenti psk e psk_id sono forniti come richiesto, allora il destinatario è assicurato che il mittente possedesse la chiave pre-condivisa corrispondente. Vedere la Sezione 9.1 per ulteriori dettagli.

Gli identificatori di algoritmo HPKE, cioè i punti di codice a 2 byte KEM kem_id, KDF kdf_id e AEAD aead_id, come definiti nelle Tabelle 2, 3 e 5 rispettivamente, sono assunti impliciti dall'implementazione e non passati come parametri. Il valore suite_id implicito utilizzato all'interno di LabeledExtract e LabeledExpand è definito in base ad essi come segue:

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)

Il parametro template ROLE è S o R, a seconda del ruolo di mittente o destinatario, rispettivamente. Vedere la Sezione 5.2 per una discussione sull'output della pianificazione di chiavi, inclusa la struttura Context specifica per ruolo e la sua API.

Si noti che la costruzione key_schedule_context in KeySchedule() è equivalente alla serializzazione di una struttura della seguente forma nella sintassi di presentazione TLS:

struct {
    uint8 mode;
    opaque psk_id_hash[Nh];
    opaque info_hash[Nh];
} KeyScheduleContext;
Ultimo aggiornamento il