From 8ce5a71652cf3a70c0f3b60d2cdba004c777a389 Mon Sep 17 00:00:00 2001
From: Fabrizio T <roughconsensusandrunningcode@tracciabi.li>
Date: Wed, 20 Nov 2024 21:17:03 +0100
Subject: [PATCH] note tecniche slide 8

---
 README.md        |  2 +-
 note-tecniche.md | 45 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 note-tecniche.md

diff --git a/README.md b/README.md
index de71100..e949cdf 100644
--- a/README.md
+++ b/README.md
@@ -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/)
 
diff --git a/note-tecniche.md b/note-tecniche.md
new file mode 100644
index 0000000..d9471a7
--- /dev/null
+++ b/note-tecniche.md
@@ -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)).