Il 20/02/2022 10:59, Davide Prina ha scritto:
*Di solito* (ma non necessariamente) l'operazione di cifratura è
deterministica: dato [algoritmo,chiave,plaintext] viene sempre
generato lo stesso cyphertext.
in realtà qui indicavo qualcosa di diverso, che secondo me potrebbe
essere possibile.
Prendo due algoritmi di cifratura diversi (o con chiavi diverse o...) su
due testi diversi e il cifrato risultato è lo stesso.
Alg1 cifra Testo1 e ottiene Cifrato
Alg2 cifra Testo2 e ottiene Cifrato
Se non ti interessa il senso del secondo plaintext (p2) è banale:
p2=D(k2, E(k1, p1))
Ovvero decripti con k2 il cyphertext ottenuto cifrando il primo
plaintext (p1) con k1. I due algoritmi per E e D possono essere uguali o
diversi, basta che generino un blocco "compatibile" (normalmente basta
che sia della stessa lunghezza, altrimenti sarebbe possibile determinare
se un blocco di dati casuale è un testo criptato o meno, e questo
sarebbe indesiderabile).
Secondo me, se si considerano solo gli algoritmi di cifratura che hanno
come risultato una lunghezza "fissa" pari al testo da cifrare e dato che
il numero di algoritmi è in teoria infinito, mentre il numero di
combinazioni possibili su una lunghezza del Testox a piacere è finito si
avranno per forza delle collisioni.
Dimostrato sopra. Con cifrari a blocchi (considerati più sicuri) hai da
rilassare il vincolo sulla lunghezza del cyphertext aggiungendo un padding.
No, questo no. Oramai anche un telefonino può eseguire decine (se non
centinaia) di cifrature a chiave pubblica al secondo.
dipende dall'algoritmo usato, dalla lunghezza della chiave, ... se
arrivi a cifrare tutto il traffico, secondo me, introduci una latenza
tale che il tuo dispositivo diventa inusabile.
Per traffico "normale" è indistinguibile. P.e. trasferire un file da
100M via https piuttosto che via http non ti porta una differenza
percettibile, a meno che non lavori su hw veramente ridotto (Arduino,
ESP8266... comunque dove non gira Debian - almeno per il momento :) ).
Il problema è che non necessariamente aumenti la sicurezza!
Esempio classico: cifri ("firmi") con RSA2048 un messaggio, *un
carattere alla volta*.
naturalmente facendo così elimini del tutto la sicurezza che stai
introducendo con la cifratura.
Infatti era un esempio estremo, anche se molto significativo.
Se cifri tutto devi cifrare il flusso di dati o il file completo.
Anche qui devi fare attenzione. P.e. c'era un attacco per determinare se
c'era qualcuno in casa analizzando il traffico cifrato generato dalle
webcam WiFi verso il DVR: senza bisogno di decifrarlo, bastava
analizzare la quantità di traffico generata che aumentava enormemente in
presenza di movimento.
Quando scrivevo di cifrare messaggi corti intendevo cifrare l'hash al
posto del messaggio completo.
Normalmente firmi solo l'hash sia per questioni di performance (su
sistemi veramente vecchi, tipo 386, una firma RSA2048 portava via una
frazione significativa di un secondo) sia perché su alcuni sistemi (tipo
le smartcard) la comunicazione è talmente lenta che trasferirgli un file
da alcuni MB richiederebbe decine di secondi.
il problema è che l'utente (al cui gruppo appartengo anch'io), spesso
non è consapevole di quello che sta facendo e se non ha interesse
diretto, ha però un interesse indiretto, quando qualcuno di più esperto
effettua un attacco e ha successo.
Ha fatto notizia giusto ieri un attacco/truffa ai possessori di NFT
tramite contratti "smart": in pratica gli veniva fatto firmare un hash
(su un sito apparentemente innocuo) e questa firma veniva poi utilizzata
per trasferire all'attaccante tutti gli NFT del firmatario.
Il problema delle collisioni è che tutti i messaggi che entrano in
collisione possono essere spacciati come autentici!
infatti.
Per questo ho da sempre proposto di non far firmare solo l'hash ma un
"riassunto" della transazione, meglio se visualizzabile su un display
nel token che difende la chiave segreta.
* 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.
questa cosa non la conosco. Mi dai qualche esempio?
Da DES in poi, una delle specifiche è che non deve essere possibile
(tranne che con forza bruta, ovviamente) ottenere la chiave conoscendo
il plaintext e il cyphertext.
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.").
alcuni punti:
1) a me sembra strano tutto questo. Prima di tutto di enigma sono state
create diverse versioni e poi l'uso che è stato fatto è stato modificato
nel tempo e anche a seconda della forza militare che lo utilizzava,
aggiungendo maggior difficoltà d'attacco[2].
Non sono un esperto di Enigma. Comunque molto dipendeva dalla segretezza
dei rotori.
Se fosse così com'è indicato nella pagina che hai indicato, come mai è
stato creato questo progetto?
http://www.enigmaathome.net/
per decifrare 3 messaggi il tempo impiegato è totalmente diverso da
quello indicato nell'articolo: "Project total CPU time equivalent to:
366959 years, 282 days, 16 hours of Athlon 3500+ running stock app."
Non lo conoscevo. Però non mi torna. O magari stanno tentando di
decifrare messaggi erronei (errore dell'operatore, errore di
trasmissione o di ricezione, o volutamente alterato al fine di far
perdere tempo agli analisti alleati).
2) TONY SALE[1] ha detto[2]:
* The total number of ways in which the Enigma machine can be configured
for any particular message is 150 million million million
* Its complexity's enormous. I mean, if I sent just one message on an
Enigma machine today it would still take a super Cray computer, the
fastest in the world, a year to go through searching for that one
message without supporting evidence as to what that message might have
been.
Il problema è capire se il plaintext ottenuto è sensato o meno.
P.e. normalmente veniva trasmesso due volte un preambolo, il che rendeva
facile capire che il messaggio era stato decrittato correttamente. Metti
che l'operatore non lo abbia fatto, non hai modo di riconoscere il
messaggio "vero", puoi solo escluderne una gran parte con delle
euristiche, ma magari in questo modo scarti anche il messaggio che è
stato trasmesso...
ok era il 1999, ma da quell'anno all'attuale un PC normale non è
diventato più potente di un supercomputer dell'epoca.
Beh, diciamo che ci si è avvicinato parecchio :)
Poi enigma ha dei "bug" che rendono, in taluni casi, la sua robustezza
minore.
Per fortuna.
3) oltre ad enigma, di cui io non avevo accennato nella mia risposta,
sono stati usati altri "algoritmi" di cifratura, ad esempio Lorenz[2][3]
Una caterva. Con diversi gradi di sicurezza.
Ho un vago ricordo di un sistema che utilizzava un mazzo di carte per
generare il keystream: cosa c'è di apparentemente più innocuo, nei beni
di un rifugiato, di un mazzo di carte?
4) purtroppo, probabilmente a causa di come funziona la mente umana nel
ricostruire i ricordi[4], in realtà io volevo riferirmi a quest'altro
caso di cifratura sempre nato negli anni della seconda guerra mondiale e
portato avanti fino al 1980: i messaggi cifrati spediti dalle spie russe
dagli USA alla Russia
ho trovato questo documentario[5] che ne parla:
revealing thousands of telegrams sent between Moscow and the Soviet
diplomats in the 1940s and '50s.
The Venona project lasted until 1980. Only those messages that reused
sheets of one-time pad could be read, less than one percent of the
total. No messages sent after 1948 could be broken;
Ah, beh, OTP è l'unico sistema dimostrabilmente sicuro. Purché non
riutilizzi il keystream. E il keystream viene consumanto con ogni messaggio.
C'è anche un documentario, sempre di PBS Nova, più recente, che parla in
modo più approfondito su questo argomento, dove dice esplicitamente che
stanno tentando di decifrare tali messaggi cifrati, ma per ora non sono
riusciti... purtroppo ora non riesco a trovarlo, nei quasi 1.000
documentari PBS Nova[6]
Se usavano (correttamente) OTP, è impossibile. A meno di non avere a
disposizione le chiavi.
5) come dimostrano i documentari PBS Nova [2][5], la causa principale
del fallimento di un sistema complesso di cifratura è l'inadeguatezza
dell'utente che li utilizza.
Secondo me, più un sistema è complesso e meno l'utente è esperto e più
sono altre le probabilità di fallimento.
Un utente per poter usare qualcosa dovrebbe capire cosa sta usando, come
funziona e adottare conseguentemente un uso consapevole.
O avere per lo meno istruzioni precise e addestramento adeguato.
6) Dalla mia scarsa conoscenza della criptografia mi sono fatto l'idea
che il metodo di cifratura più sicuro, anche considerando l'aspetto
dell'utente "ignorante" in materia che lo utilizzerà è quello di usare
un metodo di cifratura basato su una "chiave" diversa per ogni messaggio
e la lista delle chiavi posseduto solo da chi deve comunicare/ricevere.
Tale lista non deve essere generata da una lista pseudocasuale. Questo,
secondo me, è valido e inattaccabile soprattutto per messaggi brevi,
come l'autenticazione. Le chiavi possono benissimo trovarsi su un foglio
di carta.
"Don't roll your own crypto". Spesso anche gli esperti sbagliano...
Prendo ad esempio PGP, che portò alla portata di "tutti" alcune best
practice, per quanto ora sia pesantemente criticato. Per cifrare un
messaggio con RSA, come prima cosa veniva generata una chiave di
sessione, che veniva cifrata con la chiave pubblica RSA del destinatario
(o dei destinatari) e utilizzata per criptare con un algoritmo
simmetrico il plaintext. Così, oltre ad avere la massima sicurezza (una
chiave diversa per ogni messaggio) potevi mandare lo stesso cyphertext a
molti utenti (p.e. su FidoNet la banda era molto ridotta).
Un esempio è l'autenticazione a due fattori: Google ha dichiarato che
con l'autenticazione a due fattori gli attacchi che hanno successo sono
circa il 50% in meno rispetto ad un'autenticazione con sola password.
Come dire che aumentare la complessità per l'utente di 10-100 volte
diminuisce la probabilità di successo dell'attaccante del 50%. (non
trovo l'articolo)
Uh? Perché aumenti la complessità per l'utente di "10-100 volte"? Coi
token Fido basta tenere la chiavetta inserita e toccare il tasto quando
ti viene chiesto. Se invece ti riferisci a TOTP/HOTP la UX è meno
lineare ma comunque non così complessa... Anche mia madre riesce ad
usare Google Authenticator, ma sicuramente rallenta parecchio il login...
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 :)
tieni conto che alcuni modelli matematici sono proposti da enti come
l'NSA[9] o indicati come mandatori per l'uso...
E proprio per questo gli viene sbattuto in faccia in modo molto pesante
ogni piccolo difetto o comportamento sospetto. P.e. DRDB è considerato
non sicuro coi paramentri dello standard: chi è in possesso della chiave
segreta usata per generarli è anche in grado di decrittare il traffico.
Discorso diverso per DES: malgrado alcune modifiche alle s-box siano
state viste con molto sospetto dai ricercatori, si è poi scoperto che la
NSA le aveva fatte introdurre per renderlo resistente alla crittoanalisi
differenziale, allora segreto militare e "scoperta" pubblicamente solo
molti anni dopo -- il fatto che la versione iniziale di DES fosse
attaccabile e quella "rivista" no ha fatto capire che NSA la conosceva
ben prima della comunità accademica.
Io penso che sia "semplice" verificare se il modello matematico sia
corretto, mentre sia molto più complesso individuare se esista un
ulteriore modello matematico che permetta di avere un passpartout,
backdoor al primo. E nell'articolo che avevo letto, da quello che mi
ricordo, si indicava che questo secondo passaggio non viene generalmente
fatto.
Beh, se cifratura e decifratura funzionano, il modello matematico è
"corretto". La verifica che non abbia backdoor o altre debolezze è
proprio il lavoro dei crittoanalisti. P.e. molti algoritmi, anche se
implementati correttamente e senza debolezze matematiche (note) possono
rivelare dati sensibili tramite side channel. Molte implementazioni di
RSA sono "poco sicure" perché il tempo usato per decrittare dipende dal
valore dei bit della chiave. In altri casi si guarda il consumo del
chip. Comunque sempre più spesso una delle specifiche per nuovi
algoritmi è l'essere "constant time".
--
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
