Esistono numerose gui che semplificano la gestione di una chiave gpg.
Questo articolo ha lo scopo di semplificare la creazione di una chiave gpg attraverso la cli di GnuPG, senza entrare nel suo mare magnum di opzioni.
Indice
- Premessa
- Gestione della chiave
- Come proteggere il nostro keyring
- Cos'è un keyserver
Cosa NON è una chiave gpg?
Una coppia di chiavi, una pubblica e una privata basate sulla crittografia asimmetrica.
Cos'è una chiave gpg?
Non è solo una coppia di chiavi asimmetriche ma è un certificato.
Dal punto di vista delle informazioni, una chiave gpg contiene:
- informazioni identificative (nome, commento, email, foto, ecc)
- informazioni non identificative (dati tecnici che fanno parte delle chiavi: scadenza, keyserver, algoritmi di hash e cifratura, revoker ecc.)
Una chiave gpg, in definitiva, è costituita da:
- una chiave primaria (detta anche secret key o master key)
- da una o più sottochiavi
- da una serie di informazioni personali.
Ognuna di queste “chiavi” è in realtà una coppia di chiavi asimmetriche dotate delle seguenti autorizzazioni:
- Certificazione: capacità della chiave di firmare, e quindi validare, le chiavi gpg di altri utenti.
- Firma: capacità di firmare documenti.
- Cifratura: capacità di cifrare documenti.
- Autenticazione: capacità di autenticare l'utente su alcuni protocolli come TLS o SSH.
La certificazione, ossia la capacità di validare altre chiavi oltre la propria, è esclusiva della master key.
Le altre autorizzazioni possono essere delegate alle sottochiavi.
Certificazioni e firma, garantiscono autenticazione, integrità e non ripudio del mittente.
La cifratura garantisce confidenzialità.
Le prime due sono da considerarsi più critiche e normalmente assegnate alla master key.
Una chiave può avere una o più proprietà. Di default, gpg crea una master key con autorizzazioni per firma e certificazione e una sottochiave con autorizzazioni per cifratura.
Per la creazione e la gestione della chiave nei suoi elementi principali, vedremo:
- come creare la chiave primaria
- come aggiungere sottochiavi, uid
- come modificare password o scadenza
- come si certifica un'altra chiave con la nostra (firma di chiave)
- come si cancellano localmente uid, sottochiavi e firme
- come si revoca un certificato, una sottochiave, un uid o una certificazione
- come si usa un keyserver per la pubblicazione e la ricerca delle chiavi
Creazione della chiave primaria
# gpg --quick-gen-key <uid> <algo> <auth> <expire>, dove
# - <uid>: "uid_name (comment) <e-mail>"
# - <algo>: uno fra 'gpg --with-colons --list-config'
# - <auth>: cert|encr|sign
# - <expire>: 0 => illimitato, ny|nm|nd => n anni|mesi|giorni
gpg --quick-gen-key gandalf ed25519 cert 0
Crea una chiave gpg la cui secret key può solo certificare, l'uid è composto dal solo nome gandalf
e ha scadenza illimitata.
gpg -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid [ultimate] gandalf
Ecco la chiave appena creata, nella prima riga distinguiamo:
- “sec”, sta per secret key
- algoritmo/KeyID
- data di creazione
- capability ([C]=certify).
Nella riga successiva è visibile il fingerprint e nella terza, l'uid (gandalf). Questi elementi, come il KeyID, servono per indirizzare la chiave.
Una sintassi più completa sarebbe:
gpg --quick-gen-key "nome (commento) <e-mail>" algo cert|sign|encr <scadenza>
Per avere una lista degli algo:
gpg --with-colons --list-config
Aggiungere una sottochiave
Aggiungiamo le chiavi di firma e di cifratura con scadenza 5 anni e 1 anno rispettivamente
# gpg --quick-add-key <fpr> <algo> <auth> <expire>
gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B ed25519 sign 5y
gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B cv25519 encr 1y
Come prima, oltre alla secret key, ora sono visibili le sottochiavi (ssb, Secret SubKey) di firma e cifratura con le evidenze per:
algoritmo, KeyID, creazione, capability ([S] per sign e [E] per encrypt) e scadenza.
gpg -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid [ultimo] gandalf
ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04]
ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05]
Meccanismi di indirizzamento per una chiave
Una chiave può essere riferita attraverso l'uid, il key ID o il fingerprint. Il riferimento è importante nelle operazioni di manipolazione della chiave.
gpg --with-subkey-fingerprint -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid [ultimate] gandalf
uid [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>
ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2029-11-04]
87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2025-11-04]
4DD33D36C54E2247486C9DC7AAEF649D51D832E8
0xE01BDCB6A3C6778B
è il key ID della master key
8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
è il fingerprint della master key
gandalf
è uno degli uid
Aggiungere un uid
Aggiunge un nuovo uid in termini di nome-commento-email e lo battezza come primario.
# gpg --quick-add-uid <primary_uid> <new_uid>
gpg --quick-add-uid gandalf "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>"
# gpg --quick-set-primary-uid <primary_uid> <new_uid>
gpg --quick-set-primary-uid "gandalf" "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>"
Firmare una chiave
Ossia riconoscere una chiave gpg come valida attraverso la certificazione.
Pubblicare questa chiave sul keyserver, comunica al mondo che riconosciamo quella chiave come valida.
Convalida tutti gli uid della chiave identificata da <fpr>
# gpg --quick-sign-key <fpr>
gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0
Convalida un uid specifico della chiave identificata da <fpr>
# gpg --quick-sign-key <fpr> <uid>
gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0 frodo
Modificare la password
Inserisce la password con cui tutte le chiavi private (master key e subkey) relative all'uid indicato, vengono cifrate. Se la password viene lasciata vuota, la chiave non viene cifrata.
# gpg --passwd <uid|KeyID|fpr>
gpg --passwd gandalf
Modificare la scadenza
Modifico le scadenze delle chiavi come segue:
- la master key da illimitata a 10 anni
- la sottochiave di firma da 5 anni a 4 anni
- la sottochiave di cifratura da 1 anno a 2 anni
# gpg --quick-set-expire <fpr> <expire>
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 4y
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 2y
gpg --with-subkey-fingerprint -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] [expires: 2034-11-04]
8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid [ultimate] gandalf
uid [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>
ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2028-11-04]
87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2026-11-04]
4DD33D36C54E2247486C9DC7AAEF649D51D832E8
Cancellazione di elementi dal keyring
La cancellazione di elementi come uid, firme o sottochiavi ha effetto solo sul keyring locale.
Se la chiave è stata pubblicata su un repository, le cancellazioni non avranno alcun effetto.
Se si vuole inibire uno di questi elementi, si deve ricorrere alla revoca che è esportabile sui keyserver.
Cancellare una sottochiave
Cancella la sottochiave di firma
# gpg --delete-secret-and-public-keys <KeyID|fpr>
gpg --delete-secret-and-public-keys 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB!
# o, equivalentemente
gpg --delete-secret-and-public-keys 0xA391F0548FB542DB!
Cancellare un uid
Cancella la seconda identità della chiave gandalf
(0xA391F0548FB542DB
)
# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key gandalf
uid 2
deluid
save
Cancellare una firma
Cancella tutte le firme del 2° uid che non siano self-signature.
# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key gandalf
uid 2
delsig
save
Operazioni di revoca
Per quel che riguarda le chiavi gpg (i certificati) di cui si possiede la chiave privata, l'operazione di revoca può avvenire su uno degli elementi della chiave o sull'intero certificato.
Revocare un uid
Revoco l'uid (gandalf il grigio
),
# gpg --quick-revuid <primary_uid> <uid>
gpg --quick-revuid gandalf "gandalf il grigio"
Revocare una sottochiave
# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key 0xA391F0548FB542DB
key 1
revkey
save
Revocare una nostra certificazione
Così come validiamo le chiavi altrui con la nostra firma di certificazione, allo stesso modo possiamo revocarla.
Revoco la mia firma su tutti gli uid di una chiave pubblica
# gpg --quick-revoke-sig <KeyID|fpr del firmato> <KeyID|fpr del firmante>
gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B
Posso anche revocare la mia firma su un uid specifico
# gpg --quick-revoke-sig <KeyID|fpr del firmato> <KeyID|fpr del firmante> <uid_i>
gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B frodo_uid2
Revocare l'intero certificato
Va a revocare non solo tutti gli uid e tutte le sottochiavi, ma anche la masterkey.
gpg --import 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev
Il certificato di revoca viene generato all'atto della creazione della chiave.
Se non ci fosse, conviene sempre crearlo così che, se la master key venisse compromessa, saremmo almeno in grado di revocare l'intero certificato.
# gpg -o <file> --gen-rev <fpr>
gpg -o 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev --gen-rev 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
Le operazioni di revoca, nel mondo gpg, corrispondono alle maledizioni senza perdono, nel mondo di Harry Potter.
Non si torna indietro a meno di un backup, e se le revoche vengono pubblicate su un keyserver, diventano irreversibili.
Operazioni sul keyserver
Il caricamento delle chiavi su un keyserver costituisce la finalizzazione delle operazioni svolte finora.
Il keyserver pubblica al mondo le nostre chiavi, la configurazione avviene nel file dirmngr.conf aggiungendo una riga (ad es. per keys.openpgp.org):
vi dirmngr.conf
...
keyserver hkps://keys.openpgp.org
...
e ricaricando la configurazione:
gpgconf --reload dirmngr
Cerca
Cerca nel keyserver le chiavi con uid specificato. In caso di successo, chiede se possono essere aggiunte al keyring.
# gpg --search-keys <uid>
gpg --search-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0
Per gli utilizzatori di keys.openpgp.org:
gpg --auto-key-locate keyserver --locate-keys <uid>
Invia
Invia una lista di chiavi al keyserver
# gpg --send-keys <KeyIDs|fpr>
gpg --send-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0
Per gli utilizzatori di keys.openpgp.org:
Il classico send non è sufficiente perché non sarebbe possibile validare la mail di conferma. Si consiglia, non volendo usare l'interfaccia web, di usare il seguente comando:
# gpg --export <KeyID|fpr|uid> | curl -T - https://keys.openpgp.org
gpg --export 0xE01BDCB6A3C6778B | curl -T - https://keys.openpgp.org
che restituisce un link diretto alla pagina di verifica.
Ricevi
Scarica dal keyserver le chiavi
# gpg --keyserver-options honor-keyserver-url --receive-keys <KeyIDs|fpr>
gpg --keyserver-options honor-keyserver-url --receive-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0
Scarica dal keyserver la chiave indicata dall'uri
# gpg --fetch-keys <uri>
gpg --fetch-keys https://keyserver.ubuntu.com/pks/lookup?search=0xE01BDCB6A3C6778B&fingerprint=on&op=index
Aggiorna
Per rinnovare tutte le chiavi pubbliche del keyring.
gpg --keyserver-options honor-keyserver-url --refresh-keys
Come visto in precedenza, suggerisco di creare la master key per la sola certificazione e le due sottochiavi per firma e cifratura (anche quando la chiave primaria dovesse contenere altre autorizzazioni).
Questo permetterebbe, volendo ma non è necessario, di ruotare più agevolmente le chiavi di firma e cifratura svincolandole dalla certificazione.
Inoltre, così è più semplice rendere le chiavi gpg “partially stripped”, chiavi la cui sola secret key sia mancante della chiave privata, cosicché, se queste venissero smarrite o trafugate, la secret key in nostro possesso ci permetterebbe immediatamente di generare un certificato di revoca per le sottochiavi compromesse, generare delle nuove sottochiavi di firma e cifratura e di distribuire il tutto ad un keyserver.
Chiavi gpg siffatte permetterebbero di svolgere le consuete operazioni di firma e cifratura documentale (quello che potremmo definire “utilizzo giornaliero”) ma impedirebbero qualunque operazione critica sulla propria chiave gpg (impossibilità di aggiungere, revocare sottochiavi o uid, di alterare scadenza o password ecc.) e su quelle altrui (certificare e quindi validare altre chiavi) poichè è la chiave privata della master key a sigillare self-signed le informazioni della chiave gpg.
In generale, posso estrarre la chiave privata da qualunque coppia di chiavi, siano esse sottochiavi o master key, ma non è uno scenario molto comune. Per estensione, eliminandole tutte otterremo un insieme di chiavi pubbliche (quella che otterrei anche con gpg —export ).
Quello che invece ci interessa è eliminare la chiave privata della sola master key.
L'eliminazione della chiave privata dalla master key, di per sè, non è un'operazione particolarmente onerosa.
La vera “difficoltà” risiede nel cambio di paradigma per l'utente che l'utilizzo di master key stripped comporta, perché avremo a che fare con un keyring da proteggere accuratamente e dei keyring da “trincea” da usare liberamente sui nostri device.
Realizzare un keyring per l'uso quotidiano
Per farlo dobbiamo eliminare le chiavi private di tutte le master key del nostro keyring e per farlo dobbiamo fare un po' di assunzioni.
- Come primo passo, bisogna spostare, se non è stato già fatto, il keryring dal pc/laptop/device ad un luogo sicuro (ad es. pendrive cifrata)
- quindi si devono estrarre le chiavi private dalle master key e distribuirle dove possano servire
- in caso di emergenza o se vi è necessità di modificare le chiavi, importare le chiavi gpg dal dispositivo sicuro, effettuare le modifiche, rigenerare e ridistribuire le nuove chiavi stripped
Eliminazione della chiave privata dalla master key
La cancellazione della chiave privata impedisce alla master key o alla sottochiave di esercitare pienamente le funzioni indicate dalle proprie autorizzazioni ossia certificazione, firma o decifratura.
Per intervenire sulla singola chiave privata, occorre individuare il suo fingerprint o il suo keyid e usarlo per cancellare postponendo il carattere “!”.
Ad es. sulla master key di gandalf:
gpg --delete-secret-keys 0x055D271BD85313D0!
Il carattere “#” (accanto a sec) vuol dire che la chiave privata è stata eliminata
gpg -K
/home/gandalf/ramfs_gpg/pubring.kbx
-----------------------------------
sec# ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid [ultimo] gandalf
ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04]
ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05]
Generalizzando, per realizzare il nostro keyring di lavoro si può agire, una tantum, in questo modo:
1. spostiamo il keyring di lavoro sul dispositivo sicuro
KEYRING_RAMFS=<path_ramfs>
KEYRING_VAULT=<path_pendrive_cifrata>
KEYRING_WORK=<path_gpg_daily>
export GNUPGHOME=${KEYRING_WORK}; cd $GNUPGHOME
rsync -avp ${KEYRING_WORK}/ ${KEYRING_VAULT}/
2. rendiamo il keyring stripped cancellando le chiavi private di tutte le master key.
for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do
gpg --batch --yes --delete-secret-keys "${FPR}!"
done
In seguito, come detto in precedenza, per lavorare sul keyring occorrerà ripristinarlo dal dispositivo sicuro, ad es. una pendrive cifrata.
Per non lasciare tracce su altri device che non sia la pendrive cifrata, si possono seguire due strade.
- usare una distribuzione live (più sicura)
- montare una partizione in ram su ramfs (non usa lo swap) su cui caricare il keyring.
La prima via è certamente preferibile. Non c'è alcun uso dei dispositivi di storage fisici della macchine, solo quelli volatili, ma presuppone che si possa avviare un SO da pendrive.
La seconda è più accessibile per certi versi ma presuppone che si possiedano i privilegi per montare una partizione su ram.
Mostrerò la seconda via che è più articolata.
Lavorare con un keyring effimero
La strategia è quella di avere un keyring effimero montato su ramfs che farà da tramite fra il keyring master (su pendrive cifrata) e il keyring di lavoro.
L'obiettivo finale è quello di rendere strutturale il fatto di riuscire a compiere operazioni sul keyring usando il meno possibile i dispositivi di storage.
0. Init
KEYRING_RAMFS=<path_ramfs>
KEYRING_VAULT=<path_pendrive_cifrata>
KEYRING_WORK=<path_gpg_daily>
1. Monto la partizione effimera
mkdir -p ${KEYRING_RAMFS}
sudo mount -t ramfs -o size=10M ramfs ${KEYRING_RAMFS}
sudo chown $(logname):$(logname) ${KEYRING_RAMFS}
2. Esporto chiavi pubbliche e trust dal keyring di lavoro
gpg -o ${KEYRING_RAMFS}/keyring_pubkeys.gpg --export
gpg --export-ownertrust > ${KEYRING_RAMFS}/keyring_ownertrust.txt
3. Copio il keyring master sulla partizione effimera, modifico GNUPGHOME
in modo che gpg lavori direttamente sulla partizione effimera. Su questo keyring effimero, completo l'allineamento importando le chiavi pubbliche e il trust provenienti dal keyring di lavoro.
rsync -avp ${KEYRING_VAULT}/ ${KEYRING_RAMFS}/
export GNUPGHOME=${KEYRING_RAMFS}; cd $GNUPGHOME
gpg --import keyring_pubkeys.gpg
gpg --import-ownertrust keyring_ownertrust.txt
4. Eseguo le mie manipolazioni sul keyring effimero: uid, key, passwd, firme, revoche ecc.
...
[operazioni gpg]
...
5. Copio il keyring master dalla partizione effimera alla pendrive cifrata
rsync -avp ${KEYRING_RAMFS}/ ${KEYRING_VAULT}/
6. Rendo il keyring effimero di nuovo stripped
for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do
gpg --batch --yes --delete-secret-keys "${FPR}!"
done
7. Ripristino il keyring di lavoro escludendo i certificati di revoca e cancellando la partizione effimera
rsync -avp --exclude openpgp-revocs.d ${KEYRING_RAMFS}/ ${KEYRING_WORK}/
export GNUPGHOME=${KEYRING_WORK}/
sudo umount ${KEYRING_RAMFS}; rmdir ${KEYRING_RAMFS}
La complessità di questa gestione può essere ridotta rendendo scriptabili i due blocchi (1,2,3) e (5,6,7), ad es. immaginando di avere a disposizione delle funzioni come gpg-vault [open|close|status], avendo la consapevolezza che, se usate male, possono essere delle operazioni distruttive.
Il keyserver è il luogo in cui pubblichiamo le nostre chiavi per renderle disponibili agli altri utenti.
Inizialmente i keyserver avevano una logica p2p, distribuita e decentralizzata ottenuta con un'implementazione chiamata SKS (Synchronizing Key Server) basata sulla rapida diffusione delle chiavi fra keyserver.
I keyserver inizialmente servivano anche a realizzare il WOT (Web Of Trust) per la convalida delle chiavi.
Col tempo, la mancanza di aggiornamenti del protocollo sks e la suscettibilità ad attacchi di tipo “key poisoning”, che possono rendere indisponibili interi certificati (ad es. riempiendo la chiave con innumerevoli firme contenenti tonnellate di dati tali da far crashare i client) o gli stessi keyserver (pubblicando quantitivi enormi di certificati non validi), amplificata dalle caratteristiche di sincronizzazione dei server, ne hanno decretato la fine.
La realizzazione del WOT, tra l'altro, offriva pubblicamente una tale quantità di chiavi che permetteva, da un lato, di tracciare interi social network basati sulle firme che vi venivano apposte, dall'altro, di essere un formidabile serbatoio di email e altri dati sensibili a disposizione di attori malevoli, spammer e altro.
Inoltre leggi recenti sulla privacy come GDPR, cozzavano contro la natura immutabile dei keyserver che, by design, aggiungono chiavi e non permettono la cancellazione.
Modelli recenti
I modelli di keyserver successivi mitigano (ma non risolvono completamente) queste debolezze:
- rinunciando alla federazione e alla distribuzione
- sposando un modello basato sul controllo dell'email prima dell'accettazione della chiave
- ricorrendo a limitazioni, filtri e valutazioni sulla bontà delle chiavi prima che queste vengano accettate.
I principali modelli di keyserver sono:
- Hagrid
- Mailvelope
- HockeyPuck
Sono stati tutti creati per sopperire ai limiti dei server SKS.
Hagrid
Il primo, basato su SequoiaPGP, ha una natura centralizzata (non sarà mai federato), è GDPR compliant ed ha dato luogo a keys.openpgp.org.
I keyserver di questo tipo non aderiscono al modello WOT per ragioni di privacy e di efficienza. Sono quindi rifiutate le chiavi di terze parti, essenziali nel modello WOT, l'accettazione della chiave pubblica è vincolata dalla verifica dell'email, è possibile rimuovere le chiavi. Sono più resistenti agli attacchi di key poisoning.
Mailvelope
Ha dato luogo al keyserver keys.mailvelope.com, molto simile al primo e ne condivide la politica: no federazione, niente firme di terze parti e verifica dell'email vincolante per l'accettazione della chiave.
A differenza di altri keyserver, il focus di Mailvelope è la semplificazione dell'utilizzo della crittografia sull'e-mail, che sia webmail, con i provider e i browser che supportano Mailvelope, o client, quando si integrino con le sue api.
Hockeypuck
È un ritorno alle origini, ha una natura federata ed è considerato l'alternativa robusta ai server SKS. Uno fra i più noti server hockeypuck è certamente:
il keyserver gestito dalla comunità Ubuntu che contiene le chiavi per i suoi pacchetti ma è anche aperto al pubblico.
Un altro keyserver hockeypuck più di nicchia perché legato ad una specifica realtà tecnologica olandese è:
Sebbene possa essere meno aggiornato del primo, può essere usato liberamente per pubblicare le proprie chiavi.
I keyserver di questo tipo, come il pool di server sks, anche se con un filtraggio più stringente, abbracciano il modello WOT con tutto quello che ne consegue.
Altri keyserver
Infine, per dovere di cronaca, bisogna citare due decani dei keyserver apparsi all'alba di pgp e ormai non più utilizzabili per motivi di obsolescenza e di abbandono.
pgp.mit.edu: uno dei primi repository a permettere la pubblicazione e la distribuzione di chiavi pubbliche, facente anche parte della rete SKS.
global.pgp.com: l'alternativa proprietaria, appartenente a PGP Corporation prima e Symantec dopo, era il repository centralizzato per la distribuzione di chiavi usato dall'applicazione pgp.
In conclusione, se la necessità è di utilizzare il WOT, allora la scelta è senza dubbio Hockeypuck quindi keyserver.ubuntu.com.
Se invece la privacy è prioritaria, Hagrid quindi keys.openpgp.org diventa la scelta obbligatoria, tanto che è il default sia di GPG che di OpenKeyChain
#gpg #gnupg #crittografia #keyserver #hagrid #hockeypuck #mailvelope