Encryption Part I: Introduction to Encryption 3

Encryption Part I: Introduction to Encryption 3


Welcome to the third video in our series on
Encryption. We’re going to cover practical ways of implementing the types of encryption
we covered in the last two videos. As we’ve mentioned repeatedly, the biggest
issue with encryption is keeping those keys secret. With secret-key encryption, you’re
giving the key to someone else, and you have to trust them. If Alice gives the secret key
to Bob, she has to trust him not to turn around and give the key to Eve. We talked about private key encryption and
how Alice doesn’t need to trust Bob, since the public key she gives Bob can only encrypt
messages and verify digital signatures; only the private key can decrypt and sign messages.
Bob can make sure that only Alice can read his messages, and can verify a message was
sent by Alice, assuming that Eve hasn’t stolen the private key. But there’s a weakness here, and that happens
when Alice first gives Bob her public key. If Eve intercepts this message, she can substitute
her own public key for Alice’s. If she then intercepts Bob’s messages to Alice, then Eve
can use her own private key–without having to steal Alice’s–and decrypt the messages
and sign her responses. Bob THINKS he’s using Alice’s public key, but he’s really using
Eve’s. So we need a method of doing a secure key
exchange so that we can verify that we have the correct key. If Alice and Bob get on the
phone or a video chat, then they can make sure Bob can send test messages to Alice encrypted
with her private key. They’d be able to tell instantly if Alice can receive and decrypt
the messages, and if she can’t–if Eve is pulling something–then they’d be able to
tell right away, and since Bob just sent a harmless test message Eve doesn’t get anything
important. We also need a method of key revocation. If
Alice learns that her private key has been compromised, if she thinks there’s even a
chance that Eve has stolen it, she needs to let Bob know, and generate a new public/private
key pair and send the new public key to Bob. PGP is a de facto standard for securely encrypting
email. People can exchange public keys through keyservers, like this one at MIT. But since
anyone can upload any key they want, how do you know that you’re really getting the right
key for that person? If Bob and Alice exchanged keys in person
or over the phone or video chat, they know they got the correct key. They can then “trust”
that key. Bob can sign Alice’s key using his private key, and give it a level of trust.
There are 5 levels of trust in the PGP standard: 1. I don’t know
2. I do NOT trust 3. I trust marginally
4. I trust fully, and 5. I trust ultimately Bob and Alice each trust their own keys ultimately–because
it’s their key, after all. But they shouldn’t do that with any other key; Bob should not
trust Alice’s key ultimately and vice-versa. What they should do is an indirect trust,
which happens when they sign the key. So Bob signs Alice’s key, and he can give it one
of 4 trust values: 0. I don’t know
1. I have done no checking 2. I have done casual checking, and
3. I have done very careful checking So since they actually got together, exchanged
keys, and verified them, Bob can sign Alice’s key at level 3. Let’s bring in a third person: Carol. Carol
has also exchanged keys with Bob. Although she hasn’t directly exchanged keys with Alice,
Bob has, and Carol trusts Bob enough to trust his evaluation of Alice’s key. So she doesn’t
need to go over the whole thing again with Alice; as long as she trusts Bob enough to
make sure Alice can be trusted, she can trust Alice, too. This is called a “Web of Trust.” A key can be trusted by answering two questions:
1. How many other keys trust this one, and 2. How trustworthy are THOSE keys? If Carol
is sloppy about which keys she trusts, Alice and Bob might not trust keys signed by her
that much. Also, Alice’s trust of Bob means that, since she trusts Bob, she’ll accept
Bob’s evaluation when he trusts Carol’s key at a lower level, or distrusts Eve’s key entirely. Bob can also generate a new key any time he
wants, and sign it with his old key to let people know it’s genuine. He can then revoke
this older key. Keys can also be set to expire at a certain date. Threema is a smartphone app that lets users
send secure messages from one smartphone to another. Unlike PGP, there’s no web of trust
here; they do have public keys on their server, but that only gives the user an “orange” verification
level. The way to get the “green” level is to exchange keys directly, and here’s how
it works: Alice and Bob get together with their smartphones.
They pull up the Threema app, and have it display their public keys on the screen in
the form of a QR code. They then scan the QR codes directly from each other’s phone.
Since they can be sure that no one else has monkeyed around with this exchange, they trust
each other’s key to the highest “green” verification level. This method doesn’t work very well, though,
for things like public web servers. When you shop at, say, Amazon.com, you need to be able
to trust the encrypted connection with Amazon without having to run around and find someone
you trust to sign their key. For this purpose, we use a trusted third party called a Certificate
Authority. Bob gets a certificate from a trusted CA and
puts it on his server. The CA has digitally signed his public key and verified that it
belongs to his website. The private key, as usual, is held solely by Bob on his server.
When Alice connects to Bob’s server, she gets the certificate, and checks its digital signature
to make sure it was signed by the CA. At that point, she knows she can trust that she has
the correct public key for Bob’s server. The third method of implementation is TNO,
or Trust No One. This is used when Alice needs to secure her data, and doesn’t need to exchange
it with anyone else. Financial records, for example. Alice may want to use a third-party service
like Carbonite to back up her data online. By default, Carbonite manages the encryption
keys, which means that they can access the unencrypted data. If Alice wants to make sure
no one else can read it, or needs to comply with something like HIPAA for medical records,
Carbonite gives her the option of making her own encryption key. She then keeps track of
the key herself, and no one else can decrypt the data. But there are disadvantages. First of all,
Alice will lose access to certain features such as accessing her backup files from her
smart phone. Second, Alice has to make sure she doesn’t lose this key–if she does, she
will lose access to all of her backup files. Alice has other options for encrypting files
on her hard drive, laptop, or cloud storage. The 7-zip archive program has an option to
encrypt the archive with strong, industry-standard AES-256 encryption. She picks a secure password
and enters this into the 7-zip interface. This password is then securely turned into
an encryption key which encrypts the files in the archive. No one can get the files out
of the archive unless they know the password, so whether it’s on her hard drive, backed
up with Carbonite, or put on a cloud storage provider like Dropbox, no one can access the
contents without getting her password. Trust No One means that Alice can do whatever
it takes to keep the key secure–but if she ever loses it, she’s out of luck. So in this video, we’ve covered ways of implementing
the encryption methods we talked about in earlier videos. We talked about a key exchange
between individuals who trust each other. We talked about verifying a key with a trusted
authority. And we talked about Trust No One security, where only one person has and needs
the encryption key. In the next video, we’ll complete Part I by
looking at issues that arise with those all-important random numbers.

