Re: RFP: CompoundStorage document



On Tue, 2002-04-16 at 10:07, Alan Horkan wrote:
> > XML is quite useful in many ways but it has limitations.
> > 2) Encryption is extremely ugly.
> Am i missing something obvious?
> What does encryption have to do with the document being in XML format.
> I dont know how this works out in practice but at least in theory I
> thought that you compress the document then encryption is the absolute
> last step done.  Encryption as a complete seperate task.
With a zipfs you can add to the manifest that the contents are ciphered.

That would be post document handling, and would be a feature that can be
added to the zip manifest.

> It would not be done not as an integral part of the document, that
> cryptography would be left to the experts and you would just encrypt the
> file irrespective of its contents or type.  In the case of compression
> it does not make sense to have to decompress the whole document every time
> (tar.gz) and there are clear benifits to be able to easily access
> different parts or the document, or have some parts uncompressed (zip) and
> use existing tools (zcat).  But I really think that the encryption should
> be an almost completely seperate task.

It is a separate task, completely independent of application scope.
Ideally we should have more integration of criptography on the desktop,
and I plan to do something about that, but linking with gpg isn't that
hard.

> Am i lost in computer science?  Are there practical reasons for not doing
> it this way.  I would be interested to know.

It's nice to support crypted files because of enterprise use.
Not some rot13 looser cipher of course.


Hugs, rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Ghandi
+ So let's do it...?

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]