It is a good idea to automatically detect if the right key was used or not before feeding possible gibberish to the next process in the chain. The tricky part about this is to make the way you do that of least practical use to an attacker who might be using a brute force key-checking attack. Naturally, even if you didn't have the foresight to include an easy way to do this, the encoded text has certain attributes that can be recognized automatically by either an attacker or the legitimate user who just fumble-fingered a key. With open source software, you basically hand the attacker your method, anyway, so we really rely on the secrecy of the key and the security of the algorithm. It doesn't make a significant difference to the security of the system if you choose one of several reasonable approaches.
If you have the flexibility to alter the encrypted file format and to re-encrypt all of the locked texts (which you do... at the cost of having customers with legitimate unlock codes re-download the texts they bought), then you could insert 8 or more random bytes at the beginning of the stream, followed by actual interesting data, followed by a end marker and the same random bytes repeated at the end. If the repeated random bytes actually match, you got the right key. If not, you didn't, or maybe the file was damaged. This method is nice, because it provides easy checking, with no significant wasted effort if the key was valid. However, it would take an attacker doing a brute force key attack more processing time than simple known plain text bytes at the beginning of the stream. Indeed, a clever attacker could probably figure out a more efficient check than processing the whole file for most key guesses, anyway, so you lose no security this way. You also gain robustness and convenience with this repeated random byte trick. (A variation of this is to put the repeated bytes right after the originals, but that has the disadvantages of not requiring as much work per bad key guess, and it also is useless for detecting corrupted files.) If you don't want to change any of the encrypted texts, then you could look for characteristics that any valid text would have. If you don't find them, it must have been a bad key. This kind of checking is probably more complicated, given that we want to be able to encode texts in any language, but you can always check for valid markup, etc. More robust error checking later on down the line is a good thing, too. :-) Nobody has gloated to me, yet, about breaking the Sapphire stream cipher. That doesn't prove anything, but it would have proved something if a weakness in the cipher were exposed. :-) That is not the weakest link in the chain by a long shot. It is the keeping the common encryption keys secret and the text that can be easily copied once decrypted by a legitimate user. For that, we rely on the moral code written in the Book we encode. :-) Michael (whose code contribution to this project consists of the Sapphire Stream Cipher) http://kahunapule.org _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
