Feature Proposal: Feature Request for Encryption of the Data Pages

Motivation

I run some personal twikis on virtual hosted web space. TWiki runs great and it is very convenient to have a system that tracks my thoughts and version history out there on the big bad web!

I like DakarRelease, too, because of the great session handling capabilities!

But I'm nervous, because the underlying pages are in plain text form, making it easy for any system administrator, or should I be so unlucky a hacker, to view my source (and personal) data.

Description

I would like a plug-in or some method of having my twiki data encrypted in some way. Instead of storing plain text, I would like the data files to be goobledegook binary, or goobledegook text. Something to dissuade system admins from pouring over my data.

Ideally TWiki would decrypt the underlying file before processing and subsequently displaying. Obviously this plug-in/function would need to run before all other Plug-ins that operate on the plain-text.

The biggest challenge this would present (besides choosing an encryption algorithm) would be how to deal with RCS, as ideally changes would be encrypted also.

This is a personal wish-list, as any company that relied on the security of the data would surely host the data themselves in a fashion they regard as secure.

Evidently the search function would also be impacted as it presently relies on grepping through plain files..

-- PeterPayne - 05 Jan 2006

Impact and Available Solutions

Note: Patch is attached as https://twiki.org/p/pub/Codev/EncryptUnderlyingPages/twiki-foo-bar-patch.diff. The patch is against the TWikiAlphaRelease of 15 Feb 2004.

Documentation

Somewhere between the TWiki engine and the filing system there needs to be a means of decrypting/encrypting pages.

Retrieval of each page would require:

• decryption of the page before twiki plug-ins and engine processes the text

Searching would require:

• decryption of each page before grepping through

Storage of each page would require:

• decrypting existing RCS file
• creating ,v file with new changes from data file
• encrypting changed RCS file
• encrypting data file

Obviously it would not be okay to decrypt files to disk. Decrypting to memory (e.g. piped processes) would be okay though.

Examples

Implementation

Discussion:

This smells slightly like paranoia, but if you need encryption this should be done transparently by the underlying operating system by a kind of encrypted filesystem. EnFS has a Wiki about an encrypted filesystem in user-space.

-- FranzJosefSilli - 05 Jan 2006

The EncryptedPagesPlugin aimed at this - the encryption part works fine, but the TWiki integration was not finished.

The author of that plugin was a friend - I can ask him questions if this helps.

-- MartinCleaver - 07 Jan 2006

I like the EnFS idea, very neat indeed.. Worth looking into for home use.. Wouldn't work on a virtual web host that one can only FTP to/from.. And paranoia can be a very good thing sometimes..

-- PeterPayne - 10 Jan 2006

There is a way to do this but it strikes me as clumbersome.

UNIX/Linux has a mechanism for encypting file systems 'out of the box'. Many other 'filesystems' such as FTP-FS, SSH-FS are built on the idea. It is based on the losetup loopback driver. You mount a virtual file system. The file system is encrypted and looks like an encrypted file.

The trick is to mount it for each TWiki session, then unmount it at the end of the session. The encryption key is in TWiki. (It will have to be algorithmically obscured so the sysadmin can't read it.)

Yes, this is going to be cripplingly slow.

Yes, if the sysadmin is patient enough he can reverse engineer teh code in TWiki, figure out the key and mount the file system himself.

If its a home system, sure you are the admin!

If its a hosted system, then your best bet it get a dedicated machine, admin it yourself and just pay for the racking space & power.

-- AntonAylward - 11 Jan 2006