Hello Mark, > OK, some thoughts in no particular order that may help. > > - One of the problems with .Net applications is that, being that > intermediate byte-code stuff, it is inherently easy to > reverse-engineer. There is no way to absolutely hide an encryption key > in a .Net assembly. You can make it pretty darn hard to find though, > rather than shipping the XML as a data file along with the > application, make it an embedded resource and get a StreamReader like > so (sorry about the formatting): > > myAssembly = System.Reflection.Assembly.GetExecutingAssembly() > s = New StreamReader( > myAssembly.GetManifestResourceStream(myAssembly.GetName().Name & "." & > ResourceName)) > - Most applications I develop that require encryption have a default > encryption setup used only for encrypting and decrypting keys. I then > have a mechanism for loading new encryption keys as needed. So maybe > you could change the encryption keys periodically? > > - Use digital signatures. In this case, there's a "magic cookie" > inside the encrypted data file that is itself a product of encryption > that's hard to forge and the application can use to verify the data is > from you and not the Evil Mr. X. Look in the > System.Security.Cryptography.DSA namespace. > > - Get "Programming .Net Security" by Adam Freeman & Allen Jones, > available at O'Reilly Press. It tells everything I've forgotten about > encryption and then some. > > I think that about sums up my wisdom on the topic unless you need that > test code. Good luck. > Thanks very much. I think I will end up using a combination of encryption and signing to meet my needs. Thanks again -- Rory
