Paris Marx, "Don't listen to the 'godfather of AI'"
*Don't listen to the 'godfather of AI'** */Geoffrey Hinton is using fantasies to distract us from the real harms of AI// / Paris Marx May 5, 2023 The media’s been captivated this week by the story of Geoffrey Hinton, the supposed “godfather of AI” who left Google to speak more freely about the supposed threat he sees artificial intelligence posing to humanity — and which he ultimately helped to advance. You can see why it’s such an attractive story, but the focus on Hinton and his framing of the problems with AI continues to distract us from the real conversations we should be having that aren’t focused on some imagined future, but on the harms these technologies are causing in the present. For Hinton, the threat of AI is a future problem. It’s not about how AI will increase the power of employers over employees <https://www.businessinsider.com/chatgpt-ai-will-not-take-jobs-create-future-...>, how it will be wielded <https://www.theguardian.com/australia-news/2023/mar/11/robodebt-five-years-of-lies-mistakes-and-failures-that-caused-a-18bn-scandal>against <https://www.theguardian.com/technology/2020/feb/05/welfare-surveillance-system-violates-human-rights-dutch-court-rules>marginalized <https://www.cbc.ca/news/politics/human-rights-ai-visa-1.4838778>communities <https://www.theguardian.com/inequality/2017/aug/08/rise-of-the-racist-robots...>, its potential environmental <https://www.wired.com/story/the-generative-ai-search-race-has-a-dirty-secret/>impacts <https://www.washingtonpost.com/climate-environment/2023/04/25/data-centers-d...>, and other serious concerns that will affect a lot of people outside the circles of wealthy technologists and executives. Instead, Hinton’s focus is on the fantasy that AI is on the cusp of becoming more intelligent than humans, and will then have the capacity to trick and manipulate us into doing its bidding. [...] continua qui: https://www.disconnect.blog/p/dont-listen-to-the-godfather-of-ai
Ciao, mi sono imbattuto in questo articolo del New Yorker che, secondo me, meriterebbe di essere copi-incollato tutto;non necessariamente perché sia d'accordo con tutto quello che dice, ma perché è sicuramente thought provoking (il titolo nella subject line è mio, quello del pezzo è leggermente diverso). Qualche estratto: "Just to be clear, when I refer to capitalism, I’m not talking about the exchange of goods or services for prices determined by a market, which is a property of many economic systems. When I refer to capitalism, I’m talking about a specific relationship between capital and labor, in which private individuals who have money are able to profit off the effort of others. So, in the context of this discussion, whenever I criticize capitalism, I’m not criticizing the idea of selling things; I’m criticizing the idea that people who have lots of money get to wield power over people who actually work. And, more specifically, I’m criticizing the ever-growing concentration of wealth among an ever-smaller number of people, which may or may not be an intrinsic property of capitalism but which absolutely characterizes capitalism as it is practiced today. As it is currently deployed, A.I. often amounts to an effort to analyze a task that human beings perform and figure out a way to replace the human being. Coincidentally, this is exactly the type of problem that management wants solved. As a result, A.I. assists capital at the expense of labor. There isn’t really anything like a labor-consulting firm that furthers the interests of workers. Is it possible for A.I. to take on that role? Can A.I. do anything to assist workers instead of management? Some might say that it’s not the job of A.I. to oppose capitalism. That may be true, but it’s not the job of A.I. to strengthen capitalism, either. Yet that is what it currently does. If we cannot come up with ways for A.I. to reduce the concentration of wealth, then I’d say it’s hard to argue that A.I. is a neutral technology, let alone a beneficial one." -------- "By building A.I. to do jobs previously performed by people, A.I. researchers are increasing the concentration of wealth to such extreme levels that the only way to avoid societal collapse is for the government to step in. Intentionally or not, this is very similar to voting for Trump with the goal of bringing about a better world. And the rise of Trump illustrates the risks of pursuing accelerationism as a strategy: things can get very bad, and stay very bad for a long time, before they get better. In fact, you have no idea of how long it will take for things to get better; all you can be sure of is that there will be significant pain and suffering in the short and medium term.I’m not very convinced by claims that A.I. poses a danger to humanity because it might develop goals of its own and prevent us from turning it off. However, I do think that A.I. is dangerous inasmuch as it increases the power of capitalism. The doomsday scenario is not a manufacturing A.I. transforming the entire planet into paper clips, as one famous thought experiment has imagined. It’s A.I.-supercharged corporations destroying the environment and the working class in their pursuit of shareholder value. Capitalism is the machine that will do whatever it takes to prevent us from turning it off, and the most successful weapon in its arsenal has been its campaign to prevent us from considering any alternatives.People who criticize new technologies are sometimes called Luddites, but it’s helpful to clarify what the Luddites actually wanted. The main thing they were protesting was the fact that their wages were falling at the same time that factory owners’ profits were increasing, along with food prices. They were also protesting unsafe working conditions, the use of child labor, and the sale of shoddy goods that discredited the entire textile industry. The Luddites did not indiscriminately destroy machines; if a machine’s owner paid his workers well, they left it alone. The Luddites were not anti-technology; what they wanted was economic justice. They destroyed machinery as a way to get factory owners’ attention. The fact that the word “Luddite” is now used as an insult, a way of calling someone irrational and ignorant, is a result of a smear campaign by the forces of capital.Whenever anyone accuses anyone else of being a Luddite, it’s worth asking, is the person being accused actually against technology? Or are they in favor of economic justice? And is the person making the accusation actually in favor of improving people’s lives? Or are they just trying to increase the private accumulation of capital?" https://www.newyorker.com/science/annals-of-artificial-intelligence/will-ai-... Ciao, Federico
grazie! jc (messaggio spedito in movimento - scusate brevità ed eventuali refusi)
Il giorno 6 mag 2023, alle ore 10:35, Federico Guerrini via nexa <nexa@server-nexa.polito.it> ha scritto:
Ciao, mi sono imbattuto in questo articolo del New Yorker che, secondo me, meriterebbe di essere copi-incollato tutto; non necessariamente perché sia d'accordo con tutto quello che dice, ma perché è sicuramente thought provoking (il titolo nella subject line è mio, quello del pezzo è leggermente diverso).
Qualche estratto:
"Just to be clear, when I refer to capitalism, I’m not talking about the exchange of goods or services for prices determined by a market, which is a property of many economic systems. When I refer to capitalism, I’m talking about a specific relationship between capital and labor, in which private individuals who have money are able to profit off the effort of others. So, in the context of this discussion, whenever I criticize capitalism, I’m not criticizing the idea of selling things; I’m criticizing the idea that people who have lots of money get to wield power over people who actually work. And, more specifically, I’m criticizing the ever-growing concentration of wealth among an ever-smaller number of people, which may or may not be an intrinsic property of capitalism but which absolutely characterizes capitalism as it is practiced today. As it is currently deployed, A.I. often amounts to an effort to analyze a task that human beings perform and figure out a way to replace the human being. Coincidentally, this is exactly the type of problem that management wants solved. As a result, A.I. assists capital at the expense of labor. There isn’t really anything like a labor-consulting firm that furthers the interests of workers. Is it possible for A.I. to take on that role? Can A.I. do anything to assist workers instead of management?
Some might say that it’s not the job of A.I. to oppose capitalism. That may be true, but it’s not the job of A.I. to strengthen capitalism, either. Yet that is what it currently does. If we cannot come up with ways for A.I. to reduce the concentration of wealth, then I’d say it’s hard to argue that A.I. is a neutral technology, let alone a beneficial one."
--------
"By building A.I. to do jobs previously performed by people, A.I. researchers are increasing the concentration of wealth to such extreme levels that the only way to avoid societal collapse is for the government to step in. Intentionally or not, this is very similar to voting for Trump with the goal of bringing about a better world. And the rise of Trump illustrates the risks of pursuing accelerationism as a strategy: things can get very bad, and stay very bad for a long time, before they get better. In fact, you have no idea of how long it will take for things to get better; all you can be sure of is that there will be significant pain and suffering in the short and medium term. I’m not very convinced by claims that A.I. poses a danger to humanity because it might develop goals of its own and prevent us from turning it off. However, I do think that A.I. is dangerous inasmuch as it increases the power of capitalism. The doomsday scenario is not a manufacturing A.I. transforming the entire planet into paper clips, as one famous thought experiment has imagined. It’s A.I.-supercharged corporations destroying the environment and the working class in their pursuit of shareholder value. Capitalism is the machine that will do whatever it takes to prevent us from turning it off, and the most successful weapon in its arsenal has been its campaign to prevent us from considering any alternatives. People who criticize new technologies are sometimes called Luddites, but it’s helpful to clarify what the Luddites actually wanted. The main thing they were protesting was the fact that their wages were falling at the same time that factory owners’ profits were increasing, along with food prices. They were also protesting unsafe working conditions, the use of child labor, and the sale of shoddy goods that discredited the entire textile industry. The Luddites did not indiscriminately destroy machines; if a machine’s owner paid his workers well, they left it alone. The Luddites were not anti-technology; what they wanted was economic justice. They destroyed machinery as a way to get factory owners’ attention. The fact that the word “Luddite” is now used as an insult, a way of calling someone irrational and ignorant, is a result of a smear campaign by the forces of capital. Whenever anyone accuses anyone else of being a Luddite, it’s worth asking, is the person being accused actually against technology? Or are they in favor of economic justice? And is the person making the accusation actually in favor of improving people’s lives? Or are they just trying to increase the private accumulation of capital?"
https://www.newyorker.com/science/annals-of-artificial-intelligence/will-ai-...
Ciao,
Federico
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Personalmente concordo con gran parte di questa analisi, ma colgo un difetto di fondo. Continua a considerare il problema in termini esclusivamente economici, noveventeschi. Si tratta di una cornice interpretativa gravemente insufficiente ad affrontare il cambio di paradigma in corso. (non a caso, non è quella usata internamente dalle BigTech) Non si tratta più solo di equità nella distribuzione dei profitti (tant'è che molti miliardari dell'ITC si dicono favorevoli ad ull'Universal Basic Income). Si tratta di Potere Cibernetico. Si tratta di poter imporre la propria volontà a individui, gruppi e persino nazioni intere. Vi propongo un esperimento mentale: vi offro letteralmente qualsiasi cifra possiate desiderare in cambio di poter decidere tutto ciò che da lì in poi farete o direte. Accettate? È quasi quello che stanno facendo le BigTech ma con una differenza: i servizi ad alto valore (economico) aggiunto che forniscono sottocosto (spesso gratis) in cambio di poter decidere (probabilisticamente) cosa facciamo, sono al contempo le catene con cui ci vincolano. Mai nella storia umana gli schiavi erano stati contenti di indossare le catene. Ma le catene sono sempre state gratis, per gli schiavi. Giacomo Il 6 Maggio 2023 08:28:13 UTC, Federico Guerrini via nexa <nexa@server-nexa.polito.it> ha scritto:
Ciao, mi sono imbattuto in questo articolo del New Yorker che, secondo me, meriterebbe di essere copi-incollato tutto;non necessariamente perché sia d'accordo con tutto quello che dice, ma perché è sicuramente thought provoking (il titolo nella subject line è mio, quello del pezzo è leggermente diverso).
Qualche estratto: "Just to be clear, when I refer to capitalism, I’m not talking about the exchange of goods or services for prices determined by a market, which is a property of many economic systems. When I refer to capitalism, I’m talking about a specific relationship between capital and labor, in which private individuals who have money are able to profit off the effort of others. So, in the context of this discussion, whenever I criticize capitalism, I’m not criticizing the idea of selling things; I’m criticizing the idea that people who have lots of money get to wield power over people who actually work. And, more specifically, I’m criticizing the ever-growing concentration of wealth among an ever-smaller number of people, which may or may not be an intrinsic property of capitalism but which absolutely characterizes capitalism as it is practiced today. As it is currently deployed, A.I. often amounts to an effort to analyze a task that human beings perform and figure out a way to replace the human being. Coincidentally, this is exactly the type of problem that management wants solved. As a result, A.I. assists capital at the expense of labor. There isn’t really anything like a labor-consulting firm that furthers the interests of workers. Is it possible for A.I. to take on that role? Can A.I. do anything to assist workers instead of management?
Some might say that it’s not the job of A.I. to oppose capitalism. That may be true, but it’s not the job of A.I. to strengthen capitalism, either. Yet that is what it currently does. If we cannot come up with ways for A.I. to reduce the concentration of wealth, then I’d say it’s hard to argue that A.I. is a neutral technology, let alone a beneficial one." -------- "By building A.I. to do jobs previously performed by people, A.I. researchers are increasing the concentration of wealth to such extreme levels that the only way to avoid societal collapse is for the government to step in. Intentionally or not, this is very similar to voting for Trump with the goal of bringing about a better world. And the rise of Trump illustrates the risks of pursuing accelerationism as a strategy: things can get very bad, and stay very bad for a long time, before they get better. In fact, you have no idea of how long it will take for things to get better; all you can be sure of is that there will be significant pain and suffering in the short and medium term.I’m not very convinced by claims that A.I. poses a danger to humanity because it might develop goals of its own and prevent us from turning it off. However, I do think that A.I. is dangerous inasmuch as it increases the power of capitalism. The doomsday scenario is not a manufacturing A.I. transforming the entire planet into paper clips, as one famous thought experiment has imagined. It’s A.I.-supercharged corporations destroying the environment and the working class in their pursuit of shareholder value. Capitalism is the machine that will do whatever it takes to prevent us from turning it off, and the most successful weapon in its arsenal has been its campaign to prevent us from considering any alternatives.People who criticize new technologies are sometimes called Luddites, but it’s helpful to clarify what the Luddites actually wanted. The main thing they were protesting was the fact that their wages were falling at the same time that factory owners’ profits were increasing, along with food prices. They were also protesting unsafe working conditions, the use of child labor, and the sale of shoddy goods that discredited the entire textile industry. The Luddites did not indiscriminately destroy machines; if a machine’s owner paid his workers well, they left it alone. The Luddites were not anti-technology; what they wanted was economic justice. They destroyed machinery as a way to get factory owners’ attention. The fact that the word “Luddite” is now used as an insult, a way of calling someone irrational and ignorant, is a result of a smear campaign by the forces of capital.Whenever anyone accuses anyone else of being a Luddite, it’s worth asking, is the person being accused actually against technology? Or are they in favor of economic justice? And is the person making the accusation actually in favor of improving people’s lives? Or are they just trying to increase the private accumulation of capital?" https://www.newyorker.com/science/annals-of-artificial-intelligence/will-ai-... Ciao, Federico
Si tratta di Potere Cibernetico. Si tratta di poter imporre la propria volontà a individui, gruppi e persino nazioni intere.
Se parli di un futuro, più o meno lontano, ti posso dare ragione. Oggi credo non sia così. Oggi a condizionare fortemente la volontà delle persone è un potere mediatico (controllato da quello finanziario) estremamente potente come mai nella storia. Nel passato abbiamo avuto la stampa, il cinema, la radio, la televisione, ieri Internet, oggi TUTTO insieme nelle mani di pochissime persone. L'Italia è al 41esimo posto e gli Stati Uniti al 45esimo nel global score della libertà di stampa [1]. I social sono stati (uso il passato perché anche loro stanno cambiando) un mezzo potentissimo in mano a quei gruppi. Anche per l'intelligenza artificiale sarà la stessa cosa. Chi avrà soldi da investire per imporre, per ora direi condizionare fortemente, la volontà, lo farà, senza tante remore. Nei sogni utopistici di (noi) pionieri, Internet doveva essere la risposta popolare, della cittadinanza attiva, allo strapotere del potere mediatico dell'epoca. Un mezzo di comunicazione (quasi) gratuito, un mezzo di espressione (quasi) gratuito, cosa chiedere di più. E' avvenuto esattamente l'opposto. Ad imporre, se non la volontà, i temi, la scaletta, i contenuti è ancora e più di ieri, la televisione. Il 90/95% delle persone ha come fonte primaria di informazione la televisione. Ieri l'ho accesa per pochi minuti, una volta di mattina, l'altra di sera, ironia della sorte, in entrambi i momenti c'era un arcivescovo che incoronava un re ed una regina ... Ho spento. In macchina ho acceso la radio, sintonizzata su una emittente locale. Poche frasi mi hanno ricondotto alla dura e triste realtà. "Mi pagano tre euro l'ora e devo lavorare 12 ore al giorno per mantenere me e mia figlia". Per un attimo ho avuto l'impressione di essere nel 1823 e non nel 2023. Una buona domenica, Antonio [1] https://rsf.org/en/index?year=2023
Ciao Antonio, Il 7 Maggio 2023 08:25:30 UTC, Antonio <antonio@piumarossa.it> ha scritto:
Si tratta di Potere Cibernetico. Si tratta di poter imporre la propria volontà a individui, gruppi e persino nazioni intere.
Se parli di un futuro, più o meno lontano, ti posso dare ragione. Oggi credo non sia così.
Vorrei tanto che tu avessi ragione. Ma decine di risposte che ho letto alla nostra richiesta alle PA di interrompere i trasferimenti sistematici di dati personali (spesso sensibilissimi) verso aziende USA dimostrano il contrario. Decine di ospedali e ASL informano Google o Microsoft di ogni patologia che abbiate, oncologica, psichiatrica... tutto! E questo perché utilizzano i loro servizi cloud. Migliaia di scuole permettono ANCORA OGGI a Google e Microsoft di realizzare profili dettagliatissimi di ogni informazione ricevuta a scuola da milioni di studenti e ogni lacuna, opinione o fragilità espressa. Ogni certificato medico inviato alla segreteria, ogni risposta ad un form Google, ogni materiale didattico scaricatobda Drive. E sai cosa ti rispondono? "Non esistono alternative e il Ministero dice vhe loro dicono di essere GDPR compliant" Nom tutti ovviamente: molte scuole li stanno dismettendo, ma molte altre continuano a dire che non ci sono alternative. E qualcuna (anche Università! Che VERGOGNA!), quando gli segnaliamo il seminario organizzato dall'Intendenza Scolastica di Bolzano dove se ne mostrano alcune [1], ci ha persino risposto spiegandoci che le alternative devono essere identiche a quelle di Google, gratuite e non richiedere competenze tecniche all'ateneo. Tutto firmato o sottoscritto da Data PROTECTION Officer. Giacomo
Decine di ospedali e ASL informano Google o Microsoft di ogni patologia che abbiate, oncologica, psichiatrica... tutto! E questo perché utilizzano i loro servizi cloud.
Caro Giacomo, sono perfettamente consapevole dell'attuale trasferimento, direi, senza timore di esagerare, epocale, di dati della pubblica amministrazione italiana verso datacenter situati al di fuori del territorio nazionale. Agli ospedali, alle scuole, alle università sono da aggiunguere (come segnalato in lista da Antonio N. qualche giorno fa), tutti gli enti "gestiti" da Sogei (v. appalto in corso di svolgimento [1]). Quello che denunciavo io è che di questi temi, nei "media", se ne parla poco e male (alla gente piace la "favola" dei re e delle regine, mica queste cose difficili, complesse). Come giustamente segnalavi tu, la risposta classica di chi sta trasferendo i dati è: "Non esistono alternative e il Ministero dice che loro dicono di essere GDPR compliant". In pratica chiedono all'oste se il vino è buono. Il cloud, in definitiva, è come le cassette di sicurezza delle banche, sulle quali, dalle lex horreorum, in poi, c'è una legislazione infinita. Ma i dati non sono denari o gioielli. Uno spazio riservato su un cloud è come una cassetta di sicurezza trasparente. Sicura e presidiata sì ma, appunto, trasparente. I politici tacciono, al più ti possono rispondere: "ne siamo coscienti e stiamo lavorando al cloud nazionale, è solo questione di tempo e i dati "ritorneranno" in Italia). Nel frattempo che si fa? Beh, si potrebbe, tornando all'analogia con le cassette di sicurezza, mettere una cassettina con il lucchetto dentro. Quindi criptare i dati in partenza ... A. [1] https://www.consip.it/bandi-di-gara/gare-e-avvisi/as-sdapa-ea-microsoft-per-...
On Mon, May 08, 2023 at 09:45:34AM +0200, Antonio wrote:
Il cloud, in definitiva, è come le cassette di sicurezza delle banche, sulle quali, dalle lex horreorum, in poi, c'è una legislazione infinita. Ma i dati non sono denari o gioielli. Uno spazio riservato su un cloud è come una cassetta di sicurezza trasparente. Sicura e presidiata sì ma, appunto, trasparente.
Non è una buona metafora, perché la copia dei dati non lascia traccia. Non è semplicemente trasparente: puoi tirar fuori infinite copie del contenuto della "cassetta" e usarli a tuo piacimento senza che nessuno se ne possa accorgere. Per questo nessuna legislazione progettata senza una profonda comprensione dell'informatica e del FUNZIONAMENTO dei sistemi di cui parliamo può proteggere davvero quei dati.
I politici tacciono, al più ti possono rispondere: "ne siamo coscienti e stiamo lavorando al cloud nazionale, è solo questione di tempo e i dati "ritorneranno" in Italia). Nel frattempo che si fa?
La Rivoluzione? :-D In fondo, se la Legge non è ugiale per tutti, se le BigTech, i Dirigenti Scolastici, i Dirigenti Ospedalieri etc.. possono violarla impunemente... Se la Legge non conta più niente, cosa ci rimane?
Beh, si potrebbe, tornando all'analogia con le cassette di sicurezza, mettere una cassettina con il lucchetto dentro. Quindi criptare i dati in partenza ...
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... Non è possibile criptare i destinatari di una email. O l'ora in cui è inviata. Giacomo
On 5/9/23 10:12, Giacomo Tesio wrote: [...]
Beh, si potrebbe, tornando all'analogia con le cassette di sicurezza, mettere una cassettina con il lucchetto dentro. Quindi criptare i dati in partenza ... 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...
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]. Si possono implementare Mail Server che offrono persino funzioni di ricerca con HE [2], filtri anti-spam omomorfici [3] e sono stati studiati sistemi HE per il routing anonimo [4] (l'applicazione Signal ne usa uno per impedire la disclosure del mittente a livello di router). 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. D. [1] = https://en.wikipedia.org/wiki/Homomorphic_encryption [2] = https://thesai.org/Downloads/Volume9No3/Paper_16-Secure_and_Privacy_Preservi... [3] = https://www.sciencedirect.com/science/article/pii/S0140366422004261 [4] = https://dumas.ccsd.cnrs.fr/dumas-00854815/document [5] = https://queue.acm.org/detail.cfm?id=3561800 [6] = https://link.springer.com/chapter/10.1007/978-3-642-33615-7_ (null)
Ciao Davide, "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? 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)? 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
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] 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?
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? Ad oggi ci sono implementazioni del protocollo APART (Anonymous Proactive Ad hoc RouTing)? 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://arstechnica.com/information-technology/2018/10/new-signal-privacy-fe...) 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://en.wikipedia.org/wiki/Signal_Protocol#Metadata) immagina chi fa wiretapping, puoi :-) mi spiace ma non c'è proprio nessuno scampo a quanto faccia tecnicamente schifo Internet
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? Grazie! 380°
[1] = https://en.wikipedia.org/wiki/Homomorphic_encryption
[2] = https://thesai.org/Downloads/Volume9No3/Paper_16-Secure_and_Privacy_Preservi...
[3] = https://www.sciencedirect.com/science/article/pii/S0140366422004261
[4] = https://dumas.ccsd.cnrs.fr/dumas-00854815/document
[5] = https://queue.acm.org/detail.cfm?id=3561800
[6] = https://link.springer.com/chapter/10.1007/978-3-642-33615-7_
[1] https://xapian.org/ [2] https://notmuchmail.org/ [3] https://www.lesbonscomptes.com/recoll/pages/index-recoll.html [4] https://0xacab.org/liberate/trees [5] https://www.w3.org/2014/strint/papers/65.pdf The Internet is Broken: Idealistic Ideas for Building a GNU Network -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
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)
Ciao Davide, "D. Davide Lamanna" <davide.lamanna@binarioetico.it> writes: [...]
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.
OK ho capito grazie, quindi sostanzialmente occorrerebbe riscrivere il protocollo IP (o SMTP, DNS, ecc.) affiché sia in grado di usare la HE (che come dici tu ha un grosso overhead) Se non mi sfugge qualcosa, dal punto di vista architetturale preferisco l'approccio usato da GNUnet (cover traffic) [1], che funziona (anche) /sopra/ al protocollo IP così com'è (può essere pensata come una specie di overlay net) [...]
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.
scusa se puntualizzo ma tecnicamente si tratta di usare la CPU (computazione) in una Public Cloud senza che input e output siano "interpretabili" dai proprietari ...e però dal punto di vista sistemistico avendo accesso all'hardware si possono fare così Tante Cose™ che dubito seriamente che un proprietario sufficientemente motivato non sia in grado di leggere i bit in chiaro.
Io mi sono appassionato alla materia nell'ambito del mio dottorato di ricerca. Posto che sono comunque un promotore di Private Cloud.
Campo nel quale la _motivata_ fiducia è fondamentale
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.
e anche più sicura [...]
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.
è questo che a mio avviso la rende inadatta allo scopo: già /rifare/ i protocolli di rete usando la cifratura standard comporta un calo di "prestazioni", non credo sia il caso di appesantire ulteriormente [...]
...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.
OK chiaro, ciò significa quello che abbiamo detto sopra: comunque i protocolli di comunicazione andrebbero rifatti e in questo caso si possono ottenere ottimi risultati evitando l'overhead della HE [...]
Ad oggi ci sono implementazioni del protocollo APART (Anonymous Proactive Ad hoc RouTing)?
Non saprei. Penso che si tratti comunque ancora di sperimentazione.
Grazie, io ho fatto alcune ricerche sul web ma mi pare che questi strumenti siano rimasti a livello (sub)prototipale [...]
(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:
[...]
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.
Sì giusto, si tratta solo di capire fino a che livello sono in grado di preservare la privacy: loro (Signal) e alcune potentissime agenzie senza dubbio hanno tutti i metadati _e_ fanno analisi del traffico di quel protocollo. [...]
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.
Sì sì, assolutamente sì. Solo che io sono _estremamente_ triste nell'osservare che le poche risorse che si dedicano a questo compito si disperdono in progetti... poco coerenti con lo status quo [...] Grazie, 380° [1] https://docs.gnunet.org/about.html#anonymity -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Ciao Davide e 380, On Wed, May 10, 2023 at 02:20:48PM +0200, 380° wrote:
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.
scusa se puntualizzo ma tecnicamente si tratta di usare la CPU (computazione) in una Public Cloud senza che input e output siano "interpretabili" dai proprietari
...e però dal punto di vista sistemistico avendo accesso all'hardware si possono fare così Tante Cose™ che dubito seriamente che un proprietario sufficientemente motivato non sia in grado di leggere i bit in chiaro.
banalmente, la Homomorphic Encryption temo resterà sempre fortemente vulnerabile a timing attack. Un ipotetico fornitore cloud che abbia accesso alla chiave PUBBLICA di cifratura (NB: non quella privata, basta quella pubblica) può cifrare una elaborazione arbitraria e applicarla ai dati cifrati ottenendo un risultato anch'esso cifrato. Il bello della FHE è che tale avversario non può decifrare il risultato senza la chiave privata. Tuttavia, nulla gli impedisce di cifrare un elaborazione che è estremamente lenta se il primo bit del testo cifrato è 1 ed estremamente veloce se è 0. Applicando tale elaborazione cifrata e misurando i tempi di risposta può dedurre il valore del primo bit del testo in chiaro. Ho un vaghissimo ricordo di una tecnica simile presentata l'anno scorso ma non ritrovo l'articolo accademico che ne parlava. Giacomo
On Wed, May 10, 2023 at 04:56:19PM +0200, Giacomo Tesio wrote:
Ho un vaghissimo ricordo di una tecnica simile presentata l'anno scorso ma non ritrovo l'articolo accademico che ne parlava.
era questo: https://eprint.iacr.org/2022/204.pdf (ovviamente non potevo che trovarlo DOPO aver risposto... scusate) Giacomo
On 5/10/23 16:56, Giacomo Tesio wrote:
Ciao Davide e 380,
On Wed, May 10, 2023 at 02:20:48PM +0200, 380° wrote:
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. scusa se puntualizzo ma tecnicamente si tratta di usare la CPU (computazione) in una Public Cloud senza che input e output siano "interpretabili" dai proprietari
...e però dal punto di vista sistemistico avendo accesso all'hardware si possono fare così Tante Cose™ che dubito seriamente che un proprietario sufficientemente motivato non sia in grado di leggere i bit in chiaro.
Grazie mille, Giacomo, dell'articolo che hai inviato. Trovo stupefacente e mi fa davvero piacere, che in Nexa si arrivi a livelli così alti di analisi in ambiti di ricerca super-specialistici. Rispondo ai tuoi punti.
banalmente, la Homomorphic Encryption temo resterà sempre fortemente vulnerabile a timing attack.
Attenzione! L'articolo parla di una specifica software library, molto diffusa in HE, ma certamente non l'unica. Altri importanti librerie sono ad esempio: HElib PALISADE TFHE HEAAN ma ne esistono moltissime altre. Inoltre i ricercatori che hanno scoperto la vulnerabilità di cui si parla nell'articolo, hanno lavorato su versioni di Microsoft SEAL inferiori alla 3.6, dopo la quale è stato introdotto un diverso protocollo di campionatura. Tutto questo per dire che gli studi di crittografia in generale, e in particolare quelli di crittografia omomorfica, che rappresenta una specializzazione completamente a sé, hanno una lunghissima storia e una notevole vitalità. Di HE si è parlato moltissimo dopo che Craig Gentry, uno studente di dottorato della Duke University, è riuscito, nel 2009, ad ideare per primo nella storia uno schema di Fully Homomorphic Encryption. Ma di HE i matematici (molto più che gli informatici) si occupano da ben prima, sicuramente dagli anni '80, e continuano a farlo, come dimostra questo e numerosissimi altri articoli, che mettono alla prova i sistemi ideati da loro colleghi. Questo succede anche nella crittografia di uso comune, ma non è sufficiente per dire che la crittografia resterà _sempre_ vulnerabile a questo o quell'attacco. E' un processo continuo di verifiche, di rotture di protocolli, di schemi, di sistemi, volto a migliore continuamente l'applicabilità della cifratura. L'HE è solo più indietro degli altri tipi di cifratura, perché è notovolmente più complessa. Ma la comunità è molto più che vitale, ci sono migliaia di articoli che escono ogni anno.
Un ipotetico fornitore cloud che abbia accesso alla chiave PUBBLICA di cifratura (NB: non quella privata, basta quella pubblica) può cifrare una elaborazione arbitraria e applicarla ai dati cifrati ottenendo un risultato anch'esso cifrato.
Questo però lo puoi fare anche con la cifratura di uso comune.
Il bello della FHE è che tale avversario non può decifrare il risultato senza la chiave privata.
Anche questo è vero per qualunque meccanismo di cifratura.
Tuttavia, nulla gli impedisce di cifrare un elaborazione che è estremamente lenta se il primo bit del testo cifrato è 1 ed estremamente veloce se è 0.
Applicando tale elaborazione cifrata e misurando i tempi di risposta può dedurre il valore del primo bit del testo in chiaro.
E' questo il punto importante in cui si evidenzia la particolare vulnerabilità. Non possiamo però estenderla alla HE tout court. La HE è molto di più di Microsoft SEAL.
Ho un vaghissimo ricordo di una tecnica simile presentata l'anno scorso ma non ritrovo l'articolo accademico che ne parlava.
Grazie ancora per l'articolo e per lo scambio. D. (null)
On Thu, May 11, 2023 at 09:45:37AM +0200, D. Davide Lamanna wrote:
banalmente, la Homomorphic Encryption temo resterà sempre fortemente vulnerabile a timing attack.
Attenzione! L'articolo parla di una specifica software library, molto diffusa in HE, ma certamente non l'unica.
L'articolo è solo un esempio della classe di vulnerabilità che ho descritto, basato sul controllo dell'elaborazione effettuata sui dati cifrati anche in assenza della possibilità di decifrare il risultato di tale elaborazione. Ovviamente, se chi effettua l'elaborazione non ha accesso alla chiave pubblica (oltre che alla chiave privata) il problema non si pone. Tuttavia tale strategia pone un problema di protezione della chiave "pubblica" che va comunque condivisa con chi è autorizzato a trattare i dati cifrati (ovvero a stabilire quali elaborazione è possibile fare). Il che rende la crittografia omomorfica qualcosa di intermedio fra la crittografia simmetrica e quella asimmetrica. Ma fintanto che chi esegue l'elaborazione cifrata può anche cifrare un'elaborazione di propria scelta, dubito che si possa aggirare il tipo di timing attack che descrivevo.
Di HE si è parlato moltissimo dopo che Craig Gentry, uno studente di dottorato della Duke University, è riuscito, nel 2009, ad ideare per primo nella storia uno schema di Fully Homomorphic Encryption.
L'idea di cifrare l'algoritmo di decifratura per ottenere una versione (sempre cifrata) del plain text con un rumore ridotto è stata GENIALE. Comunque, personalmente, sono interessato anzitutto alla FHE.
L'HE è solo più indietro degli altri tipi di cifratura, perché è notovolmente più complessa. Ma la comunità è molto più che vitale, ci sono migliaia di articoli che escono ogni anno.
Vero, ma non tratterrei il respiro in attesa di una sua applicazione su vasta scala.
Un ipotetico fornitore cloud che abbia accesso alla chiave PUBBLICA di cifratura (NB: non quella privata, basta quella pubblica) può cifrare una elaborazione arbitraria e applicarla ai dati cifrati ottenendo un risultato anch'esso cifrato.
Questo però lo puoi fare anche con la cifratura di uso comune.
Uhm... irrilevante. Con la cifratura non omomorfica, l'unico modo che hai per effettuare un'elaborazione sul dato cifrato è decifrarlo prima. A quel punto hai accesso al dato in chiaro e, oltre a ciò che devi, ci puòi fare quel che vuoi impunemente (perché la copia dei dati non lascia tracce). Insomma, con la crittografia di uso comune l'attacco che descrivevo è inutile (se hai accesso alle chiavi di cifratura) o impossibile (se non hai accesso a tali chiavi).
Il bello della FHE è che tale avversario non può decifrare il risultato senza la chiave privata.
Anche questo è vero per qualunque meccanismo di cifratura.
Non sono stato chiaro: la FHE ti permette di cifrare un programma ed applicarlo ad un dato cifrato ottenendo un output cifrato senza che in alcun passaggio la CPU abbia accesso al dato in chiaro. Questo con la crittografia non-FHE è impossibile: 1. per usare un dato come input di un programma devi prima decriptarlo. 2. l'output che ottieni dal programma è in chiaro e se vuoi cifrarlo con un'algoritmo di cifratura asimmetrico, devi cifrarlo successivamente solo a quel punto, se non hai tenuto copie dei dati in chiaro non hai più accesso all'output se non hai la chiave privata. Poter effettuare l'elaborazione in modo completamente cifrato è ciò che caratterizza la FHE. Il problema è che i timing attack che ho descritto ne vanificano il selling point.
Tuttavia, nulla gli impedisce di cifrare un elaborazione che è estremamente lenta se il primo bit del testo cifrato è 1 ed estremamente veloce se è 0.
Applicando tale elaborazione cifrata e misurando i tempi di risposta può dedurre il valore del primo bit del testo in chiaro.
E' questo il punto importante in cui si evidenzia la particolare vulnerabilità. Non possiamo però estenderla alla HE tout court. La HE è molto di più di Microsoft SEAL.
Naturalmente. Ma l'articolo è (IMHO) solo un caso specifico di un problema strutturale. Un problema non invalicabile (trattando la chiave pubblica come chiave "riservata", ma distinta dalla chiave privata che deve rimanere _segreta_) ma comunque da non ignorare. Anche perché, se lo ignoriamo, non passerà troppo tempo prima che le BigTech usingo la FHE per buttare un po' di fumo negli occhi di utenti e policy maker, dichiarando di non poter accedere ai dati ricevuti mentre potranno farlo tranquillamente.
Ho un vaghissimo ricordo di una tecnica simile presentata l'anno scorso ma non ritrovo l'articolo accademico che ne parlava.
Grazie ancora per l'articolo e per lo scambio.
Grazie a te! Spero solo che non siamo stati troppo "opachi" per chi non conosce il tema. Giacomo
On 5/11/23 11:30, Giacomo Tesio wrote:
On Thu, May 11, 2023 at 09:45:37AM +0200, D. Davide Lamanna wrote:
banalmente, la Homomorphic Encryption temo resterà sempre fortemente vulnerabile a timing attack. Attenzione! L'articolo parla di una specifica software library, molto diffusa in HE, ma certamente non l'unica. L'articolo è solo un esempio della classe di vulnerabilità che ho descritto, basato sul controllo dell'elaborazione effettuata sui dati cifrati anche in assenza della possibilità di decifrare il risultato di tale elaborazione.
E' un esempio ed è l'unico. Almeno per ora. Il successo di questo tipo di attacchi dipende dalle proprietà di "Semantically security" dei criptosystem. Possiamo vederla come una difficoltà in più per i crittografi del mondo HE.
Ovviamente, se chi effettua l'elaborazione non ha accesso alla chiave pubblica (oltre che alla chiave privata) il problema non si pone.
Tuttavia tale strategia pone un problema di protezione della chiave "pubblica" che va comunque condivisa con chi è autorizzato a trattare i dati cifrati (ovvero a stabilire quali elaborazione è possibile fare).
Il che rende la crittografia omomorfica qualcosa di intermedio fra la crittografia simmetrica e quella asimmetrica.
Non la gestirei comunque così. Significherebbe rendere del tutto vani gli sforzi dell'HE. Se poi addirittura non dessi la chiave pubblica al gestore del server, allora non potrei eseguire funzioni che non siano definite a priori lato server. Anche in questo caso, troppo limitante.
Ma fintanto che chi esegue l'elaborazione cifrata può anche cifrare un'elaborazione di propria scelta, dubito che si possa aggirare il tipo di timing attack che descrivevo.
Certo che si può. E' sufficiente che il sistema di cifratura stesso non sia prono a questo tipo di attacchi, ossia che non sia possibile ottenere informazioni statisticamente certe o probabili da applicazioni di funzioni arbitrarie. Come del resto si sono dimostrati, almeno per ora, tutti i criptosystem in uso, tranne Microsoft SEAL. [...]
Tuttavia, nulla gli impedisce di cifrare un elaborazione che è estremamente lenta se il primo bit del testo cifrato è 1 ed estremamente veloce se è 0.
Applicando tale elaborazione cifrata e misurando i tempi di risposta può dedurre il valore del primo bit del testo in chiaro. E' questo il punto importante in cui si evidenzia la particolare vulnerabilità. Non possiamo però estenderla alla HE tout court. La HE è molto di più di Microsoft SEAL. Naturalmente.
Ma l'articolo è (IMHO) solo un caso specifico di un problema strutturale.
Dipende cosa intendi con problema. Se intendi una cosa che si può affrontare, allora la ricerca può andare avanti, come in effetti sta andando avanti e pure in ottima salute. Se invece intendi che non si può affrontare, allora chiunque si stia occupando di HE sta semplicemente perdendo tempo. Solo che in quest'ultimo caso la comunità potrebbe richiederti di sostanziare le tue affermazioni scrivendo un paper e facendotelo revisionare dagli addetti ai lavori. Se decidi di farlo, sarei felice di collaborare con te.
Un problema non invalicabile (trattando la chiave pubblica come chiave "riservata", ma distinta dalla chiave privata che deve rimanere _segreta_) ma comunque da non ignorare.
Come già detto, direi proprio che non è il caso.
Anche perché, se lo ignoriamo, non passerà troppo tempo prima che le BigTech usingo la FHE per buttare un po' di fumo negli occhi di utenti e policy maker, dichiarando di non poter accedere ai dati ricevuti mentre potranno farlo tranquillamente.
Certo. Siamo qui per questo.
Ho un vaghissimo ricordo di una tecnica simile presentata l'anno scorso ma non ritrovo l'articolo accademico che ne parlava. Grazie ancora per l'articolo e per lo scambio. Grazie a te!
Spero solo che non siamo stati troppo "opachi" per chi non conosce il tema.
Abbstanza, direi... :-D Possiamo continuare anche off-line, io penso che sia fondamentale. D. (null)
On 5/10/23 14:20, 380° wrote:
Ciao Davide,
"D. Davide Lamanna"<davide.lamanna@binarioetico.it> writes:
[...]
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. OK ho capito grazie, quindi sostanzialmente occorrerebbe riscrivere il protocollo IP (o SMTP, DNS, ecc.) affiché sia in grado di usare la HE (che come dici tu ha un grosso overhead)
Se non mi sfugge qualcosa, dal punto di vista architetturale preferisco l'approccio usato da GNUnet (cover traffic) [1], che funziona (anche) /sopra/ al protocollo IP così com'è (può essere pensata come una specie di overlay net)
[...]
GNUNet è sicuramente più dritto allo scopo di anonimato in rete, e di conseguenza più efficace (ed efficiente) per questo specifico scopo. Lo scopo dell'Homomorphic Encryption è più ampio e generale e numerosissimi sono gli ambiti applicativi. In definitiva, si tratta di sommare numeri cifrati ottenendo il cifrato della somma (che poi non è direttamente la somma algebrica, ma non disperdiamoci in dettagli). I ricercatori poi applicano questa proprietà matematica a molte diverse cose, tra cui il routing anonimo, ma non solo. Hanno trovato, ad esempio, che sia ottimale per le applicazioni che utilizzano database in cui alcuni specifici valori devono restare illegibili (memorizzati cifrati ed operati sempre in cifrato). Le applicazioni pensabili sono sconfinate, la ricerca deve fare il suo corso. [...]
No, non è necessario. E' solo una possibilità in più che la HE potrebbe rendere possibile: usare Public Cloud senza essere visti dai proprietari. scusa se puntualizzo ma tecnicamente si tratta di usare la CPU (computazione) in una Public Cloud senza che input e output siano "interpretabili" dai proprietari
Esattamente.
...e però dal punto di vista sistemistico avendo accesso all'hardware si possono fare così Tante Cose™ che dubito seriamente che un proprietario sufficientemente motivato non sia in grado di leggere i bit in chiaro.
Per intenderci: nella ALU entrano numeri cifrati ed escono numeri cifrati. Se vuoi leggere bit in chiaro, devi rompere il protocollo di cifratura. Come nell'articolo che ha posta Giacomo e che riguarda lo schema di cifratura "Microsoft SEAL" (rispondo anche a quella email a parte) [...]
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. Sì sì, assolutamente sì.
Solo che io sono _estremamente_ triste nell'osservare che le poche risorse che si dedicano a questo compito si disperdono in progetti... poco coerenti con lo status quo
[...]
Mettiamola così: è la libertà della ricerca. Ognuno scommette su qualcosa. Il campo di applicazione dell'HE è vastissimo. Se qualcuno si vuole cimentare con il routing anonimo, ben venga. Magari fatti 100 i risultati della sua ricerca, ce ne sarà 1 che servirà a GNUNet. O forse neanche 1, ma saranno state comunque formate persone su ambiti e approcci verticalissimi che aprono a nuovi sviluppi, sempre con l'etica della riservatezza al centro. D. (null)
Purtroppo rimangono innumerevoli dati personali contenuti in quelli impropriamente detti "metadati".
L'ottimo è nemico del bene. E' vero, gli indirizzi IP devono essere in "chiaro", così come i destinatari delle mail, ma questo riguarda solo uno dei tanti "servizi" internet. Prendiamo il caso, invece, di una amministrazione/ente/azienda di medie/grandi dimensioni che usa il "cloud" di una bigtech. Alla bigtech, come "dato personale" contenuto nell'header HTTP(S), non arriva nulla, solo l'IP e la porta TCP del proxy/gateway/firewall. Quindi la bigtech si ritrova miliardi di pacchettini, a tutte le ore, provenienti da un unico indirizzo IP. Ora, un conto è che dentro quei pacchettini ci sia l'anamnesi di un paziente, scritta in italiano o qualsiasi altra lingua traducibile, un conto è che ci sia: "SJdKJDg7E-MK2..." che solo l'autore possa decifrare. A.
Il 9 Maggio 2023 17:56:06 UTC, Antonio <antonio@piumarossa.it> ha scritto: .
Prendiamo il caso, invece, di una amministrazione/ente/azienda di medie/grandi dimensioni che usa il "cloud" di una bigtech. Alla bigtech, come "dato personale" contenuto nell'header HTTP(S), non arriva nulla, solo l'IP e la porta TCP del proxy/gateway/firewall. Quindi la bigtech si ritrova miliardi di pacchettini, a tutte le ore, provenienti da un unico indirizzo IP. Ora, un conto è che dentro quei pacchettini ci sia l'anamnesi di un paziente, scritta in italiano o qualsiasi altra lingua traducibile, un conto è che ci sia: "SJdKJDg7E-MK2..." che solo l'autore possa decifrare.
Certo, ma se la tua ipotetica PA usa il cloud solo come storage cifrato, le offerte delle BigTech diventano estremamente costose. Tanto da essere ingiustificabili. Infatti le PA non si limitano a caricare dati cifrati ma utilizzano innumerevoli servizi che trasferiscono molti più dati personali identificabili anche quando sono usati esclusivamente dalla rete interna alla PA (cosa piuttosto rara, pensa alle scuole). Però sì: se usati solo come storage cifrato esclusivamente da rete aziendale e tramite utenze pseudonimiche, i servizi cloud dei GAFAM sono solo cari, ma non violano il GDPR. (forse però la PA che li adotta continua a violare il CAD) Giacomo
participants (7)
-
380° -
Antonio -
D. Davide Lamanna -
Federico Guerrini -
Giacomo Tesio -
J.C. DE MARTIN -
J.C. DE MARTIN