Up to Main Index Up to Journal for January, 2018
JOURNAL FOR TUESDAY 30TH JANUARY, 2018
______________________________________________________________________________
SUBJECT: Cryptography with Alice, Bob & Theresa
DATE: Tue 30 Jan 20:24:24 GMT 2018
This entry was written on Friday, but I didn’t publish it. In fact I
didn’t know if I would publish or just delete it. In the end, after a
lot of cogitating, I thought it might be interesting and maybe useful
to some. So, for better or worse, here it is…
A minor detour from my usual ramblings, but it seems that our Prime Minister
Theresa May is banging on about encryption again. This time in relation to
messaging apps because they are “home to criminals and terrorists”. No, sorry,
they are also used by all sorts of people for various reasons, like privacy
and security. Should we remove, weaken or otherwise hobble encryption for
everyone else? What about online banking because “criminals and terrorists”
might use it? What about secure online commerce?
So I want to make a small point about using ANY unencrypted medium, not just
messaging apps. It nothing new or original, but it is important.
If you want to play along and try this yourself, all of the examples below
were tested using OpenSSL 1.1.0g on Debian Linux (Testing). In the examples
that follow, lines that start with ‘>’ show the commands to type in. Don’t
type the ‘>’ itself, it is just there to represent the prompt on a command
line.
Let us assume Alice wants to send a message to Bob without Theresa being able
to read it, but they both use an app that sends insecure, plain text messages
with no encryption. We also assume that Alice and Bob have pre-shared a secret
password. What can they do? They can send text that is already encrypted if
the app isn’t going to do it for them automatically!
Alice starts by preparing her message:
> echo "Hello World" | openssl aes256 -a
enter aes-256-cbc encryption password: ············
Verifying - enter aes-256-cbc encryption password: ············
U2FsdGVkX1/UsERDIi+1wNvmErOlI2nkp2cFjJH6gD0=
Alice copies, pastes and sends "U2FsdGVkX190xCjmJYPn+qwSQVfSkATBhPE4VV6TTac="
as plain text to Bob via email, SMS, message app, postcard, etc. Bob receives
the message, copies it and pastes it onto a command line:
> echo "U2FsdGVkX1/UsERDIi+1wNvmErOlI2nkp2cFjJH6gD0=" | openssl aes256 -a -d
enter aes-256-cbc decryption password: ············
Hello World
Oh no! Theresa can’t read the secret message! Even though the app is using
insecure, plain text and putting everybody — except Alice and Bob — at risk :(
It’s just as easy to write a long email and either copy and paste the
encrypted text or send it as an attachment. Here we assume email.enc is either
copied into the email or is the attachment:
Alice:
> openssl aes256 -in ./email.txt -out ./email.enc -a
enter aes-256-cbc encryption password: ············
Verifying - enter aes-256-cbc encryption password: ············
Bob:
> openssl aes256 -in ./email.enc -out ./email.txt -a -d
enter aes-256-cbc decryption password: ············
These are just silly, simple — but workable — examples. Maybe we need an app
that has a drop down field to select the person’s secret password to use, a
text area to copy/paste text and two buttons: one to encrypt and one to
decrypt the text[1].
If you just wanted to see the easy stuff, I’ve made my point — encrypted data
can just as easily be sent using an insecure, unencrypted medium. Making
messaging apps or any other software less secure is not going to do anyone any
favours. Point made — you can stop reading here. If you want an example of a
better, but slightly more complex solution keep reading…
Can Alice and Bob do better? What about using private and public keys instead
of a pre-shared shared secret password?
First of all, Alice and Bob need to generate their private and public keys,
with the private key password protected:
> openssl genrsa -out private.pem -aes256 2048
Generating RSA private key, 2048 bit long modulus
.......................................+++
..................................................................+++
e is 65537 (0x010001)
Enter pass phrase for private.pem: ············
Verifying - Enter pass phrase for private.pem: ············
> openssl rsa -in private.pem -out pub.pem -outform PEM -pubout
Enter pass phrase for private.pem: ············
writing RSA key
Once this is done the public keys in the pub.pem file can be safely shared,
even publicly. When Alice wants to share a message she generates a random key,
encrypts the message with the random key, encrypts the random key with Bobs
public key and finally sends Bob the encrypted message and encrypted random
key. Phew! That’s a lot, but only three commands:
> openssl rand -base64 -out key.bin 128
> openssl aes256 -in email.txt -out ./email.enc -pass file:./key.bin -a
> openssl rsautl -encrypt -inkey pub.pem -pubin -in key.bin -out key.bin.enc
This method requires a separate key file rather than using rsautl to encrypt
the data directly as rsautl can only encrypt small amounts of data
Bob soon receives the two files — the encrypted random key and the encrypted
message, key.bin.enc and email.enc. He then decrypts the random key using his
private key, then decrypts the message using the decrypted random key:
> openssl rsautl -decrypt -inkey private.pem -in key.bin.enc -out key.bin
Enter pass phrase for private.pem: ············
> openssl aes256 -in email.enc -out ./email.txt -pass file:./key.bin -a -d
This is a little more complex than before and could certainly do with the
encrypting and decrypting commands being put into some simple scripts. Maybe
we need to make our theoretical app, mentioned earlier, a little smarter?
The ‘magic’ here is that because the random key is encrypted with Bob’s public
key only Bob can decrypt the random key using his password protected, private
key. Once again Theresa is thwarted from reading the message even though Alice
sent Bob the two files using an unencrypted plain text medium ;)
I don’t suppose for one minute that anyone is going to take any notice of me,
but the point is encrypted data can easily be sent using an insecure medium.
You just need to strongly pre-encrypt the data — at the end of the day it’s
all just data, encrypted or not.
The genie is out of the bottle, and it isn’t going back.
--
Diddymus
[1] If you search the Google Play store for ‘aes encrypt decrypt’ there are
apps like this already. As I have not used any I can’t recommend or
endorse any of them. However I would highly suggest using one you can
examine the source code for…
Up to Main Index Up to Journal for January, 2018