10 thoughts to “Encryption Part I: Introduction to Encryption 3”

  1. I was a bit confused with the sentence “Bob can sign Alice's key using his private key, and give it a level of trust.” Does this mean that Bob uses his key to assign Alice's key a 1-5 level of truts as defined by the OpenPGP standard? Then, what is the difference between direct and indirect trust? The whole OpenPGP thing confuses me, can someone please elaborate?

  2. Are there any other open source encryption services (similar to 7-zip) that are also cross platform (preferably Mac/Windows/Linux)?

  3. My problem with the example (that I'm loving despite this) is this just seams a bit too over the top if there going though all this trouble why don't they just meat up

  4. So how can we verify if Bob doesnt give his private key to Eve? That could be very bad news to Alice.

    Also: Can we make it possible to only open a document when using both private keys without Alice and Bob knowing the others private key?

  5. Just for test purpose only!
    I have made an encrypted message to myself using my own secret key in PGP4win. Let us see how long it will take technology to be able to decrypt this message without having my secret key. The encrypted message is below!

    —-BEGIN PGP MESSAGE—-

    hQIMA5GvaMUEyLw+AQ/6A+xBs4k2cMhUSVBIbm1fFwFGlRsHAeQRD/EW4OAGRGEQ
    gris5A4tcYJNilsyTM71cHWI+9MaaeattvR0b8/4zy4Ow1A6CQfs5WyEPkA24ybM
    myhMB/XQv8H9u8aCw3wGOJszTPlBkM0k0xcncIkNSsjVD0PbXd0Yu+DQT733ajjx
    9uwe5nVoRh9ok0hQoQjUw3HmBCnyqgA9RsU2qxtg4Setz0xBGJWdmoaZEWaPNEx2
    h3v7rY0CxXuvTTMaJEp1+AF3zCxHyJfMhliE0RaanYrrLLfCY+oum+ZQEXvR3v0I
    utkTSZk6zDikBbE9ciPZBwAxiS+V1Thn/ariZd1Ep33S5vYFF3O2+TQZfDdbb3mi
    vCkADaL204ai3zjduMuzmXzNVaVxg5ObJQhA9lyrBeSGHcgxuLrVjt7TDnEHnY1T
    2ooSssc7lBtRbGxY4+6zUs78orQJfCF5PfU4bBQ2SIghw2rikpdincWnJkh4SkxD
    ydc3mcNP52iwRtNUzSZvKoPli1ibvcaDszI55pAR7vbE3KH69t9k7QeMt61/i6pO
    qB87sGJunXYjqA8ZJJFergrcZ1gDQBq7UeGEeSwdXFs4CRV02E8K4VylvXG3o5yb
    GIUpxuUs/hRa5NTj7zzcjQmlwLGA5QENOSgok7sNYgDw/MR1JPe0PcrLm1a/TS/S
    6QE6B5OHtoBKcdLi4JFtWIi3kYGDmEl4N5UwAS0WKc16axi5vZ+QwWoKN3EJ6eyu
    wFIuPpwB4Q7TOw8phGsurulEeR8QOxk8bPDLRhNkBr4JKWL4YuV9aE6lgo2guzW4
    7mnFB9SS0XxFr4BQcCz4etHlieqexRFE8udsyAJqmD98QYGcdpr+iE33Lvg2FN5A
    SQj8TZZ4wDFC0PLgO4aAQxG64z4zRBIyizQKuFVsUk2NPkjKGkDpK6LAFLoUnc9I
    dZW8xi/8X9jNguy0WGqoX0Kx812i0ZZc0V2bvf2HPBSAY+5MtIzohFBRocQgsS0n
    T+sSDJeX/GDBmbKlputIyLn+KWf0DJUOvP/ZB4WBmXX0M40wGgHmfxhblGshvIou
    8p98bJVhqIGRkn2E4PYHp3yDxEasfnOlTGgU/5O+WW2P9Ly/oCxg6dkNvd62ddha
    RojXIb3tMF9Va0NX6KSvsXzdA3Ef4dtkHqG4C9N2sul5PCHTjdNFjlqv+VaSfrJd
    Tl82I6RQlWDN/aTQf+5RZAAfy71s78HsklEyvH1JhIWk+IQg/y9Oh41M6vF6VnjX
    cgt7AjEVn35gTaB8rMo8covW/7+XAzKv/asVuY7rT91rItD10pBJQfJdpynveoOP
    iCROA+ktYQ9snNY/+mbrFJSYRYjjawKTpt2VBKx8WZrqwHdpfRPVO30DiLhnF6fP
    RqW7HzcrDp7Z+4slkyHMwaPJTNU/xTOkrssphrGY/XMs8fwy6gtyzDd46vPf953h
    pi/DR0VYgoULVoPgzjPYf04QGqetOWXryELRDBsn4xbxQeHE7Gao9rTrOoAPrfkU
    +kfU28WS7aBRlTDVVJNJ0HnhuWpVjKYJFIYFimGw9VLhDDE8y9D1oGwADBEI+YfT
    ranadxAu+ra5GTtlcUsjnpJFsPlpc3xn5+TUJru6eBVwEvBQhYMDSVJjUlHdgA5y
    cVmDQ+JxniWtgkoXVJzFmxDehTQcq8xyRn8Hzw07M5feytyBBBI2pNgUIrNWU8sK
    GX2B/8UPMzNcAkFzaHa420RnZGKrkZ/qjxmtJK6GxHCYICdcCOpvpD+TdiCU6O7r
    aEWUENKvc9ln5A==
    =ahxD
    —-END PGP MESSAGE—-

Leave a Reply

Your email address will not be published. Required fields are marked *