Newsgroup: it.comp.sicurezza.crittografia
Titolo: One Time Pad

Avrei qualche domanda riguardo OTP.
Viene detto che la "chiave" non deve essere riutilizzata,
perche` altrimenti tutta la sicurezza va a farsi benedire.
La prima domanda e`: neanche nel caso si trasmetta lo stesso
identico messaggio?
Se si manda "ciao come stai" xor X (dove X e` un numero
casuale di pari lunghezza) e poi si ri-manda lo stesse
messaggio, cioe` di nuovo "ciao come stai" xor X, si hanno
lo stesso delle potenziali vulnerabilita`?
Perche` chi intercetta i dati crittografati trova lo stesso
identico bitstream, il che puo` voler dire o che il messaggio
e` lo stesso con la stessa chiave (nessuna informazione) oppure
che il messaggio e` diverso, la chiave anche, ed incidentalmente
risulta identico ad un messaggio precedente.
Seconda domanda: il pad puo` essere lo stesso se il messaggio
e` un altro numero (o stringa) casuale?
In questo caso, chi intercetta il messaggio puo` essere in
grado di sfruttare il riuso del pad, anche se il messaggio e`
a sua volta random?
Grazie anticipatamente,
bye,
-- 
piergiorgio

 a sua volta random?
Se il messaggio è "veramente" random (ovvero non pseudorandomico), lo 
saranno anche i dadi crittografati (praticamente stai utilizzando un 
cifrario di Vigenère su uno stream random).
Il risultato è lo stesso che otterresti inviando lo stesso messaggio X 
ripetuto n volte, crittato con un OTP (non ripetuto), ovvero ottieni uno 
stream random.
L'ascoltatore non riuscirà a risalire al messaggio *E* allo stream, in 
compenso una cosa del genere non ti serve a nulla (se è per dare 
fastidio all' ascoltatore, tanto vale trasmettere lo stream originale).
ciao,
--zz

 fastidio all' ascoltatore, tanto vale trasmettere lo stream originale).
Mi serve per trasferire, in modo sicuro, un secondo pad,
da usare con messaggi normali.
In altre parole, e` possibile usare un primo pad, per
trasferire N pad successivi, da usarsi, poi con messaggi
di effettivo interesse.
Sempre che le condizioni di "sicurezza" tengano.
bye,
-- 
piergiorgio

 Sempre che le condizioni di "sicurezza" tengano.
Non reggono, perchè posto che vengano intercettate SIA le trasmissioni 
dei pad crittati CHE i messaggi crittati con tali pad, ti riconduci ad 
una situazione di cifrario di Vigenère.
Detto in altre parole: non serve a nulla aggiungere entropia se poi dai 
modo all' ascoltatore di venirne in possesso.
Ciao,
-zz

 modo all' ascoltatore di venirne in possesso.
Quello che mi sfugge e` come faccia l'ascoltatore a
trarre informazioni utili dal messaggio contenente
un xor fra due "stringhe" casuali.
Anche sapendo che una delle due e` stata gia` usata
con un altro messaggio.
Grazie di nuovo,
bye,
-- 
piergiorgio

 con un altro messaggio.
Come detto in un post precedente, l' operatore non può risalire al pad e 
alla chiave durante la prima serie di trasmissioni, il tutto però crolla 
nel momento in cui cerchi di usare questi pad per crittare i tuoi 
messaggi. Sei stato proprio tu, durante la prima serie di trasmissioni, 
a fornire all' attaccante la tua sorgente di entropia.
La dimostrazione è elementare:
tu vuoi effettuare uno xor di n pad (P) con la stessa chiave (V), 
ottenendo n trasmissioni (chiamiamole T)
(non ho il simbolo dello xor, usiamo x)
P1 x V = T1
P2 x V = T2
...
Pn x V = Tn
Utilizzare questi pad per crittare n messaggi (M), ottenendo n messagi 
finali (diciamo K)
M1 x P1 = K1
M2 x P2 = K2
...
Usando entrambe le trasformazioni puoi scrivere
M1 x T1 x V = K1
M2 x T2 x V = k2
...
e quindi
M1 x V = K1 x T1
M2 x V = K2 x T2
...
Mn x V = Kn X Tn
Come vedi ti riconduci alla situazione di n messaggi crittati con la 
stessa chiave di cui conosci l' output (se conosci sia K che T, ovvio), 
ovvero al cifrario di Vigenère.
ciao,
-zanna

 
Sprechi tempo. Come farai ad avere una chiave non solo lunga come il 
messaggio ma "random"?
Max

 messaggio ma "random"?
Usando un TRNG, ovviamente.
Per esempio, uno fra tanti:
http://www.idquantique.com/products/quantis.htm
bye,
-- 
piergiorgio


Secondo me perdi tempo :-) se il tuo interesse non e' puramente ludico.
A parte il fatto che simili dispositivi hanno complessi meccanismi di 
guasto (come fai a sapere che funziona dopo 1 , 2... 6 mesi 
dall'acquisto?), non pensare a test di randomness perche non e' 
possibile dimostrare con "certezza" che una sequenza sia realmente 
random (puoi solo stabilire il livello di confidenza al quale l'ipotesi 
di randomicita' e' vera) . Ci sono poi una miriade di problemi da 
risolvere, ad esempio il file di swap del tuo PC potrebbe mantenere 
informazioni sensibili (ci hai pensato ?) oppure si puo fare sniffing 
delle emissioni elettromagnetiche dal tuo PC/dispositivo (si puo' fare!).
Inoltre come pensi di distribuire in modo sicuro e pratico le chiavi?
Io non penso che tu abbia la reale necessita' di avere la "certezza" 
aver scritto un algoritmo "unbreakable" (non l'avrai mai) e nemmeno 
penso che tu abbia bisogno di maggiore sicurezza di quella che un AES256 
(ad esempio) ti garantisce.
Ammesso che tu possieda informazioni cosi' importanti da proteggere ci 
sono molti "alternativi" di averle (Guantanamo?) se veramente 
interessano. E poi l'anello debole di un software di cifratura non e' 
quasi mai l'algoritmo ma la sua implementazione (in senso lato).
Comunque buon lavoro!!
Max

 Comunque buon lavoro!!
:-) Nessun lavoro, solo una curiosita`...
bye,
-- 
piergiorgio

 :-) Nessun lavoro, solo una curiosita`...
Ah be allora se e' solo per curiosita'... comunque buon lavoro lo stesso
Ciao
  Max
"One-time pads may be theoretically secure, but they are not secure in a 
practical sense" B. Schneier

 inutilizzabile proprio per la gestione delle chiavi.
Esattamente per questo la domanda iniziale... :-)
Il punto era proprio capire, da parte mia, quale fosse il
problema (perche` ero sicuro non funzionasse...) di usare
il metodo proposto per scambiare la chiave.
Non sto certo cercando di re-inventare la crittograffazione,
cercavo solo di capire i limiti dell'idea che mi era passata
per la testa.
bye,
-- 
piergiorgio

 Il problem di OTP e` la chiave...
Non ci siamo capiti. Ovviamente "recuperare" la chiave e' un possibile 
attacco. Ma in genere la chiave la si recupera sfruttando gli anelli 
deboli non quello (solitamente forte) dell'algoritmo di crittografia.
Intendevo quello.
Max

 Intendevo quello.
Appunto, esattamente quello che intedevo io quando
scrivevo di key-management.
Mi sa che stiamo esattamente dalla stessa parte.
bye,
-- 
piergiorgio

 La domanda iniziale era proprio questa, mi pare.
Allora ho capito male.
Max

 Allora ho capito male.
Vediamo, cerco di rispiegare meglio il problema.
Tutto il punto del discorso ruota su avere un metodo
di crittograffazione che sia complesso piu` o meno
quanto un xor.
Una (la?) soluzione e` OTP.
Il problema di OTP e` la chiave: come si fa, tra le
altre cose, ad aggiornarla.
E` possibile usare la vecchia chiave per trasmettere
la nuova?
Questa era la domanda e mi e` stato fatto notare come
la cosa non sia possibile.
Ovviamente, visto che siamo in tema, si potrebbe cambiare
la domanda e chiedere:
Esiste un metodo di crittograffazione semplice piu` o meno
quanto un xor, che sia piu` maneggevole di OTP?
bye,
-- 
piergiorgio

 forse si meno... :-)
