Monthly Archives: March 2018

Public Key Cryptography

Leave a reply

We talked about how in cryptography you want your key to be complex so people can’t guess it.  Otherwise, why encrypt if they can figure out how to decrypt it easily?  We need another play to fix this. We’re going to talk about that other plan, it’s called Public Key Cryptography.

Public Key Cryptography means I have a public cryptography key.

Public Key

Public Key

I can use that to encrypt anything I want, but I can’t use it to decrypt anything.  It’s like having a key to your house that will only lock doors, but not unlock them.  I can lock the house up when I leave, but there’s no way for me to get back inside.  This means I can share the key because there’s no worry that someone will break in using it.  In Public Key Cryptography, I share my public key with the world and they can encrypt things they want to send me.

Private Key

Private Key

This is my private key, it’s purple because that’s my favorite color and this is my favorite key.  It’s the one I can use to unlock doors, or in encryption terms, I can use it to decrypt anything that’s encrypted with my public key.

This sounds pretty safe, right?  It’s actually used in something called Pretty Good Privacy so we’ll call it Pretty Safe Public Key Cryptography.  Well, not really, the real name doesn’t have Pretty Safe as part of it, but it’s still a good name.

It’s also used in web traffic.  If you go to a website using https:// rather than http://, you’re making a secure connection that encrypts your traffic.  That’s done using Public Key Cryptography, it’s just under the hood so you don’t see it.

Pretty cool, right?

 

Encryption and Cryptography

Leave a reply

Encryption and cryptography are two words we hear all the time. We want to hide our information from prying eyes. Cryptography is the math that makes it work, encryption is the process that does the work. We’re not going to talk math, I promise. We’ll talk encryption instead, that’s more fun.

Encryption and cryptography are two words we hear all the time. We want to hide our information from prying eyes. Cryptography is the math that makes it work, encryption is the process that does the work. We're not going to talk math, I promise. We'll talk encryption instead, that's more fun. <KEY/Lock> Let's start with two kinds of encryption. One way encryption and two way encryption. If I encrypt something with a one-way method, then I can't get it back. It's like locking a padlock then throwing away the key. That sounds silly, right? Why on earth would I lock a padlock and throw away the key? Well, this being computers it's not exactly like locking a padlock and throwing away the key. When you use one-way encryption, what you get back is a unique combination of characters that means eactly what you encrypted. You can't decrypt it to find out what it was to begin with, but you can encrypt a word and see if it matches that weird looking string of characters you have.

Lock and Key

Let’s start with two kinds of encryption. One way encryption and two way encryption. If I encrypt something with a one-way method, then I can’t get it back. It’s like locking a padlock then throwing away the key.

That sounds silly, right? Why on earth would I lock a padlock and throw away the key?

Well, this being computers it’s not exactly like locking a padlock and throwing away the key. When you use one-way encryption, what you get back is a unique combination of characters that means eactly what you encrypted. You can’t decrypt it to find out what it was to begin with, but you can encrypt a word and see if it matches that weird looking string of characters you have.

Sounds weird, right? It’s actually the method used for passwords. That way no one has any idea what your password is, they just know what the hash looks like. You type your password in, the system encrypts it and compares it to what they have on file. If it matches, then bingo, you’re in.

Here’s an example, suppose Tony Stark’s password is ShellHead. Then the password could look like:

$_OIhfVvnK$.UYVFlACkTI

That doesn’t look anything like ShellHead, does it? So figuring out what the password is just by looking at that is impossible.

Suppose I type in ShellHea instead of ShellHead. Then the password could look like:

$_jCoO/YKY$GeTermseGL2

That isn’t anything like ShellHead’s password, so I’m not getting in.

How do people break passwords then? It’s called a dictionary attack. They run through all the words in the dictionary in various combinations and encrypt each one. Then they compare it to the password string of characters and if it matches, they have your password.

That’s why choosing a good password is so important! You don’t want people breaking into your system, do you? Imagine the damage someone could do if they broke into Batman’s computer.

