Cartilha de OpenPGP

This guide is deprecated, you only need to use the defaults because GnuPG is doing sane things. Just keep your software up-to-date. That is it, you are done!

If you had previously tweaked your configurations, you should consider starting over with a base configuration, so you do not have outdated recommendations that are less secure than the defaults.

Como usar este guia

Reunimos aqui uma grande quantidade de informações sobre como configurar o GnuPG. Damos explicações detalhadas para cada sugestão de configuração. Grande parte destas definições requerem que você edite o arquivo de configuração do GnuPG, localizado no seu computador em ~/.gnupg/gpg.conf. Para maior conveniência, todas as alterações sugeridas para o arquivo gpg.conf estão reunidas no fim desta página. Recomendamos veementemente que você não copie o arquivo às cegas, mas que leia este documento e entenda o que cada configuração faz.

Este guia foi escrito com versões mais antigas (1.4) do GnuPG em mente e pode sugerir definições que já são padrão em lançamentos mais recentes (2.1 e posterior). Estamos trabalhando em uma revisão para garantir que o documento esteja atualizado. Você também pode ajudar propondo mudanças.

Use software livre e mantenha-o atualizado

Segurança da informação é uma questão importante demais para se resolver com software proprietário. A melhor opção é usar uma implementação livre de OpenPGP e mantê-la atualizada. A opção mais tradicional é o GnuPG, disponível para todos os sistemas operacionais modernos mais populares. Entretanto, não basta instalar o GnuPG e esquecer-se dele. Você deve mantê-lo atualizado para que falhas críticas de segurança sejam consertadas quando necessário. Todo software tem defeitos e o GnuPG não é exceção. Se você usa:

GNU/Linux (Debian, Ubuntu, Mint, Fedora, etc.)

seu sistema operacional instala o GnuPG automaticamente e mantém-no atualizado.

Windows

você pode instalar o programa Gpg4win e inscrever-se na lista gpg4win-announce para saber quando atualizar.

MacOS

você pode instalar a GPG suite da GPGTools. O software avisará quando houver uma atualização disponível, e você também pode acompanhar as novidades pelo Twitter.

Qualquer outro sistema operacional, com o programa instalado a partir da fonte

você deve se inscrever na lista gnupg-announce para saber quando atualizar.

Selecione um servidor de chaves e configure seu computador para manter seu chaveiro atualizado

Se você não atualizar regularmente suas chaves públicas, não acompanhará as expirações e revogações no tempo certo, e ambas são informações muito importantes! Dois aspectos devem ser considerados para garantir o recebimento das atualizações. Muitas pessoas enviam suas atualizações para servidores de chaves. Para recebê-las, você deve primeiro se certificar de que seu servidor de chaves está funcionando corretamente. Em seguida, precisa configurar seu computador para receber as atualizações regularmente.

Use o banco de servidores de chaves SKS, em vez de um servidor específico, com conexões seguras

A maioria dos clientes de OpenPGP vem especificamente configurada com um único servidor de chaves. Não é o ideal, já que, se o servidor falhar, ou pior, se não estiver funcionando adequadamente, mas parecer estar, você pode deixar de receber atualizações críticas. Esse servidor será não apenas um ponto de falha, mas também uma das principais fontes de vazamento das relações entre as pessoas que se comunicam com OpenPGP, logo um alvo de ataques.

Por isso recomendamos o banco de servidores de chaves SKS. Os computadores nesse banco são checados regularmente para garantir que estejam funcionando corretamente. Se um servidor não estiver funcionando bem, ele será removido automaticamente do banco.

Certifique-se também de se comunicar com o banco de servidores de chaves por um canal criptografado, com um protocolo chamado HKPS. Para usar HKPS, você precisa instalar gnupg-curl:

sudo apt-get install gnupg-curl

Então, para usar o banco de servidores de chaves, baixe o certificado disponível em sks-keyservers.net. Não esqueça o local onde salvou o arquivo! Em seguida, verifique a impressão digital do certificado.

Agora, edite ~/.gnupg/gpg.conf para incluir os seguintes parâmetros, especificando o caminho completo para o arquivo .pem.

keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

