As you probably know, PEM is a base64-encoded format with human-readable headers, so you can kind of figure out what you’re looking at if you open it in a text editor.
For example, let’s look at an RSA public key:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
We can see that we have a public key just from the header. But what’s all the base64 stuff? If it’s a public key, we know that there should be a modulus and an exponent hidden in there. And there’s also probably some kind of hint that this is an RSA key, as opposed to some other type of key.
That base-64 payload actually has the potential to contain a lot of information. It’s an ASN.1 (Abstract Syntax Notation One) data structure, encoded in a format called DER (Distinguished Encoding Rules), and then finally base64-encoded before the header and footer are attached.
ASN.1 is used for a lot of stuff besides keys and certificates; it is a generic file format that can be used to serialize any kind of hierarchical data. DER is just one of many encoding formats for an ASN.1 structure — e.g. there is an older format called BER (Basic Encoding Rules) and an XML-based format called XER (you can probably guess what that stands for).
But anyway, what is inside that public key? How can we find out?
Continue reading What’s inside a PEM file?
Let’s Encrypt is old news by now. It launched back in December, so it has been giving away free DV certificates for nearly four months now. Being a TA for a Computer Security course, it’s about time that I actually tried it out.
Let’s Encrypt is a free certificate authority. They grant TLS certificates that you can use to secure your webserver. They are Domain Validated (DV) certificates, which means they will verify that you control the domain name you are trying to certify.
Continue reading My first adventure with Let’s Encrypt on nginx, dovecot, and postfix
DES (Data Encryption Standard) is an old-school block cipher which has been around since the 1970s. It only uses a 56-bit key, which is undeniably too short for use in the modern day. Between the realization that DES is weak in the late 90s and the invention of AES in the early 2000’s, Triple-DES had a brief time to shine.
Triple-DES is just what it sounds like: you run the DES algorithm three times. You use two 56-bit keys, K1 and K2, and apply them in the order K1–K2–K1. The result is a cipher with 112 bits of key strength.
Students often ask me, why not just encrypt twice: K1, K2, done? The reason is that this construction is vulnerable to a particular chosen-plaintext attack, which we call the meet-in-the-middle attack. That is, if the attacker knows your plaintext in addition to your ciphertext, he doesn’t have to try all 2^112 keys. The maximum amount of work he has to perform is actually only 2^56 — not much more than to break single DES.
Continue reading Demonstrating the double-DES meet-in-the-middle attack
Authentication is the process by which a system determines whether a particular user is allowed to access it. There are three widely agreed-upon methods to authenticate a user:
- Something you have.
- Something you know.
- Something you are.
When you use your key to unlock your front door, you are authenticating yourself using something you have. In information security, passwords are the most popular method of authentication; they are something you know. Authentication by something you are (i.e., biometrics) has historically been only a niche practice, but in recent years it has caught on in the realm of consumer electronics.
When Apple announced Touch ID in late 2013, security experts immediately voiced their concern. The authentication mechanism was quickly compromised, and there is still very little that Apple can do about it. Why, you ask? Because fingerprints are inherently insecure.
Continue reading No, fingerprints are not secure