Newsgroup: it.comp.sicurezza.crittografia
Titolo: XEVRON Password Maker. nuovi php

Come anticipato sono disponibili dei nuovi PHP che sistemano il bug 
trovato da Leonardo.
E' stata migliorata la gestione dei permessi nella scrittura del 
database.  Sostanzialmente XPM effettua 4 azioni ( Alice Start, Alice 
End, Bob Start, Bob End; gli acronimi sono ovviamente AS, AE, BS, BE )
Non è importante per quanto tempo i valori Sh, MidA e MidB rimangano 
memorizzati sul server posto che XEVRON è attualmente incraccabile. E' 
importante però evitare il MITM.
Se Alice manda il ticket a Bob via Email e questa email viene 
intercettata dalla NSA... Alice sta facendo uno scambio password non con 
Bob ma con la NSA con tutto quello che ne consegue.
Altra ipotesi di attacco potrebbe far si che l'NSA, sniffando il 
traffico di Bob ( immediatamente dopo l'azione BS), risponda prima di 
Bob. ( l'attacco trovato da Leonardo )
Ora come ora questo attacco è stato parzialmente risolto nel senso che 
il php controlla che le azioni BS e BE provengano dallo stesso IP 
(blanda protezione) e comunque Bob non può mai riutilizzare il ticket ( 
evitata anche la sovrascrittura di MidB)
Questo è probabilmente il massimo che si può fare in un sistema dove 
nessun utente di XPM si è registrato sul server e dove per l'appunto non 
esistono certificati digitali che affermano di star effettuando lo 
scambio proprio con lo stesso utente che ha mandato il ticket.
Una futura versione di XPM 2.0 potrebbe eventualmente colmare questa lacuna
Per i più paranoici attualmente consiglio di comunicare il ticket al 
telefono (riconoscendo la voce dell'interlocutore), o meglio via 
videoconferenza e chiedere all'interlocutore un paio di caratteri della 
password appena generata. ( su 32 caratteri se ne possono anche 
sacrificare un paio no ? :-)
In questo modo, il MITM verrebbe scoperto immediatamente poichè qualora 
ci fosse stato un attacco del genere le password di Alice e Bob non 
concorderebbero.
distinti saluti
D.Vantaggiato
www.XorLabs.net

 sacrificare un paio no ? :-)
Questo thread, nonostante possa, potenzialmente, rivelarsi solo un modo 
per farsi un po' di pubblicita', mi sembra cmq molto interessante. Erano 
eoni che non leggevo niente di cosi' interessante su questo gruppo, e mi 
riferisco specialmente alle critiche e le analisi volte a smontare 
questo nuovo sistema di generazione delle chiavi.
Pero' mi chiedo: se consigliate voi stessi di fare cmq la verifica dei 
dati per altro canale sicuro (se cioe' il mitm non e' evitabile neanche 
col vostro sistema, come invece si potrebbe fare con la crittografia 
quantistica), quale sarebbe il reale vantaggio del vostro metodo 
rispetto al sistema a chiavi pubbliche?
A me francamente sfugge, perche' se si tratta solo di non usare numeri 
primi, non mi pare molto vantaggioso.
-- 
BArrYZ

 questo nuovo sistema di generazione delle chiavi.
Quali analisi?
Non ho visto esperti di crittografia su questo ng, ad essere sincero...
Mi pare che questo ng sia frequentato più da utenti di software di 
crittografia che da ricercatori.
A questo punto chiedo su sci.crypt per vedere se il problema del 
troncamento è conosciuto e cosa ne pensano.
Kiuhnm

 primi, non mi pare molto vantaggioso.
1) I numeri primi sono sempre più rari con il crescere delle grandezze. 
XEVRON è invece scalabile all'infinito.
2) Attualmente praticamente tutta la crittografia a chiave pubblica si 
basa sui numeri primi e sulla difficoltà di fattorizzarli velocemente. 
Avere una alternativa può sempre fare comodo no ?
3) la generazione dei numeri primi è una operazione abbastanza 
complessa. il mio pc monoprocessore da 3ghz ha impiegato 60 secondi per 
generare le chiavi pubbliche e private del PGP. Una volta generate 
queste chiavi le devo usare per più volte. Con XEVRON posso generare dei 
numeri casuali anche su un cellulare in una frazione di secondo... e 
posso permettermi il lusso di cambiare le chiavi anche ogni minuto. Chi 
ha craccato la tua chiave pgp invece continua a decifrare tutte le tue 
comunicazioni....
4) l'aumento della base numerica permette in XEVRON di aumentare la 
complessità quasi senza minimamente influire sulla potenza di calcolo !!!
Incollo un esempio appena generato con le seguenti grandezze random:
-------------------------------------
LidA= 760
LidB= 280
LSh= 1243
LSecA= 2182
LSecB= 2062
L1= 127
R1= 94
L2= 40
R2= 60
base= 90
Ticks impiegati 43 pari a 0,7166667 secondi
--------------------------------------
con gli stessi parametri ma in base 10 ecco il tempo necessario:
Ticks impiegati 42 pari a 0,7 secondi
eppure tra il cracking di una chiave di 644 cifre in base 10 e una di 
644 in base 90 c'è una differenza mostruosa.
Questi giochini non sono possibili con l'attuale crittografia a chiave 
pubblica.
Meno potenza di calcolo necessaria significa che i server che 
attualmente creano connessioni SSL e sono limitati (per esempio ) a 5000 
utenti, potrebbero con la stessa CPU gestirne invece 10.000 (esempi 
ipotetici).
Meno potenza di calcolo significa che un cellulare potrebbe scambiare 
una chiave XEVRON-T3 in circa 1-2 secondi ( uno scambio T3 necessita 
complessivamente dell'invio di appena 414 byte)  e poi cifrare tutta la 
telefonata con una chiave "a perdere", che viene distrutta alla fine 
della telefonata e non memorizzata da nessuna parte. ( un esempio più 
concreto)
La distruzione delle chiavi segrete immediatamente dopo l'uso è una 
innovazione da non sottovalutare. Se il tuo computer viene rubato e 
dentro hai la tua chiave pgp segreta.....
Se invece la chiave la crei al momento e la distruggi subito dopo....
Distinti Saluti
D.Vantaggiato
www.XorLabs.net

 Kiuhnm
Posteremo ufficialmente su sci.crypt nella prossima settimana, stiamo 
ultimando le traduzioni.
Nonostante la grande curiosità all'interno di XorLabs e di tutti i 
nostri amici e consulenti riteniamo che potrebbe sembrare scortese un 
debutto su sci.crypt senza una adeguata documentazione in inglese.
E' anche vero d'altra parte che i sorgenti dei software sono tutto 
sommato "universali" e che forse come "preview" basterebbe una sua 
sintetica spiegazione.
Nel caso decida di postare a titolo personale può dire tranquillamente 
che nella prossima settimana avremo delle traduzioni ufficiali della 
documentazione.
Distinti Saluti
D.Vantaggiato
www.XorLabs.net

[MEGACUT]
Provo ad ipotizzare uno scenario senza certificati e senza
intercettazioni su canale insicuro sfruttando proprio la sicurezza
data da xevron. (da premettere leggendo velocemente la cosa sembra
interessante ed offre tanti spunti, pian pianino me lo studio) ..
1. Alice genera una sua chiave con il server XEVRON
2. Bob genera una sua chiave con il server XEVRON
3. Alice scambia la sua chiave che deve inviare a Bob con il server
XEVRON usando la chiave generata precedentemente.
4. Bob scambia la sua chiave che deve inviare ad Alice con il server
XEVRON usando la chiave generata precedentemente.
5. Il server XEVRON usando la chiave generata con Alice invia la
chiave di Bob ad Alice
6. Il server XEVRON usando la chiave generata con Bob invia la chiave
di Alice a Bob
Visto che il tutto si pone sulla sicurezza di Xevron perchè allora non
usare questo procedimento. una sorta di challenge usando solo ed
esclusivamente Xevron.
In questo modo anche se viene intercettata l'informazione tra Alice e
Xevron (Bob e Xevron) prima e tra Alice e Bob dopo sarà sempre
criptata e non sarà possibile risalirne alla fonte.
Logicamente se la sicurezza di Xevron è messa in discussione o
cracckata il tutto non funziona più ..
--
[CapoBecchino]
msn: capobecchino |[@]| hotmail |[.]| com
SEZIONE DIVERTIMENTO & AFFINI: "Qual è il poliziotto più sfortunato?
Quello che muore al posto di blocco. E quello più fortunato? Blocco!"

 interessante ed offre tanti spunti, pian pianino me lo studio) ..