Agora suas interações com o servidor de chaves serão criptografadas via HKPS, o que tornará seu mapa de relações sociais invisível para alguém que esteja xeretando o seu tráfego. Por exemplo, se você executar o comando gpg --refresh-keys em um servidor de chaves pelo protocolo inseguro HKP, uma pessoa que esteja bisbilhotando terá acesso a todas as chaves do seu chaveiro conforme você solicita as atualizações delas. Essa pode ser uma informação bem interessante.

Obs.: hkps://keys.indymedia.org, hkps://keys.mayfirst.org e hkps://keys.riseup.net oferecem esse recurso (embora seja preferível usar um banco de servidores).

Isso é padrão a partir do GnuPG 2.1.18.

Certifique-se de que todas as chaves sejam atualizadas através do servidor de chaves selecionado

Quando uma chave é criada, é possível designar um servidor de chaves específico do qual puxar outras chaves. Recomenda-se que se adicione a seguinte opção a ~/.gnupg/gpg.conf, que irá ignorar essas designações:

keyserver-options no-honor-keyserver-url

Isso é útil porque (1) evita que alguém designe um método inseguro para puxar a chave e que (2), se o servidor designado usar HKPS, a atualização falhe porque o certificado de AC não é o correspondente, ou seja, as chaves jamais seriam atualizadas. Repare também que uma pessoa mal-intencionada pode designar um servidor de chaves que ela controle para monitorar a hora e rastrear até você a origem da atualização da chave dela.

Atualize suas chaves devagar, uma por uma

Agora que configurou um bom servidor de chaves, você precisa garantir que suas chaves sejam atualizadas regularmente. A melhor maneira de fazer isso no Debian ou Ubuntu é usando parcimonie:

sudo apt-get install parcimonie

Parcimonie é um daemon que atualiza seu chaveiro paulatinamente a partir de um servidor de chaves, através do Tor -. O programa usa hibernação randomizada e novos circuitos do Tor para cada chave. O objetivo é dificultar, em caso de ataque, a correlação entre as atualizações de chave e o seu chaveiro.

Você não deve usar o comando gpg --refresh-keys ou atualizar as chaves pelo menu do seu cliente de e-mail, pois a lista de chaves a serem atualizadas é revelada para quem estiver à espreita, além da pessoa reponsável pela operação do servidor de chaves.

Não confie cegamente em chaves de servidores

Qualquer pessoa pode subir chaves para servidores e não há garantia de que uma chave baixada realmente pertença ao indivíduo informado. Por isso, é necessário verificar diretamente com seu contato a impressão digital completa da chave. Isso deve ser feito pessoalmente ou por telefone.

Depois que verificar a impressão digital da chave que precisa, você pode baixar a chave do banco de servidores:

gpg --recv-key '<impressão digital>'

O próximo passo é confirmar que puxou a chave certa do servidor. É possível que o servidor de chaves transmita uma chave diferente da solicitada. Se a sua versão do gpg instalada for anterior à 2.1, você deve confirmar manualmente a impressão digital após baixar a chave (2.1 e posterior recusam chaves incorretas transmitidas pelo servidor).

Você pode confirmar a impressão digital da chave de duas maneiras:

Opção 1. Verifique se a impressão digital foi incorporada ao seu chaveiro:

gpg --fingerprint '<impressão digital>'

Opção 2. Tente assinar (localmente) uma chave com essa impressão digital:

gpg --lsign-key '<impressão digital>'

Se você está confiante de que tem a impressão digital correta dada pela pessoa à quem pertence a chave, é preferível que use o método de assinar a chave localmente. Se quiser anunciar publicamente a sua conexão com essa pessoa, você pode, em vez disso, fazer uma --sign-key publicamente exportável.

