In a previous post, I described how to use the openssl tool to encrypt and decrypt files using strong symmetric ciphers like Triple DES or AES. This form of encryption is typically used for making encrypted backups, but it lacks some key features like digital signatures that are only available if we make use of open key cryptography. In this post, I’ll show how Alice and Bob can exchange public keys over an insecure channel, in order to preserve secrecy and integrity of their communications. But if not used carefully, public key algorithms can still be abused by man-in-the-middle attacks.

The key-exchange problem

Alice and Bob are good friends, and they share a lot of common hobbies. Unfortunately, they are living far apart in different countries, and can only communicate over the Internet. One day, they talk about their favorite songs, and Alice keeps raving about that great song of her favorite country singer. So she decides to email countrysong.mp3 to Bob. Strangely enough, Alice’s email bounces. She tried again from another email account, but here too, she’s not able to send that file to Bob. How weird: after all, other emails went through flawlessly, just not the mail with countrysong.mp3!

After a lot of head scratching, emailing and googling, the reason for the bouncing emails soon becomes apparent: Bob is unfortunate enough to be living in a country of the western world which (like most other countries in the West) has allowed itself to be strongarmed or bribed by the RIAA to implement a mandatory internet censorship infrastructure designed to clamp down on file sharing of copyrighted materials. Alice’s email with the country song has simply been caught in the filter and couldn’t make it through to Bob.

What now?

One possible work around would have been for Alice to slightly modify countrysong.mp3 so that it message digests to another check sum, therefore thwarting the censorship infrastructure of Bob’s ISP or Bob’s country’s Great National Firewall. But since Alice and Bob were no programmers, they couldn’t guess that those kinds of filters are essentially based on message digesting whole files or chunks of files in real-time and comparing the digests with a blacklist of copyrighted files.

Fortunately, Bob and Alice belong to the cryptographic family, and so, they agreed upon the following crypto protocol:

  1. Alice would encrypt countrysong.mp3 with AES-256 in CBC mode, using some password. [Update 07/31/2009: Bruce Schneier reports some very intriguing cryptanalytic attacks against AES-256 and recommends to stick to AES-128 for now, until the number of internal rounds for the AES family has been increased. I won’t update the post to reflect this, but you should be aware of it: just replace aes-256-cbc with aes-128-cbc.]
  2. She would then send the encrypted file to Bob.
  3. After a couple of days, she’ll send the password to Bob.
  4. Bob would then decrypt the file, and will enjoy Alice’s favorite country song.

So far, so good. Alice uses the techniques shown in my previous post to encrypt and base-64 encode the file, which she emails to Bob:

(alice) $ openssl enc -a -e -aes-256-cbc -in countrysong.mp3 -out ciphertext.asc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

(alice) $ ls -la
total 9486
drwxr-xr-x    2 alice  users        4 Dec  1 18:37 .
drwx------  159 alice  users      296 Nov 30 20:33 ..
-rw-r--r--    1 alice  users  5566970 Dec  1 18:37 ciphertext.asc
-r--r--r--    1 alice  users  4110965 Dec  1 18:32 countrysong.mp3

ciphertext.asc was slightly larger than countrysong.mp3, but that was because of the base64-encoding and absolutely harmless.

Unsurprisingly, the ciphertext.asc went right through the censorship infrastructure, and landed safely in Bob’s mailbox.

A few days later, Alice sent another email to Bob, telling him just how much she loved the word “cryptme“. That was all Bob needed to know to decrypt the file:

(bob) $ openssl enc -a -d -aes-256-cbc -in ciphertext.asc -out alicesong.mp3
enter aes-256-cbc decryption password:

(bob) $ ls -la
total 13507
drwxr-xr-x    2 bob    users        5 Dec  1 18:40 .
drwx------  159 bob    users      296 Nov 30 20:33 ..
-rw-r--r--    1 bob    users  4110965 Dec  1 18:40 alicesong.mp3
-rw-r--r--    1 bob    users  5566970 Dec  1 18:37 ciphertext.asc

Yes, it worked! Bob enjoyed that song just like Alice, and was really happy.

