Hi Leonard,

> >If you support a limited number of cipher and key sizes pairs
> >(which you always do), and treat them as separate ciphers, then
> >you do not actually need to know how many bits the key is, nor
> >what strength the algorithm is.
> 
>          True.  However, by storing the key length it allows you to upgrade 
> the encryptor without having to upgrade the decryptor and thereby provide 
> users with backwards compatibility.

You will need to leave in the decryptor for both the old and new 
keysize, so you can just try them both, perhaps in the order new, 
old :).

> >You go about finding out which
> >cipher-key size is the correct one by trial and error; in the two
> >number approach which I suggested you only need to decrypt the
> >first 8-bytes to know unequivocally when you have the right cipher
> >and key (and since the two numbers are generated at random, this
> >approach is not susceptible to plaintext attack).
> 
> That would work, but it still takes time and doesn't offer the 
> level of compatibility.

It does take more time than knowing a priory what cipher and key 
size we deal with, but that only becomes an issue if you suport a 
realy *huge* number of ciphers; even if you have 10 ciphers and the 
right one is the one you try last, you only decrypted 72 bytes in 
vain, that's less than decrypting the fancy <!--============--> 
line in the AW file header. 

As far as compatibility is concerned, I do not see any serious 
problems here. True, you could not tell a person who does not 
know the password what cipher and keysize was used to encrypt 
the document, but then, if they do not have the password that is 
none of their business. Along the same lines, if you did not 
succeed in decrypting the document, you could not tell whether it 
was because the user did not provide correct password, or 
because the document was encrypted using a cipher you do not 
support. The latter will only happen if you discontinue support for a 
particular cipher, in which case you will need to warn the users 
before upgrading anyway.

Even if you include a some kind of a header with the cipher name 
and size, abisource ulr, etc, you still need a bomb-proof method of 
detecting that you have been given the wrong key, so that you can 
gracefully abort opening the file. The two number system is ideal 
for this, because it does not require any knowledge about the 
plaintext and so it will work even if the AW file format is for some 
reason completely changed. (BTW, I have not devised this trick 
myself, I found it a while back while examining Scramdisk sources -
- an excellent piece of Windows software, www.scramdisk.com).

Tomas

Reply via email to