PersonalEncrypter – New and Improved

A couple of months ago I updated the PersonalCLI project to remove information leakage in the form of the original filename of the encrypted data. In my original post about this project I eluded to updating it to move away from the Microsoft encryption libraries and to implement the libSodium library instead.

Well, I’m happy to say that I’ve found some time to do this and moved to .NET Standard at the same time – yep, the future is here.

The initial project was really a quick and dirty exercise to demonstrate the ease with which these applications can be developed. It didn’t really lend itself well for extension – it was only meant to be a proof of concept after all.

In the new project I have created a class library to handle the mechanics of the encryption and a separate project for the CLI. There is also a skeleton project for a UWP desktop application which I’m currently working on (and committed in error – but hey, I’m only human). The UWP application will be initially aimed at Windows 10 but the ultimate aim to for a version of this project to be installable on just about any platform, e.g. Mac, Linux, iOS and Android.

Note: The libSodium project uses a different encryption algorithm to the Microsoft libraries so it will require a new key pair to be generated.

So, I’m now working on the UWP application which may even find it’s way onto the Microsoft Store (if they’ll have it) – afterall, that’s the aim isn’t it – to get encryption into the hands of the masses so that they can have some semblance of privacy.

I’ll be pushing updates to the public Github repo and announcing major milestones here so …… watch this space!

Personal Encryptor CLI v1.1.0 Released

It’s been a good seven months since I released the initial version of the PersonalEncryptorCLI project and in that time I’ve had more than a handful of emails asking me about the utility. Most of these were asking if I could/would be creating a Desktop version, i.e. something with a GUI. It seems only geeks like the Command Line – who knew 😉

Well the answer is yes, but I needed to clear the remaining issue that I had identified with version 1.0.0 – the need for the recipient to know the context of the encrypted content, i.e. whether it was a text file, an image or a Word document.

This was due to the initial release of the utility requiring the filename to be specified during the decryption process – including it’s extension. Now, if the user didn’t know that it was a Word document, how would they know to specify a filename with a .docx (or .doc) extension?

Sure, the sender could include that in the email (or some other mechanism) but this is information leakage and this could potentially assist so-called ‘bad actors’ in determining the contents – regardless of whether they would access the actual contents or not.

Well, today I managed to get a couple of hours to test update the code to include the original filename in the Encrypted Packet (the value being encrypted of course). During the decryption process this value is extracted and used to create the file for the decrypted data to be written to.

There have been a couple of tweaks to the project Readme.md file to handled the changes to the command line options for the decryption operation but it’s fairly trivial – just dropping the filename from the output path parameter.

“But what if I have encrypted packages that were created with the previous version – which don’t contain the filename?”

Don’t fret – I have a few of these too so the code will use a temporary filename in this instance (hopefully you remembered/know what the file was!).

I’ll be decrypting my now-legacy data and re-encrypting with the new version of the utility – you may want to do the same 😉

You can access the main project page here or the new 1.1.0 release here.

Now that the desks are clear – I can turn my attention to the Desktop client which may or may not look something like this:

The Personal Encryptor 1.0 Released

 

Following on from my post about the UK Governments campaign to erode our privacy by demanding that tech companies put back doors in their encrypted products, I have created a simple utility to demonstrate how easy it is for a reasonably competent developer to create their own using standard development tools and libraries.

Now, I’m not expecting the UK Government to take a blind bit of notice but the fact is that encryption is out there, it’s only mathematics after all, and it’s not going away. You cannot feasibly make maths illegal – although the US did classify encryption as a weapon until 2000 (and to some degree still does).

Anyway, following my commitment to watch at least one Pluralsight course a month during 2018 I opted for Practical Cryptography in .NET by Stephen Haunts to give myself some suitable background.

The course was a minute under four hours and took me a couple of evenings to get through, Cryptography is not the most stimulating subject but Stephen did his best to key the information flowing. At times I did feel frustrated at how he seemed to labour some points but the upshot is that by doing this the information did seem to get through and stick. During the course he slowly increased the complexity, developing and enhancing C# code to demonstrate the principles.

It is this code which I have used as a base to create the ‘Personal Encryptor’ (hereafter referred to as PE) – a command line application that can be used to generate encryption keys, encrypt and, of course, decrypt data into files that can be safely sent over the Internet. Only someone with the required public and private keys will be able to decrypt the file and view the original data.

I’ll probably put another post together shortly diving a bit deeper into the functionality and explain the contents of the output file – but I highly recommend you watch the above course as Stephen know the subject inside out and does a great job of explaining it.

Why would I need/want to encrypt a file?

Imagine the following scenario;

Alice and Bob want to exchange private messages with each other; maybe they are planning  a surprise birthday party or sharing ideas about a new business venture. Whatever the messages contain, they are Alice and Bobs business and nobody elses.

  1. Alice and Bob both download the PE application and copy it to a location on their Windows PC (Mac version coming soon).
  2. They then use the utility to generate a Public and Private key pair – which will create two XML files.
  3. They each send each other their PUBLIC keys (this is just an XML file and can be freely sent over the Internet or via Email).
  4. Both Alice and Bob copy their PRIVATE keys to a safe location (maybe a secure USB key – or a normal USB key which is stored in a safe)

