[sword-devel] Sapphire, module cipher

[DM Smith]

Kahunapule Michael Johnson wrote:
> 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.
I think that this would work well. It does not matter what the random bytes are. The nature of the stream cipher is that it uses what it has seen so far to encrypt/decrypt the next character. With the random bytes repeated at the end there is no way that it will decipher to a match if the key is not correct.

The random bytes probably should be generated by the cipherraw utility. I don't know if backward compatibility is needed, if it is then the cipherraw utility can drop a file which could contain the number of bytes used for the random bytes.

Since the handling of text is a block at a time when enciphered, the change to the SWORD API is minimal. Using the length of the random bytes, the beginning and end of the block is compared. At this point the block is "substringed" to yield the original block. Alternatively, the length of the random bytes can be added to the seek offset obtained from the index.

Still, the simpler route is Martin's check for non-printables after deciphering the first 100 or so characters. (I'm assuming that it is fully UTF-8 aware.) The advantage of this technique is that it is simple, doesn't require any changes to the existing sword module format, and doesn't require the entire block to be deciphered. The disadvantage is that it has a slight chance of saying that the unlock key is good when it is not.