Communicating the keys to the authorised people is
exactly what I'm
talking about.
In a public, decentralized wiki, that would certainly be a problem.
In a corporate environment (where this is be needed most) though, it
would "only" be cumbersome.
Even with user groups, if the decryption is taking
place client-side (which is what you're suggesting with Javascript),
the key needs to be transferred somehow.
True.
So, what if we move away from the client-side en-/decryption and insert
a step in between retrieving the page contents from the database and
sending it to the client:
1. retrieve page contents
2. retrieve password* (blank by default)
3. decrypt contents with password (no check whether it worked)
4. send decrypted page
* either via user groups, or with a simple input field for the password
Hmm ... so I guess having user groups might not be feasible after all.
But for crude (but simple and workaround-proof) protection, client-side
en-/decryption would work!? (Though things like link analysis, job
running, transclusion etc. would obviously not be possible... )
-- F.