updated namecoin post

_posts/2013-10-25-namecoind-ssl.md

@@ -17,7 +17,7 @@ A component of our current solution is to deliver the site's javascript (and all
 other assets, for that matter) using SSL encryption. This protects the files
 from tampering in-between leaving our servers and being received by the client.
 Unfortunately, SSL isn't 100% foolproof. This post aims to show why SSL is
-faulty, and propose a solution using.
+faulty, and propose a solution.
 
 # SSL
 
@@ -34,57 +34,59 @@ a key isn't ever re-used and so only the client and the server know it.
 
 ## Public-Private Key Cryptography
 
-There exists something called public-private key cryptography. In this system
+SSL is based around public-private key cryptography. In a public-private key
-person A has a public and a private key. They can give the public key to anyone
+system, you have both a public key which is generated from a private key. The
-at all that they want to talk with, doing so can't hurt them. They must keep the
+public key can be given to anyone, but the private key must remain hidden. There
-private key secure from everyone but themselves. If they give their public key
+are two main uses for these two keys:
-to person B, then person B can use it to create a message that can only be
-decrypted by the private key. Additionaly, person A can sign messages with their
-private key, so that anyone with the public key can verify that the message came
-from person A and that the contents of the message haven't been tampered with.
 
-There are two problems with public-private key cryptography. First, it's slower
+* Someone can encrypt a message with your public key, and only you (with the
-then normal cryptography where both parties simply share the same key. Second,
+  private key) can decrypt it.
-it assumes that the public key given to person B hasn't been tampered with. If
+
-person C intercepted A's message to B and instead gave B a different public key,
+* You can sign a message with your private key, and anyone with your public key
-then when B encrypted a message with that key C would be able to read it instead
+  can verify that it was you and not someone else who signed it.
-of A.
+
+These are both extremely useful functions, not just for internet traffic but for
+any kind of communication form. Unfortunately, there remains a fundamental flaw.
+At some point you must give your public key to the other person in an insecure
+way. If an attacker was to intercept your message containing your public key and
+swap it for their own, then all future communications could be compromised. That
+attacker could create messages the other person would think are from you, and
+the other person would encrypt messages meant for you but which would be
+decrypt-able by the attacker.
 
 ## How does SSL work?
 
-SSL is at its heart a public-private key system. The client uses the server's
+SSL is at its heart a public-private key system, but its aim is to be more
-public key to send the server an encrypted message with the symmetric key it
+secure against the attack described above.
-wants to use. Since it's only used in the initial setup of the connection to
-negotiate a symmetric key the speed isn't as much of a factor. But getting the
-client the server's public key is.
 
 SSL uses a trust-chain to verify that a public key is the intended one. Your web
 browser has a built-in set of public keys, called the root certificates, that it
 implicitly trusts. These root certificates are managed by a small number of
-companies designated by some agency who decides on these things. These companies
+companies designated by some agency who decides on these things.
-sign intermediate certificates for intermediary companies. These intermediary
+
-companies then sign certificates for websites to serve with SSL. So when you get
+When you receive a server's SSL certificate (its public key) that certificate
-a servers SSL certificate (its public key) you also get the signing chain. Your
+will be signed by a root certificate. You can verify that signature since you
-browser sees that the server's key is signed by an intermediate public key, and
+have the root certificate's public key built into your browser. If the signature
-that that intermediate public key is signed by one of the root public keys. As
+checks out then you know a certificate authority trusts the public key the site
-long as all signatures check out, the public key for the server you're talking
+gave you, which means you can trust it too.
-to also checks out.
+
+There's a bit (a lot!) more to SSL than this, but this is enough to understand
+the fundamental problems with it.
 
 ## How SSL doesn't work
 
 SSL has a few glaring problems. One, it implies we trust the companies holding
 the root certificates to not be compromised. If some malicious agency was to get
