Function used to convert passphrase to encryption key


So this issue is one of security. I don't know that the function that I used (or rather wrote) is cryptographically strong enough to store the account information when it is AES encrypted. There is a "random" IV that I am using and there is a lot of hashing going on; I'm not using a single hash or ECB, so it's not completely crap, but I wonder if it's strong enough.

This is something that I need to contemplate, because if I change it, it will break any stored accounts right now. I haven't been doing version tracking in the XML or in the overall application, so there's no real good way to say "You're on a old version, please wait while I convert your accounts to the latest version." aside from the change from a .DAT file to XML.

I recently coded up a PBKDF2<T> (RFC2898) method for another project that would work here nicely, but as I stated above, any changes to the hash methods used to set the key and IV for the AES encryption will BREAK any stored accounts. I don't want to put any users through that pain unless I can safely, and automatically, upconvert them to the new version. In the future, I also need to better keep track of the assembly version and the build number in case of such issues going forward.

I will be revisiting this....
Closed Nov 15, 2013 at 5:27 PM by dsparksColossus
Tested. Works :)


dsparksColossus wrote Sep 8, 2013 at 3:20 AM

I am implementing PBKDF2 and using it with HMACSHA512. The individual accounts will have salts attached to them (as before) and the name of the element has been changed from "iv" to "salt" to help differentiate the "Accounts.xml" version number. To further differentiate it, I've added a version attribute, which is set to 1.1 for the upcoming release. I've renamed the methods and classes to also differentiate which class writes which version. The last release is [ClassName]10, this release is [ClassName]11 to indicate version "1.1".

As for the actual user account, I might not be able to get away from using a static salt value (which I'm using a GUID internally). I don't like having the master, user-derived key without a dynamic salt, but storing and retrieving the salt in a reliable fashion might prove interesting, as I don't want it just hanging out in the open in an XML file somewhere... we shall see. If it's no big deal to be floating out there, then I can just shove it as an attribute into the main xml file. In that case, the user can decide to generate a new salt (I already have code to change the PassPhrase, so it should be painless). If the salt were to get corrupted, however, and the user hadn't created a backup somewhere, the whole Accounts.xml file is useless and unrecoverable!

As for my concerns about breaking people's accounts file by changing the internal routines, I had forgotten I implemented IMPORT/EXPORT, so this is effectively a non-issue. Users can export NON-ENCRYPTED and then re-import after the upgrade. Problem solved on that front! In fact I've marked the old code as obsolete, and I might even remove it entirely.

wrote Sep 8, 2013 at 3:26 AM

dsparksColossus wrote Sep 11, 2013 at 4:36 AM

Requires testing to confirm the master salt for the accounts is set/read correctly in all cases, and that the import/export is correct in all cases.

wrote Nov 15, 2013 at 5:27 PM