Subject: Re: encryption
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Wed Apr 25 2001 - 06:01:13 CDT
At 09:34 AM 4/25/2001 +0100, Tomas Frydrych wrote:
>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.
I don't know if it is worth it or not either, and it definitely
touched a few nerves here on the list...
>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?
The latter.
>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 bad passphrase is helpful for a brute force, but not for a
plaintext. But I agree, a bad passphrase is always going to be a
mitigating factor with any private key crypto system.
>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.
You bet!!
>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 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.
> 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
But then we start doing more obscurity and given that we're open
source I am not sure I see the advantage/disadvantage.
> (plus it makes it
>impossible to prove that the file is in fact an encrypted document,
>since it only contain random data).
Good point.
>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.
zlib is already in the tree ;).
LDR
This archive was generated by hypermail 2b25 : Wed Apr 25 2001 - 06:00:57 CDT