Flash forward a couple days later. In the wee hours of the morning, a SWAT team fired tear gas grenades into Bob’s house and broke open his door with an armored vehicle. They arrested a half-sleepy Bob in front of his terrified 4 and 5 year old daughters and shocked wife, and hauled him into a supermax prison. His computer was confiscated too. 6 months later, he was charged with digital theft of the highest order (criminal copyright infringement), and sentenced to 35 years without parole for that one file alicesong.mp3. He died in that very same prison mere 9 weeks after his sentence became permanent. Rumors had it, that he didn’t die a natural death, because as a somewhat crypto-savvy computer user, he was deemed a grave threat to his oh-so-democratic government.

How could that happen? Did his government break 256-bits AES in CBC-mode? Probably not. Actually, Alice and Bob were very negligent, and and used a flawed cryptographic protocol, despite them using rather strong cryptographic tools. So what happened exactly?

  1. The first time Alice sent countrysong.mp3 to Bob, she triggered an alarm at Bob’s nation- or provider-wide censorship infrastructure, and raised a red flag.
  2. The infrastructure flagged Bob as suspicious criminal file sharer, and assigned human operator Eve to read all his emails.
  3. Eve read how Alice and Bob agreed on using aes-256-cbc to encrypt the file.
  4. Eve intercepted ciphertext.asc and saved it in Bob’s investigation file for later. Up to now, she wasn’t able to decrypt it yet, even though she expected it would contain the previously intercepted countrysong.mp3. But Bob was already on the hook, and it was merely a matter of time until Eve could close his case.
  5. When Alice finally sent the email with the cryptme password, Eve manually applied it to ciphertext.asc, and got a real MP3 file. She tested this file against the nation-wide blacklist of copyrighted songs, and Bingo! it was a hit.
  6. Eve sent a message to her supervisor, and from then on, a routine arrest operation for criminal file sharing was started. Of course, they found the copyrighted song on Bob’s confiscated computer too, strengthening their case even more, and Bob’s life was over.

To summarize: Alice’s use of strong cryptography prevented automated censorship infrastructure as well as Eve from reading the content of the file. But Alice sending the password in clear text through that insecure channel gave the secrecy away. Eve was able to intercept that password, decrypt the file, then have Bob arrested, framed and finally killed. Evolutionists would say: a fitting punishment for stupidity.

This wouldn’t have happened with public key cryptography, used the right way.

Secrecy with Public Key Cryptography

Alice and Bob’s dilemma was that although they used a strong symmetric cipher, they still had to transmit the password (key) over the same insecure channel than ciphertext.asc. Of course, that’s an absolute no-go. If they had a secure channel, they could have sent the password over that… but then, Alice could also have directly sent countrysong.mp3 over the secure channel, instead of just the key/password, right? Unless that secure channel’s bandwidth was very small compared to the insecure channel, in which case it would still have made sense, of course.

In our case, Alice and Bob don’t have a secure channel at all: neither one with enough bandwidth for the whole plain text, nor one with just enough bandwidth for the password or key. The only channel they have is through the public Internet, that is monitored by censorship infrastructures, Eve et. al.

With public key cryptography, Alice creates a couple of two interrelated keys, consisting of:

  1. A private key that she’ll never send over an insecure channel (she’ll keep it to herself)
  2. A public key that she’ll disseminate as widely as possible (everyone can read it, including Eve)

Bob will do the same on his side. Then, Alice will send her public key to Bob, and Bob will send his public key to Alice. From the on, both can encrypt files with the public key of the recipient.

Creating a key pair

Let’s see how it’s done. Alice will use openssl to generate a couple of private/public RSA keys of 4096-bit length. This couple of keys will be saved in the file aliceprivkey.pem, which she must protect at all costs:

(alice) $ openssl genrsa -out aliceprivkey.pem -des3 -f4 -rand /dev/random 4096
2048 semi-random bytes loaded
Generating RSA private key, 4096 bit long modulus
e is 65537 (0x10001)
Enter pass phrase for aliceprivkey.pem:
Verifying - Enter pass phrase for aliceprivkey.pem:

(alice) $ chmod 400 aliceprivkey.pem 

(alice) $ ls -la
total 4042
drwxr-xr-x    2 alice  users        4 Dec  1 18:43 .
drwx------  159 alice  users      296 Nov 30 20:33 ..
-r--------    1 alice  users     3311 Dec  1 18:44 aliceprivkey.pem
-r--r--r--    1 alice  users  4110965 Dec  1 18:32 countrysong.mp3

Curious about what’s in aliceprivkey.pem? Okay! aliceprivkey.pem contains the following gibberish (edited):

(alice) $ cat aliceprivkey.pem 
Proc-Type: 4,ENCRYPTED


(... a lot more similir lines ...)


This file is nothing more than a text file containing a private and a public key. Both keys are encrypted with Triple DES and then Base64-encoded (Alice used the weak pass phrase “” in this example, but she should use a much stronger pass phrase in the real world).

The reason for encrypting the private/public key pair with Triple DES before saving it into a file is simply precaution: even if Plod had access to aliceprivkey.pem by confiscating Alice’s computer, he won’t be able to obtain the private key (unless he could extract the Triple DES pass phrase out of Alice through coercion and torture). In most cases, you should really encrypt your private/public key pair.

Right now, both the private and public key are saved together in aliceprivkey.pem. To extract the public key, Alice can use openssl like this:

(alice) $ openssl rsa -in aliceprivkey.pem -out alicepubkey.pem -pubout
Enter pass phrase for aliceprivkey.pem:
writing RSA key

(alice) $ ls -la
total 4043
drwxr-xr-x    2 alice  users        5 Dec  1 18:49 .
drwx------  159 alice  users      296 Nov 30 20:33 ..
-r--------    1 alice  users     3311 Dec  1 18:44 aliceprivkey.pem
-rw-r--r--    1 alice  users      800 Dec  1 18:49 alicepubkey.pem
-r--r--r--    1 alice  users  4110965 Dec  1 18:32 countrysong.mp3

(alice) $ cat alicepubkey.pem 
-----END PUBLIC KEY-----

Alice can now publish alicepubkey.pem on her website, attach it to her emails etc… It doesn’t matter that Eve reads it: without the corresponding private key, Eve can’t use that public key to decrypt anything Bob sends encrypted to Alice.

Bob will do just the same and create a private/public key pair as well, and encrypt that pair with the weak pass phrase “b.ob” (again: in real life, Bob will use a much longer and hard to guess pass phrase to protect his key pair):

(bob) $ openssl genrsa -out bobprivkey.pem -des3 -f4 -rand /dev/random 4096
2048 semi-random bytes loaded
Generating RSA private key, 4096 bit long modulus
e is 65537 (0x10001)
Enter pass phrase for bobprivkey.pem:
Verifying - Enter pass phrase for bobprivkey.pem:

(bob) $ chmod 400 bobprivkey.pem 

(bob) $ openssl rsa -in bobprivkey.pem -out bobpubkey.pem -pubout
Enter pass phrase for bobprivkey.pem:
writing RSA key

(bob) $ ls -la
total 4064
drwxr-xr-x    2 bob    users        7 Dec  1 18:54 .
drwx------  159 bob    users      296 Nov 30 20:33 ..
-rw-r--r--    1 bob    users      800 Dec  1 18:49 alicepubkey.pem
-r--------    1 bob    users     3311 Dec  1 18:53 bobprivkey.pem
-rw-r--r--    1 bob    users      800 Dec  1 18:54 bobpubkey.pem

Here too, Bob will distribute bobpubkey.pem as widely as possible (on his website, blog, in every email he sends along…). As long as he keeps bobprivkey.pem secret, he has nothing to worry about Eve having access to bobpubkey.pem.

Alice sends a short message encrypted with Bob’s public key

Armed with Bob’s public key bobpubkey.pem, which she may have fetched from a public web site or got from Bob directly per email, Alice can now send an encrypted message to Bob. Because RSA encryption is slow, Alice won’t RSA-encrypt the big countrysong.mp3 file (it would take very long to encrypt, and also very long to decrypt). Instead Alice will simply encrypt the pass phrase “cryptme” she used for the symmetric cipher aes-256-cbc that transformed countrysong.mp3 into ciphertext.asc:

(alice) $ echo 'Hey Bob, pass phrase for ciphertext.asc is "cryptme"' > plaintext.txt

(alice) $ openssl rsautl -in plaintext.txt -out tobob.bin \
?                        -pubin -inkey bobpubkey.pem \
?                        -encrypt

(alice) $ openssl base64 -e -in tobob.bin -out tobob.asc

(alice) $ ls -la
total 4073
drwxr-xr-x    2 alice  users       10 Dec  1 18:59 .
drwx------  159 alice  users      296 Nov 30 20:33 ..
-rw-r--r--    1 alice  users      800 Dec  1 18:54 bobpubkey.pem
-rw-r--r--    1 alice  users  5566970 Dec  1 18:37 ciphertext.asc
-r--r--r--    1 alice  users  4110965 Dec  1 18:32 countrysong.mp3
-rw-r--r--    1 alice  users       53 Dec  1 18:58 plaintext.txt
-rw-r--r--    1 alice  users      695 Dec  1 18:59 tobob.asc
-rw-r--r--    1 alice  users      512 Dec  1 18:58 tobob.bin

(alice) $ cat tobob.asc 

Alice has already sent ciphertext.asc to Bob. Now she emails him tobob.asc, as well.

Bob decrypts Alice’s short message with his private key

Bob, armed with his private key bobprivkey.pem (and with the Triple DES pass phrase “b.ob” used to encrypt this key pair), can now decrypt tobob.asc, manually extract the aes-256-cbc pass phrase “cryptme“, and use that to decrypt ciphertext.asc into alicesong.mp3.

Here are all the steps. Bob starts with the following files (I omitted his or Alice’s public keys, as they don’t matter in this scenario):

(bob) $ ls -la
total 4074
drwxr-xr-x    2 bob    users       11 Dec  1 19:04 .
drwx------  159 bob    users      296 Nov 30 20:33 ..
-r--------    1 bob    users     3311 Dec  1 18:53 bobprivkey.pem
-rw-r--r--    1 bob    users  5566970 Dec  1 18:37 ciphertext.asc
-rw-r--r--    1 bob    users      695 Dec  1 18:59 tobob.asc

Bob will have to perform the following operations in that order:

  1. Base64-decode tobob.asc into tobob.bin, to get the raw RSA cipher text.
  2. RSA-decrypt tobob.bin into tobob.txt using his RSA private key bobprivkey.pem.
  3. Read tobob.txt, and extract the aes-256-cbc pass phrase.
  4. Use that pass phrase to decrypt ciphertext.asc into alicesong.mp3.
  5. Enjoy alicesong.mp3.

Easy, eh? Let’s do it:

(bob) $ openssl base64 -d -in tobob.asc -out tobob.bin

(bob) $ openssl rsautl -in tobob.bin -out tobob.txt \
?                      -inkey bobprivkey.pem \
?                      -decrypt
Enter pass phrase for bobprivkey.pem:

(bob) $ cat tobob.txt
Hey Bob, pass phrase for ciphertext.asc is "cryptme"

(bob) $ openssl enc -a -d -aes-256-cbc -in ciphertext.asc -out alicesong.mp3
enter aes-256-cbc decryption password:

(bob) $ mplayer alicesong.mp3

What have we learned so far?

Alice used Bob’s public key to RSA-encrypt the “cryptme” pass phrase, which itself was used to encrypt countrysong.mp3 with a strong symmetric cipher (AES-256 in CBC mode). “cryptme” is also called an ephemeral password.

In fact, crypto software like PGP does exactly the same under the hood: it selects a random ephemeral password (or key), and uses that with a strong symmetric cipher to encrypt the payload. Then, it RSA-encrypts the ephemeral password (or key) with the public key of the recipient, and packages both the symmetrically encrypted payload and the RSA-encrypted ephemeral password into a file.

The recipient (or his software) then extracts the ephemeral key/password by RSA-decrypting it with his private key, and then uses that ephemeral key to symmetrically decrypt the payload.

What can Eve do to eavesdrop on that communication? Without the ephemeral key, she can’t decrypt the payload (unless she can perform a brute force attack against a well-known symmetric cipher like aes-256-cbc), so she’ll have to concentrate on getting that ephemeral key. But without Bob’s private key, she can’t RSA-decrypt the part of the message containing the ephemeral key (unless, again, she brute-forces the RSA algorithm, which is just as unlikely than bruteforcing AES).

So is Bob safe?

Against Eve, Bob is more or less safe,

  • as long as Alice selected a much better ephemeral password than “cryptme” which is too easily guessable with brute force. Ideally, Alice would select her pass phrase out of  a few thousands of absolutely random bits instead of  words or pseudo words that Eve could try in a dictionary attack.
  • as long as Bob selected a long enough private/public key pair (4096 bits should be enough for the time being), and made absolutely sure that his private key remains private (i.e. out of reach of Eve, Mallory etc…, and of course encrypted with a good random enough pass phrase).

But poor Eve with her passive eavesdropping is not the only attacker on the big bad Internet. Bob’s evil government could also have assigned Mallory to his surveillance. Unlike Eve, Mallory is a much cleverer operator: she can actively intercept Alice and Bob’s traffic, and modify it en route. As man-in-the-middle, Mallory could intercept all of Bob’s traffic, including the part of the traffic where Bob sends his public key to Alice.

