Today, I went back over the scripts that I use in Powershell to perform encryption to give them and update. I wanted to have a simple script that will perform encryption over a string, using a string as a password, and return a string, because strings are easy to manage in a shell. (I had been using a really complex but really awesome object based encryption script.) Before I started I took a look at what was available on the web. As it turned out there isn't much out there and what is out there is garbage. In particular I saw http://poshcode.org/116 with it's hard coded salt and weak IV selection. It's key schedule as a whole is worthless.

So I open up PSPad and start typing. About an hour of research and 104 lines of code later, I now have a string encryption script that better adheres to cryptoanalytic recommendations, is easier to use, and even supports compression before encryption. I'm normally used to being the first to release any script of any specific genera and don't have any reason to speak down on any other script in that genera. However, in this case, seeing as how poorly the predecessor handles key information, I have to strongly recommend switching to my script as soon as possible if you have been using the script linked to above. To be serious now, since you're data is important enough to encrypt, I would bet you would be rather upset if someone managed to crack your password when your encrypted data does get leaked.

The cryptanalysis of my script is quite simple. The stream cipher is Rijndael, and the key schedule is RFC2898 with a random 256 bit salt that is tacked on to the cipher message(just as it should be). Don't understand all that? Don't worry. The only weakness here will likely be the passwords you use. I'm sure you have heard it a hundred times: make passwords that are hard to predict and change passwords as often as possible. You can make the password as long as you want and use any characters you want. Also don't store passwords anywhere someone else might see them. For further cryptanalysis look up Rijndael and RFC2898.

I had to add in compression because the moment just before encryption is the last chance you get to do compression. Not only is it the last chance, but generally also the best time to perform compression. Compression works best on uncompressed data and when there is a great amount of it. Compression also will not work at all on encrypted data. Beware that compression will not work for very small parcels of information. You'll want a string of at least 1500 characters before you can get any benefit out of using compression.

Library-StringCrypto.ps1

I can't imagine any uncool way to use this so if you find a use for this I would like a comment here or on Twitter @aitsusan so I can hear about it.

Important Update:

I have already rewritten this script. The changes are wide enough to make the old version and the new version incompatible, but I'm going to use the same script name anyway, because I feel this update to be very important for the security of any person that uses this script.

If you have Library-StringCrypto.ps1 version 1.0 please download version 2.0 now.

The change is an addition of an HMAC. What this means is that now the script can more effectively detect any corruption of modification to the encrypted data. In version 1.0 no direct method of detecting corruption was implemented. This raises a potential security hole where an attacker could modify the cipher string in a way that would result in garbage being returned in the decrypted string, and not having any exception thrown.

The lack of a HMAC before could have caused a script, that did not on it's own perform any authentication, to reveal some information about the encrypted data to an attacker or could have caused the script to otherwise behave in an unexpected manner. Now, with the HMAC in place an exception is thrown before any of the data is decrypted, none of the remaining encrypted data can be leaked and the script should then terminate.