Repare nas aspas simples acima (’), que devem circundar a impressão digital completa e são necessárias para o comando funcionar. Aspas duplas (") também podem ser utilizadas.

Não confie no ID da chave

IDs de chave OpenPGP curtos, tais como 0×2861A790, contam com 32 bits de complexidade. São comprovadamente fáceis de falsificar usando outra chave com o mesmo ID. IDs longos (como 0xA1E6148633874A3D), por sua vez, têm 64 bits de complexidade. São suscetíveis a ataques de colisão, o que pode ser um problema sério.

Se você quiser um identificador criptograficamente forte para a chave, use a impressão digital completa. Jamais confie no ID da chave, curto ou longo.

Você deveria, pelo menos, adicionar as opções keyid-format 0xlong e with-fingerprint ao gpg (incluindo-as em ~/.gnupg/gpg.conf) para aumentar o tamanho de exibição normal do ID de chave para 64 bits e sempre exibir a impressão digital.

Vale ressaltar que um defeito foi detectado no Enigmail, já consertado na versão 1.7.0: se você adicionar a opção ‘with-fingerprint’ para exibir as impressões digitais completas quando listar chaves, a impressão digital exibida na janela de gerenciamento de chave do Enigmail será da subchave, e não da chave primária. Você sempre pode encontrar a impressão digital da sua chave primária (por exemplo, se quiser dá-la para alguém verificar em uma “festa” de assinatura de chaves), exibindo as impressões digitais de todas as suas chaves secretas com o seguinte comando:

gpg --with-fingerprint --list-secret-key

Verifique a impressão digital da chave antes de importá-la

Se você receber ou baixar uma chave em um , você pode e deve exibir a impressão digital antes de importá-la para o seu chaveiro, verificando-a assim sem correr o risco de contaminar seu chaveiro com uma chave comprometida:

gpg --with-fingerprint <arquivo-chave>

Configuração da chave

Agora que você aprendeu a atualizar suas chaves regularmente a partir de um servidor mantido em dia, você precisa se certificar de que sua chave OpenPGP está configurada da melhor forma possível. Muitas das alterações a seguir podem requerer que você gere uma nova chave.

Tenha uma chave primária forte

Algumas pessoas ainda usam chaves DSA de 1024 bits. Se é o seu caso, você realmente deveria migrar para uma chave mais comprida, com um algoritmo de dispersão mais forte. Em 2011, a agência governamental estadunidense NIST declarou obsoletas as chaves DSA-1024, e desde 2014 elas são proibidas. Em 2015, o NIST também proibiu as chaves RSA de 1024 bits e a utilização de SHA-1 para assinaturas.

É recomendável criar uma chave RSA de 3072 bits, com o algoritmo de hashing sha512, fazer uma declaração de transição assinada por ambas as chaves, e então divulgá-la. Veja também este documento, que detalha exatamente como criar uma chave desse tipo, garantindo que você use o algoritmo de hashing correto (o que pode ser ligeiramente complicado se você estiver usando uma versão do GnuPG anterior a 1.4.10).

Fazer a transição pode ser sofrido, mas vale a pena, além de ser uma boa oportunidade para aprender mais sobre as ferramentas!

Defina um tempo de validade menor que dois anos

Talvez você pense que não quer que sua chave expire, mas essa é a melhor opção. Por quê? Você sempre pode adiar a data de validade, mesmo depois que a chave expirar! Essa “validade”, na verdade, é uma válvula de segurança ou “sistema homem-morto” programado para disparar automaticamente em um dado momento. Se você tiver acesso ao material da chave secreta, poderá desengatilhá-lo. A questão é estabelecer um sistema para desabilitar sua chave caso você perca o acesso a ela (e não possua certificado de revogação).

Definir um prazo de validade significa que você precisará estendê-lo no futuro. É uma pequena tarefa que deverá se lembrar de cumprir (veja o próximo item para saber como configurar um lembrete).

Você pode achar tudo isso chato demais para se lidar, mas, na verdade, é bom ter que passar por isso de vez em quando para manter frescos seus conhecimentos de OpenPGP. Mostra às pessoas que a sua chave ainda está ativa, ainda está sendo usada, e dá a você a oportunidade de rever o estado das suas ferramentas e as melhores práticas. Além disso, muitas pessoas não assinam chaves sem data de validade!

Se já gerou uma chave sem data de validade, você ainda pode defini-la fazendo o seguinte:

gpg --edit-key '<impressão digital>'

Agora, selecione a subchave para a qual deseja estabelecer uma data de validade (p.ex. a primeira), ou não selecione nenhuma para configurar a data de validade da sua chave primária, e então use o comando ‘expire’:

gpg> key 1
gpg> expire

Em seguida, defina uma data razoável (p.ex. 2 anos), salve a chave e encerre o programa:

Key is valid for? (0) 2y
gpg> save

Então você poderá enviar sua chave para os servidores de chaves publicarem a mudança:

gpg --send-key '<impressão digital>'

Configure um evento no calendário como lembrete da data de validade

Você não se lembrará, então é melhor pedir ao computador para fazer isso por você. Configure seu lembrete para um mês ou mais antes da data para que você tenha tempo para fazer a alteração. É melhor não se apressar quando estiver lidando com suas chaves.

Lembre-se: você sempre pode estender a validade (mesmo depois que a chave expirar!), então não precisa criar uma nova chave, apenas adiar a data. Fazer isso com regularidade é um bom exercício para os seus músculos OpenPGPianos — de outra forma, você acabará se esquecendo das coisas.

Gere um certificado de revogação

Se você esquecer sua frase secreta ou se sua chave privada for comprometida ou perdida, a sua única esperança será esperar que a chave expire (não é uma boa solução) ou ativar seu certificado de revogação, publicando-o nos servidores de chaves. Ao fazer isso, você notifica às pessoas de que a chave foi revogada.

Uma chave revogada ainda pode ser usada para verificar assinaturas antigas ou decriptografar dados (se você ainda tiver acesso à chave privada), mas não pode ser usada para criptografar novas mensagens enviadas a você.

gpg --output revoke.asc --gen-revoke '<impressão digital>'

Assim, será criado um arquivo chamado revoke.asc. Você pode imprimir uma cópia do certificado para armazená-la em algum lugar seguro (dá-la para sua mãe ou guardá-la junto aos seus backups externos). Se alguém conseguir acessá-la, poderá revogar sua chave, o que seria muito inconveniente, mas se também tiverem acesso à sua chave privada, isso é exatamente o que deve acontecer.

Observe que isso é padrão nas versões mais recentes do GnuPG (a partir de 2.1).

Use sua chave primária apenas para certificações (e possivelmente assinaturas). Tenha uma subchave separada para criptografia.

Isso é padrão a partir do GnuPG 1.4.18 (e talvez versões mais antigas). Se você criou sua chave usando implementações mais antigas da OpenPGP, pode ser necessário criar novas subchaves como se para assinaturas, abaixo.

Separe uma subchave para assinaturas

Por padrão, o GnuPG usa a mesma subchave para assinaturas (p.ex. assinar um e-mail) e certificações (p.ex. assinar outra chave). É útil separar esses propósitos, já que um deles é muito mais importante que o outro.

Nesse cenário, sua chave primária seria usada apenas para certificações, que não são frequentes.

É possível criar uma nova subchave na seção --edit-key, usando o comando addkey. Dentro da seção, você pode escolher a “capacidade” da chave…

Mantenha sua chave primária inteiramente off-line

Isso é complicado de se fazer, mas ajuda a proteger a importantíssima chave primária. Se alguém roubá-la, poderá criar novas identidades, revogar as existentes e se fazer passar por você. Armazenar chaves off-line é, portanto, uma boa proteção contra esse tipo de ataque.

Certifique-se de criar uma chave separada para assinaturas antes, ou não conseguirá assinar e-mails sem a chave off-line.

Extrair a chave primária é complicado, mas deve dar certo se você fizer o seguinte:

# extrair a chave primária
gpg -a --export-secret-key john.doe@example.com > secret_key
# extrair as subchaves, que serão reimportadas depois
gpg -a --export-secret-subkeys john.doe@example.com > secret_subkeys.gpg
# *deletar* as chaves secretas do chaveiro, deixando apenas as subchaves
$ gpg --delete-secret-keys john.doe@example.com
Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
# reimportar as subchaves
$ gpg --import secret_subkeys.gpg
# verificar se está tudo em ordem
$ gpg --list-secret-keys
# remover as subchaves do disco
$ rm secret_subkeys.gpg

Em seguida, guarde o arquivo secret_key off-line, talvez em um pen drive que você sempre carregue consigo ou em um cofre. Outras pessoas podem usar cartões inteligentes para armazenar a chave e guardá-la em seus chaveiros físicos. Da segurança desse dispositivo dependerá a segurança da sua chave.

Novamente, certifique-se de que tem um certificado de revogação.

Você pode garantir que o material da chave secreta foi removido executando --list-secret-keys, que marca o material ausente com um sec# em vez de sec.

Observação: raramente, --delete-secret-keys pode não remover completamente o material da chave secreta, que será mostrado como sec em vez de sec# ao comando --list-secret-keys.

Nesse caso, você pode tirar o diretório .gnupg do caminho em vez de executar --delete-secret-keys. Será necessário reimportar seu trustdb e suas chaves públicas, é claro. Veja abaixo:

em vez de executar gpg --delete-secret-keys john.doe@example.com, faça o seguinte:
$ mv .gnupg .gnupg.bak
# reimportar as subchaves
$ gpg --import secret_subkeys.gpg
# verificar se está tudo em ordem
$ gpg --list-secret-keys
# remover as subchaves do disco
$ rm secret_subkeys.gpg
# reimportar o chaveiro público
$ gpg --homedir .gnupg.bak --export | gpg --import
# reimportar trust db
$ gpg --homedir .gnupg.bak --export-ownertrust | gpg --import-ownertrust
# remover o diretório GPG de backup, o que apagará *todas* as chaves secretas
$ rm -rf .gnupg.bak

Por fim, repare que, acima, o material da chave secreta é armazenado em texto puro na memória. Você pode apagar esses arquivos com segurança (usando, por exemplo, nwipe) em vez de usar um simples rm para remover o material da chave privada. Considere que dispositivos de armazenamento modernos como SSDs rodam firmware avançado que pode não obedecer tais comandos e deixar rastros da chave privada na memória. A melhor defesa, nesse caso, é usar criptografia de disco inteiro.

Observe que os procedimentos podem mudar de versão para versão. Veja esta discussão, este artigo ou ainda este guia concebido para GnuPG 2.x e superior.

Verificação de chaves OpenPGP

Existe uma ferramenta útil que faz por você as verificações de chave descritas abaixo. Você pode baixá-la da fonte ou, se estiver usando Debian ou Ubuntu, instalar o pacote diretamente com o seguinte comando:

sudo apt-get install hopenpgp-tools

Observação: hopenpgp-tools atualmente não funciona com GnuPG 2.1 ou superior. Isso porque versões mais recentes armazenam suas chaves pública e privada em ~/.gnupg/pubring.kbx. hkt procura sua chave pública em ~/.gnupg/pubring.gpg e mostra uma mensagem de erro se você estiver usando GnuPG 2.1 ou superior.

Para executar esses testes com a ferramenta, você pode fazer o seguinte:

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

A saída exibirá quaisquer problemas com sua chave em vermelho. Se tudo estiver verde, sua chave terá passado em todos os testes listados abaixo. Se houver algo em vermelho, sua chave não terá passado em algum dos testes, e você deverá consertá-la ou gerar uma nova chave, após se certificar de que sua gpg.conf está configurada conforme recomendado.

Certifique-se de que sua chave é OpenPGPv4

De acordo com a norma RFC 4880: "Chaves V3 estão obsoletas. Elas têm três fraquezas. Primeiro, é relativamente fácil construir uma chave V3 que tenha o mesmo ID de Chave que qualquer outra chave, pois o ID de Chave é composto simplesmente pelos últimos 64 bits do módulo público. Segundo, como a impressão digital de uma chave V3 dispersa o material da chave, mas não seu comprimento, existe uma chance maior de colisões entre impressões digitais. Terceiro, o algoritmo de dispersão MD5 tem fraquezas que o colocam em desvantagem em relação a outros algoritmos. Veja abaixo mais informações sobre IDs de Chave e impressões digitais.

Para determinar se sua chave é V3, faça o seguinte:

gpg --export-options export-minimal --export '<impressão digital>' | gpg --list-packets |grep version

Chaves primárias devem ser RSA, idealmente de 3072 bits.

Para verificar se você está usando RSA, faça isto:

gpg --export-options export-minimal --export '<impressão digital>' | gpg --list-packets | grep -A2 '^:public key packet:$' | grep algo

Se o algoritmo relatado for 1, você está usando RSA.

Se for 17, então é DSA e você precisará confirmar se o tamanho relatado na próxima verificação é superior a 1024 bits; se não for, você não está usando DSA-2.

Se o algoritmo relatado for 19, você está usando ECDSA. Se for 18, você está usando ECC. A verificação de tamanho abaixo não é um critério apropriado para esses tipos de chave, já que os tamanhos de chave são significativamente menores nesses casos.

Para verificar o comprimento em bits da sua chave primária, faça o seguinte:

gpg --export-options export-minimal --export '<impressão digital>' | gpg --list-packets | grep -A2 'public key' | grep 'pkey\[0\]:'

Autoassinaturas não devem usar MD5 exclusivamente

Você pode verificar isso desta forma:

gpg --export-options export-minimal --export '<impressão digital>' | gpg --list-packets | grep -A 2 signature | grep 'digest algo'

Se você vir algo como ‘digest algo 1’ nos resultados, então você possui autoassinaturas que usam MD5, que é o algoritmo de resumo criptográfico número 1. Consulte a norma [[OpenPGP RFC 4880, seção 9.4 para uma tabela de correspondência entre algoritmos de resumo criptográfico e números.

Para consertar, primeiro você deve adicionar a seguinte definição ao seu arquivo ~/.gnupg/gpg.conf:

cert-digest-algo SHA512

Em segundo lugar, você deve gerar uma autoassinatura para sua chave (p.ex., alterando a data de validade da chave → /best-practices#use-an-expiration-date-less-than-two-years]]).

Autoassinaturas não devem usar SHA-1

Você pode verificar isso desta forma:

gpg --export-options export-minimal --export '<impressão digital>' | gpg --list-packets | grep -A 2 signature | grep 'digest algo 2,'

Se os resultados incluírem a expressão ‘digest algo 2’, então você possui autoassinaturas que usam SHA-1, que é o algoritmo de resumo criptográfico número 2. Consulte a norma [[OpenPGP RFC 4880, seção 9.4, para uma tabela de correspondência entre algoritmos de resumo criptográfico e números.

Para consertar, você pode gerar uma autoassinatura para sua chave (p.ex., alterando a data de validade da chave → /best-practices#use-an-expiration-date-less-than-two-years]]) depois de acrescentar a seguinte definição ao seu arquivo ~/.gnupg/gpg.conf:

cert-digest-algo SHA512

As preferências de algoritmo de resumo criptográfico devem incluir pelo menos um membro da família SHA-2 cuja prioridade seja superior a MD5 e SHA-1.

Você pode verificar isso desta forma:

gpg --export-options export-minimal --export '<impressão digital>' | gpg --list-packets | grep 'pref-hash-algos'

Depois, examine os resultados. A ordem de preferência é baseada em que número vem primeiro, da esquerda para a direita. Se você vir o número ‘3’, ‘2’ ou ‘1’ antes de ‘11’, ‘10’, ‘9’ ou ‘8’, então você especificou suas preferências para priorizar um algoritmo mais fraco.

Para consertar, primeiro acrescente o seguinte ao seu arquivo ~/.gnupg/gpg.conf:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Então, configure as preferências da sua chave assim:

$ gpg --edit-key '<fingerprint>'
gpg> setpref
...
gpg> save

Chaves primárias devem ter um tempo de validade razoável (não mais que dois anos)

Você pode verificar quais são suas datas de validade desta forma:

gpg --export-options export-minimal --export '<impressão digital>' | gpg --list-packets | grep 'key expires after'

Então, examine os resultados para confirmar — mas a data listada será relativa à criação da chave, o que pode ser difícil de interpretar.

Outra maneira de verificar a validade é simplesmente com o seguinte comando:

gpg --list-keys '<impressão digital>'

Ele deve exibir as datas de criação e validade da chave primária e de cada subchave associada. Se você não vir a palavra “expires”, não configurou adequadamente uma data de validade.

Para consertar, você pode:

$ gpg --edit-key '<impressão digital>'
gpg> expire
...
gpg> save

Juntando tudo

Todas as definições recomendadas discutidas neste guia foram combinadas em um único arquivo de configuração no duraconf, a “coleção de arquivos de configuração reforçados” de Jacob Appelbaum. Você pode clicar com o botão direito neste link e salvar o arquivo gpg.conf no local ~/.gnupg/gpg.conf (Linux e MacOS). No Windows, o arquivo gpg.conf deve ser salvo em AppData\GnuPG\.

Você precisará descomentar e/ou ajustar as seguintes configurações de acordo com suas preferências locais: default-key, keyserver-options ca-cert-file e keyserver-options http-proxy.

Sugestões adicionais

Você tem um backup criptografado do material da sua chave secreta?

Verifique.

Não inclua um “Comentário” no seu ID de Usuário

Se você acha necessário ter um campo de “Comentário” no seu ID de Usuário OpenPGP, pense melhor antes de se decidir definitivamente. Você provavelmente não precisa nem quer um “Comentário”, e tê-lo pode dificultar que outras pessoas saibam o que estão certificando.