Riepilogo Tecnico: Pepper

Problematica

I protocolli di broadcast anonimo (ABP) sono essenziali per applicazioni sensibili alla privacy come l' whistleblowing e la pubblicazione resistente alla censura, tuttavia il loro dispiegamento pratico ad alta larghezza di banda affronta sfide persistenti. Mentre i sistemi tradizionali come Tor offrono un routing a bassa latenza, essi rimangono vulnerabili ad attacchi di correlazione del traffico su scala globale. Le alternative con garanzie crittografiche basate su reti Dining Cryptographers (DC-net) e mix-net offrono una protezione più forte, ma soffrono di limitazioni critiche:

1. Dipendenze Esterne: Sistemi all'avanguardia come Spectrum ed Express si affidano a servizi di "dialing" o registrazione esterni non specificati per l'allocazione dei canali, lasciando un vuoto nella specifica del protocollo end-to-end.
2. Colli di Bottiglia del Throughput: Le varianti esistenti di DC-net tipicamente limitano i broadcaster a un solo messaggio per epoca, rendendoli impraticabili per trasferimenti di dati di grandi dimensioni (ad esempio, trasmettere un file da 1GB può richiedere oltre 13 ore).
3. Auditing Complesso: I meccanismi di controllo degli accessi e di auditing robusti spesso impongono un pesante overhead computazionale o richiedono assunzioni di fiducia irrealistiche (ad esempio, maggioranze oneste di server).
4. Mancanza di Integrazione: I lavori precedenti non hanno esplorato appieno la compatibilità con infrastrutture decentralizzate esistenti come Tor o le reti sociali federate, che potrebbero fornire traffico di copertura naturale e risorse server.

Metodologia

Pepper affronta queste limitazioni attraverso un design innovativo e integrato basato su un'architettura DC-net a due server. Il sistema opera in due sottoprofocolli sequenziali: Registrazione e Messaggistica, utilizzando primitive crittografiche avanzate per garantire l'anonimato del mittente e un throughput efficiente.

1. Registrazione Anonima Autocontenuta

A differenza dei sistemi precedenti, Pepper specifica un intero sottoprotocollo di registrazione che elimina la necessità di servizi di dialing esterni.

• Meccanismo: I broadcaster utilizzano Verifiable Distributed Point Functions (VDPFs) per acquisire canali di messaggistica in modo anonimo.
• Processo: Un broadcaster costruisce un messaggio di registrazione contenente la propria chiave pubblica, un ID canale di partenza e la larghezza di banda richiesta. Questo viene condiviso tramite secret-sharing tra due server di aggregazione.
• Verifica: I server eseguono un audit congiunto utilizzando token di verifica VDPF per garantire che le condivisioni siano ben formate e corrispondano a una richiesta valida senza apprendere i canali target o l'identità del broadcaster. Le registrazioni andate a buon fine legano la chiave pubblica a intervalli di canali specifici su un bulletin pubblico.

2. Messaggistica Batch con Auditing Efficiente

Pepper introduce il supporto per la messaggistica batch, consentendo a un singolo broadcaster di inviare fino a $t$ messaggi a canali distinti in una singola epoca.

• Meccanismo: Il sistema sfrutta le Distributed Multi-Point Functions (DMPFs) e le loro varianti verificabili (VDMPFs). Questo generalizza le DPF da un singolo punto non nullo a molteplici punti non nulli, permettendo a una singola coppia di chiavi di codificare più messaggi.
• Controllo degli Accessi: Per garantire che solo il proprietario del canale possa scrivere, Pepper integra le Schnorr Proofs over Secret Shares (SPoSS). Ciò consente ai server di verificare che un client possieda la chiave privata corrispondente a un canale registrato senza ricostruire il messaggio.
• Traffico di Copertura: Il sistema introduce i "Phantom Channels" — canali speciali con chiavi private universalmente note (ad esempio, $g^1, g^2$) — che permettono ai client di traffico di copertura di generare scritture dummy valide senza necessità di identità registrate.
• Efficienza dell'Audit: Fondamentalmente, il meccanismo di auditing di Pepper verifica un intero batch di $t$ messaggi in un'unica operazione. Scambia un solo paio di token di audit indipendentemente dalla dimensione del batch, ammortizzando significativamente l'overhead di verifica rispetto ai sistemi che richiedono $t$ verifiche separate.