More DNS Records

Leave a reply

In the last post we talked about some common DNS records.  There’s more DNS records to talk about but we’re going to only talk about the common ones.  This is a good thing, because there’s 39 of them.  We could be talking about more DNS records for quite some time.

Suppose you have a domain, let’s call it rhodey.example.com.  We know that rhodey.example.com is always going to do what the domain tonystark.example.com does.  So if we change tonystark.example.com’s IP address, we have to and change the IP address for rhodey.example.com.

Rhodey and Tony Stark at work

Rhodey and Tony Stark at work

We’re lazy though, we don’t want to have to do that every time.  Plus, fumble fingers me could get the IP address wrong for rhodey.example.com.   Instead, I’ll use the CNAME record.  That’s the record that let’s one domain say ‘hey, what that domain over there is doing, I want to do.’

There’s no rule that a CNAME record has to exist.  We can find them using:

Alpha:~ computerlamp$ host -t CNAME google.com
google.com has no CNAME record

There’s nothing there!  Well, I said there’s no rule that something had to be there, and nothing’s there.  You should try it with some of your favorite domains and see if they have a CNAME.

The next record we’re going to talk about (and the final one, for now) is the TXT record.   That’s read as ‘text’.  It was meant for human readable information to be stored in DNS, but these days it’s most often used for machine readable information.  Which is kind of boring.

Let’s try one out:

Alpha:~ computerlamp$ host -t TXT akamaihd.net
akamaihd.net descriptive text "This" "is" "not" "the" "nameserver" "you" "are" "looking" "for."

Aww, and I was looking for Artoo Detoo.

TXT records aren’t required either.  Look what happens when I try:

Alpha:~ computerlamp$ host -t TXT theavengers.com
theavengers.com has no TXT record

 

DNS Records

Leave a reply

We know what MX records are, we know what SOA records are, so now we want to learn what other records are available. Every time you query DNS for something, you’re asking for a record and according to Wikipedia there are 39 record types.  Not all of these are commonly used, so let’s talk about the common ones.

When you ask a name server for an IP address for a domain, you’re asking for an A record.  The way to make this query is:

Alpha:~ computerlamp$ host -t A www.google.com
www.google.com has address 209.85.144.105
www.google.com has address 209.85.144.103
www.google.com has address 209.85.144.147
www.google.com has address 209.85.144.106
www.google.com has address 209.85.144.99
www.google.com has address 209.85.144.104

See that -t flag?  That tells the command host to look for the record type A.

We’ve discussed name servers before too.  How do I find out the name servers for google.com?  The DNS record to query for a name server is the NS record.  That means the query looks like:

Alpha:~ computerlamp$ host -t NS www.google.com
google.com name server ns1.google.com.
google.com name server ns2.google.com.
google.com name server ns3.google.com.
google.com name server ns4.google.com.

If you can ask for an IP address for a domain, can you ask for a domain if you have an IP address?  Well, yes, you can.  That’s a PTR record.  That’s pronounced pointer record, by the way.  It’s the reverse of an A record and is known as a reverse lookup.

And once again, you can look it up with the host command:

Alpha:~ computerlamp$ host -t PTR 209.85.144.105
105.144.85.209.in-addr.arpa domain name pointer qv-in-f105.1e100.net.

There’s a couple of weird things about that response.  First of all, I used an IP address from the responses for www.google.com, but I got a different domain back.  Which is actually just fine.  One IP address can have a lot of domains with A records for it, but only one reverse record.

Second, it reversed my domain!   You see that

105.144.85.209.in-addr.arpa

response?  That looks weird, doesn’t it?  Well, it’s one of the underpinnings of DNS that makes all things work nicely.  All PTR records are in the domain in-addr.arpa.  Remember, it’s the Domain Name System, so there has to be a domain. We take that IP address, reverse it so that instead of 209.85.144.105 we get 105.144.85.209 and stick it in front of that domain.  That’s what we’re actually querying for when we make a reverse lookup.