The AES standard has become synonymous with state-of-the-art encryption. The AES (Rijndael) cipher is specified in NIST FIPS-197.  I decided to implement the cipher in LabVIEW, my favorite programming language.  All code was written from scratch from the specification. In addition, the first four encryption modes in NIST SB 800-38A were implemented. Electronic Code Book (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), and Output Feedback (OFB) are included and work. The programs pass all test vectors listed for the included modes.

Two simple utilities can be found in the Tools section which demonstrate the AES standard implemented in LabVIEW. The first encrypts a given file and saves it with an ".encr" extension. The second decrypts and (by default) strips off the last extension. The default key is from the spec so I don't suggest using it. It's a perfectly good key, just easy to guess. I wont promise these programs are secure against all attacks, but they do work.

Don't forget your key! The utility doesn't remember it. It's a feature not a bug. I suggest you write it down and store it on a safe place. You'll need to download and install a recent LabVIEW runtime engine to make these work.

Update:  We have added an installer which includes the Labview 2012 runtime.  We're sorry the runtime is such a beast.  This way you will not have to create a (free) NI account to try these out!

Encryption Utility

Decryption Utility

Encrypt a File

Decrypt a File

New!  Installer with Labview 2012 Runtime

MD5sum Tools

An MD5sum is a quick way to verify whether or not a file has changed.  It's known as a Hash function.  A hash function takes in any length of data, mixes it all up and spits out an unique string called a hash.  Any small change in the input file is supposed to vastly change the hash which allows one to quickly verify that the same data was read twice.

It's not considered a secure hash, because it is feasible to intentionally create a given hash if you try hard enough.  This is a bad thing when looking for intentional modifications to a file.  A bad guy could create a file and then randomly flip bits to create two files (a good file and a malicious file) with the same MD5sum.  MD5sums are NOT a security check.

MD5sums are perfect for rooting out accidental corruption.  Downloaders being a horrible as they are.  (Who else has ever left IE downloading a large file and gone to bed only to find out they have a large corrupt hunk of junk in the morning?)  Windows still doesn't have a decent downloader for large files built in.  For this reason, the MD5sum is often included along with large file downloads to make sure you got all the data and it's the same as before it was sent.

These tools generate an md5sum for everything in a directory, with or without recursion.  The checker can verify md5sums you have generated, or you can compare the hash it spits out in a terminal window to the one which accompanied your download.

Since windows doesn't have a good way to generate or verify MD5sums, I created a few standalone windows programs to do just that.  You can find them in my tools section.  I hereby place my MD5sum tools in the public domain.  Please don't sue me if they eat your data, work badly or otherwise cause bodily injuries.

MD5sum directory

MD5sum recursive

MD5sum verify directory

MD5sum verify recursive