Best practices per gpg

Mantenere aggiornati i defaults di ~/.gnupg/gpg.conf

• Ad ogni cambio di versione, fare il merge delle modifiche del file di configurazione standard. Per generarlo, è suffciente avviare ed interrompere subito gpg, dopo aver rinominato la directory contenete la configurazione

mv ~/.gnupg/ ~/.gnupg.ori

• Creare il nuovo config file:

 gpg --list-keys

gpg: directory `/home/diesis/.gnupg' created
gpg: new configuration file `/home/diesis/.gnupg/gpg.conf' created
...

• Spostare il vecchio files personalizzo, spostare il nuovo files coi defaults, rimuovere la nuova directory, e ripristinare la vecchia

mv  ~/.gnupg.ori/gpgp.conf /tmp
mv ~/.gnupg/gpg.conf ~/.gnupg.ori
rm -rf ~/.gnupg
mv ~/.gnupg.ori ~/.gnupg/

• Fare il merge delle proprie personalizzazioni nel nuovo files coi defaults

vimdiff /tmp/gpg.cong ~/.gnupg/gpgp.conf 

Configurazione keyserver

• Si utilizzeranno i server del pool sks, e per colloquiare in modalità protetta hkps, installare

sudo apt-get install gnupg-curl

• Per poter collegarsi, è necessario utlizzare il certificato CA apposito:

cd ~/.gnupg/ && wget https://sks-keyservers.net/sks-keyservers.netCA.pem

• Impostare il keyserver, ed il percorso del certificato:

vi ~/.gnupg/gpg.conf

keyserver hkps://hkps.pool.sks-keyservers.net
# keyserver-options ca-cert-file=sks-keyservers.netCA.pem # viene cercato nella direcory corrente

• Testare un refresh delle chiavi pubbliche:

gpg --refresh-keys -v

• 'TODO: Verificare per enigmail che si riesca a uploadare in hksp [Enigmail Documentation needs Update / Error Message]

• Aggiungere l'opzione per forzare il refresh delle key SOLO dal pool sks

keyserver-options no-honor-keyserver-url 
# oltre alle altre già settate

• Impostare la visualizzazione degli ID delle key in formato lungo e col fingerprint, per poterle verificare con il propietario, ed evitare possibili collisioni:

vi ~/.gnupg/gpg.conf

keyid-format 0xlong
with-fingerprint

• Verificare che vengano mostrati:

gpg   --list-secret-keys

...
ssb   2048g/0xE0F60A38E4E9035C 2009-03-02
      Key fingerprint = DBA2 29BD 1DA3 8032 DBA4  DBC6 E0F6 0A38 E4E9 035C
...

NON:

ssb   2048g/E4E9035C 2009-03-02

• Se la chiave è vulnerabile, generarne una nuova.
• Un altro modo per verificare l'adegautezza di una chiave è tramite gli hopenpgp-tools:

sudo apt-get install hopenpgp-tools

hkt export-pubkeys '<fingerprint>' | hokey lint

• I requisti della nuova chiave dovrano essere:

• utilizzare una struttura a master key a 4096 bit, SOLO per la generazione di altre chiavi. Questa chiave andrà tenuta separata da quelle per il daily use, tenuta offline e stampata su carta, con la password scrita a a matita. La mster key sarà necessaria solo per

• firmare chiavi altrui per un WOT
• creare nuove subkeys
• per revocare delle subkeys

• Le child keys dovranno avere lunghezza almeno a 2048 bit. Non scegliere dimensioni esagerate, in quanto si impiegherebbero minuti per decifrare un messaggio, soprattutto su dispositivi mobili. Queste chiavi saranno usate sui propri dispositivi per la firma/cifratura

