Re: [crypto] xorlabs...

MultiTaskinG wrote:

> XEVRON funziona in maniera completamente diversa. giusto

[diversa da Diffie Hellman, nda]

No, non e' diverso, e' identico: solo che utilizza il prodotto
(invertibile) al posto del logaritmo modulare (one-way trapdoor).

> esemplificativamente:
> 1) Non usa numeri primi ma numeri random creati all'occorrenza

Diffie Hellman non usa numeri primi come chiavi ma numeri random. Sei
sicuro di aver mai letto una descrizione di tale algoritmo ?

> 2) Non utilizza DUE chiavi pubbliche ma una soltanto ( Sh )

Sh non e' la chiave, nel tuo algoritmo, ma un parametro del sistema di
comunicazione. Sarebbe l'equivalente del primo generatore del campo su
cui esegui le operazioni di D-H, ma con la differenza che non ci hai
fatto vedere che diavolo di struttura numerica venga invece fuori dal
tuo "algoritmo".

La chiave pubblica nel tuo caso e', per ognuna delle due parti, il
prodotto tra chiave segreta (il numero scelto) e Sh.

> La dimostrazione sarà online (in anteprima mondiale) entro le ore
> 21.00 del 10 marzo 2007 al link

Le dimostrazioni si sottomettono a peer review, non si mettono in
anteprima mondiale: comunque non e' un problema, perche' quella non e'
una dimostrazione (hint: "per un'opportuna scelta dei parametri" -> non
e' una proprieta' numerica, a meno che tale opportuna scelta segua una
regola).

In ogni caso: il troncamento di per sé non e' una funzione one-way
trapdoor, a meno che tu non dimostri che per invertirla ti serve il
numero ORIGINALE e non ti basta quello troncato.

>> 4) la proprieta' per cui cambiando L'ORDINE il prodotto non cambia e' la
>> proprieta' commutativa, non associativa ;)
> 
> La proprietà commutativa non è mai stata citata nell'RFC e negli altri
> documenti.
> XEVRON si basa sulla proprietà associativa parziale, scoperta dagli
> autori e dimostrata nel documento di cui sopra.

No, si basa sulla proprieta' COMMUTATIVA

a * (b * c) = (a * b) * c -> associativa

a * b * c = c * a * b -> commutativa

Quella che voi descrivete e' una proprieta' commutativa, NON
associativa. Sono contento di aver contribuito alla correzione del piu'
secondario degli infiniti errori di quel documento.

>> 5) gli algoritmi in Europa ed in Italia non godono di protezione
>> brevettuale (in particolare un'applicazione della MOLTIPLICAZIONE...),
> 
> Gli algoritmi, non le procedure ;-)

Il codice della proprieta' intellettuale e' ancora piu' chiaro, se ti serve:
http://www.camera.it/parlam/leggi/deleghe/testi/05030dl.htm

Art. 45.
Oggetto del brevetto

1. Possono costituire oggetto di brevetto per invenzione le invenzioni
nuove che implicano un'attività inventiva e sono atte ad avere
un'applicazione industriale.

2. Non sono considerate come invenzioni ai sensi del comma 1 in particolare:
a) le scoperte, le teorie scientifiche e i metodi matematici;
b) i piani, i principi ed i metodi per attività intellettuali, per gioco
o per attività commerciale ed i programmi di elaboratore;
c) le presentazioni di informazioni.

"i metodi per attivita' intellettuali" includono gli algoritmi.

E' sempre stato cosi', eh:
Decreto 1127/1939, articolo 12, comma 2: "Non sono considerate come
invenzioni ai sensi del precedente comma in particolare: [...] b) i
piani, i principi ed i metodi per attività intellettuali, per gioco o
per attività commerciali e i programmi per elaboratori"

>> ne' tantomeno vi si possono imporre condizioni di licenza se non vengono
>> tutelati come segreto industriale.
> 
> E' una fortuna che l'ufficio brevetti non la pensi come Lei ;-)

Sapete come funziona un brevetto, si' ? Cioe' che la sua concessione e'
soggeta soltanto ad un esame formale, dopodiche' esso e' valido finche'
non viene contestato in tribunale ?

La concessione del brevetto non significa affatto che il brevetto sia
valido e approvato da chicchessia. E se qualcuno dovesse avere mai
voglia di implementare il vostro algoritmo sicuramente non avrebbe
problemi a farsene beffe :)

> In qualsiasi linguaggio di programmazione serio esiste la possibilità
> di generare numeri casuali mentre non riesco a trovare la possibilità
> di generare numeri SICURAMENTE primi di centinaia di cifre con la
> stessa velocità/semplicità.

Questo deriva dal fatto che:
a) non sai come funziona Diffie Hellman (quindi non sai che il numero
primo ti serve come generatore e non per generare le chiavi)
b) non sai che la generazione di una chiave privata-pubblica e' fatta
"semel in anno", non necessariamente all'inizio di ogni comunicazione
(anche perche' cio' sarebbe incompatibile con una PKI)
c) non sai che esistono (ovviamente) algoritmi efficienti per generare
numeri "probabilisticamente primi" con una elevata probabilita', che
rendono la generazione di chiavi basate su primi "relativamente lenti",
ma assolutamente accettabili per un'operazione (ripetiamolo) che non si
ripete frequentemente.

> La invito cortesemente a rileggere con più attenzione la
> documentazione fornita 

Fatto

> ed ad analizzare i software 

No need ;) Se l'idea e' buona, l'incarnazione nel software puo' solo
peggiorarla. In questo caso, non vedo come possa :)

-- 
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel.    +39 02 2399-4010/3660
Fax.    +39 02 2399-3411
E-mail: zanero@xxxxxxxxxxxxxx
Web:    www.elet.polimi.it/upload/zanero