-ahold of a root certificate they could man-in-the-middle any connection on the
+ahold of a root certificate they could listen in on any connection on the
-internet they came across. They could trivially steal any data we send on the
+internet by swapping a site's real certificate with one they generate on the
-internet. Alternatively, the NSA could, [theoretically][nsa], get ahold of a
+fly. They could trivially steal any data we send on the internet.
-root certificate and do the same.
 
 The second problem is that it's expensive. Really expensive. If you're running a
 business you'll have to shell out about $200 a year to keep your SSL certificate
-signed (those signatures have an expiration date attached, of course). Since
+signed (those signatures have an expiration date attached). Since there's very
-there's very few root authorities there's an effective monopoly on signatures,
+few root authorities there's an effective monopoly on signatures, and there's
-and there's nothing we can do about it. For 200 bucks I know most people simply
+nothing we can do about it. For 200 bucks I know most people simply say "no
-say "no thanks" and go unencrypted. The solution is causing the problem.
+thanks" and go unencrypted. The solution is creating a bigger problem.
 
 # Bitcoins
 
@@ -103,7 +105,7 @@ they work.
 # Namecoins
 
 Few people actually know about bitcoins. Even fewer know that there's other
-cryptocurrencies besides bitcoins. Basically, developers of these alternative
+crypto-currencies besides bitcoins. Basically, developers of these alternative
 currencies (altcoins, in the parlance of our times) took the original bitcoin
 source code and modified it to produce a new, separate blockchain from the
 original bitcoin one. The altcoins are based on the same idea as bitcoins
@@ -133,7 +135,7 @@ have [lots of issues][dht] as far as security goes, the main one being that it's
 fairly easy for an attacker to forge the value for a given key, and very
 difficult to stop them from doing so or even to detect that it's happened.
 
-Namecoins don't have this problem. To forge a particular key an attacker whould
+Namecoins don't have this problem. To forge a particular key an attacker would
 essentially have to create a new blockchain from a certain point in the existing
 chain, and then replicate all the work put into the existing chain into that new
 compromised one so that the new one is longer and other clients in the network
@@ -152,18 +154,19 @@ constantly increasing). When they find one they broadcast it out on the network.
 Assuming the block is legitimate they receive some number of coins as
 compensation.
 
-This last step is the crucial piece. Receiving compensation for doing the work
+When a block-chain based currency like bitcoin and namecoin, the element of the
-of putting a block onto the chain is what keeps the bitcoin style of
+system that keeps the currency going is there is compensation for doing the work
-crypto-currency going. If there were no compensation there would be no reason to
+of getting items placed on the blockchain.  If there were no compensation there
-mine except out of goodwill, so far fewer people would do it. Since the chain
+would be no reason to mine except out of goodwill, so far fewer people would do
-can be compromised if a malicious group has more computing power then all
+it. Since the chain can be compromised if a malicious group has more computing
-legitimate miners combined, having few legitimate miners is a serious problem.
+power than all legitimate miners combined, having few legitimate miners is a
+serious problem.
 
 In the case of namecoins, there's even more reason to involve a currency. Since
 you have to spend money to make changes to the chain there's a disincentive for
 attackers (read: idiots) to spam the chain with frivolous changes to keys.
 
-### Why a new currency?
+### Why a *new* currency?
 
 I'll admit, it's a bit annoying to see all these altcoins popping up. I'm sure
 many of them have some solid ideas backing them, but it also makes things
@@ -176,9 +179,9 @@ about this problem my instinct was to just use the existing bitcoin blockchain
 as a key-value storage. However, the maintainers of the bitcoin clients
 (who are, in effect, the maintainers of the chain) don't want the bitcoin
 blockchain polluted with non-commerce related data. At first I disagreed; it's a
-P2P network, no-one gets to say what I can or can't use the chain for, and they
+P2P network, no-one gets to say what I can or can't use the chain for!  And
-can't stop me! And that's true. But things work out better for everyone involved
+that's true. But things work out better for everyone involved if there's two
-if there's two chains.
+chains.
 
 Bitcoin is a currency. Namecoin is a key-value store (with a currency as its
 driving force). Those are two completely different use-cases, with two