Non solo e nulla vieta che ti sia prodotto più di una volta e anche
consecutivamente.
Cosi come nulla vieta che il generatore di password alimentato dal
generatore più casuale possibile ti produca come password "topolino".
Le cose sono un pochino più complicate (o piu semplici?).
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 
In realta' all'inizio ho erroneamente capito che OTP lo volevi usare per 
la sua perfezione e non per la sua semplicita'.
Bene. OTP e' xor + ( 1)  and  2) and  3) ). Se lo semplifichi, 
eliminando anche una sola ipotesi, ti rimane solo lo xor.
Se ad esempio la chiave e' piu' corta del messaggio avrai una 
ripetizione ed avrai essenzialmente una codifica Vigenere.
Se la chiave e' lunga ma viene usata piu' volte ricadi nel precedente 
esempio concatenando  i messaggi criptati.
Se la chiave non e' "true" random puoi rompere OTP. AD esempio GEE (la 
macchina OTP tedesca) usava un generatore random hardware ma imperfetto
perche' conteneva predicibilita'. Ovviamente il sistema e' stato forzato.
Non mi e' noto l'ambito quindi tentativamente...uno stream cipher
Poiche' non ti interessa la "perfezione di Shannon" ma solo una 
sicurezza "empirica" potresti usare uno stream cipher usando una chiave 
(magari hashando una frase) come seed di un generatore pseudo-casuale 
(e' inutile spendere soldi per il Quantum!) "crittograficamente forte"
come Yarrow che e' free (
http://www.schneier.com/yarrow.html
) oppure 
CryptGenRandom() delle API crittografiche microsoft (preferibilmente se 
usi XP SP3 o Vista) o altri come ISAAC. Il generatore pseudocasuale 
genera uno stream di bit che puoi XORare con lo stream da trasmettere.
In pratica un OTP debole :-) Il seed del generatore puo' essere un punto 
da approfondire. Guarda ISAAC
http://www.burtleburtle.net/bob/rand/isaacafa.html
Max

 quanto un xor, che sia piu` maneggevole di OTP?
Potresti usare una sequenza pseudocasuale generata da un prng come
Yarrow o Fortuna, o uno stream cypher, o anche un block cypher basato
su AES, Twofish o Serpent in modo, ad esempio, CTR che trasforma ai
fini pratici il block cypher in uno stream cypher.
In questo modo la chiave da comunicare si ridurrebbe alla password o
il keyfile utilizzato per il seeding dell'algoritmo che ha generato la
sequenza usata nello xor con il messaggio, e la sicurezza si
ridurrebbe alla difficoltà di recuperare la chiave... in qualsiasi
maniera, ma in ogni caso data una chiave di dimensioni adeguate (es
256 bit, ma per quel che sappiamo anche meno possono bastare) il brute
force non sarebbe l'attacco migliore (cioè quello più semplice e meno
costoso) e, almeno per un tempo futuro utile che possiamo immaginare,
non è nemmeno fattibile.
Attenzione però che il significato di "sicurezza" dipende anche dallo
scenario; ad esempio questo metodo può andare benissimo per rendere
indecifrabile il messaggio ma se l'attaccante mira invece a introdurre
modifiche un OTP o un simil-OTP in molti casi non offrono alcun
margine di sicurezza.
Un esempio banale, se l'attaccante Caio sa che il messaggio è un
bonifico per lui da parte di Tizio a banca_di_Tizio, può modificare
"Pagare a Caio 10.000 euro" in "Pagare a Caio 20.000 euro"
semplicemente aggiungendo 1 al primo byte della cifra che
probabilmente avrà un offset a lui noto (magari è il tracciato che usa
anche la sua banca...).
In molti casi sicurezza non corrisponde 1:1 ad indecifrabilità ma
devono entrare in gioco altri fattori (almeno un hashing, o meglio uno
schema crittograficamente sicuro di autenticazione) per mettere in
piedi un sistema crittografico in grado di garantire comunicazioni
"sicure" per un un ampio spettro di applicazioni pratiche: garantire
che il messaggio non sia stato letto o modificato, che realmente
provenga da chi dice di esser l'autore ecc...

 
http://www.burtleburtle.net/bob/rand/isaacafa.html
Grazie del suggerimento, daro' un'occhiata.
bye,
-- 
piergiorgio

 Attenzione però che il significato di "sicurezza" dipende anche dallo
[...]
E grazie anche per questi suggerimenti.
bye,
-- 
piergiorgio

 E dammi un link, qualcosa, no! :-)
Va bene! Mi costringi a perdere un po' di tempo :-)
http://www.cryptography.com/resources/whitepapers/IntelRNG.pdf
paragrafo 4.6
Partial failures are more difficult to
detect and could reduce the entropy of the
output, but many such faults would be fixed by
the corrector.
.
.
.
It is also not possible to guarantee that
manufacturing flaws, intentional sabotage, and
other unexpected failures will never occur.
Oppure puoi leggere
http://ece.wpi.edu/~sunar/preprints/rings.pdf
parla di un TRNG realizzato con ring. Gli autori analizzano possibili 
problemi e raccomandano migliorie al primo progetto che evidentemente 
aveva qualche problema.... :-)
...externally controlled operating conditions such as supply voltage and 
operating temperature may have serious implications on the quality of 
the TRNG output....
Max

Atreides wrote:
[...]
Uhm, avevo risposto anche a questo post, ma non
vedo il messaggio sul mio server.
Comunque sia, grazie per i suggerimenti sulle
soluzioni alternative.
bye,
-- 
piergiorgio

 the TRNG output....
In questo caso, per prima cosa il fatto che si propongano
migliorie gia` dimostra che e` possibile migliorare, cioe`
che si puo` passare la soglia oltre la quale le critiche
diventano supposizioni.
Secondo, questi usano test standard (DIEHARD) per misurare
se il TRNG funziona o meno...???
Per concludere, intendiamoci per _definizione_ non e`
possibile dimostrare a *posteriori* se una sequenza e`
random oppure no (a parte il test di ML).
Resta pero` il fatto che un TRNG e` random *apriori*,
cioe` lo e` per costruzione, cosi` come lo e` il lancio
di un dado (non truccato)... :-)
In altri termini, l'ipotesi di randomicita` di un TRNG
puo` essere solo per design, non certo per verifica
successiva, quello che si puo` verificare e` che produca
bit utilizzabili.
bye,
-- 
piergiorgio