It's a good point that we probably shouldn't seed the values just to avoid someone from accidentally using "deadbeefdeadbeef" in their production environment. I'll also investigate if we can reuse the transformation instances (and make the change if we can).
We didn't use the machine key as we'd have to pick one of two paths: 1) Using the [`System.Web.Security.MachineKey`](http://msdn.microsoft.com/en-us/library/system.web.security....) class to perform the encryption would probably leave us with the same issue we wanted to resolve (the class only exposes methods for encryption, not the key itself). 2) Parsing the configuration file manually is error-prone and makes us rely on the current format (and while it's unlikely to change given Microsoft's dedication to backward compatibility, it's an unnecessary dependency for an independent solution).
Our code serves as an example and while some will probably copy the code right into their solution, I expect most people will adapt it to suit their needs*. [Poul-Henning Kamp](http://phk.freebsd.dk/sagas/md5crypt_eol.html) recently wrote "Please notice that there is _no_ advantage in everybody in the world using the exact same algorithm, quite the contrary in fact." (relating to the application of well-known encryption algorithms, not designing such algorithms). We believe it's beneficial to share a solution that people can build and improve on. If nothing else, using different solutions prevent a single attack from affecting us all.
We didn't use the machine key as we'd have to pick one of two paths: 1) Using the [`System.Web.Security.MachineKey`](http://msdn.microsoft.com/en-us/library/system.web.security....) class to perform the encryption would probably leave us with the same issue we wanted to resolve (the class only exposes methods for encryption, not the key itself). 2) Parsing the configuration file manually is error-prone and makes us rely on the current format (and while it's unlikely to change given Microsoft's dedication to backward compatibility, it's an unnecessary dependency for an independent solution).
Our code serves as an example and while some will probably copy the code right into their solution, I expect most people will adapt it to suit their needs*. [Poul-Henning Kamp](http://phk.freebsd.dk/sagas/md5crypt_eol.html) recently wrote "Please notice that there is _no_ advantage in everybody in the world using the exact same algorithm, quite the contrary in fact." (relating to the application of well-known encryption algorithms, not designing such algorithms). We believe it's beneficial to share a solution that people can build and improve on. If nothing else, using different solutions prevent a single attack from affecting us all.