On 5/9/23 14:55, 380° wrote:
Ciao Davide,
Ciao 380°,
"D. Davide Lamanna" <davide.lamanna@binarioetico.it> writes:
On 5/9/23 10:12, Giacomo Tesio wrote: [...]
Purtroppo rimangono innumerevoli dati personali contenuti in quelli impropriamente detti "metadati".
Pensa ad esempio agli header SMTP delle email, agli header HTTP inviati dalle richieste web etc... Agli IP senza i quali Internet non funziona
Non è possibile criptare i destinatari di una email. O l'ora in cui è inviata.
Negli ultimi anni si sono fatti passi avanti importanti nel campo dell'Homomorphic Encryption [1]. AFAIU quella fa la crittazione dei dati, non dei metadati, sbaglio?
Puoi cifrare quel che vuoi, dati, metadati, non ci sono limiti. Perché dovrebbero esserci del resto? Il problema semmai è far funzionare gli handshake protocollari con questo tipo di cifratura. Negli esempi che ho riportato, il routing, ad esempio, tratta decisamente dati nel dominio dei "cosiddetti" metadati (per dirla con Giacomo :-)).
BTW:
--8<---------------cut here---------------start------------->8---
Homomorphic encryption is a form of encryption that allows computations to be performed on encrypted data without first having to decrypt it.
--8<---------------cut here---------------end--------------->8---
Domanda: ma è proprio necessario consentire che i dati siano oggetto di computazione "nel cloud" (cioè sul computer di qualcun altro)?
No, non è necessario. E' solo una possibilità in più che la HE potrebbe rendere possibile: usare Public Cloud senza essere visti dai proprietari. Io mi sono appassionato alla materia nell'ambito del mio dottorato di ricerca. Posto che sono comunque un promotore di Private Cloud.
Io in alternativa ho una modesta proposta: crittografia dei dati nello storage (remoto o locale), computazione dei dati nella CPU locale... intanto che aspettiamo la Homomorphic Encryption :-D
Questa è sempre la strada maestra. :-)
Si possono implementare Mail Server che offrono persino funzioni di ricerca con HE [2], Che non riusciranno _mai_ a battere le performance di ricerca locale, ad esempio usando xapian [1] per le email via notmuch [2] o per i documenti via Recoll [3]
Poco ma sicuro. Senza contare che la cifratura omomorfica dà luogo a overhead prestazionali mastodontici rispetto alla cifratura standard.
In merito allo storage crittografato sul mail server, segnalo Technology for Resting Email Encrypted Storage (TREES) [4]
...nel frattempo, però, i contenuti delle email, se non crittografati, viaggiano "in chiaro", per non parlare dei metadati.
filtri anti-spam omomorfici [3] già, lo SPAM... quello meriterebbe un capitolo a parte, mi viene una tristezza infinita quando penso ai cicli macchina sprecati per calcolare i punteggi di "spammosità" di un messaggio
...e comunque perché funzionino servono i metadati in chiaro, o no?
Dipende da come implementi i protocolli. La HE ti dà la possibilità di fare operazioni su dati cifrati il cui risultato è il cifrato del risultato che avresti avuto eseguendo quelle stesse operazioni sul dato in chiaro. Teoricamente ci puoi fare quello che vuoi.
e sono stati studiati sistemi HE per il routing anonimo [4] non conoscevo, grazie! (studierò con calma)
stando al paragrafo "5.5.3 State of Progress" nel 2013 non esisteva ancora un'implementazione: sbaglio?
Penso di no. Quando me ne occupavo io (2011/2012) non mi risulta ci fosse.
Ad oggi ci sono implementazioni del protocollo APART (Anonymous Proactive Ad hoc RouTing)?
Non saprei. Penso che si tratti comunque ancora di sperimentazione.
nel frattempo, GNUnet (compreso il routing anonimo) è un'implementazione di questo paper del 2014 [5]
(l'applicazione Signal ne usa uno per impedire la disclosure del mittente a livello di router). Non sapevo di questa cosa: hai dettagli per favore?
Ti riferisci forse alla funzione "sealed sender" introdotta nel 2018? Perché se così fosse, faccio umilmente notare che:
--8<---------------cut here---------------start------------->8---
Even under the sealed sender, observers said, Signal will continue to map senders' IP addresses. That information, combined with recipient IDs and message times, means that Signal continues to leave a wake of potentially sensitive metadata.
--8<---------------cut here---------------end--------------->8--- (via https://urlsand.esvalabs.com/?u=https%3A%2F%2Farstechnica.com%2Finformation-... )
e
--8<---------------cut here---------------start------------->8---
A contemporaneous wiretap of the user's device and/or the Signal servers may still reveal that the device's IP address accessed a Signal server to send or receive messages at certain times.
--8<---------------cut here---------------end--------------->8--- (via https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSign... )
Sì, mi riferisco a quella e sì, conosco i passaggi che hai riportato. Rimane interessante, a mio avviso, che Signal abbia introdotto la tecnologia in produzione, nei suoi sforzi di essere Privacy preserving. Nota che non sono un grandissimo fan di Signal. Anzi, nutro una certa antipatia per Moxie Marlinspike, fondatore di Signal, dopo che nel 2016 è uscita fuori questa cosa [1] a seguito di un suo intervento al Chaos Computer Club in cui difendeva i sistemi centralizzati contro quelli federati.
immagina chi fa wiretapping, puoi :-)
mi spiace ma non c'è proprio nessuno scampo a quanto faccia tecnicamente schifo Internet
Mi sa che hai ragione. Ogni tentativo di spingere all'estremo l'anonimato in rete va comunque apprezzato, secondo me.
Io me ne sono occupato ormai più di 10 anni fa [6], quando il tema era fantascientifico, ma stando a [5], l'adozione commerciale potrebbe non essere troppo lontana. OK, ma anche una volta che la Homomorphic Encryption sarà commercialmente adottata, i metadati che fine fanno?
Eh... In teoria dovrebbero morire gonfi tutti quelli che hanno lucrato sul Capitalismo della Sorveglianza. In pratica non lo so. D. [1] https://signal.org/blog/the-ecosystem-is-moving/ (null)