[pmwiki-users] Flat files crypt/decrypt

[Martin Fick]

--- "Patrick R. Michaud" <pmichaud at pobox.com> wrote:

> On Wed, Oct 24, 2007 at 11:46:17AM -0700, Martin
> Fick wrote:
...
> > So, for each combination of password that can
> > be used to log into the site a separate key file
> > would exist.  This key file would contain all the
> > page-keys to all the pages that this particular 
> > password can access.
> 
> This approach still suffers from the problem that if
> the key files are lost or corrupted (or the
passwords
> needed to decrypt the key files), then all of the
> page data is truly lost.

Well, sure, but one could just as easily say that if 
the page files themselves are lost/corrupted the data 
is also lost/corrupted! :)  I am not sure how this 
scheme really provides any further risk?  Maybe simply

that the key files are not "bound" to the pages 
themselves?

As for lost passwords, this scheme at least provides
the ability of multiple passwords including an admin
password for each page.


> Also, I'm not quite sure how one would deal with
> admin passwords -- it would seem that the key file
> corresponding to an admin password would need to
contain
> the page keys for every page on the system.

Yes, it would, this would not be a big deal if the
page keys do not change (although I added some more
thoughts to the PITS about this: see security
improvements), since the admin key file would simply
need a new page-key appended to it every time that
a new page is created (so would any other key files
which need access to the new page.)


> If an admin then wanted to change the admin 
> password, a completely new key file would 
> need to be generated that would contain all 
> of the page keys, yes? Where would we get 
> that list from?

A new key file would not need to be generated, 
but rather the private key for the admin key 
file would simply need to be re-encrypted with
the new admin password (unless you are using the
improved security method I added to the PITS.)



> > [...]
> > Finally, the private key for a key file could be
> > encrypted in the key file with a password allowing
> > the private key to be something obtuse generated 
> > along with the public key, but the password can be

> > something simpler for users to remember/type.  

> Who are the "users" in this last sentence -- do you
> mean "visitors to a site" or the "site 
> administrator"?

Both, anyone one with a password allowing them 
access to encrypted pages.


> Here's a scenario:  let's suppose that I'm an author
> (not admin) that wants to set a new edit password on

> a page. Where does the system go to get the
> (existing) page key for the page, so that
> it can create the key file?

Hmmm, are you really asking about the edit
password?  I would assume that having an edit
password would not imply encryption, but that
having a read password would.  I will answer
the question from the perspective of a new 
read password, let me know if that doesn't make
sense?

There are probably two cases here, (1) a page which
never has been encrypted and (2) a page that 
currently is.

1)  Since someone is trying to encrypt it for the
first time the system would generate a random
symmetric page-key for the page and encrypt the page
with it.  At this point there may be several key
files which need to get this page-key added to them
How to determine which ones?  I'll admit that I am
a bit fuzzy on that since I am not familiar with all
of the authentication schemes available to pmwiki.

It all depends on the mapping of a password to a 
key file.  In a typical authentication scheme, one
password/user (not pmwiki's default scheme,) there 
would be one key file per user and thus per password.
But with pmwiki's default (if I understand it), since
pages get passwords and not users, you would instead 
probably have one key file for the admin and one for 
each page (and thus still one key file per password.)
In essence the page would act as a user/role and its
role only allows access to itself.


2)  Instead of creating a new page-key, the current
page-key will just need to be re-encrypted in the
current author's (or page's) key file.


> (Regardless, the above scenario sounds _far_ more
> complex than anything I want to implement anytime 
> soon, so I highly recommend that a cookbook recipe 
> be made for it if someone is truly interested.)

Whole heartedly agreed!!!  I was assuming a recipe 
and would probably be willing to help someone 
implement it,


-Martin



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com