@geesk.bsky.social
Ho appena scoperto con piacere che proprio Arke è stato menzionato in un commento alla RFC:
github.com/bluesky-soci...
github.com/bluesky-soci...
December 21, 2025 at 3:30 PM
Ho appena scoperto con piacere che proprio Arke è stato menzionato in un commento alla RFC:
github.com/bluesky-soci...
github.com/bluesky-soci...
I vari link che ho mandato si riferiscono tutti a protocolli diversi: il paper del 2024 parla di "Arke", che sviluppa un'idea da un paper del 2020 che parla di "UDM"; Signal ha usato gli HSM.
Mi sembra che BS migliori su Signal e UDM, ma possa fare di più con gli HSM. Non so dire su Arke
Mi sembra che BS migliori su Signal e UDM, ma possa fare di più con gli HSM. Non so dire su Arke
December 21, 2025 at 3:24 PM
I vari link che ho mandato si riferiscono tutti a protocolli diversi: il paper del 2024 parla di "Arke", che sviluppa un'idea da un paper del 2020 che parla di "UDM"; Signal ha usato gli HSM.
Mi sembra che BS migliori su Signal e UDM, ma possa fare di più con gli HSM. Non so dire su Arke
Mi sembra che BS migliori su Signal e UDM, ma possa fare di più con gli HSM. Non so dire su Arke
Tuttavia sarebbe sempre un compromesso, perché i sistemi basati su hardware sicuro dipenderebbero da tecnologie proprietarie dei produttori di CPU e comunque richiederebbero di mandare i numeri di telefono
La ricerca si sta avvicinando a una soluzione pratica e solida ma forse non ci siamo ancora
La ricerca si sta avvicinando a una soluzione pratica e solida ma forse non ci siamo ancora
December 21, 2025 at 2:52 PM
Tuttavia sarebbe sempre un compromesso, perché i sistemi basati su hardware sicuro dipenderebbero da tecnologie proprietarie dei produttori di CPU e comunque richiederebbero di mandare i numeri di telefono
La ricerca si sta avvicinando a una soluzione pratica e solida ma forse non ci siamo ancora
La ricerca si sta avvicinando a una soluzione pratica e solida ma forse non ci siamo ancora
Secondo me, potenzialmente BS potrebbe migliorare il protocollo senza stravolgerlo usando alcune delle tecniche che usa Signal, e in effetti loro stessi lo accennano in fondo alla RFC, ma mi dispiace che non vogliano farlo per ora.
December 21, 2025 at 2:40 PM
Secondo me, potenzialmente BS potrebbe migliorare il protocollo senza stravolgerlo usando alcune delle tecniche che usa Signal, e in effetti loro stessi lo accennano in fondo alla RFC, ma mi dispiace che non vogliano farlo per ora.
Questo descritto in un paper del 2020 (par.nsf.gov/biblio/10160...), da quel che ho capito senza approfondire troppo, protegge adeguatamente i grafi sociali degli utenti ma non i numeri dei contatti registrati al servizio. -->
December 21, 2025 at 2:39 PM
Questo descritto in un paper del 2020 (par.nsf.gov/biblio/10160...), da quel che ho capito senza approfondire troppo, protegge adeguatamente i grafi sociali degli utenti ma non i numeri dei contatti registrati al servizio. -->
Dal 2017 a oggi, Signal prende i numeri dei contatti, usando "hardware sicuro" lato server per evitare che Signal possa leggerli, ma soffre almeno di attacchi di enumerazione.
signal.org/blog/contact...
signal.org/blog/private... -->
signal.org/blog/contact...
signal.org/blog/private... -->
December 21, 2025 at 2:38 PM
Dal 2017 a oggi, Signal prende i numeri dei contatti, usando "hardware sicuro" lato server per evitare che Signal possa leggerli, ma soffre almeno di attacchi di enumerazione.
signal.org/blog/contact...
signal.org/blog/private... -->
signal.org/blog/contact...
signal.org/blog/private... -->
Anche qui evitare di ricevere i numeri potrebbe non essere semplicissimo: sembra che la ricerca privata dei contatti sia un problema irrisolto (o forse risolto con compromessi) e tuttora argomento di ricerca: l'ultimo paper che trovo è del 2024 (eprint.iacr.org/2023/1218) e sembra interessante -->
December 21, 2025 at 2:37 PM
Anche qui evitare di ricevere i numeri potrebbe non essere semplicissimo: sembra che la ricerca privata dei contatti sia un problema irrisolto (o forse risolto con compromessi) e tuttora argomento di ricerca: l'ultimo paper che trovo è del 2024 (eprint.iacr.org/2023/1218) e sembra interessante -->
Alla fine sono d'accordo ma non è così semplice: se l'attaccante conosce #C allora conosce automaticamente anche hash(#C) e qualsiasi sua trasformazione che non si basa su un segreto noto solo a C e BS. All'attaccante basterebbe sapere questo dettaglio del protocollo per continuare a impersonare C.
December 21, 2025 at 2:32 PM
Alla fine sono d'accordo ma non è così semplice: se l'attaccante conosce #C allora conosce automaticamente anche hash(#C) e qualsiasi sua trasformazione che non si basa su un segreto noto solo a C e BS. All'attaccante basterebbe sapere questo dettaglio del protocollo per continuare a impersonare C.
Ci sarebbe anche un problema di scoperta dei grafi sociali: se una persona con # noto è su BS, potrei impersonarla e trovare i suoi contatti su BS. Non so se questo possa essere generalizzato per trovare i grafi sociali di tutti, attaccando tutti i possibili #A, però è un'altra cosa da considerare
December 21, 2025 at 2:29 PM
Ci sarebbe anche un problema di scoperta dei grafi sociali: se una persona con # noto è su BS, potrei impersonarla e trovare i suoi contatti su BS. Non so se questo possa essere generalizzato per trovare i grafi sociali di tutti, attaccando tutti i possibili #A, però è un'altra cosa da considerare
O, alternativamente, si inviano i contatti e il server aspetta la verifica del numero prima di salvare gli hash nel db. Non so come faccia Bluesky ma credo che funzioni ugualmente.
December 21, 2025 at 12:57 AM
O, alternativamente, si inviano i contatti e il server aspetta la verifica del numero prima di salvare gli hash nel db. Non so come faccia Bluesky ma credo che funzioni ugualmente.
L'attaccante otterrebbe così:
-la scoperta che #A è un numero di telefono valido, se trova un qualsiasi match
-la scoperta, via ricerca binaria come descritto nella RFC, dei numeri dei match (tra i vari #B) e delle associazioni tra #B e account Bluesky, se B ha il contatto di A. (5/5)
-la scoperta che #A è un numero di telefono valido, se trova un qualsiasi match
-la scoperta, via ricerca binaria come descritto nella RFC, dei numeri dei match (tra i vari #B) e delle associazioni tra #B e account Bluesky, se B ha il contatto di A. (5/5)
December 21, 2025 at 12:54 AM
Bluesky fa quindi l'hash delle coppie (#C, #contatto) e non trova match, perché i contatti non hanno C come contatto. Bluesky non suggerisce utenti a C, l'attacco fallisce.
Se si inviassero direttamente gli hash invece dei numeri, potrebbe esserci paradossalmente un problema di privacy. (2/5)
Se si inviassero direttamente gli hash invece dei numeri, potrebbe esserci paradossalmente un problema di privacy. (2/5)
December 21, 2025 at 12:29 AM
Bluesky fa quindi l'hash delle coppie (#C, #contatto) e non trova match, perché i contatti non hanno C come contatto. Bluesky non suggerisce utenti a C, l'attacco fallisce.
Se si inviassero direttamente gli hash invece dei numeri, potrebbe esserci paradossalmente un problema di privacy. (2/5)
Se si inviassero direttamente gli hash invece dei numeri, potrebbe esserci paradossalmente un problema di privacy. (2/5)
Una volta che il client (C) ha verificato il proprio numero, c'è una finestra in cui il server ricorda il numero di C.
In questa finestra, C invia la lista dei contatti e può inviare contatti arbitrari, ma non può mentire sul proprio numero. (1/5)
In questa finestra, C invia la lista dei contatti e può inviare contatti arbitrari, ma non può mentire sul proprio numero. (1/5)
December 21, 2025 at 12:28 AM
Una volta che il client (C) ha verificato il proprio numero, c'è una finestra in cui il server ricorda il numero di C.
In questa finestra, C invia la lista dei contatti e può inviare contatti arbitrari, ma non può mentire sul proprio numero. (1/5)
In questa finestra, C invia la lista dei contatti e può inviare contatti arbitrari, ma non può mentire sul proprio numero. (1/5)
Ciao Christian, intanto scusa perché ieri ho frainteso completamente il tuo articolo, ignorando che gli hash vengono calcolati sulle coppie di numeri. Questo cambia tutto in caso di furto di db.
Invece su questo punto ho risposto qui (e sul commento di livello superiore):
bsky.app/profile/gees...
Invece su questo punto ho risposto qui (e sul commento di livello superiore):
bsky.app/profile/gees...
Il problema fondamentale è che non si può fare questa verifica lato app, perché non si può fare affidamento su un client controllato da un attaccante. C'è bisogno di un round trip, come si fa per la verifica delle email.
December 20, 2025 at 12:59 PM
Ciao Christian, intanto scusa perché ieri ho frainteso completamente il tuo articolo, ignorando che gli hash vengono calcolati sulle coppie di numeri. Questo cambia tutto in caso di furto di db.
Invece su questo punto ho risposto qui (e sul commento di livello superiore):
bsky.app/profile/gees...
Invece su questo punto ho risposto qui (e sul commento di livello superiore):
bsky.app/profile/gees...
Il problema fondamentale è che non si può fare questa verifica lato app, perché non si può fare affidamento su un client controllato da un attaccante. C'è bisogno di un round trip, come si fa per la verifica delle email.
December 20, 2025 at 12:49 PM
Il problema fondamentale è che non si può fare questa verifica lato app, perché non si può fare affidamento su un client controllato da un attaccante. C'è bisogno di un round trip, come si fa per la verifica delle email.
Letta, c'è decisamente molto lavoro dietro.
Rileggendo l'articolo di Christian, ho capito di aver perso il dettaglio importante che fanno hash di coppie di contatti, non dei singoli numeri. Però spiegano anche che i numeri servono a verificarne il possesso per evitare un'enumerazione lato app
Rileggendo l'articolo di Christian, ho capito di aver perso il dettaglio importante che fanno hash di coppie di contatti, non dei singoli numeri. Però spiegano anche che i numeri servono a verificarne il possesso per evitare un'enumerazione lato app
Request For Comments: A secure contact import scheme for social networks | Bluesky
This article outlines plans for a future Bluesky feature \- it doesn’t exist yet\! By sharing our ideas early, we hope to solicit feedback from the community.
docs.bsky.app
December 20, 2025 at 12:39 PM
Letta, c'è decisamente molto lavoro dietro.
Rileggendo l'articolo di Christian, ho capito di aver perso il dettaglio importante che fanno hash di coppie di contatti, non dei singoli numeri. Però spiegano anche che i numeri servono a verificarne il possesso per evitare un'enumerazione lato app
Rileggendo l'articolo di Christian, ho capito di aver perso il dettaglio importante che fanno hash di coppie di contatti, non dei singoli numeri. Però spiegano anche che i numeri servono a verificarne il possesso per evitare un'enumerazione lato app
E comunque richiederebbe a qualche programmatore di conoscere il segreto.
<Aggiunta in seguito a eliminazione vecchio commento>:
Anzi, non avrebbe proprio senso perché il segreto sarebbe esposto nell'app prima di finire nel SE.
Quindi una black box del genere non potrebbe essere fatta client side
<Aggiunta in seguito a eliminazione vecchio commento>:
Anzi, non avrebbe proprio senso perché il segreto sarebbe esposto nell'app prima di finire nel SE.
Quindi una black box del genere non potrebbe essere fatta client side
December 18, 2025 at 10:19 PM
E comunque richiederebbe a qualche programmatore di conoscere il segreto.
<Aggiunta in seguito a eliminazione vecchio commento>:
Anzi, non avrebbe proprio senso perché il segreto sarebbe esposto nell'app prima di finire nel SE.
Quindi una black box del genere non potrebbe essere fatta client side
<Aggiunta in seguito a eliminazione vecchio commento>:
Anzi, non avrebbe proprio senso perché il segreto sarebbe esposto nell'app prima di finire nel SE.
Quindi una black box del genere non potrebbe essere fatta client side
Apparentemente esiste l'idea di sale segreto, si chiama pepe:
en.wikipedia.org/wiki/Pepper_...
Tutto sommato la black box si potrebbe tentare anche lato client con i Secure Element, ma non è così semplice: per esempio, avendo rubato il db degli hash, si potrebbe pensare di usare l'app come oracolo.
en.wikipedia.org/wiki/Pepper_...
Tutto sommato la black box si potrebbe tentare anche lato client con i Secure Element, ma non è così semplice: per esempio, avendo rubato il db degli hash, si potrebbe pensare di usare l'app come oracolo.
Pepper (cryptography) - Wikipedia
en.wikipedia.org
December 18, 2025 at 9:10 PM
Apparentemente esiste l'idea di sale segreto, si chiama pepe:
en.wikipedia.org/wiki/Pepper_...
Tutto sommato la black box si potrebbe tentare anche lato client con i Secure Element, ma non è così semplice: per esempio, avendo rubato il db degli hash, si potrebbe pensare di usare l'app come oracolo.
en.wikipedia.org/wiki/Pepper_...
Tutto sommato la black box si potrebbe tentare anche lato client con i Secure Element, ma non è così semplice: per esempio, avendo rubato il db degli hash, si potrebbe pensare di usare l'app come oracolo.
Naturalmente per me l'alternativa migliore è non prendere né i numeri di telefono né gli hash, con sale o meno.
December 18, 2025 at 8:56 PM
Naturalmente per me l'alternativa migliore è non prendere né i numeri di telefono né gli hash, con sale o meno.
È sicuramente strano parlare di sale come segreto e questa è solo una cosa che ho pensato al momento, ma non so se la scarterei immediatamente come security by obscurity.
Bisogna comunque confrontare questo con l'alternativa di conservare soltanto gli hash senza sale, che chiunque potrebbe invertire
Bisogna comunque confrontare questo con l'alternativa di conservare soltanto gli hash senza sale, che chiunque potrebbe invertire
December 18, 2025 at 8:53 PM
È sicuramente strano parlare di sale come segreto e questa è solo una cosa che ho pensato al momento, ma non so se la scarterei immediatamente come security by obscurity.
Bisogna comunque confrontare questo con l'alternativa di conservare soltanto gli hash senza sale, che chiunque potrebbe invertire
Bisogna comunque confrontare questo con l'alternativa di conservare soltanto gli hash senza sale, che chiunque potrebbe invertire
..si può prendere il numero di telefono e passarlo a una black box che aggiunge il sale segreto e fa l'hash.
Poi si salva il risultato nel db e, si spera, si scarta il numero di telefono senza lasciare accidentalmente copie in memoria permanente. (4/4)
Poi si salva il risultato nel db e, si spera, si scarta il numero di telefono senza lasciare accidentalmente copie in memoria permanente. (4/4)
December 18, 2025 at 8:38 PM
..si può prendere il numero di telefono e passarlo a una black box che aggiunge il sale segreto e fa l'hash.
Poi si salva il risultato nel db e, si spera, si scarta il numero di telefono senza lasciare accidentalmente copie in memoria permanente. (4/4)
Poi si salva il risultato nel db e, si spera, si scarta il numero di telefono senza lasciare accidentalmente copie in memoria permanente. (4/4)
Per questo andrebbe usato il sale, ma se è sempre lo stesso ed è salvato nel db allora è come se non ci fosse; se è sempre diverso, la scoperta dei contatti non può funzionare.
Quindi invece... (3/4)
Quindi invece... (3/4)
December 18, 2025 at 8:37 PM
Per questo andrebbe usato il sale, ma se è sempre lo stesso ed è salvato nel db allora è come se non ci fosse; se è sempre diverso, la scoperta dei contatti non può funzionare.
Quindi invece... (3/4)
Quindi invece... (3/4)
Il grosso problema dell'invio diretto degli hash è che, in caso di breccia dati, questi hash sono inutili: siccome lo spazio dei numeri di telefono è molto piccolo, è banale craccare tutti gli hash provando uno a uno tutti i possibili numeri. (2/4)
December 18, 2025 at 8:37 PM
Il grosso problema dell'invio diretto degli hash è che, in caso di breccia dati, questi hash sono inutili: siccome lo spazio dei numeri di telefono è molto piccolo, è banale craccare tutti gli hash provando uno a uno tutti i possibili numeri. (2/4)