Agora eu entendo por que quase ninguém usa e-mail criptografado

Views: 172
0 0
Read Time:8 Minute, 40 Second

E-mail criptografado é doloroso! Descobri recentemente o quão doloroso. Um conhecido on-line muito consciente de segurança me enviou sua chave PGP pública e me pediu para começar a usar e-mail criptografado para me comunicar com ela. Não, ela não é da NSA ou da CIA, apenas uma pessoa normal interessada em manter sua privacidade. Eu nunca tinha enviado um e-mail criptografado antes, mas eu pensei, “Por que não?” Isso é algo que eu queria aprender a fazer há anos, mas nunca tive ninguém com quem trocar e-mails criptografados.

Comecei instalando o GnuPG no meu computador Linux. O GnuPG é semelhante ao PGP, pois usa chaves públicas e privadas para criptografia e descriptografia, mas o GnuPG é de código aberto e vem gratuitamente com muitas distribuições Linux. OpenPGP é outra versão de código aberto do PGP. GnuPG para Windows pode ser baixado no site do GnuPG sob o nome Gpg4win. Escolhi um método geral de criptografar e descriptografar mensagens que não está vinculado a nenhum provedor de e-mail, porque não queria me limitar a apenas poder usar e-mails criptografados com um provedor. Além disso, a única maneira de garantir que nem mesmo seu provedor de e-mail possa ler seu e-mail é criptografá-lo você mesmo. How-To Geek tem um dos tutoriais mais úteis sobre GnuPG que encontrei on-line.

Importei a chave pública do meu conhecido com este comando:

gpg --import her_public_key_file.key

Eu substituí “her_public_key_file.key” no comando acima com seu arquivo de chave pública real. Em seguida, verifiquei se a chave dela tinha sido importada com sucesso com:

gpg --list-keys

Uma mensagem como esta apareceu:

pub   2048R/FFE7947D 2019-10-11 [expires: 2021-10-10]
uid                  her_email@her_email_provider.com
sub   2048R/AB48FEC2 2019-10-11

Isso significa que o GnuPG reconhece sua chave pública como válida e a guardou para uso posterior.

Em seguida, assinei a chave pública dela:

gpg --sign-key her_email_address@email_provider.com

Assinar uma chave pública diz ao GnuPG que você confia que veio da pessoa de quem você acha que veio. Cada chave pública deve ser assinada antes que as mensagens do proprietário dessa chave pública possam ser descriptografadas. Este passo não faz sentido para mim. Por que você importaria uma chave se não achaque veio da pessoa certa?

Tentei gerar minhas chaves com este comando:

gpg --output ~/temp.key --armor --export My Name 

Bem, isso deu uma mensagem de erro dizendo que o fim de uma nova linha tinha sido encontrado. Eu pensei que poderia ser devido aos espaços em meu nome e entre meu nome e meu endereço de e-mail, então eu tentei vários formatos. Depois de cerca de uma hora e muitas tentativas fracassadas, algumas que pareciam ter sido bem sucedidas, mas não foram, finalmente encontrei o comando certo:

gpg  --gen-key

O comando acima guia você com uma série de perguntas a responder. Escolhi a opção “1” no primeiro prompt. Escolhi a opção de comprimento de 2048 bits para as minhas chaves. Eu fiz minhas chaves válidas para sempre. Para meu nome, eu digitei um nome, mas você pode ter espaços em seu nome se você usar seus nomes e sobrenomes. Então eu digitei meu endereço de e-mail. Deixei o comentário em branco. E finalmente, eu digitei uma frase de passe forte. “Senha” é apenas outra palavra para senha. Escrevi em algum lugar que não perderia. Na verdade, eu coloquei em um arquivo criptografado com Truecrypt. Você precisará de sua senha mais tarde para criptografar mensagens e, caso precise reinstalar o GnuPG no seu disco rígido e ter que reimportar suas chaves. Além disso, não se esqueça de fazer um backup de suas chaves!

Depois de gerar com sucesso minhas chaves, digitando este comando no prompt do Linux:

gpg --list-keys

produziram algo assim:

pub   2048R/FFE7947D 2019-10-11 [expires: 2021-10-10]
uid                  her_email@her_email_provider.com
sub   2048R/AB48FEC2 2019-10-11


pub   2048R/3A785D3F 2020-02-22
uid                  My Name 
sub   2048R/A7B384FE 2020-02-22

Eu passei pelo processo de geração de chaves duas vezes, porque eu não tinha certeza se o resultado acima significava que eu tinha um par de chaves públicas e privadas ou apenas uma chave. De alguma forma, eu finalmente percebi que eu tinha criado dois pares de chaves, então eu deletei o segundo par.

Em seguida, eu tentei exportar minha chave pública para um arquivo. Sua chave pública deve ser enviada para qualquer pessoa a quem você enviar um e-mail criptografado. O receptor da sua mensagem precisa dele para descriptografar sua mensagem. Não sei qual comando usei, mas produziu um arquivo de texto simples começando com “—–BEGIN PGP PUBLIC KEY BLOCK—– Versão: GnuPG v1”. Mandei isso por e-mail para meu conhecido, e ela me mandou uma mensagem criptografada.

Quando tentei descriptografar seu arquivo de mensagem, “message.asc”, com:

gpg --decrypt message.asc > plain.txt

O GnuPG me informou com a seguinte mensagem de erro que não conseguia encontrar uma chave secreta:

