Scusa il top quote e il resend della mail. Ma 1) ti farebbe scaricare il
javascript che gira in locale. La chiave non lascia mai il tuo pc. La
crittografia avviene a casa tua, non vedo differenza tra 1 2 o 3.
Anzii,
Mentre 2 e 3 ti fidi di debian o apple. Della 1 magari ti fidi di
autistici. No?
On Friday, December 6, 2013, Joe wrote:
> Ciao a tutti,
>
> dato che mi pare ci sia un po' di confusione sul tema, mi sembra il caso
> di chiarire qualche concetto. Ovviamente qui c'e' gente che di
> crittografia sa piu' di me e che correggera' eventuali errori/omissioni.
>
> I modelli che nel tumultuoso thread precedente abbiamo confrontato come
> metodi di fruizione della crittografia E2E sono i seguenti:
>
> - Una applicazione standalone da scaricare ed installare
> - Un'estensione di un browser opportunamente sandboxed
> - Una web application che funzioni sul browser "liscio".
>
>
> Iniziamo dalle basi: quando parliamo di crittografia "end to end"
> intendiamo che le comunicazioni tra due utenti, Alice e Bob, sono
> cifrate alla sorgente da Alice e sono solo decrittabili da Bob.
>
> Un classico esempio di tale sistema crittografico e' GPG: Alice cifra il
> messaggio alla sorgente con la chiave GPG di Bob, e il messaggio lo puo'
> leggere solo Bob. O, piu' precisamente, solo qualcuno che sia in
> possesso della chiave privata di Bob.
>
> Vediamo come questa applicazione si puo' gestire nei tre casi:
>
> - BROWSER "LISCIO": Alice apre la sua fichissima
> webapp-con-supporto-a-gpg e cifra il suo messaggio con la chiave
> pubblica di Bob. Bob apre a sua vota la suddetta webapp e legge il
> messaggio usando la sua chiave privata. Per fare quello, la chiave
> privata deve essere letta dal motore javascript del browser, utilizzando
> uno script javascript opportunamente gestito dal server. Peccato che la
> sicurezza della chiave privata di Bob dipenda *integralmente* dal fatto
> che il gestore del server sia affidabile e che il server in questione
> non sia bucato ad *OGNI* richiesta. Se non e' cosi', infatti, il
> javascript di cui sopra potrebbe tranquillamente succhiarsi la chiave
> privata di Bob, gia' decifrata dalla sua passphrase, e rubarla. Insomma
> esattamente l'opposto dello scopo della crittografia e2e: il server deve
> essere integro per garantire la cifratura delle comunicazioni.
>
> - ESTENSIONE DEL BROWSER: Sia Alice che Bob scaricano un'estensione del
> browser tramite il chrome store. Dopo di che tutto avviene *quasi* come
> nel caso precedente, a parte il fatto che la componente javascript sta
> dentro l'estensione e non e' possibile per il contesto d'esecuzione del
> javascript della pagina web accedere alla chiave privata. Percio' in
> questo caso ci dobbiamo solo fidare di Google (o qualsivoglia altro app
> store) e di chi ci fornisce la connettivita' verso di esso) quando
> scarichiamo l'estensione.
>
> - APPLICAZIONE "TRADIZIONALE": In questo caso Alice e Bob si devono
> fidare del sistema di distribuzione del software in questione scelto dal
> fornitore (ad es, le firme gpg dei pacchetti debian).
>
>
> Spero che sia un po' piu' chiaro a tutti qual'e' la criticita' piu' o
> meno insormontabile del primo scenario. E perche' comunque ritengo
> preferibile affidarmi a debian che a google o a apple :)
>
> Da questa discussione ho volutamente lasciato fuori il problema
> interessante e difficile, ovvero come rendere facile e insieme
> affidabile la parte complessa della crittografia E2E: la certificazione
> dell'identita' del proprio interlocutore. Questo problema e' stato
> brillantemente risolto in LEAP con la creazione del nymserver, non sono
> certo che sarebbe possibile interagire correttamente con esso
> all'interno di una estensione del browser, ma non ho mai affrontato la
> questione sul serio.
>
> Integrazioni / correzioni sono sempre benvenute.
> Ciao
>
> Joe
> _______________________________________________
> Hackmeeting mailing list
> Hackmeeting@??? <javascript:;>
> https://www.autistici.org/mailman/listinfo/hackmeeting
>
--
Pierluigi Maori
aka Robert J. Newmark
aka newmark
aka gniu
aka gnumark
