Security on the Internet is full of buzzword terminology and endless acronyms: Public keys, private keys, key exchange, SSL, SSH, PGP. In an attempt to clear up at least a little bit of the mess, we have put together a video that explains basic Diffie-Hellman key exchange using tennis balls.

Everyone understands tennis balls.

If you can’t be bothered to watch the whole video, here’s the basic sequence of events (without the tennis balls, though, so you might want to go watch the vid):

• We start with our own private key that we want to use to swap secret messages. This is something only we know and that can be used to encrypt messages between us
• We encrypt this with our own ‘padlock’ - a private encryption method that only we know. It is important that this is commutative with the other party’s encryption method (I.e. that they can be applied and removed in any order) as we’ll see below
• We send this message to the other party, who encrypts it with their own ‘padlock’ or private encryption method. They send the doubly-encrypted package back to us
• We now remove our ‘padlock’ or decrypt using our private decryption method leaving our private key protected only by the other party’s encryption and send it back to them
• By decrypting at their end, they finally securely receive the private key we have been trying to send them all along
• At any point in the future, message can now be encrypted in such a way that the private key can decrypt them and sent safely between us in the knowledge that only these two parties have access to the private key for decryption

It should be noted that the scheme described above has no checking of authenticity of either the other party of the message and so real-world encryption uses more sophisticated algorithms to avoid ‘man in the middle’ and other attacks, but this demonstrates the basic elements of key exchange.

Music: Electricity

Isn’t it easy to get confused about nameservers, registrars, domain names, ICANN, whois and so forth? The underlying concepts for building a resilient distributed network might not be too tricky, but as soon as you actually start making that network resilient, distributed and public, it can get mighty complicated.

To make it all simple, we have put together a video that explains how navigating to a URL works, behind the scenes.

To make it all even more simple, we’ve done it with tennis balls. Everyone understands tennis balls.

If you can’t be bothered to watch the whole video, here’s the basic sequence of events (without the tennis balls, though, so you might want to go watch the vid). If we want to get the homepage for www.google.com:

• First, the PC sends a request to ICANN in order to find the registrar for Google.com.
• The answer comes back that we need to be talking to the server at whois.enom.com
• Behind the scenes, the PC then needs to find out which nameservers can tell where www.google.com is hosted (whois -h whois.enom.com google.com)
• Once the PC discovers that the answer is ns1.google.com (among others) - with an IP address of 216.239.32.10, we can then dig 216.239.32.10 www.google.com to find out which host we should approach for the web page
• The answer is 64.233.187.99 (among others - I think they might do a bit of load-balancing!).
• This means we now have all the information required to send a GET request to that IP address and receive back the information we need to display the page

Music: Walking the dogg