note tecniche slide 8
This commit is contained in:
parent
da68fdf30c
commit
8ce5a71652
2 changed files with 46 additions and 1 deletions
|
@ -1,7 +1,7 @@
|
|||
Slide e risorse per il talk _(Open|Libre)PGP - Novità, controversie e sviluppi futuri_ proposto ad [HackЯocchio](https://hackrocchio.org/) e [Hack or Di(y|e)](https://hacklabbo.indivia.net/hackordiye24/) 2024.
|
||||
|
||||
|
||||
[Abstract](abstract.md) | [Bibliografia](bibliografia.md)
|
||||
[Abstract](abstract.md) | [Bibliografia](bibliografia.md) | [Note tecniche](note-tecniche.md)
|
||||
|
||||
Framework usato: [Marp](https://marp.app/)
|
||||
|
||||
|
|
45
note-tecniche.md
Normal file
45
note-tecniche.md
Normal file
|
@ -0,0 +1,45 @@
|
|||
# Note tecniche
|
||||
|
||||
## Note alla slide 8
|
||||
|
||||
### AEAD (_Authenticated encryption with associated data_)
|
||||
Schema di cifratura simmetrica che garantisce confidenzialità e integrità.
|
||||
|
||||
In RFC 4880, il controllo di integrità veniva fatto appendendo al testo in chiaro il suo hash SHA-1. Gli schemi AEAD ([OCB](https://en.wikipedia.org/wiki/OCB_mode), [EAX](https://en.wikipedia.org/wiki/EAX_mode), [GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode)) risolvono il problema in modo più robusto e con migliori prestazioni.
|
||||
|
||||
### Key derivation
|
||||
In precedenza, lo schema di cifratura di OpenPGP funzionava (semplificando) così:
|
||||
- Cifratura
|
||||
- Si genera una chiave simmetrica casuale chiamata _Session Key_
|
||||
- Si cifra il messaggio con la _session_ key ottenendo il _Ciphertext_
|
||||
- Si cifra la _session_ key con la chiave asimmetrica pubblica del destinatario (ESK, _Encrypted Session Key_)
|
||||
- Si inviano al destinatario ESK e Ciphertext
|
||||
- Decifratura
|
||||
- Il destinatario decifra con la sua chiave asimmetrica privata la _session_ Key
|
||||
- Quindi usa la _session_ key per decifrare il Ciphertext
|
||||
|
||||
In RFC 9580 si aggiunge un passaggio:
|
||||
- Cifratura
|
||||
- Si genera una chiave simmetrica casuale chiamata _Session Key_
|
||||
- Si genera un _salt_ casuale
|
||||
- Dalla _session_ key e dal salt si "deriva" con l'algoritmo [HKDF](https://en.wikipedia.org/wiki/HKDF) un'altra chiave simmetrica chiamata _Message Key_
|
||||
- Si cifra il messaggio con la _message_ key in modalità AEAD
|
||||
- Si cifra la _session_ key con la chiave asimmetrica pubblica del destinatario
|
||||
- Si inviano al destinatario ESK, salt e Ciphertext
|
||||
- Decifratura
|
||||
- Il destinatario decifra con la sua chiave asimmetrica privata la _session_ Key
|
||||
- Usando la _session_ key e il salt deriva a sua volta con HKDF la message key
|
||||
- Quindi usa la _message_ key per decifrare il Ciphertext
|
||||
|
||||
Questo passaggio in più permette di prevenire certi attacchi (ad es. [OpenPGP SEIP downgrade attack](https://www.metzdowd.com/pipermail/cryptography/2015-October/026685.html)).
|
||||
|
||||
### _Memory-hard_ S2K - Argon2
|
||||
Gli algoritmi String-to-Key servono a convertire una stringa (password o passphrase) in una chiave crittografica simmetrica. In OpenPGP vengono usati tra l'altro per proteggere le chiavi private.
|
||||
|
||||
In precedenza questa operazione veniva fatta semplicemente calcolando ripetutamente l'hash della passphrase e di un salt.
|
||||
Il problema di questo meccanismo è che con la potenza di calcolo attuale il brute force è relativamente poco costoso.
|
||||
|
||||
Un algoritmo _memory hard_ oltre a richiedere molte iterazioni richiede anche tanta memoria, ciò lo rende difficile da parallelizzare e rende quindi molto più costoso il brute force.
|
||||
|
||||
### Firma digitale non deterministica
|
||||
Aggiungendo un salt casuale ad ogni firma si mitigano certi attacchi ai quali sono vulnerabili le firme digitali tradizionali, deterministiche (es. [SHAMBLES](https://sha-mbles.github.io/), [PSSLR17](https://eprint.iacr.org/2017/1014)).
|
Loading…
Reference in a new issue