Quando un segreto è conosciuto da più di due o tre persone, non è più un segreto, semplicemente discreto . Qualsiasi destinatario della mailing-list, per definizione, può leggere tutti i messaggi, quindi è trusted (nel senso di: ha il potere di tradirti). Questo limita le tue opzioni.
Con GnuPG, nel tuo caso, puoi svolgere una delle seguenti azioni:
-
Chiedi a ciascun destinatario di disporre di una coppia di chiavi, come è normale con GnuPG. Ogni messaggio viene crittografato con tutti gli utenti come destinatari (il formato OpenPGP lo supporta; il sovraccarico di dimensioni sarà di poche centinaia di byte per destinatario , quindi tollerabile finché ci sono meno di poche centinaia di destinatari). Il manutentore della mailing list invia regolarmente l'elenco dei destinatari sulla mailing-list stessa, in modo che ogni utente possa conoscere le chiavi pubbliche di tutti i destinatari.
Questo metodo è ciò che meglio si adatta a ciò che GnuPG sa come fare. Tuttavia, presenta alcuni svantaggi: overhead delle dimensioni (a seconda del numero di destinatari), attività complessa per i mittenti (non tutte le interfacce di GnuPG rendono facile inviare un messaggio di posta elettronica a dozzine di destinatari), pubblicazione dell'elenco dei destinatari (ogni membro di la lista impara chi altro è un membro).
-
Fai un relay. Anche in questo caso, ogni destinatario possiede una coppia di chiavi. Tuttavia, i messaggi vengono inviati con un singolo destinatario (ad esempio il manutentore della mailing list) che inoltra il messaggio a tutti i destinatari. Ciò lo rende molto più semplice per gli utenti finali, poiché inviano semplicemente i messaggi al manutentore della mailing list; e ogni messaggio inoltrato può essere crittografato per un singolo destinatario alla volta. Questo risolve i problemi del metodo precedente.
Tuttavia, aggiunge alcuni problemi aggiuntivi: latenza aggiuntiva (ogni messaggio deve attendere che il maintainer lo elabori), maggiore vulnerabilità alla censura (il maintainer può bloccare qualsiasi messaggio), firme più complesse (se il mittente firma il suo messaggio, il maintainer deve racchiudere il messaggio firmato all'interno della crittografia per tutti gli altri, questo è consentito dal formato di file ma alcune implementazioni potrebbero avere qualche problema nell'elaborazione di questo). Inoltre, lo stesso manutentore ha un sacco di lavoro o deve utilizzare alcuni strumenti automatici che potrebbero o meno essere disponibili per lui.
-
Utilizza una password comune. Invece di utilizzare coppie di chiavi asimmetriche, utilizza la crittografia simmetrica con una password nota a tutti i destinatari. Questo è decentralizzato: per aggiungere un abbonato, è sufficiente dargli la password, e ogni abbonato può farlo. La stessa mailing-list può essere sostituita da qualsiasi mezzo, anche decentralizzato, che supporterà una modalità no-single-point-of-failure (ad esempio, Usenet ). Questo schema assomiglia molto a quello usato dalle reti di resistenza durante la seconda guerra mondiale (vedi Radio Londres per esempio).
Il problema principale con una password comune è quello che ho detto all'inizio di questa risposta: una password comune non può essere quella segreta.
Le strategie miste sono possibili. Ad esempio, dividi i tuoi iscritti in celle , dove i membri di ciascuna cella si conoscono (e possono condividere una password comune o almeno conoscersi reciprocamente le chiavi pubbliche) e conoscere la chiave pubblica di due o tre persone in celle "adiacenti". I messaggi vengono quindi inoltrati da una cella all'altra, senza che nessuno conosca l'intera estensione della rete. Tali reti si sono storicamente dimostrate solide per quanto riguarda l'infiltrazione e il collasso totale. Vedi anche questo romanzo per un'illustrazione. Questo potrebbe essere un po 'estremo nel tuo caso - dipende davvero dal tuo modello di sicurezza. Forse la tua situazione non è di persuasione pericolosa per la vita.