One Time Pad, atto secondo...

Ciao,
	sono appassionato di crittografia da non molto tempo, ma ho potuto
comunque formulare idee - spero non banali - che vorrei esporvi.
Leggendo le faq di sci.crypt sono venuto a conoscenza del sistema di
codifica OTP, sistema che si appoggiava sul semplice fatto che xorando due
elementi (gruppi di byte) ottenevo un risultato dal quale non potevo
deterministicamente ritornare ad uno degli elementi. Penso che sia simile
alla situazione in cui a+b=c (oppure a*b=c) e conoscendo c non posso
ricavare a senza sapere b e viceversa. Ritornando al OTP, il principale
difetto era quello che per ottenere un'assoluto grado di sicurezza, la
chiave di cifratura doveva essere il piu' aleatoria possibile e grande come
il testo da cifrare. Al che, mi e' venuta in mente un'implementazione che
avrebbe potuto eliminare questo problema, non elminando comunque la
necessita' di un buon generatore di numeri pseudo-casuali (PRNG ?) e infine
mantenendo un alto grado (spero :-) di sicurezza. L'idea e' semplice, 

supponendo p[i] l'i-esimo elemento del testo in chiaro, eseguo le seguenti
operazioni:

--> r=random()

-/*caso char*/> r = random() % 255;
//nel caso utilizzi un char questa puo' essere un'alternativa, ma credo che
limiti di molto l'aleatorieta' del numero

genero un numero pseudo-casuale.

Entra in gioco ora il fattore k, la chiave segreta. E' un numero anch'esso
molto grande.

Assumo c[i] l'i-esimo elemento del testo cifrato.

--> c[i+1] = r XOR k*k;

-/*caso char*/> c[i+1] = (r + k * k) MODULO 255;           


memorizzo l'informazione del numero p-random nella cella successiva

--> c[i] = p[i] XOR (r * k);

-/*caso char*/-> c[i] = p[i] + ((r * k) MODULO 255);


cifro il testo in chiaro e lo memorizzo in c[i]

Tralasciando - per ora - le implicazioni tecniche che tali operazioni
comportano passo alla fase di decrittazione:

--> r = c[i+1] XOR (k*k);

-/*caso char*/-> r[i] = c[i+1] - ((k * k) MODULO 255)

riottengo il numero p-random

--> p[i] = c[i] XOR (r * k);

-/*caso char*/-> p[i] = c[i] - ((r * k) MODULO 255)

Il sistema si appoggia pesantemente sulla generazione di numero
pseudo-aleatori, e presenta le seguenti caratteristiche:

--> senza conoscere il fattore segreto k non si può ottenere il testo in
chiaro;

--> questo metodo implica la memorizzazione di un numero di byte doppio
rispetto al testo in chiaro;

--> la grandezza dei numeri con cui si lavora va ridotta al blocco che si
cifra, forse minando la sicurezza dell'intero sistema

Naturalmente queste sono solo le mie supposizioni, ora entrate in gioco voi
:-)
Sarei grato se mi poteste dare un parere sugli eventuali anelli deboli
presenti.
Sicuramente avro' detto della panzane mega-galattiche, correggetemi senza
timore :)
Ah, ho gia' compilato un prog in c funzionante, che lavora con l'addizione
modulare. Se qualcuno volesse posso postare il sorgente o mandargli
l'eseguibile.

La mail comunque non finisce qui ;)

Ho notato nella mia breve incursione nel mondo dei PRNG che essi si
basavano per lo più su eventi  automatizzati e senza l'intervento
dell'utente. Penso che la vera casualita' si possa ottenere quando due
eventi interagiscono tra di loro senza conoscere il funzionamento l'uno
dell'altro. Mi spiego meglio: se mi affido alla presunta casualita' di un
fenomeno artificiale o naturale prima o poi noterò una ridondanza poiche' i
fenomeni tendono a ripetersi ciclicamente. 
Pensiamo invece al caso in cui una persona interagisce con un programma che
scorre ciclicamente (e velocemente) una lista di numeri. Il ciclo si ferma
alla pressione di un tasto da parte dell'utente. In questo semplice caso,
la determinazione del valore dipendeva solo dall'utente il quale non sapeva
la frequenza del ciclo (che puo' benissimo cambiare dinamicamente ad ogni
pressione del tasto in base al valore risultante dal ciclo). Questo caso,
seppur nella sua semplicite' fornisce (credo) un numero molto aleatorio. E'
vero, anche se si verifica la presunta aleatorieta' dei valori risultanti,
usare tale sistema non e' molto comodo..

Recentemente ho letto in un libro, Cryptonomicon, in cui il protagonista
generava una serie di numeri pseudo casuali a partire da un input.
Applicava la funzione Z di Riemman:
                
             infinito                                                      
                   
               ____
	         \        1             1       1           
                \    -------  = 1 + ----- + ----- + . . . 
       Z(s) =   /        s             s       s          
               /        N             2       3           
               ----
              n = 1

Z(s)=sommatoria( (n=1) --> infinito) (1/(n alla s))

Mi potete dire di piu' su questa funzione?

Ultima parte della mail [ok, oramai avrete capito quanto sono logorroico
:-]
Riprendendo il discorso di:

a+b=c

per non lavorare con numeri molto grandi si puo' applicare alla somma a+b
il modulo

(a + b) MODULO n = c

la determinazione di a a partire da c,b ed n si riconduce ad una semplice

(c - b) MODULO n = a

ovvero:

if ( (c - b) >= 0 ) a = c - b;
          else a = n - ( c - b );

ma nel caso in cui al posto dell'addizione eseguo una moltiplicazione o
"peggio" un elevamento a potenza?

(a * b) MODULO n = c

oppure

(a ^ b) MODULO n = c

come eseguo l'operazione inversa? Mi sembra di ricordare un metodo che
applicava un teorema di Euclide, ma qui le mie esperienze matematiche mi
dicono "Ciao, ciao.."

Saluto tutta la ml

p.s: non sono un genio in matematica, molto probabilmente avro' detto delle
cavolate...


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List