Powershell and String Encryption and Compression

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.


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.


~ by lunaticexperimentalist on May 16, 2009.

4 Responses to “Powershell and String Encryption and Compression”

  1. what am I missing with the use of this great library? I am a little confused as to how I make this secure when all I need is the pass phrase to decode the string easily. For my case, I want to encrypt my SQL Server login info, but if I can easily decode that from the encrypted file, how are the credentials more secure than just typing them in the original script? I ma sure there is one thing I am missing here. Does this hinge on the file system security as well (assuming the use that encrypted the file is the only one who has file system access to it so logging in with another username that does not have access to the file wont allow the decrypt to work)

    • The beauty of the encryption functions is how it allows you to combine a set of credentials and other secret data into a single passphrase. You could write write a script that automates the process of interacting with five services with differing credentials for each. Then, you can store all of those credentials into a single file, encrypted with a single passphrase, and have your automation just ask for a single passphrase, rather than five. I also intentionally made it safe to reuse passphrases. Just be sure to keep the passphrase a secret.

      • sorry, should have given a little more info. I am trying to do some automated builds. The encryption/decryption works great, but if I am automating (writing a PS Script) a build, I would need to pass in the pass phrase to decrypt the encrypted file housing my db credentials. My gold is in my locked house, but I gave the thief my keys.

  2. So you’re trying to perform automated builds using encrypted data triggered by a scheduled task? Unfortunately, I can’t help you much here. This goes beyond just encryption/locks. There is a trust issue here. Activating the script by scheduled task is like asking someone to do work for you. If you need them to do work in your home while you are away, you must either leave your home unlocked, or give them the key. You must also trust that person. Calling your worker a thief displays distrust. In that case you must find a worker you can trust, or do the work yourself. (Use a more secure machine, or type your passphrase in at the console?)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: