[sword-devel] Sapphire, module cipher

[Kahunapule Michael Johnson]

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