On 5/9/23 14:55, 380° wrote:
Ciao Davide,
Ciao 380°,
"D. Davide Lamanna" <[email protected]> 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-technology%2F2018%2F10%2Fnew-signal-privacy-feature-removes-sender-id-from-metadata%2F&e=566de099&h=2b9c5c50&f=y&p=n
)
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%2FSignal_Protocol%23Metadata&e=566de099&h=76bf72a0&f=y&p=n
)
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)
_______________________________________________
nexa mailing list
[email protected]
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