gpg: encrypted with RSA key, ID XXXXXXXX
gpg: decryption failed: secret key not available

Mas, eu podia ver a minha chave secreta. Eu poderia até exportá-lo. Eu sabia que estava lá! Às vezes, as pessoas que escrevem código criam as piores mensagens de erro. Neste ponto, eu estava ficando bastante frustrado.

Eu não sabia o que tinha feito de errado, mas a única coisa que eu podia pensar era que eu tinha falhado em criar as chaves corretamente. Ou isso, ou eu tinha exportado a chave pública errada. Então, decidi começar de novo. Eu excluí meu par de chaves, gerei um novo par de chaves e exportei minha chave pública para um arquivo com este comando:

gpg --output ~/my_public_gpg_key.key --armor --export My Name my-email@my-email-povider.com

Então, enviei minha nova chave pública para meu conhecido. A opção “-armor” no comando acima diz ao GnuPG para criar o arquivo de chave pública em texto simples. O arquivo criado é “my_public_gpg_key.key”.

Ela recriptografou a mensagem e mandou de volta para mim. Quando tentei decifrá-lo, vi a mesma mensagem de erro novamente:

gpg: encrypted with RSA key, ID XXXXXXXX
gpg: decryption failed: secret key not available

Desta vez, notei que a chave combinava com a minha velha chave pública, não com a minha nova chave. Presumi que ela tinha cometido um erro, e pedi-lhe para tentar novamente com a nova chave. Então, só para ter certeza de que não tinha cometido um erro, decidi verificar que a chave que eu tinha usado era na verdade minha nova chave. Não foi nada. A nova chave que enviei nem sequer era uma das minhas chaves públicas! Era sua chave pública com isso no topo: “—–BEGIN PGP PUBLIC KEY BLOCK—– Versão: GnuPG v1”! De alguma forma eu tinha exportado sua chave com “Versão: GnuPG v1” adicionado a ele! Eu sei, porque eu ainda tinha o arquivo que ela me enviou com a chave, e começa com, “—–BEGIN PGP PUBLIC KEY BLOCK—–“. Não diz: “Versão: GnuPG v1”! E a chave pública dela bate com a que eu mandei.

Eu reexportei minha chave pública com o mesmo comando mostrado acima. Desta vez, verifiquei que era a minha chave antes de enviar por e-mail para ela. Eu também vi ao procurar por mais informações do GnuPG na Internet que uma mensagem-chave secreta perdida pode ser gerada se duas pessoas estiverem usando versões diferentes do GnuPG. Eu mencionei isso a ela quando enviei a nova chave.

Algumas semanas depois, recebi um e-mail de volta. A essa altura, eu tinha assumido que ela tinha desistido. Durante as semanas de intervenção, tive alguns problemas de computador que me fizeram ter que reformar meu disco rígido. Então, tive que reinstalar o GnuPG, reimportar minhas chaves e reimportar a chave pública dela. Por sorte, eu tinha feito backups! Respondi então ao seu último e-mail com outro e-mail criptografado, que criptografei com este comando:

gpg --encrypt --sign --armor -r her-email@her-email-provider.com --passphrase my-pass-phrase my-msg.txt

Claro, eu substituí minha senha real, por “minha frase de passe” e minha mensagem de texto simples não criptografada para “my-msg.txt”. A mensagem criptografada foi criada, e seu nome de arquivo era “my-msg.tx.gpg”. Não consegui encontrar nenhuma informação explicando como descriptografar minha própria mensagem criptografada, então tive que enviá-la para ela sem saber se a tinha criptografado corretamente. Tudo o que eu sabia era que parecia que era o tamanho correto. Algumas semanas depois, recebi um novo e-mail criptografado dela sobre um assunto diferente. Não até então eu tinha alguma confiança de que eu tinha finalmente chegado ao ponto onde poderíamos nos comunicar com sucesso por e-mail criptografado. Todo o processo do início ao fim tinha levado mais de um mês! Ainda estou tentando obter os comandos GnuPG documentados o suficiente para que eu possa usá-los sem ter que pensar muito sobre o que estou fazendo.

Aprendi com essa experiência que o e-mail criptografado, embora um exercício interessante, não é muito prático. A menos que talvez, você seja Edward Snowden com a NSA atrás de você, você provavelmente não tem nada a dizer que justifique o trabalho envolvido na configuração e uso de e-mail criptografado. E, a menos que você seja alguém como Edward Snowden com enormes segredos para revelar, provavelmente ninguém estará disposto a gastar o esforço para manter uma conversa de e-mail criptografada com você.

Criptografar e descriptografar e-mails do jeito que eu fiz, com o GnuPG, é muito tedioso. Como já coloquei a maior parte do trabalho para aprender como, continuarei usando-o para me comunicar com meu conhecido online. Mas, eu não recomendaria que a pessoa comum use GnuPG para e-mails criptografados se puder evitá-lo. Meu entendimento é que algumas soluções mais fáceis estão disponíveis de provedores de e-mail específicos, como o Protonmail, mas a maioria das pessoas não vai querer mudar os provedores de e-mail para tirar proveito delas. Todos nós precisamos de uma maneira mais fácil de enviar e receber e-mails criptografados sem alterar os provedores de e-mail. GnuPG não é a solução.

FONTE: CHEAPSKATE’S GUIDE

Previous post Como a tecnologia pode garantir a segurança do paciente?
Next post Brasileiros ignoram riscos de ataques contra roteadores domésticos

Deixe um comentário