[23-03-2023]
Sha3 derived functions. Quando è stato progettato ed è stato fatto il contest si era pensato di sopperire a delle lacune di sha3 e si dice di fare un contest per fare qualcosa che fosse realmente scollegato da md5, sha1, sha2, … in concomitanza sono state pensate che sono riconducibili a sha3, ma che hanno una interfacci leggermente diversa, più vicine a quelle che potrebbe servire ad uno sviluppatore. Tra queste funzioni la più popolare che troviamo implementata in python per esempio è cSHAKE. Le altre sono meno diffuse tipo TupleHas, ParallelHash, KMAC. La prima funzione da che cosa nasce? Quando lavoriamo in funzioni hash queste accettano input di dimensioni variabili (c’è una lunghezza massima ma non ci interessa), l’output invece è di dimensione costante e lo associato a livello di sicurezza con il modello di attacco. In alcune applicazioni ci troviamo a voler generare dei digest più piccoli o anche più grandi. Sono state pensate allora delle fuzioni chiamate XOF (extendiile output functions) in cui ho un output di dimensioni parametrizzabile. Quando parliamo di avere un digest in output di dimensione variabile parliamo di due contesti differenti: vogliamo avere un digest di 128 bit oppure vogliamo avere un digest più grande. In generale nel mondo reale la funzione più elegante sarebbe andare ad usare una XOF in cui voglio andare ad usare una dimensione X. Nella realtà dei fatti quando voglio un digest piccolo prendo una hash standard e lo vado a troncare. La prima cosa è che con le funzioni hash questo non è un problema, e questo con le funzioni hash moderne non è un problema.
<aside> 💡 Sha224 ha gli stessi interni di sha256 ma con l’ouput che viene troncato
</aside>
In generale se prendiamo una sha256 posso andare a fare un taglio sull’output digest senza andare a creare problemi di sicurezza. Questo lo posso andare a fare anche con altre funzioni derivate da funzioni hash, come HMAC, per cui posso andare a troncare l’output. Con le funzioni MAC se usiamo HMAC non è un problema, se ho altre funzioni mac non è scontato. Potrei andare a provocare delle vulnerabilità molto più forte. Tipo CBCMAC meglio non andare a fare un troncamento. Una XOF in realtà non ha questo problema, ha la funzione cshake. In python potresti andarlo a trovare come shake. Il nome non indica la dimensione dell’output, shake128 e shake256 utilizzano il numero per indicare il livello di sicurezza. Si progetta sha2 in due versioni sha256 e sha212. Anche da sha3_256 è stato pensato shake128, mentre da sha3_512 è stato pensato shake256, questo perché si identifica 128 e 256 come sicurezza a collision resistance. Al posto di avere una funzione hash e ci metto le mani andando a troncare il digest posso andarea ad usare una XOF perché è molto più elegante! Una XOF potrebbe anche essereuno stream cipher, ma in base a come è progettato internamente cambia il suo uso. Uno stream cipher mi richiede un input con una chiave con distribuzione uniforme, pensa di andare a chiamare chacha. Non posso dargli come input una password o una parola segreta. Hash o XOF non ha questo requisito. Posso anche dargli un input segreto senza distribuzione uniforme. La differenza tra cSHAKE e SHAKE: è che cSHAKE oltre che accettare la dimensione di input, si prende anche una custom string (domain o context string meglio). questa stringa agisce come un tweak nei tweaked stream cipher. Viene usata per andare a fare domain separation. Quando uso una funzione hash voglio andare a customizzare l’esecuzione per un certo scopo. Nelle funzioni hash questo obiettivo realizzo l’obiettivo nella stringa che mi sto calcolando.
In base alle librerie che si usano alcune usa la dimensione in byte altre in bit! Mi raccomando vai sempre a leggere sempre le documentazioni ufficiali, non quelle riassuntive magari da IDE.
Concettualmente sarebbe una funzione che parallelizza l’esecuzione del dato… devo approfondire perché non ci ho capito tantissimo
sha3 è stato pensato per andare ad evitare di avere lenght extension attacks. Non usare mai MAC + SHA2 perché sarebbe un casino sicuramente.
Standard basato su una versione modificata di cSHAKE. Questa funzione mac è chiamata come variable lenght mac. Non devo effettuare una troncazione o riduzione del mac ad hoc. Posso andare a definire quanto mi serve e via. C’è una stringa di customizzazion e eposso andare a fare context separation e poi è una funziona mac tradizionale ottimizzata per essere eseguita su sha3, che ha come input dimensione output e stringa di customizzazione. Abbiamo delle scelte interessante come la lunghezza.
Prende come input una chiave e genera una chiave derivata. La chiave in input la definiamo come input key material. E’ stato pensato uno standard ad hoc a questo scopo, per aggiungere features a questo standard di derivazione. Una key derivation function è simile ad una funzione pseudo random, in qualche modo è però anche diverso. Dobbiamo tenere a mente che le funzioni che sono state standardizzate come input non accettano una chiave segreta, ma una stringa segreta. E’ come la questione degli hash prima. Questa funzione potrebbe anche non essere un valore uniformemente distribuito di n bit. Una key derivation function funziona come una stringa segreta arbitraria. Le key derivation function per essere ottimizzate per derivare delle chiavi sono ottimizzate per andare a genere dati random non tanto più grandi rispetto alla chiave di partenza. Gli internals sono pensati diversamente dalle funzioni di generazione pseudo random. C’è supporto ad input che potrebbe non essere uniformemente distribuiti. Ho anche funzionalità di scoping e domain separation. Vedremo una funzione che da K1 mi genera tante chiavi per diversi tipi di applicazioni! Voglio avere un input che mi permette di andare a customizzare in che contesto quella determinata chiave sarà utilizzata. Il salting e il domain separation spesso ci sono molti casini in internet e trovi brutte implementazioni, tipo come su Django. HKDF è una funzioni di derivazioni di chiavi basata su HMAC con tutte le derivazioni del caso. Questo è proprio uno standard de facto. Prendo in input una chiave che può anche essere una stringa segreta e nemmeno una chiave crittografica a distribuzione uniforme. Si prende subito in input anche un valore che si chiama salt. Questo è una informazione a volte pubblica, ma a volte no. Questo dovrebbe essere effettivamente ad una chiave crittografica, quindi n bit a distribuzione uniforme. HKDF extract sarebbe partire da una chiave che gli diamo tirarci fuori una chiave crittografica. HKDF expand prende una chiave segreta e mi da un info per contesti diversi, praticamente fa domain separation. Le librerie mettono a disposizione anche i due sotto blocchi perché è utile anche per motivi di performance andare ad usare un blocco anziché due. La fase di extract potrebbe essere opzionale. Il salt lo si può studiare il contesto di esecuzione di HKDF. Il salt posso anche non usarlo se non sono sicuro, non c’è problema.
Se parliamo di pin, password e stringhe segrete, le cose cambiano perché l’entropia di una sequenza di n numeri è pari a n volte per 3.32 bit circa se scelgo sempre i bit in maniera totalmente randomica (sarebbe log2(10^n)). Una stringa di 39 simboli numerici scelti totalmente random è 128 bit di sicurezza (128 per 3.32), viceversa se voglio 128 bit di sec faccio 128/3.32. Per quel che riguarda le password possiamo applicare la dimensione dell’alfabeto, se ho 62 simboli uso l’operatore 5.7
Accetto stringhe segrete ad ALTA entropia, altrimenti genero pseudo chiavi vulnerabili, perché parto da poche combinazioni di partenza. Meglio dare stringhe che siano codificate e mantenute come stringhe alfanumeriche. La parte di estrazione di HKDF ha già entropia, ma non si presenta come formato binario e alla fine devo vedere HKDF come una sorta di conversione. Devo avere una entropia alta, perché tutto gioca sull’extract. Quando uso delle informazioni segrete con entropia BASSA introduco un’altra tipo di derivazione: password based key derivation function. Ho davvero un’altra famiglia di funzioni.
<aside> 💡 Non usare HKDF con password generate da utente, perché hanno bassissima entropia e posso generare solo altre chiavi fragili
</aside>