Now Alice wants to encrypt a file, a PowerPoint presentation for their new product, and send it to Bob

  1. Alice uses the PE application to encrypt the file using Bobs PUBLIC key.
  2. The PE application Digitally Signs the encrypted data using Alices PRIVATE key.
  3. A text file is created containing the encrypted data and everything needed to verify the contents has not been tampered with and to confirm that Alice encrypted it.
  4. Alice then emails the file to Bob as she normally would if she was sending a photo of her cat!

Bob receives the message and downloads the encrypted file to his computer.

  1. Bob uses PE to decrypt the file by specifying the location of his PRIVATE key and Alice’s PUBLIC key.
  2. The PE utility will check the digital signature using Alice’s PUBLIC key to confirm that it was signed with her PRIVATE key.
  3. It will then check the integrity of the package to ensure that it has not been tampered with in transit
  4. If all is well then the PE application will decrypt the file and write the contents out to a location that Bob has specified.
  5. Bob can now endure enjoy Alice’s PowerPoint presentation.

Of course if Alice (or Bob) just wanted to encrypt a file for their own personal use and not for sharing it is perfectly feasibly to provide their own Private AND Public keys to encrypt the data. These keys will be required to decrypt the data.

And that’s it, privacy restored/reclaimed.

I can now safely download my Lastpass vault in plain text, encrypt it and save it to any cloud drive I like, secure in the knowledge that, as long as my private key remains under my control, nobody can decrypt it to access it’s contents. Nothing illegal there – these are passwords to legitimate sites (Amazon, Pluralsight, Microsoft, Apple etc) and need to be protected. A valid use of The Personal Encryptor.

Going Forward

Yes, at the moment it requires the users to have some familiarity with the Command Line but this project was always intended to be a proof of concept. The original aim was to explore encryption to enable me to implement it in an existing mobile Chat application.

Creating a simple GUI would certainly be possible – a simple Winforms or WPF application to collect file paths and call out to the command line utility shouldn’t take too long for a competent developer to write. That said, I’m probably going to focus my attention elsewhere.

While using the Microsoft libraries is perfectly valid in my opinion, I am aware that many people will wince just a little bit. With this in mind I intend to investigate using the libSodium Crypto Library which Steve Gibson is such a fan of – so that’s good enough for me.

You can download the latest version of the Personal Encryptor application by clicking here. Alternatively you can download the full source from Github.

Parsing Console Application Arguments using CommandLineParser

When we open Visual Studio and click File > New we are greeted with a huge list of project templates to choose from. Now and then we may opt for a simple Console Application for a quick one off utility, e.g. post processing some .csv files or images.

Similarly we have all used command line utilities which require numerous arguments and switches to ‘tune’ exactly what we want it to do, e.g. git or tar.

Well I’m looking to create a Command Line utility that will allow users to encrypt and decrypt textual messages.

Why? I hear you ask – well check out my thoughts on the UK Governments attempts to get WhatsApp to create a backdoor.

The utility will allow users to

  • Generate Public/Private Key Pairs
  • Encrypt textual messages, packaging them for sending to the intended recipient
  • Decrypt packaged messages

Each action will require/allow a number of parameters to be set to specified key bit lengths, key names, output locations and of course the message to be encrypted or decrypted.

Something like this:

C:Encryptor generateKeys -n Daves -o C:UsersDaveMyKeys

which would create a key pair files called DavesPrivateKey.xml and DavesPublicKey.xml in C:UsersDaveMyKeys

But what is the best way to do this?

We could handle it in the Program.Main method by locating arguments and setting their values, like this
https://gist.github.com/OnTheFenceDevelopment/d08bb935661c91d3a11dac50daacbb09.js

But that’s a bit nasty and relies on each parameter having a value and that it’s been specified in the correct way to allow casting etc. There has to be a better way .. well there is and it comes in the form of a nuget package called, suitably enough, CommandLineParser.

Now, I didn’t find the documentation (the ReadMe.md on the projects Github page) that helpful and it took a lot of trial and error to work out how to use it for my needs. When I got to grips with it though – I was impressed.

After installing the CommandLineParser via nuget I needed to create a new class to define each operation, i.e. GenerateKeys, Encrypt and Decrypt.

Each class is decorated with a ‘Verb’ attribute – this defines the action – while the properties are decorated with ‘Option’ attributes.
https://gist.github.com/OnTheFenceDevelopment/30640f89914a961bf0d2f81995e36c19.js

So the above code defines the Generate Keys action and provides options for Key Length, Name and Output Folder. Notice that the Key Length will default to 2048 bits if not specified by the user. It is also possible to make options mandatory and the operation will fail if they are not specified.

When the Console Application project was created a Program.cs class was added containing a single method called Main. I’ve modified the signature to return an integer instead of a void as I think it is good practice to return exit codes from command line utility.

https://gist.github.com/OnTheFenceDevelopment/2725e47e2482535a681e2b794901fcc0.js

To test the configuration I can right-click on the project file, open the Properties page and click on the ‘Debug’ option. Enter suitable values into the ‘Command Line Arguments’ as below

and then run the application (I had a breakpoint on the return statement within the GenerateKeyPair method).

If the parser fails for any reason then it will automatically generate the required output and error ‘gracefully’.

Try dropping the value for one of the options and rerunning the application – below I dropped the DavesMessage value from the -n parameter:

Obviously I want to add another couple of Option configurations and this is easy enough to do – take a look at the sample app in the github repo, in particular the Program.cs file, to see how this is done. Alternatively you can keep track of this application when it hits GitHub as I will be open sourcing the code.