3. Architettura di Sistema e Compatibilità

Pepper è progettato per un dispiegamento pratico accanto a reti decentralizzate esistenti:

• Server di Aggregazione: Il sistema utilizza coorti di due server. Questi possono essere co-distribuiti come relay Tor o istanze Mastodon.
• Servizio di Directory: Un servizio di directory mantiene un registro delle coppie di server attive, consentendo ai client di selezionare le coorti dinamicamente.
• Tolleranza ai Guasti: Il sistema assume un modello "any-trust" (almeno un server onesto per coorte) e supporta la scalabilità orizzontale aggiungendo più coppie di server.

Contributi Chiave

1. Registrazione Anonima Integrata: Il design di un intero sottoprotocollo di registrazione autocontenuto utilizzando VDPF, eliminando la dipendenza da sistemi di dialing esterni richiesti da Spectrum ed Express.
2. Messaggistica Batch ad Alto Throughput: La costruzione di un meccanismo di controllo degli accessi leggero che combina VDMPF con SPoSS. Ciò consente la verifica efficiente di batch di scritture (fino a $t$ messaggi) con un singolo scambio di prove, migliorando significativamente il throughput effettivo.
3. Implementazione e Valutazione: Un'implementazione open-source (~8.000 righe di Go, ~2.900 righe di C/C++) che dimostra audit di registrazione nell'ordine dei millisecondi e prestazioni scalabili fino a migliaia di canali.
4. Percorso di Dispiegamento Pratico: Una compatibilità dimostrata con le infrastrutture esistenti, mostrando come Pepper possa sfruttare Tor per il traffico di copertura e le risorse server, e integrarsi con le reti sociali federate.

Risultati

Gli autori hanno valutato Pepper rispetto ai baseline allo stato dell'arte (Spectrum, Express e PACLs) in termini di costo di comunicazione, tempo di auditing, throughput e latenza.

• Latenza di Auditing: Gli audit di registrazione completano in millisecondi anche per 16.000 canali. Per la messaggistica, l'auditing batch di Pepper scala efficientemente, superando Spectrum di 10,8×–12,4× e i PACL di 2,3×–3,6× in termini di tempo di auditing per richiesta per messaggi da 5KB con batch size $t=8$.
• Throughput Effettivo: Sebbene il throughput di singola richiesta sia inferiore a quello di Spectrum (a causa della maggiore computazione per richiesta nel batching), il tasso di messaggistica effettivo è significativamente più alto. Per $t=8$, Pepper fornisce tassi da 1,2× a 5,0× superiori rispetto ai PACL e da 13,6× a 20× superiori rispetto a Spectrum attraverso varie quantità di canali.
• Latenza End-to-End: Nei test di trasmissione file (da 100KB a 100MB), Pepper ha costantemente ottenuto la latenza più bassa. Per un file da 100MB, Pepper ha impiegato circa 10,2 ore, rispetto alle ~16,7 ore dei PACL e alle stimate ~274 ore di Spectrum.
• Overhead di Comunicazione: Pepper mantiene costi di comunicazione competitivi. Sebbene le chiavi VDMPF siano leggermente più grandi delle standard DPF per supportare il batching, la riduzione degli scambi di token di audit server-server (uno per batch invece di $t$) compensa il costo per grandi batch.

Significato

Il paper sostiene che Pepper rappresenti un passo significativo verso il dispiegamento pratico della diffusione anonima ad alta larghezza di banda. Eliminando le dipendenze esterne, supportando la messaggistica batch efficiente e integrandosi perfettamente con le reti decentralizzate esistenti come Tor e Mastodon, Pepper affronta i colli di bottiglia di throughput e scalabilità che hanno ostacolato i precedenti sistemi DC-net. Il sistema dimostra che l'anonimato del mittente può essere raggiunto con metriche di performance adatte ad applicazioni reali come la condivisione anonima di file e la disseminazione di media, senza richiedere assunzioni di fiducia irrealistiche o sacrificare le garanzie di anonimato.