Re[2]: One time key

ola antirez
Thursday, February 01, 2001, 3:16:38 PM, you wrote:

scusate il "ritardo" nella risposta ma ho la febbre :°(

a> On Wed, Jan 31, 2001 at 09:36:13PM +0100, Sorrow The Prince wrote:
>> la mia idea e' questa:
>> 1) Key n bits (grossa, anche qualche centinaio di K)
>> 2) KeyStream = RAND (Key, offset, len)
>> 3) C = M xor keyStream

a> Il punto 2 non e' molto logico.
a> Se tu hai una segreto puoi generare il keystream senza
a> affidarti ad offset e lunghezze utilizzando un block
a> cipher o una funzione ad una via in counter mode
a> o in qualche modo che ha un feedback interno se vuoi
a> la propagazione dell'errore (dipende dal goal).
a> In questo modo potete scambiarvi un ammontare di bytes
a> uguale al periodo nel quale la keystream non si ripete.
offset e len sarebbero utili per far si' di non utilizzare
mai lo stesso keystream per criptare differenti messaggi...
se io ho 4k di chiave, supponendo che al generatore di keystream
servano solo 8bytes come seme, posso creare la bellezza di 512
keystream... questo per evitare di doversi scambiare frequentemenete
il seme... ovviamente si puo' sfruttare anche la lunghezza del
keystream come hai indicato tu

a> Alla fine devi usare una larghezza del blocco che e' quella
a> di un block cipher o di una one-way hash function per generare
a> il tuo keystream, dunque anche questo non mi e' chiaro.
a> O passi tante chiavi grandi quanto la dimensione del blocco
a> del cipher che userai o non avrai alcun modo di utilizzare
a> tutti quei bytes. Dunque se mi dici "n bits" di chiave
a> io suppongo n/m chiavi in cui m e' la dimensione del blocco
a> del tuo cipher.
si vero... diciamo che n bits e' la dimensione del block cypher:
se io mi passo un file da m bits, ho la bellezza di m/n chiavi
da scegliere per generare i keystream....

>> quando devo criptare un messaggio M, uso un pezzo di quella chiave,
>> a partire da offset per la lunghezza len (magari questa poi sara'
>> fissa...)... generando quindi il KeyStream...
a> vedi sopra
diciamo che uso una delle 1000 (ad esempio) chiavi che ci siamo
passati, e gli dico ovviamente quale (tanto siamo solo io e lui che
possediamo il file con tutte le chiavi...)

>> faccio lo XOR del messaggio con il KeyStream...
>> a questo punto dovrei avere la sicurezza dell'One Time Pad: senza
>> chiave non mi decripti :)
a> Assolutamente no :)
a> Se tu usi uno stream cipher il segreto e' quello che conta.
a> Se qualcuno fa brute force sul tuo segreto e prova a fare
a> l'xor con il tuo ciphertext alla fine otterra' un messaggio
a> in chiaro riconoscibile facilmente.
a> Con la one time pad questo problema non eisiste.
a> Poiche' la chiave e' grande quanto il messaggio stesso
a> l'attacker puo' inventarsi tutte le chiavi che vuole
a> che decifreranno in tutti i possibili messaggi di quella
a> lunghezza, ma non sapra' mai qual'e' la vera.
a> Per questo la OTP e' "perfect security".
si ci siamo...
diciamo che il segreto e' tutto nel seme e nella bonta' del RAND di
generare keyStream abbastanza casuali...
perche' cmq generero' keystream lunghi quanto il messaggio da cifrare,
solo che il metodo di generazione del keystream e' noto a tutti,
indi devo stare attento a far si' che il seme sia piuttosto "sicuro"...
non e' la sicurezza di una OTP... cerco solo di "ricrearla"...

se avessi una OTP, orbene, tramite il canale (1) dello scorso email
mi passo la OTP, e poi attraverso qualunque canale mi passo il
messagio cifrato (senza dire a nessuno come ho creato l'OTP)...

nel "mio" metodo dico invece al mondo come ho creato l'OTP,
e quindi devo passarmi il seme tramite il canale (1), non piu' la
OTP... quindi e' possibile l'attacco bruteforce al seme, sicuramente
piu' piccolo dela OTP stessa...
ma se cmq il seme e' bello grosso e il RAND "abbastanza"
pseudo-casuale, ho quasi (e sottolineo *quasi*) una OTP...
sbaglio? sinceramente non mi sono state tutte chiare le tue obiezioni
:)

>> ovviamente la sicurezza sta nel generatore e nella key...
>> se trovassi un generatore che sono certo non crei numeri predicibili
>> dopo tot passi (avevo letto che i generatori di numeri pseudo-casuali
>> che sfruttano i registri a retroazione lineare si ripetono dopo un
>> toto di passi...) e, nel caso, *so* dopo quanto si ripetono o sono
>> predicibili, orbene, so quanto il mio messaggio puo' essere lungo al
>> massimo...

>> teoricamente un attacco intelligente sarebbe crearsi tutti i KeyStream
>> possibili, in modo da averli pronti per decriptare ogni messaggio
>> cifrato utilizzando lo XOR...
a> Questo presuppone capacita' di immagazzinamento proibitive.
mah! :)

>> non c'e' modo di trasformare questa linearita' della generazione del
>> KeyStream in qualcosa di piu' complesso (ad esempio due chiavi di n
>> bits in ingresso al RAND generator, in modo che un brute force debba
>> fare (2^n * 2^n) tentativi per creare un KeyStream valido)?
a> Be, dipende. Puoi generare due keystream invece che uno se le chiavi
a> sono completamente non correlate, ma poi rimane da provare che il tuo
a> keystream cosi' ottenuto non sia lo stesso ottenibile con un solo
a> keystream ed una chiave diversa dalle tue due chiavi. Vedi gli argomenti
a> a proposito di 3DES e cose del genere per sapere di piu' sull'argomento.
a> In ogni caso non rischiare, e' molto piu' facile che abbassi la sicurezza
a> del tutto con cose di questo tipo.
vero... quindi e' meglio basarsi sulla lunghezza del seme, piuttosto
che concatenare algoritmi a casaccio :)

>> a> Questo e' uno "stream cipher". La chiave e' il seme, non quello che generi
>> a> per fare l'xor, quello e' il key stream. La sicurezza di una cifratura
>> a> di questo tipo sta tutta nella lunghezza della chiave e nella bonta'
>> a> della generazione dei numeri pseudo casuali. Puoi usare un block cipher
>> a> in counter mode per fare questo, o una funzione crittografica ad una via.
>> ho gia' implementato questo schema usando blowfish e
>> 
>> Hi = E(Mi)[H(i-1)] XOR H(i-1)
>> 
>> cioe' criptando con kiave Mi il predente blocco e xorandolo con lo
>> stesso (w i neologismi :)

a> Ups no, evita cio'. Usa un normale counter mode ed un "modo" dell'algoritmo
a> gia' presente in letteratura.
a quanto scritto su Applied Cryptography questo e' uno dei pochi modi
sicuri per generare hash usando algoritmi di cifratura a blocchi...

a> ciao,
a> antirez
cya!
    _.._        _.._    
  ,','"_:./\/\,'_ `.`.  Sorrow The Prince
 /_:--:_ ( oo ) _:--:_\  uin( 11603828 ) - GiR 239 
/       `'`vv'`'      `\  www.s0rr0w.net  



--------------------------------------------------------------------------
informazioni sui comandi supportati da questa ml: http://www.sikurezza.org