Re: [Hackmeeting] safegmail (pgp)

Delete this message

Reply to this message
Autore: vecna [ml]
Data:  
To: hackmeeting
Oggetto: Re: [Hackmeeting] safegmail (pgp)
2012/10/9 Robert J. Newmark <newmark@???>


> Mi chiedo perche' non si possa fare un servizio https di generazione di
> numeri random, con entropia forte, e con un js che fa riechieste https,
> passa un seed (che quindi e' personale del browser) e restituisce numeri
> random di un certo valore.
> Non credo sia difficile ne da implementare come servizio, ne tantomeno
> da implementare in safegmail o chicchessia.
>
> no?
>
> potrebbe esssere un bel servizio da esporre alla comunita'
>


mmmhh.... si, c'è qualcosa di simile, direi che come design non riceverebbe
un'approvazione scientifica, perché:

1) ti sai fidando di una terza parte, che puo' essere compromessa, per un
elemento vitale di sicurezza. Questo è proprio quel che si è evitato con il
principio di Kierkoff (probabilmente non si scrive così, whatever), per cui
l'algoritmo deve essere pubblico e sicuro, e solo la chiave segreta.

2) la terza parte sarebbe attaccabile anche in modo passivo, ad esempio,
facendo richieste in enorme quantità e "svuotandola d'entropia"

3) avresti un single point of failure per le applicazioni che vi si
affidano,amenoché non offrendo il servizio su hidden service Tor (in quel
caso o ti affideresti ad una terza parte fidata, come tor2web, o avresti
Tor sul client, e allora cade l'utilità di avere tutta la crypto in un
browser)

cmq, dell'analisi precedente, voglio ritrattare l'ultima riga. bocciare un
software solo perché non puo' garantire un alto livello di protezione, è il
comportamento da cryptonerd che devo tenere solo quando scelgo i miei
strumenti. Ma se safegmail puo' essere un modo comodo, per dare uno
strumento di protezione agli utenti (che altrimenti non avrebbero
alternativa, se non quella di usare gmail in chiaro), allora BEN VENGA.

anche se è insicuro. intanto,... è abbastanza sicuro da proteggere da
attacchi massivi. Poi co un attaccante motivato quest'ultimo potrà
sproteggerti, ma questo problema se lo pone, chi valuta un modello di
rischio tale... mentre essere protetti da attacchi massivi è qualcosa che
dovrebbe essere nell'interesse di tutti gli utenti.

per questo livello di protezione, anche avere il random collezionato dalla
propria navigazione, dal proprio javascript, storato nel password chain e
riesumato/refreshato come un random seed ogni volta che serve... sarebbe
piu' che sufficente.

E sarebbe meglio di quell'accrocco usato anni fa da firefox, che lanciava
"ps ax" e "netstat -na" per prendesi quell'output come seed :P


--
This account is intended for mailing list only. Personal email via:
vecna at globaleaks dot org