著者: vecna [ml] 日付: To: hackmeeting 題目: Re: [Hackmeeting]
Just Crypt It – How To Send A File Securely Without Additional Software
2013/10/1 boyska <piuttosto@???>
> Mentre mettendolo dentro una webmail la
> fase del keysigining party diventi magicamente piu' facile e ci si senta
> meno ridicoli a dettare fingerprint? E la distinzione tra trust e
> validity diventa finalmente chiara, se i pulsanti sono belli tondi e
> pacioccosi?
> Ah, com'e' intuitivo il perche' ci sia bisogno di verificare
> continuamente il security token [1].
>
> mancare ripetutamente il punto non e' cattiva mira, e' mirare altrove.
> E sono sempre piu' convinto che chi parla di usabilita' e pensa alle
> interfaccine non vuole divulgare sicurezza, vuole inventare mercati su
> cui fare business.
>
Umh secondo me i tuoi accorgimenti sono corretti, ma per te e per la
community di tecnici della quale fai parte. Per un utente ignaro, non è
importante cosa succeda sotto. e secondo me, se ci fosse un meccanismo
vagamente sicuro per fare key sharing, attaccabile pure, e questo sistema
fosse diffuso in tutti i browser delle future generazioni di utenti, e le
chiavi avessero pure del random debole e i browser degli exploit di valore > 1k < 10k... beh, sarebbe un gran successo.
Perché si sarebbe resa la compromissione di un'email o l'acquisizione di
una mailbox, un operazione realizzabile solo con attacchi targettizzati.
Dove devo firmare perché avvenga ?
L'alternativa attuale è che la vita di una persona sta in chiaro, vincolata
a leggi di un altro stato, e il tuo stato non ti protegge quando vieni
considerato "sospetto fino a prova contraria".
Se gli elementi di insicurezza che vengono portati a sfavore della
crittografia massiva sono solo attacchi targeted, allora sta cosa *serve un
sacco*, perché riesce ad inficiare una tecnica offensiva applicata in modo
generalizzato.
Poi mi dici che davanti agli attacchi targeted questo non basta ? ok,
allora se uno pensa di doversi proteggere da quello, farà riflessioni sulla
security, studierà o pagherà o whatever, ma il 99% degli utenti non si
porrà mai il problema, non sarà mai vittima di un attacco targeted, e si
sarà tolto il problema della collezione massiva di dati, anche se non sel'è
mai posto. cryptography4themasses IMHO è questo. (non è "operational
security 4 the masses", quello non lo voglio neppure immaginare :) )
Non è di certo l'unica soluzione a questo problema, ma come scalabilità e
maturità delle tecnologie, è la prima che puo' diventare realistica.
Fabio Pietgrosanti (naif) wrote:
> Aimè progetti come LEAP o Mailpile.is ritengo non siano future-proof e
> che per questo motivo siano broken-by-design (non dal punto di vista
> della sicurezza, ma della scalabilità e reale opportunità di diffusione
> futura).
>
Secondo me hai frainteso su alcuni aspetti di LEAP, perché rimane una
soluzione validissima, semplicemente deve essere gestita da
un'organizzazione (il gruppo di amici, la scuola, la PMI, il comitato
cittadino, la classe dei nati 1975) che mette alcune macchine a
disposizione e fornisce il supporto iniziale di installazione. Tra i loro
fanno colletta, e si ripagano le macchine.
La loro forza si basa su queste "invisible key" che vengino gestite da un
server imap che gira in locale. Non è diverso dall'avere un servizio sul
proprio desktop o sul proprio client mobile. Poi il client di posta gli va
in localhost.
Il modello di security è semplicemente più intricato (e quindi meno
criticabile) delle semplificazioni che mailvelope puo' dare ad OpenPGP, ma
alla fine l'obiettivo non è "rendere l'utente invulnerabile" ma sempre
"rendere le masse meno attaccabili in modo seriale".
Per intenderci, se il mercato dei trojan è florido, è perché la
crittografia funziona. Dire "abbandoniamo la crittografia, tanto ci sono i
trojan" è una riflessione che fa il disfattista, ma se si vede la cosa in
prospettiva, è un grande passo avanti.