Mallory could then set out to impersonate Bob by creating an own public/private key pair (just like Bob and Alice did previously). Once Bob sends his public key to Alice, Mallory would intercept that communication, and replace Bob’s public key with her own public key. Alice has no way to detect that stratagem (neither has Bob), and would happily encrypt her ephemeral password “cryptme” with Mallory’s public key; and send that to Bob. Again, Mallory would intercept that encrypted message, and since this message has been encrypted with her own public key, she’ll be able to extract “cryptme” out of it. Mallory would then re-encrypt that ephemeral password with Bob’s (real) public key (that she intercepted previously), and send it to Bob. Just like Alice, Bob has no way to know that Mallory effectively gained access to the ephemeral password. Of course, in our nightmarish scenario, Mallory would then use that ephemeral password to decrypt “ciphertext.asc“, establish that it is a copyrighted MP3 file, and call up the SWAT guys.

So what’s the problem exactly? If Bob’s network connection is compromised by Mallory, Alice has no way to establish with certainty that Bob’s public key is really genuine and created by Bob. Mallory can as man-in-the-middle easily impersonate Bob, and neither Alice nor Bob would have a way to detect this.

There’s one more point though: if Bob managed to disseminate his public key as widely as possible (on websites, blogs, forums etc..), Alice could in theory check the public key she got directly (?) from Bob with the public key that Bob sent all over the Net. If they match, Alice can assume that Mallory didn’t modify Bob’s public key en route to her. Is that a safe assumption? Well, not really.

Why not?

If Mallory can intercept all of Bob’s traffic, she can also substitute Bob’s public key on the fly with her own public key every time Bob sends that public key anywhere. More precisely: Bob would have sent Mallory’s public key instead of his own public key all over the Net, and Alice would pick up Mallory’s public key even if she decided to verify Bob’s public key on the Internet. You may think that Bob will easily detect Mallory’s tampering with his public key submissions to websites, forums etc? Well, no: Mallory would also replace her own public key with Bob’s (real) public key, every time Bob reads one of those foreign web sites… and Bob will have no way to know that Mallory effectively substituted his own public key as soon as Bob’s public key went over the wire.

Bob will detect Mallory’s substitutions if he accessed the Internet outside of his country, far away from Mallory’s influence (or if he used an SSL connection to one of those websites that Mallory can’t tap into undetected). But as long as his network connection passes through Mallory, he is effectively blind and totally unaware of her ongoing man-in-the-middle attack against his public key.

Fortunately, public key cryptography provides with digital signatures another tool that Bob and Alice could leverage against Mallory. We’ll explore this in the next sections and investigate if it is enough to thwart Mallory’s attempt at impersonating Bob.

Integrity with digital signatures

Let’s assume that Bob’s evil government decided to tighten its grip on its citizenry further by installing a troyan on every computer of its populace that would collect and report all activities to a surveillance agency. The easiest way to do that is to infect all MP3 files that their people download with a virus, which exploits a vulnerability in a popular software MP3 player running on the targets’ computers.

In practice, all Bob’s western government has to do, is to reconfigure its internet censorship infrastructure in such a way as to infect the MP3 files that pass through its intertubes.

Bob may feel secure against this kind of attack, because he got an encrypted MP3 file from Alice (ciphertext.asc in our example), and because the censorhip infrastructure wouldn’t detect this as a MP3 file, and therefore wouldn’t infect it.

Really not?

We’ve already seen how Mallory could act as a man-in-the-middle to break the encryption that Alice and Bob so cleverly devised. And if Mallory can do that, she can easily append the troyan to the unencrypted MP3 file, before sealing it again and sending it on its way to Bob.

How can Alice and Bob make life harder on Mallory? One naive possibility is for Alice to compute the SHA1 message digest of the original (not yet tampered with) ciphertext.asc, and to send that message digest (possibly alongside the RSA-encrypted ephemeral password) to Bob:

(alice) $ openssl dgst -sha1 -binary -out thedigest.bin ciphertext.asc

(alice) $ openssl base64 -e -in thedigest.bin -out thedigest.asc

(alice) $ cat thedigest.asc

Bob would then compute the SHA1 message digest of what he got as ciphertext.asc independently, and verify that this message digest corresponds to the message digest sent by Alice:

(bob) $ openssl base64 -d -in thedigest.asc -out thedigest.bin

(bob) $ openssl dgst -sha1 -binary -out mydigest.bin ciphertext.asc

(bob) $ diff thedigest.bin mydigest.bin

Since the Unix command diff didn’t complain, the digest of ciphertext.asc he computed himself (mydigest.bin) and the digest he (thought he) got from Alice (thedigest.bin) are indeed indentical.

Bob assumes now that ciphertext.asc wasn’t changed en route by the internet censorship infrastructure of his evil government.

What about Mallory?

Of course, let’s not forget Mallory. She won’t sit idly by and allow Alice to send Bob a message digest of ciphertext.asc. After all, Mallory managed to corrupt that file before sending it to Bob, so she’ll have to send a message digest of that corrupted file instead, for Bob to remain unsuspicious.

Mallory would simply intercept Alice’s thedigest.bin on the way to Bob, throw it away, compute her own message digest of the modified ciphertext.asc, and send that message digest to Bob. Bob wouldn’t be able to detect that the message digest he got from Alice wasn’t actually from Alice at all but from Mallory. He wouldn’t be able to detect that ciphertext.asc was indeed modified by Mallory, because the message digest he computes would match the message digest he got from Mallory (instead of Alice).

So what can Bob and Alice do?

Alice digitally signs her message digest with her private key

To prevent Mallory from replacing the message digest without Bob detecting this, Alice sets out to sign the SHA1 message digest she computed with her own private key, and sends that signed message digest to Bob:

(alice) $ openssl dgst -sha1 -binary -sign aliceprivkey.pem \
?                      -out thesigneddigest.bin ciphertext.asc
Enter pass phrase for aliceprivkey.pem:

(alice) $ openssl base64 -e -in thesigneddigest.bin -out thesigneddigest.asc

(alice) $ cat thesigneddigest.asc

Alice sends thesigneddigest.asc to Bob.

Bob verifies Alice’s signature with her public key

Bob will get thesigneddigest.asc (hopefully from Alice), and, armed with Alice’s public key alicepubkey.pem, he’ll first verify Alice’s signature, before checking wether the message digest provided by Alice matches the message digest he’ll compute right here and there. All those steps Bob can perform with merely two commands:

(bob) $ openssl base64 -d -in thesigneddigest.asc -out thesigneddigest.bin

(bob) $ openssl dgst -sha1 -verify alicepubkey.pem \
?                    -signature thesigneddigest.bin \
?                    ciphertext.asc
Verified OK

That’s very good: the signature of Alice verified OK, and both message digests were identical. Bob can now safely assume that ciphertext.asc hasn’t been tampered with by Mallory.

Bob’s false sense of security

However, Bob is under a false sense of security. The whole security of digital signatures depend on the fact that Bob can trust Alice’s public key alicepubkey.pem. But since Mallory could already change ciphertext.asc, she could also have replaced Alice’s public key on the way to Bob with her own public key! Mallory could then just as easily digitally sign her corrupted version of ciphertext.asc with her own private key, and Bob would “verify” that signature with the replaced alicepubkey.pem, and won’t detect anything. To him, Alice and Mallory are absolutely indistinguishable.

The problem here is that Bob can’t trust Alice’s public key, because Mallory could have replaced that key with her own public key. Whatever Alice signs, Mallory could always sign with her own private key just as well, and Bob wouldn’t be able to discern Mallory from Alice.

The only way to prevent this, is:

  • either for Bob and Alice to find a secure channel to exchange their public keys, so that Mallory can’t interfere (at least not during Alice and Bob’s exchange of public keys),
  • or use a public key infrastructure (PKI) that Mallory can’t tap into.

I’ll talk about public key infrastructures and how to use them with openssl in another post (or I may not).


If Alice and Bob have a secure channel, they can exchange their public keys, and then communicate safely over an insecure channel. Eve couldn’t decrypt messages, and Mallory couldn’t modify them without the recipient detecting the change. However, public key cryptography is only safe if used properly: exchanging public keys over an insecure channel kills both secrecy and integrity, and permits Mallory to act as a man-in-the-middle, impersonating Bob and Alice respectively. Only a solid public key infrastructure (PKI) or a secure channel for the public key exchange would thwart those attacks.


  1. Rodolfo Mazo

    Can you make money out of this blog? just curious

  2. Nope. This is a non-commercial ad-free blog.