Re: [OT] fascicolo sanitario e CIE
Il 11/02/2022 22:00, Davide Prina ha scritto:
Poiché il testo cifrato può essere decifrato, a cifrati identici
corrispondono necessariamente testi in chiaro identici.
questa frase è così generica che secondo me è falsa.
Sicuramente falsa. Controprova: basta scegliere un algoritmo di
cifratura e provare a decodificare con chiavi diverse lo stesso blocco.
Ovviamente si otterranno due "plaintext" diversi.
Due, secondo me, lo stesso algoritmo con lunghezza di chiave diversa o
algoritmi diversi o... potrebbero ottenere lo stesso cifrato a partire
da testo in chiaro diverso.
*Di solito* (ma non necessariamente) l'operazione di cifratura è
deterministica: dato [algoritmo,chiave,plaintext] viene sempre generato
lo stesso cyphertext. Questo è necessario, p.e., per testare che
l'algoritmo sia implementato correttamente (i test vector forniti con le
specifiche si basano su questo), oltre che per non consumare inutilmente
entropia. Nel caso sia richiesto un "blinding" del plaintext (fissata la
tripletta [A,K,T] devo ottenere testi cifrati ogni volta diversi) ci
sono diversi modi (banalmente -e in modo poco sicuro!- si potrebbe
mettere nel primo blocco il valore di un contatore, che verrà poi
incrementato), anche se generalmente aumentano la lunghezza del
cyphertext (che potrebbe anche essere un effetto voluto).
Un esempio banale è prendere un file a piacere e applicare diversi
algoritmi o stesso algoritmo con chiavi diverse o con lunghezze di
chiavi diverse o... per "decifrarlo". Penso che, bene o male, tutti
ritornino un file di output valido.
Generalmente si, soprattutto se usano la stessa dimensione del blocco.
Il fatto che poi il testo decifrato abbia o meno "senso" all'algoritmo
di cifratura non interessa. Potrebbe p.e. essere il cyphertext da
decodificare con un algoritmo diverso. 3DES funzionava proprio in questo
modo: in modalità EDE cifrava con K1, decifrava con K2 e tornava a
cifrare con K1. Non è ancora stato dimostrato che DES non sia un gruppo,
quindi *potrebbe* essere possibile che il risultato di 3DES equivalga
alla sola operazione di cifratura sotto una sola chiave ma è improbabile:
https://link.springer.com/article/10.1007/BF00206323
" Experiments show, with overwhelming confidence, that DES is not a group."
* visto che chi deve cifrare o decifrare è di solito un utente qualsiasi
con i suoi mezzi computazionali (normalmente tramite l'uso di una CPU)
deve essere permesso di eseguire l'operazione in tempi accettabili. Se
tutti avessero hardware "appropriato" non sarebbe un problema cifrare
messaggi lunghi
No, questo no. Oramai anche un telefonino può eseguire decine (se non
centinaia) di cifrature a chiave pubblica al secondo. Il problema è che
non necessariamente aumenti la sicurezza!
Esempio classico: cifri ("firmi") con RSA2048 un messaggio, *un
carattere alla volta*. Ti aspetti che sia sicuro? Ovviamente no: anche
se l'attaccante non può generare la firma di un carattere che non ha mai
visto, dato un numero sufficiente di firme potrebbe falsificare un
messaggio creato partendo da quelle. P.e. se hai firmato "CIAO"
ottenendo !"£$ l'attaccante può generare un messaggio "firmato" !£"$ che
viene verificato come CAIO :)
* l'uso di una funzione hash permette di minimizzare le collisioni,
soprattutto per messaggi "vicini" (o simili). Questo rende (o dovrebbe
rendere) più complesso riuscire a manipolare una parte del messaggio
facendo corrispondere la firma, anche se vengono scoperte falle nel
sistema di cifratura
All'utente non interessano le collisioni :)
Il problema delle collisioni è che tutti i messaggi che entrano in
collisione possono essere spacciati come autentici!
Esempio banale: se la funzione di hash ignora il carattere '0', il
messaggio "mi impegno a pagare 1€" e ha lo stesso hash di "mi impegno a
pagare 1000€"... Entrambi validi, ma di significato molto diverso :)
* l'uso di una funzione hash permette di usare un messaggio breve su cui
applicare la cifratura. Più il messaggio è lungo e più volte viene usata
la stessa chiave di cifratura e maggiori sono le probabilità di un
attaccante di individuare la "chiave" usata
Con algoritmi recenti questo non è un problema.
(è stato grazie a questa
tecnica che sono riusciti a decifrare messaggi tedeschi nella seconda
guerra mondiale, dove l'uso, inappropriato, della stessa "chiave" su
messaggi anche lunghi ha permesso di identificare la "chiave" usata. Per
messaggi corti, se non erro la maggior parte, invece anche ora stanno
tentando di decifrarli con la tecnologia attuale, ma non ci riescono)
* ...
Beh, non proprio:
http://practicalcryptography.com/cryptanalysis/breaking-machine-ciphers/cryptanalysis-enigma/
Con poco più di 18 miliardi di chiavi, un PC anche datato può fare brute
forcing in poco tempo ("In general it will take less than 30 seconds to
break short messages (50 characters), slightly longer for longer
messages.").
ho letto qualche anno fa un articolo che parlava di cifratura e si
indicava che la principale attività era quella di verificare che
l'algoritmo fosse stato implementato correttamente e il suo uso fosse
congruo. In modo che non vi siano bug o usi inappropriati.
Verificare che l'implementazione sia priva di bug di solito è il primo
passo. Per questo vengono pubblicati i test vector per mettere alla
prova i casi limite e notoriamente problematici.
Discorso diverso per l'uso inappropriato: questo non te lo può garantire
nessun algoritmo. Anche il più sicuro, se usato male, diventa insicuro.
Vedi l'esempio di RSA. O usare due volte ROT13 così è più sicuro :)
Però nessuno valuta se il bug è a livello matematico, cioè se vi è un
"problema", magari intenzionale, che permetta di avere un passpartout,
backdoor o come la si voglia chiamare o magari soltanto un metodo per
diminuire la complessità dell'attacco di alcuni fattori."Nessuno"? Solo tutti i crittoanalisti e buona parte dei matematici :)
--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786
Reply to: