Plug-In Encryption Solution?
Miscellaneous Forums/General Discussion/Plug-In Encryption Solution?
| ||
| I'm looking for a file encryption solution ( for BMax, but it's not really language-specific ) which I can plug in without changing much code. All the loading and saving in three different programs is already completed and now the client decides they *do* want encryption after all. So I'm looking for something which will cause me as little trouble as possible to implement at this late stage. THe loading and saving in each of the three programs is subtlely different, so it's actually going to be a bit of a pain to rewrite. |
| ||
| I don't have one written, but if all you want is some encryption, look up 3DES or AES. They're feistel chiphers, so should be fairly simple to implement. If security isn't a concern you could "Save" to a Bank first (although this would make it vulnurable to debugger tools) and then pass that Bank on to a framework that transforms it to an encrypted file on disk. If security is an issue, and you want a solution that's less prone to be hackable by debuggers, you could muck about writing a TStream extension (like BigEndianStream) that wrote to a file in an encrypted manner. If you just want very basic encryption, a simple XOR cipher might work. It really depends on what demands the encryption needs to live up to. |
| ||
| I'd throw in AES. Your client will, at some point, be chatting with someone who knows about encryption so will no doubt be less than impressed if they find that you've used anything other than an industry standard. |
| ||
| I have a RC4 file encryption solution. I utilise it in IndieNet, igLoader and in the games GEOM, cBubble. It can encrypt and decrypt complete files, or simple text. Email me if you want the files. Why RC4? RC4 is a stream cipher designed by Rivest for RSA Data Security (now RSA Security). It is a variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. Analysis shows that the period of the cipher is overwhelmingly likely to be greater than 10^100. Eight to sixteen machine operations are required per output byte, and the cipher can be expected to run very quickly in software. Independent analysts have scrutinized the algorithm and it is considered secure. |
| ||
| I think they're gonna be using some kind of in-house DRM software to wrap this thing up, so I probably already have debugger protection. Probably best to play safe and not use the bank-first approach though. Particularly since they keep moving the goalposts. I don't wanna have to do it twice. Tim, your RC4 solution sounds promising. I'll drop you an email. Thanks. |
| ||
| I never did get that email :( |
| ||
| Yes sorry about that, I've had 101 things to take care of over the weekend, and I've only just got to the last on the list. I was just about to email you now. So I will. |
| ||
| emailed ya. |