Now I Understand Why Almost No One Uses Encrypted Email

栏目: IT技术 · 发布时间: 4年前

内容简介:Encrypted email is painful! I recently discovered just how painful. A very security conscious online acquaintance sent me her public PGP key and asked me to start using encrypted email to communicate with her. No, she's not NSA or C

Encrypted email is painful! I recently discovered just how painful. A very security conscious online acquaintance sent me her public PGP key and asked me to start using encrypted email to communicate with her. No, she's not NSA or CIA, just a regular person interested in maintaining her privacy. I had never sent an encrypted email before, but I thought, "Why not?" This is something I had been wanting to learn to do for years, but I had never had anyone with whom to exchange encrypted email.

I began by installing GnuPG onto my Linux computer. GnuPG is similar to PGP, in that it uses public and private keys for encryption and decryption, but GnuPG is open source and comes for free with many Linux distributions. OpenPGP is another open source version of PGP. GnuPG for Windows can be downloaded from the GnuPG website under the name Gpg4win. I chose a general method of encrypting and decrypting messages that is not tied to any email provider, because I didn't want to limit myself to only being able to use encrypted email with one provider. Also, the only way to make sure that not even your email provider can read your email is to encrypt it yourself. How-To Geek has one of the most useful tutorials on GnuPG that I have found on line.

I imported my acquaintance's public key with this command:

gpg --import her_public_key_file.key

I replaced "her_public_key_file.key" in the above command with her actual public key file. Next, I checked to make sure her key had been imported successfully with:

gpg --list-keys

A message like this appeared:

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

This means that GnuPG recognizes her public key as valid and has stored it for later use.

Next, I signed her public key:

gpg --sign-key her_email_address@email_provider.com

Signing a public key tells GnuPG that you trust that it came from the person you think it came from. Each public key must be signed before messages from the owner of that public key can be decrypted. This step makes no sense to me. Why would you import a key if you didn't think it came from the right person?

I tried generating my keys with this command:

gpg --output ~/temp.key --armor --export My Name 
<myemail protonmail="" com="">

</myemail>

Well, that gave an error message saying that the end of a new line had been encountered. I thought that might be due to the spaces in my name and between my name and my email address, so I tried various formats. After about an hour and many failed attempts, some that looked like they might have been successful but weren't, I finally found the right command:

gpg  --gen-key

The above command guides you with a series of questions to answer. I chose option "1" at the first prompt. I chose the 2048-bit length option for my keys. I made my keys valid forever. For my name, I typed one name, but you can have spaces in your name if you use your first and last names. Then I entered my email address. I left the comment blank. And finally, I entered a strong passphrase. "Passphrase" is just another word for password. I wrote it down somewhere I wouldn't lose it. Actually, I put it into a file encrypted with Truecrypt. You will need your passphrase later to encrypt messages, and in the event that you ever need to re-install GnuPG onto your hard drive and have to re-import your keys. Also, don't forget to make a backup of your keys!

After successfully generating my keys, typing this command at the Linux prompt:

gpg --list-keys

produced something like this:

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 
<myemail protonmail="" com="">
 
sub   2048R/A7B384FE 2020-02-22

</myemail>

I went through the process of generating keys twice, because I wasn't sure if the above result meant I had a pair of public and private keys or just one key. Somehow, I eventually realized that I had created two pairs of keys, so I deleted the second pair.

Next, I tried exporting my public key to a file. Your public key must be sent to anyone to whom you send an encrypted email. The receiver of your message needs it to decrypt your message. I'm not sure what command I used, but it produced a plain text file beginning with "-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1". I emailed this to my acquaintance, and she emailed me back an encrypted message.

When I tried to decrypt her message file, "message.asc", with:

gpg --decrypt message.asc > plain.txt

GnuPG informed me with the following error message that it could not find a secret key:

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

But, I could see my secret key. I could even export it. I knew it was there! Sometimes, people who write code create the worst error messages. At this point, I was becoming rather frustrated.

I didn't know what I had done wrong, but the only thing I could think was that I had somehow failed to create the keys correctly. Either that, or I had exported the wrong public key. So, I decided to start over. I deleted my key pair, generated a new key pair, and exported my public key to a file with this command:

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