• Il metodo di hashing dovrà essere SHA-512 e assolutamente NON MD5 (in questo caso si può evitare di rigenerare la chiave: basta cambiare il metodo di hashing e la data di scadenza della chiave, in modo da rieseguire l'hashing)
• LA chiave dovrà essere almeno opepgpv4: se è v3, va annullata e ricreata.
• Le chiavi NON dovranno avere commenti. Sono inutili e impediscono la certificazione in un WOT
• Le chiavi dovranno essere possibilmente una per ogni identità, anche se è tecnicamente possibile aggiungere altre identità o indirizzi email, ma non è auspicabile in terminid i privacy/immagine
• Le chiavi dovranno avere per forza una scadenza, in modo da avere una via di uscita in caso di perdita. La scadenza può essere RINNOVATA in qualsiasi momento, ANCHE quando la chiave è già SCADUTE.
• La chiave dovrà avere un certificato di revoca, con il quale si potrà revocarla, anche se non si sarà più in possesso della chiave privata

Generazione chiave

• Verificare la propria chiave: se la primary key è una DSA/1024, oggi non è più sufficiente.

• Impostare i defaults secondo quanto espresso precedentemente:

vi ~/.gnupg/gpg.conf 

# ...
keyid-format 0xlong
with-fingerprint
# list of personal digest preferences. When multiple ciphers are supported by
# all recipients, choose the strongest one
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
# list of personal digest preferences. When multiple digests are supported by
# all recipients, choose the strongest one
personal-cipher-preferences AES256 AES192 AES CAST5
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
# Disable inclusion of the version string in ASCII armored output
no-emit-version
# Disable comment string in clear text signatures and ASCII armored messages
no-comments
# Display the calculated validity of user IDs during key listings
list-options show-uid-validity
verify-options show-uid-validity
# Don't leak DNS, see https://trac.torproject.org/projects/tor/ticket/2846
keyserver-options no-try-dns-srv
# When searching for a key with --search-keys, include keys that are marked on
# the keyserver as revoked
keyserver-options include-revoked

• Eventualmente, prelevare il template da https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf

• Creare la chiave:

gpg --gen-key

 (1) RSA and RSA (default)

What keysize do you want? (2048) 4096

Key is valid for? (0) 

Key does not expire at all
Is this correct? (y/N) y

Real name: My Name
Email address: my.name@example.com
Comment: 
You selected this USER-ID:
    "My Name <my.name@example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

• Una volta generata la chiave, verifichiamone gli attributi:

gpg --edit-key  0xiltuoiddellachiave

gpg> showpref
[ultimate] (1). My Name <my.name@example.com>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify

• Ora abbiamo una master key per firmare, con una subkey per cifrare. Vogliamo aggiungere una subkey anche per firmare, in modo che la master possa essere conservata a parte solo per la gestione del keyring.

• Modificare la chiave, ed aggiungere una subkey per firmare:

gpg --edit-key  0xiltuoiddellachi

  (4) RSA (sign only)

What keysize do you want? (2048) 4096

Key is valid for? (0) 0

• Si avrà ora 1 chiave primaria per il Signing, e due secondarie: una per l'encryption, ed una per il signing:

pub  4096R/0xiltuoiddellachia  created: 2014-07-13  expires: never       usage: SC  
                               trust: ultimate      validity: ultimate
sub  4096R/0xidchiaveCifratur  created: 2014-07-13  expires: never       usage: E   
sub  4096R/0xidChiaveFirmaxxx  created: 2014-07-13  expires: never       usage: S   
[ultimate] (1). My Name <my.name@example.com>

• Pubblicare sul proprio sito un'informativa tipo questa https://we.riseup.net/assets/176898/key%20transition, od inviarla ai propri corrispondenti abituali (no spam, please ...)

• Creaiamo ora un certificato di revoca, che sarà necessario se perderemo la MASTER KEY e non avremo altro mezzo per revocarla:

gpg --output 0xiltuoiddellachia-revocation-certificate.gpg --gen-revoke 0xiltuoiddellachia

Your decision? 1

• Conservare in luogo sicuro il file 0xiltuoiddellachia-revocation-certificate.gpg, e stamparlo.

Riferimenti

• OpenPGP Best Practices - help.riseup.net
• Creating the perfect GPG keypair - Alex Cabal
• Creating a new GPG key | Ana's blog
• Subkeys - Debian Wiki