Guardate che questo XEVRON, non è altro che un algoritmo di crittazione 
a chiave pubblica. Se anche si dimostrasse sicuro non darà nuove 
possibilità rispetto a RSA.
In particolareUtilizzare un server centralizzatato per gestire le chiavi 
di crittazione è un nonsenso perchè aggiunge un anello molto debole alla 
catena. Ogni utente deve avere il suo programma per generare la chiave 
privata, per gestire le chiavi e per crittare i messaggi. La chiave 
pubblica può essere (come dice il nome) resa pubblica ed inserita in 
appositi key-servers. E' ovvio pero' che se trovo una chiave pubblica 
che si dichiara essere di Mario Rossi, io non ho nessuna garanzia che lo 
sia veramente. Per avere questa garanzia io devo andare di persona da 
Mario Rossi, e farmi dare la fingerprint della sua chiave pubblica 
insieme ad un suo documento di identità. Questo garantisce che quella 
chiave pubblica è veramente associata a Mario Rossi.
Se non posso contattare direttamente Mario Rossi lo posso fare 
indirettamente tramite una persona fidata che faccia da intermediario. 
Questa persona firma la chiave pubblica di Mario Rossi garantendo che 
per lui quella chiave è autentica (perché lui l'ha verificata 
direttamente o indirettamente). Nella misura in cui io mi fido 
dell'intermediario posso dunque fidarmi dell'autenticità della chiave di 
Mario Rossi.
Tutto questo sistema viene gestito da apposito software, che permette di 
assegnare ad ogni chiave pubblica un livello di confidenza, a seconda 
che io l'abbia verificata direttamente o indirettamente. Mettendo queste 
informazioni sui key-server pubblici è possibile formare automaticamente 
delle catene di autenticazione tra una persona e un'altra.
Si noti che in questo modo non c'é il problema di doversi fidare del 
key-server in quanto esso gestisce solamente informazioni pubbliche.
E.

 cracckata il tutto non funziona più ..
Ovviamente... vedremo nei prossimi giorni su sci.crypt cosa accadrà ;-)
saluti
D.Vantaggiato
www.XorLabs.net

 pace dell'attaccante.
Rendere una chiave pubblica (o, similarmente, un certificato) valida per
sempre è proprio la prima cosa da non fare.
Insomma, un certificato deve prima o poi scadere ed essere rinnovato per
non avere sempre lo stesso keystream da cui attingere per cifrare i
messaggi.
-- 
Ciao.
Leo.
Web: 
www.leonardomiliani.com
E-mail: 
leon...@leonardomiliani.com
Scegli software opensource - Choose opensource software

 
Beh... per SEMPRE era riferito all'estrema volatilità delle chiavi 
generate con XEVRON.
ripeto comunque che le specifiche sono ancora in fase di elaborazione e 
stiamo vagliando diverse ipotesi. Per il momento preferiamo concentrarci 
sulla verifica dell'affidabilità di XEVRON pubblicando le specifiche in 
inglese prima possibile.
saluti
D.Vantaggiato
www.XorLabs.net