Re: [Hackmeeting] javascript e facilit? = felicit?

Delete this message

Reply to this message
Autor: brno
Data:  
Para: vecnamcclaudio
CC: hackmeeting
Assunto: Re: [Hackmeeting] javascript e facilit? = felicit?
anyway http://blog.cryptographyengineering.com/2014/07/noodling-about-im-protocols.html

Il 28/lug/2014 14:40 =?UTF-8?B?yaPEmcaIxp7EhQ==?= <vecnamcclaudio@???> ha scritto:
>
> 2014-07-28 12:47 GMT+02:00 bolo <bolo@???>:
>
> > Come faceva notare boyska, lo scambio della chiave e' alla base della
> > crittografia classica e moderna.
> >
> >
> diciamo che quello che serve è "garantire che una chiave/ID sia
> effettivamente della persona che dice di essere". che non è diverso dal
> affidarsi ad un hidden service, o ad un certificato SSL se non è firmato da
> una certification authority. Questa garanzia avviene con una verifica out
> of band (OOB), cioè non fatta nello stesso canale dello scambio di chiavi
> (verifichi il fingerprint, importi la chiave).
>
> Per risolvere questo problema, quindi identificare l'umano dall'altra
> parte, che sia davvero l'umano che dice di essere, c'è il SMP
> http://en.wikipedia.org/wiki/Socialist_millionaire che non può funzionare
> con i servizi, ma solo con gli esseri umani che probabilemtne hai già
> conosciuto (vagamente simile al concetto di ZRTP key verification: se
> conosci la voce dell'altro, le due paroline derivate dalla chiave DH
> negoziata, sono le stesse)
>
> la verifica OOB, che si è sempre detta "non devi assolutamente farla sullo
> stesso canale in cui transita la chiave", invece con meccanismi come
> keybase.io hai una ragionevole certezza che, solo se l'attaccante ha
> compromesso *tutto*, ma proprio *tutto*, sta dando una chiave differente a
> te per trarti in inganno.
>
> ... Probabilmente questa condizione ricade sulla vignetta di XKCD dei 5
> dollari di chiave inglese vs RSA 4096.
>
>
> il MITM, l'attacco per cui le verifiche si fanno OOB, è un problema che
> comunque non si è "risolto". e se si propone un meccanismo alla mailpile
> (X-PGP-Fingerprint) poi si deve avere un qualche algoritmo che validi il
> web of trust, altrimenti l'attaccante non fa altro che simulare un
> aggiornamento della chiave (update che certamente vuoi gestire, perché le
> chiavi non sono eterne, scadono e vengono compromesse)
>
> sarca, non c'è ancora una soluzione definitiva, ma una buona logica
> (applicabile anche ad enigmail) è qui:
> https://micahflee.com/2013/12/how-i-want-mailpile-to-handle-openpgp/
>
>
>
>
> --
> This account is intended for mailing list only. Personal email via:
> vecna at globaleaks dot org
> _______________________________________________
> Hackmeeting mailing list
> Hackmeeting@???
> https://www.autistici.org/mailman/listinfo/hackmeeting