Crittografia ibrida

La primitiva di crittografia ibrida combina l'efficienza della crittografia simmetrica con la comodità della crittografia a chiave pubblica (asimmetrica). Chiunque può criptare i dati utilizzando la chiave pubblica, ma solo gli utenti con la chiave privata possono decriptare i dati.

Per la crittografia ibrida, il mittente genera una nuova chiave simmetrica per criptare il testo non crittografato di ogni messaggio e generare un testo crittografato. La chiave simmetrica è incapsulata nella chiave pubblica del destinatario. Per la decriptazione ibrida, la chiave simmetrica viene decapsulata dal destinatario e quindi utilizzata per decriptare il testo crittografato e recuperare il testo non crittografato originale. Per maggiori dettagli su come archiviare o trasmettere il testo crittografato e l'incapsulamento della chiave, consulta Formato cavo Tink Hybrid Encryption.

La crittografia ibrida ha le seguenti proprietà:

  • Segretezza: nessuno può ottenere informazioni sul testo non crittografato criptato (tranne la lunghezza), a meno che non abbia accesso alla chiave privata.
  • Asimmetria: la crittografia del testo crittografato può essere eseguita con la chiave pubblica, ma per la decriptazione, la chiave privata è obbligatoria.
  • Randomizzazione: la crittografia è casuale. Due messaggi con lo stesso testo non crittografato non restituiranno lo stesso testo crittografato. Ciò impedisce agli utenti malintenzionati di sapere quale testo crittografato corrisponde a un determinato testo non crittografato.

La crittografia ibrida è rappresentata in Tink come una coppia di primitive:

  • HybridEncrypt per la crittografia
  • HybridDecrypt per la decrittografia

Parametro informazioni contesto

Oltre al testo non crittografato, la crittografia ibrida accetta un parametro aggiuntivo, context_info, che di solito è costituito da dati pubblici impliciti dal contesto, ma che devono essere associati al testo crittografato risultante. Ciò significa che il testo crittografato ti consente di confermare l'integrità delle informazioni contestuali, ma non ne viene garantita la segretezza o l'autenticità. Le effettive informazioni sul contesto possono essere vuote o nulle, ma per garantire la corretta decrittografia del testo crittografato risultante, è necessario fornire lo stesso valore delle informazioni di contesto per la decriptazione.

Un'implementazione concreta della crittografia ibrida può associare le informazioni contestuali al testo crittografato in vari modi, ad esempio:

  • Utilizza context_info come input di dati associato per la crittografia simmetrica AEAD (cfr. RFC 5116).
  • Usa context_info come input "CtxInfo" per HKDF (se l'implementazione utilizza HKDF come funzione di derivazione delle chiavi, consulta RFC 5869).

Scegli un tipo di tasto

Ti consigliamo di utilizzare il tipo di chiave DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM per la maggior parte dei casi d'uso. Questo tipo di chiave implementa lo standard HPKE (Hybrid Public Key Encryption), come specificato in RFC 9180. HPKE è costituito da un meccanismo di incapsulamento delle chiavi (KEM), una funzione di derivazione delle chiavi (KDF) e un algoritmo di crittografia autenticata con dati associati (AEAD).

DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM utilizza in modo specifico:

  • KEM: Diffie-Hellman su Curve25519 con HKDF-SHA-256 per ricavare il segreto condiviso.
  • KDF: HKDF-SHA-256 per ricavare il contesto del mittente e del destinatario.
  • AEAD: AES-256-GCM con nonce di 12 byte generati secondo lo standard HPKE.

Altri tipi di chiavi HPKE supportati includono, a titolo esemplificativo:

  • DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_128_GCM
  • DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_CHACHA20_POLY1305
  • DHKEM_P256_HKDF_SHA256_HKDF_SHA256_AES_128_GCM
  • DHKEM_P521_HKDF_SHA512_HKDF_SHA512_AES_256_GCM

Consulta RFC 9180 per ulteriori dettagli sulle scelte relative agli algoritmi per KEM, KDF e AEAD.

Sebbene non sia più consigliato, Tink supporta anche alcune varianti di ECIES, come descritto nello standard ISO 18033-2 di Victor Shoup. Di seguito sono elencati alcuni tipi chiave ECIES supportati:

  • ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM
  • ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_GCM
  • ECIES_P256_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256
  • ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256

Proprietà minime

  • Le informazioni su testo non crittografato e contesto possono avere lunghezza arbitraria (entro l'intervallo 0...232 byte)
  • Proteggerti dagli attacchi di testo cifrati scelti adattivi
  • Sicurezza a 128 bit per schemi basati su curva ellittica

Esempi di casi d'uso

Vedi Voglio scambiare dati.