2020-01-12-securing-communications.html (7093B) - raw

      1 <!-- title: Securing communications -->
      2 <!-- slug: securing-communications -->
      3 <!-- categories: Cryptography -->
      4 <!-- date: 2020-01-12T00:00:00Z -->
      5 <!-- lastmod: 2020-08-10T00:00:00Z -->
      6 
      7 <p>
      8   We use cryptographic techniques daily without really knowing how they work, so I'm going to try
      9   and explain some basic concepts. Let's start with Wikipedia's current definition:</p>
     10 <!-- /p -->
     11 
     12 <blockquote>
     13   <p>
     14     Cryptography or cryptology is the practice and study of techniques for secure communication in
     15     the presence of third parties called adversaries.</p>
     16   <!-- /p -->
     17 
     18   <p>— <em><a href="https://en.wikipedia.org/wiki/Cryptography">Wikipedia's cryptography entry</a></em></p>
     19 </blockquote>
     20 
     21 <p>
     22   One cryptographic process we are all familiar with is encryption, that allows us to change the
     23   contents of a message so only certain people with a "key" can decipher and read it. A simple—and
     24   well known—example of encryption is the <a href="https://en.wikipedia.org/wiki/Caesar_cipher">Caesar cipher</a>
     25   (if you haven't heard of it, check out how it works!).</p>
     26 <!-- /p -->
     27 
     28 <p>
     29   Let's consider the following scenario with three people (or parties): Alice, Bob and Craig. Alice
     30   wants to contact Bob privately, while Craig is trying to eavesdrop. This is all happening through
     31   a network, in this particular scenario, they are communicating through the mail. Craig works at
     32   the postal office, so he could get Alice's letter, open it, read it, put it back in a new envelope
     33   that looks exactly the same as Alice's and then send it to Bob.</p>
     34 <!-- /p -->
     35 
     36 <p>
     37   Craig's attack is known as a man-in-the-middle attack, happening when the attacker is able to
     38   secretly relay information between two parties (and with the ability to change the contents of the
     39   communication). This attack isn't particularly hard to carry out on the Internet, but we are
     40   normally protected by cryptographic methods (that ensure the privacy and authenticity of our
     41   communications).</p>
     42 <!-- /p -->
     43 
     44 <h2>Encrypting a message</h2>
     45 
     46 <p>
     47   Alice knows about the flaws of the mail system, so she decides to encrypt her message. She could
     48   use the Caesar cipher. If Bob knows how much Alice "shifted" the alphabet, he will be able to read
     49   her message, while Craig won't. Or will he? Couldn't Craig just try all the numbers from 1 to 25
     50   and just see which one gives a message that makes sense? And how did Alice tell Bob how much she
     51   "shifted" the alphabet without Craig reading it?</p>
     52 <!-- /p -->
     53 
     54 <p>
     55   Those are good points. We currently use better encryption methods than the Caesar cipher that
     56   tackle these issues. The first concern is talking about a brute-force attack (when the attacker
     57   tries many keys in order to—eventually—find the correct one). We can protect our messages against
     58   brute-force attacks by using an encryption method that admits a huge number of different possible
     59   keys. How big? If you create a key with GPG, the minimum key size is 1024 bits (which gives us
     60   2<sup>1024</sup> different possible keys). How hard would it be to crack it? <a
     61   href="https://www.youtube.com/watch?v=S9JGmA5_unY">This video</a> explains it pretty well for a
     62   key that is 256 bits long (2<sup>256</sup> possible keys). First problem solved! Bob isn't
     63   deciphering our letter anytime soon!</p>
     64 <!-- /p -->
     65 
     66 <p>
     67   About the second issue... How can Alice tell Bob her secret password before they can encrypt
     68   anything? It turns out she doesn't need to do that at all! She can use asymmetric cryptography to
     69   solve this problem. In asymmetric encryption, everyone has two keys<sup id="fnref1"><a
     70   href="#fn1">1</a></sup>: a public key and a private key. Our public key will be <em>public</em>!
     71   Everyone can know it (and that won't put our encrypted messages in danger), while our private key
     72   will only be known to us. When using asymmetric encryption, we encrypt messages using someone
     73   else's <strong>public</strong> key, but only someone with the <strong>private</strong> key will be
     74   able to decipher it.</p>
     75 <!-- /p -->
     76 
     77 <p>
     78   So now Bob can simply send Alice his public key, which she will use to encrypt the message. Only
     79   Bob with his private key will be able to decipher the message. A system of communication that is
     80   resistant to Craig's attacks, so far...</p>
     81 <!-- /p -->
     82 
     83 <h2>Signing a message</h2>
     84 
     85 <p>
     86   Craig can't decipher the message, so he might try another strategy: change it! He will get Alice's
     87   letter, destroy it, and send a different one to Bob (making it look like it came from Alice). The
     88   communication is private, but not secure yet!</p>
     89 <!-- /p -->
     90 
     91 <p>
     92   Once again, cryptographic techniques come to the rescue with the ability to digitally sign
     93   messages (also using asymmetric cryptography). What signing a message does is kind of the opposite
     94   of encryption: Alice can use her <strong>private</strong> key to sign her message, which will
     95   output a new file (the signature). Now, anybody with the message, the signature made by Alice, and
     96   her <strong>public</strong> key can check that the message was signed using Alice's private key,
     97   therefore ensuring nobody changed it (signatures are different for different messages).</p>
     98 <!-- /p -->
     99 
    100 <p>
    101   Now, Craig can still destroy the message and send a different one. However, Bob will realize there
    102   isn't a signature (or the one given doesn't match the message). This will alert Bob that the
    103   contents of the message might indeed not come from Alice. Bob might not be able to get Alice's
    104   message, but Craig will never be able to impersonate her.</p>
    105 <!-- /p -->
    106 
    107 <h2>Final notes</h2>
    108 
    109 <p>
    110   The problem with the digital signature is that there has to be an initial contact that both
    111   parties know has not been compromised<sup id="fnref2"><a href="#fn2">2</a></sup>. This could be
    112   achieved by meeting in person and exchanging keys, although that could be hard for two parties
    113   that live in different parts of the world trying to talk over the Internet. There are methods to
    114   work around this problem, although none is perfect.</p>
    115 <!-- /p -->
    116 
    117 <p>
    118   Hopefully, this post gave you a basic overview of some things that can be done using cryptographic
    119   techniques and how they are necessary when securing our online communications.</p>
    120 <!-- /p -->
    121 
    122 <p><em>Edit</em>: Invidious link has been changed to YouTube as Invidious instance is shutting down.</p>
    123 
    124 <!-- footnotes -->
    125 <hr />
    126 
    127 <ol>
    128   <li id="fn1">
    129     These pair of keys are created in a particular way (that "links" them). I won't get into detail
    130     on how it works (it is beyond the scope of this post), but there is a lot of information on the
    131     Internet if you are interested. <a href="#fnref1" title="Jump back to footnote 1 in the
    132     text">&#8617;</a></li>
    133   <!-- /li -->
    134   <li id="fn2">
    135     If not, the first time Alice sends her public key, Craig could change it a different one and
    136     therefore being able to successfully sign messages with what Bob trusts is Alice's private key.
    137     <a href="#fnref2" title="Jump back to footnote 2 in the text">&#8617;</a></li>
    138   <!-- /li -->
    139 </ol>