From: [email-masked]
Date: Mon, 17 Mar 2003 18:12:43 -0500

Thanks for the clarification (re single-user vs. multi-user
file-encryption/protection).  The multi-user case has been thoroughly
discussed in this thread, and I have nothing to add to that.  However, I'm
wondering if there isn't some lingering open-endedness left over, regarding
the single-user case?

I've tried to think of reasons one might prefer PKC techniques (over
non-cert/bare-key techniques, presumably secret-key only) for the
single-user file-encryption problem, and I couldn't think of one.  That
probably shouldn't be too surprising.  PKC/X509 is explicitly designed to
be an *authentication* framework, and authentication (properly so-called)
involves two distinct parties (a claimant and a checker/validator).  But in
the case of single-user file-encryption, there is only a single party
involved (the file is assumed to be entirely under the control of the
single "self" entity), hence no true authentication is happening.

So, given all the PKC gotcha's discussed in this thread, I couldn't come up
with any rationale whatsoever to prefer PKC over bare-key techniques for
single-user file-encryption.  If anyone can think of such an argument, I'd
really be interested in hearing about it, publicly or privately.

- Walt Tuvell, Groove Networks

----- Original Message -----
From: "Vainikainen Saku EINT" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 14, 2003 7:06 PM
Subject: Recommendation on subject matching rules needed..

>
>
> > My question is: Why is a *cert* being used for *personal*
> > file protection (i.e., "from/to self", as opposed to
> > protection of the file when it is communicated from one
> > entity to another)?  It would seem that certs are the wrong
> > tool for this job.  *Bare* keys (keypairs or secret keys,
> > perhaps derived from a passphrase) seem to be the right tool.
> >
> > ...
> >
> > All-in-all, it seems that a better solution would be to store
> > a bare secret key on the smartcard and use that to protect
> > his files, doesn't it?
>
> Yes - this sounds reasonable when the same person is always encrypting
> and decrypting the file, but the disk/folder/file encryption systems
> need multi-user capabilities, ie. more than one person is required to
> access the encrypted file.
>
> If you use secret keys to encrypt the data for let's say 20 persons,
> your data bloats 20-fold, or of course you could generate a session key
> for bulk encryption of the data and just use personal secret keys to
> encrypt that key for each user. You still have to somehow identify the
> "legal" users of the encrypted disk/folder/file, instead of
> trial-and-error decryption. What better way to do this than
> certificates.. ?
>
> This applies to hybrid encryption also: bare keypairs are not enough
> since trial-and-error decryption is resource consuming, thus not wise.
>
> Of course one could insert some checksums or whatever constant data to
> the first encrypted block to make the trial-and-error decryption faster,
> but this would also introduce a good way for a brute force key quesser
> to figure out the secret key.. No good.
>
> And passphrases still need to be broadcast/transmitted to and remembered
> by all users, and it is not wise to use the same passphrase for all
> encrypted data, so they are no good.
>
> Saku.