Hi Leonard,
> And some other things as well. However, it may be worth our
> while to also consider looking at basic DRM features as well ala PDF and
> eBooks (don't copy, don't print, etc.). Admittedly, such features aren't
> as secure in an open source product where one could just recompile a
> "secureless" version - but it would give the average user a "touchy feely".
Considering that we would have to make it very clear to the user
that anyone can compile a "secureless" version of AW, I am not
sure it is really worth the effort, even though I agree it would have a
nice touch.
> That's an option, though it still makes the file less secure than
> even something such as a "double-blind" approach (ala Unix passwords). In
> a "double-blind", you generate a random "passphrase", encrypt the document
> to that value, then encrypt that value with the user's passphrase and then
> store that. This makes "plain text" attacks of document files pretty useless.
Do you mean you encrypt the whole document twice with different
passphrases, or do you encrypt the random passphrase and
include it with the doc? If the second, then I do not see how this
reduces plaintext attack. It makes it more difficult to test any
guesses of the password though, but at the end of the day, if the
user choose a bad passphrase, there is nothing you can do about
that.
A simple and very efficient way to reduce the chances of plaintext
attack is to compress the document before encryption, this has the
added benefit of the final document being smaller, since once it is
encrypted (if the algorithm is any good) it will not compress.
> >The only other thing you
> >need is some way of identifying the algorithm and whether the
> >decryption is working.
>
> Also algorithm strength (so you know how many bits the key is),
> version, etc. As far as testing the decryption, that's another advantage
> of the double-blind since you'll know pretty quickly.
>
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. If the user types in the correct
password then when you use the same cipher-keysize pair that
was used to encrypt, it will work. 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).
>From security point of view it is better not to leave any unencrypted
headers in the file with information such as cipher and keysize;
having to work out what cipher has been used makes any kind of
attack on the encrypted file more difficult (plus it makes it
impossible to prove that the file is in fact an encrypted document,
since it only contain random data).
I have got a working prototype of a file imp/exporter along the lines I
propossed yesterday; I want to see how feasible it is to incorporate
compression in before encryption, and then I will put it up for pier
review.
all the best
Tomas
