Luckily, we can use OpenSSL to check whether a public and private key match.

For RSA keys

The classic way to compare RSA keys is to check whether the modulus is the same, as this is the only part that is shared between the public and private keys. If the modulus isn't the same, the keys can't form a pair.

Read the modulus from the public key:

openssl rsa -pubin -in public.pem -modulus -noout | openssl sha1

Then do the same with the private RSA key:

openssl rsa -in private.pem -modulus -noout | openssl sha1

If the two values match, the key files form a pair.

Note that we're piping the actual output of the -modulus command to openssl sha1 to get a shorter hash of the modulus. This makes it easier to manually compare the two values, but it's not strictly necessary. You could also compare the output directly if you're feeling brave.

For EC keys

Elliptic curve keys don't have an easy-to-compare modulus like the RSA keys above had. However, it's always possible to generate the public key² part when we have the private key.

Using the private key, generate (a hash of) the public key:

openssl pkey -pubout -in private.pem | openssl sha1

Then compare the output with the public key file you have. We need to make openssl load it and print it out again to make sure we get the exact same format.

openssl x509 -pubkey -in public.pem -noout | openssl sha1

If the two values match, these keys form a pair.

I had noticed before that the passwords generated by pwgen seemed to contain patterns: repeating vowels is something that stands out. I hadn't thought about it much, until I saw a colleague type pwgen -s at his terminal.

What is this -s?

As with most unix-y tools, a quick glance at the man page tells us everything we want to know. The -s is shorthand for --secure:

Generate completely random, hard-to-memorize passwords. These should only be used for machine passwords, since otherwise it's almost guaranteed that users will simply write the password on a piece of paper taped to the monitor...

As it turns out, pwgen actually doesn't generate secure passwords by default. The passwords it generates are designed to be easily memorized. That explains the patterns I noticed before!²

They've been really great in responding to these problems: publishing more than enough information on their website and fixing the issues blazingly fast. However, the number of issues we're currently seeing shows that they've done no independent security audit. (Or maybe they have, but in that case they seem to have paid monkeys instead of security experts.)

Another reason to leave LastPass is the issues I've had with synchronisation lately. Changing data in your vault, only to see it disappear after you've restarted the application is horrible. I've had to reset quite a lot of passwords in the last few months.

Back to KeePass

Before LastPass I had been using KeePassX for a while, which is a Qt port of the well known KeePass password manager. The problem with that piece of software is that filling passwords automatically didn't really work on all platforms. As I had to use macOS at work, this really wasn't an option anymore. Having to manually copy and paste passwords makes for a horrible experience, especially in time critical situations.

During my two years with Lastpass, however, an alternative popped up!

Meet KeePassXC

KeePassXC is a fork of KeePassX, and they've added more than a letter! Development on their Github page is going fast. The currently released version is pretty good, the next one has new goodies such as OTP code generation with autofill. Most important: it supports autofill in both browser and other applications on Windows, Linux and MacOS.

Let's be honest: when it comes to browser support, LastPass is amazing. However, combined with third-party browser plugins (over the KeePassHTTP protocol) using KeePassXC in browsers is just fine. The browser plugin does not access your password database directly, but has to ask for every password it wants to use. At this point, the desktop client asks for your permission before even sending the password to your browser.

Keeping things in sync

As with the other KeePass-apps, there is no built-in synchronisation. The password database is stored as a single encrypted file. It's up to you to make sure this file is available wherever you'll need your passwords. KeePassXC is able to merge databases, and does so automatically when the open database file is modified by another process. This makes it slightly easier to use KeePassXC with apps like Syncthing or Dropbox.

Why do we need two-factor authentication?

Online authentication used to rely on remembering a password. This is by far the easiest solution, but it has a few drawbacks. People are bad at remembering things, especially if they don't use them every day. This results in passwords being written down and attached to computer screens and keyboards. Even worse is that most people use the same password for every site they visit.

Using the same password on multiple sites becomes a problem when one of them leaks user credentials. Trying out the leaked username/e-mail and password combinations may give access to a lot of other sites, creating an avalanche effect.

Two-factor authentication attempts to solve this problem by combining the password with a physical item. A mobile device or hardware token generates an access code, usable for a limited time only. This means that someone who knows your password is still unable to access your account. Great!

How does two-factor authentication work?

An authenticator app generates an access code based on a secret and the current time. This code changes every 30 seconds, but can usually be used for about 5 minutes. Every site gives you a unique secret, and thus you can't use a single code for multiple sites.

Notice that I talk about "an authenticator app" and not a specific application? These services support the TOTP or HOTP standard. There are a lot of applications that allow you to generate these access codes. The most well-known is the Google Authenticator, but there are many more! On every platform and for every device. Even if you're using a 10 year old smartphone, chances are you'll find a suitable two-factor application.

And then there was Authy

Authy provides a solution for websites that makes it easy to implement two-factor authentication. This is a good thing as it allows more organisations to use 2FA. Their own authenticator app provides a few extra features too. Unfortunately, in order to do this, they decided to take an open standard and completely break it. They deliberately prevent you from using any other app than their own. As usual, this is a one way situation: you can import other accounts to authy, but not the other way around.