Then, I emailed my new public key to my acquaintance. The "--amor" option in the above command tells GnuPG to create the public key file in plain text. The file that is created is "my_public_gpg_key.key".

She re-encrypted her message and sent it back to me. When I tried to decrypt it, I saw the same error message again:

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

This time, I noticed that the key ID matched my old public key, not my new key. I assumed she had made a mistake, and I asked her to try again with the new key. Then, just to make sure I had not made a mistake, I decided to verify that the key I had used was actually my new key. It wasn't. The new key I had sent was not even one of my public keys! It was her public key with this at the top: "-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1"! Somehow I had exported her key with "Version: GnuPG v1" added to it! I know, because I still had the file she sent me with her key, and it begins with, "-----BEGIN PGP PUBLIC KEY BLOCK-----". It does not say, "Version: GnuPG v1"! And, her public key matches the one I sent her.

I re-exported my public key with the same command shown above. This time, I checked that it was actually my key before I emailed it to her. I also saw while searching for more GnuPG information on the Internet that a missing secret key message can be generated if two people are using different versions of GnuPG. I mentioned this to her when I emailed the new key.

A few weeks later, I received an email back. By this time, I had assumed that she had given up. During the intervening weeks, I had some computer problems that caused me to have to reformat my hard drive. So, I had to re-install GnuPG, re-import my keys, and re-import her public key. Luckily, I had made backups! I then responded to her last email with another encrypted email, which I encrypted with this command:

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

Of course, I substituted my actual passphrase, for "my-pass-phrase" and my actual unencrypted plain-text message for "my-msg.txt". The encrypted message was created, and its file name was "my-msg.tx.gpg". I could not find any information explaining how to decrypt my own encrypted message, so I had to send it to her without knowing whether I had encrypted it correctly. All I knew was that it looked like it was the correct size. A couple of weeks later, I received a new encrypted email back from her about a different topic. Not until then did I have any confidence that I had finally reached the point where we could successfully communicate by encrypted email. The whole process from start to finish had taken over a month! I am still trying to get the GnuPG commands documented sufficiently so that I can use them without having to think too hard about what I'm doing.

I've learned from this experience that encrypted email, though an interesting exercise, is not very practical. Unless perhaps, you are Edward Snowden with the NSA on your tail, you probably don't have anything to say that justifies the work involved in setting up and using encrypted email. And, unless you are someone like Edward Snowden with huge secrets to reveal, probably no one will be willing to expend the effort to hold an encrypted email conversation with you.

Encrypting and decrypting email the way I did, with GnuPG, is just too tedious. Since I have already put in most of the work to learn how, I will continue using it to communicate with my online acquaintance. But, I would not recommend that the average person use GnuPG for encrypted emails if they can avoid it. My understanding is that some easier solutions are available from specific email providers, like Protonmail, but most people will not want to change email providers to take advantage of them. We all need an easier way to send and receive encrypted email without changing email providers. GnuPG is not the solution. If you are aware of an easier method for non-real-time encrypted communication, please consider leaving a comment.

If you've found this article worthwhile, please share it on your favorite social media. You'll find links at the top of the page.

Related Articles:

How to Avoid being Tracked and Spied-On while on Line

There's no Such Thing as a Secure Computer--How to be Relatively Secure

What You should Know about Passwords

The Technologically-Challenged Internet User's Guide to Online Privacy

How to make Your Router More Secure on the Internet


以上所述就是小编给大家介绍的《Now I Understand Why Almost No One Uses Encrypted Email》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

学习JavaScript数据结构与算法(第2版)

学习JavaScript数据结构与算法(第2版)

[巴西] Loiane Groner / 邓 钢、孙晓博、吴 双、陈 迪、袁 源 / 人民邮电出版社 / 2017-9 / 49.00元

本书首先介绍了JavaScript 语言的基础知识以及ES6 和ES7 中引入的新功能,接下来讨论了数组、栈、队列、链表、集合、字典、散列表、树、图等数据结构,之后探讨了各种排序和搜索算法,包括冒泡排序、选择排序、插入排序、归并排序、快速排序、堆排序、计数排序、桶排序、基数排序、顺序搜索、二分搜索,然后介绍了动态规划和贪心算法等常用的高级算法以及函数式编程,最后还介绍了如何计算算法的复杂度。一起来看看 《学习JavaScript数据结构与算法(第2版)》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具