summaryrefslogtreecommitdiff
path: root/content/entry/goodbye-pgp.md
diff options
context:
space:
mode:
authorNicholas Johnson <nick@nicksphere.ch>2022-05-23 00:00:00 +0000
committerNicholas Johnson <nick@nicksphere.ch>2022-05-23 00:00:00 +0000
commit05fa3051e12acddfe320912a93e1927bcf1b64f6df2a14589594144df3b9f3e2 (patch)
treee2f767706bbef2caf24a3fd5ea9147f6866d3fef2c0e732f9b481932e87d67ea /content/entry/goodbye-pgp.md
parent44ef9882132619ead1f888778804893d848b7686a4833e038b67b263165eb933 (diff)
downloadjournal-05fa3051e12acddfe320912a93e1927bcf1b64f6df2a14589594144df3b9f3e2.tar.gz
journal-05fa3051e12acddfe320912a93e1927bcf1b64f6df2a14589594144df3b9f3e2.zip
Fix spelling errors
Diffstat (limited to 'content/entry/goodbye-pgp.md')
-rw-r--r--content/entry/goodbye-pgp.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/content/entry/goodbye-pgp.md b/content/entry/goodbye-pgp.md
index f7d0aad..8dcb346 100644
--- a/content/entry/goodbye-pgp.md
+++ b/content/entry/goodbye-pgp.md
@@ -78,7 +78,7 @@ Like signing keys, you can manually rotate encryption subkeys to protect past em
## No Message Padding
If that's not enough to convince you not to use PGP for messaging, let me give you another reason. PGP uses CFB, a padding-less encryption mode. That means the exact length of the encrypted message can be recovered by attackers without decrypting the message.
-If you use PGP for email, you should at least use PGP/MIME to hide attachment filetypes. Leaking filetype and length is bad, but leaking length alone is still pretty bad since it can be used to infer file and message content.
+If you use PGP for email, you should at least use PGP/MIME to hide attachment file types. Leaking file type and length is bad, but leaking length alone is still pretty bad since it can be used to infer file and message content.
PGP is also unsuitable for automated decryption since it's vulnerable to padding oracle attacks.[11]
@@ -112,9 +112,9 @@ I'm not saying long-term identity keys are useless. I have one myself. I'm also
GPG protects long-term identity keys by allowing users to have online subkeys, which frees up the primary key to be kept offline. But it's not clear to me that subkeys are necessary. Why not use a single key kept on dedicated hardware like a Yubikey? GPG's implementation of subkeys can certainly be improved. It's so lacking that it forces some users to rely on multiple keys.[18]
### SSH
-For the SSH use case, the GPG agent can be used for SSH authentication. However, OpenSSH already provides a remote login client capable of key generation that comes pre-installed on popular Linux distros.
+For the SSH use case, the GPG agent can be used for SSH authentication. However, OpenSSH already provides a remote login client capable of key generation that comes preinstalled on popular Linux distros.
-The OpenSSH server also doesn't have a concept of key revocation or expiry. It can't because that might leave clients locked out. Revoking compromised keys does nothing to stop attackers from SSH'ing into servers, which may cause confusion.
+The OpenSSH server also doesn't have a concept of key revocation or expiry. It can't because that might leave clients locked out. Revoking compromised keys does nothing to stop attackers from SSH-ing into servers, which may cause confusion.
### Password Management
For password management, there's no reason to use GPG either. The standard Unix password manager Pass[19] depends on GPG2, but there's a fork of it called Passage[20] which uses Age instead.
@@ -124,7 +124,7 @@ There are also other password managers which don't depend on PGP or Age and they
### Organizational Security
OpenPGP CA[21] is PGP software for organizations. It uses sequoia-pgp[22], which seems to be an improvement over GPG.
-For intra-organizational communication, there are so many secure messaging platforms which are better than PGP over Email. No organization should rely on PGP over email for internal communications. Period.
+For intraorganizational communication, there are so many secure messaging platforms which are better than PGP over Email. No organization should rely on PGP over email for internal communications. Period.
There are already mature identity management systems for organizations such as OpenLDAP[23]. I'm no sysadmin but I'm sure there's plenty of non-PGP dependent software which can meet organizational needs.