When asked about other apps, their customer support replied:

Are you asking about using Authy-powered tokens with third-party apps? If so, we do not support that feature, but many of our clients support authentication via SMS or phone calls.

Sure, their own app has a few amazing features. It allows you to backup an encrypted copy of your secret keys to the cloud, for example. But is that worth it? What if you're using a platform that doesn't have an Authy app? As more organisations switch to Authy, they are effectively ending the freedom of choice when it comes to authenticator apps.

Is this a bad thing? Up to you to decide.

Signing public keys

The GPG software allows you to sign other public keys, similar to how you can sign messages or basically any kind of data. Signing a public key however, has a special meaning. You declare that that, according to you, the key you've signed is real and really represents the listed person or organisation.

There are four signature levels:

• Level 0 signature: no indication. This is the default level and is usually used by people who don't know or don't care about signature levels. A lot of people don't specify the signature level when they sign public keys, so there is no reason to discard these right away.
• Level 1 signature: personal belief but no verification. As the name says this level is used when someone signs a key but was unable to verify the identity. Used for nicknames, most of the time, as you can't really prove the identity behind a pseudonym. Be careful when you encounter a level 1 signature on a key with a full name and e-mail address. These levels have to be specified manually, if someone changes it to level 1, it might be for a reason.
• Level 2 signature: casual verification: These signatures usually mean that people have met and checked identification, but didn't know each other upfront.
• Level 3 signature: extensive verification: The level used when the signer was absolutely sure that the listed name is correct. Usually this means that they have known each other in person for years and have checked government issues identification.

Note that this is the theory. The signature level names (indicated above) are listed in the GPG documentation. The explanation of these levels is unclear and usually very personal. People use them in different ways, and some even have a webpage explaining what their levels mean. And then there's the huge group that only uses level 0 signatures. So in the end, they're just a vague indication.

If you are able to verify the owner of a public key, sign their public key. Most graphical frontends for PGP have an easy way to do this, the command below signs a key using the command line:

$ gpg --sign-key <name>

But why are these signatures important?

Introducing the Web of Trust

You can't know everyone, that's just impossible. I am aware that some people claim to have thousands of friends on social networks, but seriously? However, the people that you know may overlap with the ones I know. What is the easiest solution when you need someone's phone number but have no means to communicate? Ask a mutual friend! And that's how the Web of Trust works.

Let's say that you have a personal friend Alice and want to send an encrypted message to Bob. You met Bob on an online message board and don't know him in person. You could ask Bob to verify the fingerprint of his public key, but someone might be tampering with the connection. It's possible to verify the identity of an internet stranger without meeting him, but it's pretty hard.

Fortunately Alice knows Bob in person, and we are able to verify Alice's key as we can meet her. We could use encrypted and signed communication to ask Alice if the key we have for Bob is correct. But if Alice has signed Bob's key, we don't even have to talk to her! As we trust Alice and her signatures, we are assured that Bob's key is correct.

You --> Alice --> Bob

The more keys you sign and the more people sign yours, the easier it becomes to identify the correct public keys for other people. So when you meet someone that uses PGP, attempt to sign each other's keys. And never sign a key if you are not sure about the person's identity. The strength of the web of trust is your responsibility.

Trust levels

Similar to signature levels, PGP also has a concept called trust levels. You can assign trust to keys in your keyring. This level indicates how much you trust a person's ability to sign other keys.

There are 5 levels:

• Unknown: The default level for keys.
• None: These signatures are ignored completely when calculating the web of trust. Use this when you think someone is not able to make trustworthy signatures.
• Marginal: You have marginal trust in the owner of this key, but don't believe them if they're the only one signing a key. Their signatures are accepted if multiple marginally trusted keys sign the same public key. This level will probably be used the most in your keyring.
• Full: You trust the owner of this key completely. When this person signs a public key, the software trusts that signature as if you have signed it yourself.
• Ultimate: Use this level for your own keys.

To modify the trust level of a key using the command line, edit keys in interactive mode and use the trust command:

$ gpg –edit-key <name>
trust

Combine these levels with the Web of Trust, and you have a way to select the correct public key for people around the world.

Keysigning parties

As you know by now, the strength of the web of trust depends on the number of signatures. Arranging to meet with people one by one takes a lot of time and may be costly, as transportation is not free. That's why people organise keysigning parties. Don't get your hopes up, they're not as fun as they sound.

During these parties people verify each other's keys. Some of these are pretty well organised and require you to register upfront, they then publish an easy to use list of participants and their fingerprints. Smaller parties may require you to bring printed fingerprints yourself. While it may get boring after a while, especially when there are a lot of participants, it's a great time to talk to security-minded people too!

Local signing

Just a note.. In case you really want to sign a key that you can't verify, use local signing. This works the same, but indicates that the signature shouldn't be shared with others. Local signatures never leave your own keyring and thus don't influence the Web of Trust.

$ gpg -lsign-key <name>