Subject: Re: encryption
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Tue Apr 24 2001 - 04:41:01 CDT
As far as the US export restrictions are concerned, Leonard is
obviously better informed than me; I was under the impression that
the restrictions were not flatly lifted, but that it was now
possible/easier to obtain a licence for export of strong crypto. In
any case we probably could not just place the encryption stuff into
the public CVS, because of the standing restrictions on the "7 bad
guys" ...
> Encryption is a wide open concept. Are we talking password
> protection, Digital Rights Management (DRM) Features, what?
As I understood, the request was for password protection, which is
normal in other wordprocessors; we could do a better job of it
though, by using a decent algorithm. I do think there is a legitimate
place for this, sometimes people want to 'lock' an individual
document from preying eyes, without having the wider need to use
encrypted file systems or wanting to have an encryption suite
installed; 'man gpg' is not an answer to this, that's a solution for a
hacker, not the average word processor user.
> Before you go off and do this, there are MANY other things to
> discuss (IMHO). ... Where do keys (if any)
> get stored? What algorithm(s) should we be using, and why?
The password does not necessarily get stored anywhere, it is used
to en/decrypt the file, then it can be destroyed (it certainly would
not be stored in the encrypted file, as Aaron feared). We could
support multiple algorithms if we wanted, but blowfish would be a
good start, it's fast in software and its in the public domain.
> Let's not just do a "quick and dirty hack" here. If we think this
> feature is important, let's figure out what the feature really is and the
> right way to implement it.
When I said it would be very easy, I did not mean cutting corners,
but that the AbiWord_1 file importer/exporter lends itself to do the
job. In the AbiWord_1 file format every byte that is written/read from
the disk goes through _writeByte(s)/_readBytes. Hooking in an
encryption algorithm at this point, say a block cipher (such as
blowfish) in an 8-bit CFB mode, would mean that everything that
goes on the disk would be encrypted. The only other thing you
need is some way of identifying the algorithm and whether the
decryption is working. Probably best way is to generate a pseudo-
random number, and write it into the file twice, separately
encrypted. On opening the file for reading you test that after
decryption the two numbers are identical. If not, either the key or
the algorithm are wrong. If you support more than one algorithm
you go to try the next one, until you either succeed or run out of
algorithms.
Doing password protection this way would be IMO elegant and
efficient (using blowfish, we would add around 2k to the AW
footprint). I do not like very much the idea of scripting anything to
get the file contents encrypted (and even less saving into abw or
zabw and then using external file encryptor), and there is always
the question whether product X is available on platform Y; while
password protected files are not likely to be shared with many
people, a single user might be using AW on different platforms.
I do agree with Bill that this would be ideal as a loadable module.
Tomas
This archive was generated by hypermail 2b25 : Tue Apr 24 2001 - 04:42:57 CDT