{Spam?} Re: loading psk credentials from encrypted file

[Michael Weiser]

Hi Nikos,

On Sat, Oct 24, 2009 at 04:34:55AM +0300, Nikos Mavrogiannopoulos wrote:

> > A few days ago I had an idea though: Why not abuse the PKCS12 functions
> > to save the datum_t holding the PSK key out in an encrypted PKCS12
> > structure? 

> What are the reasons for doing that? Is it for distributing the actual
> key to clients? For protecting the whole password file maybe pkcs-12 is
> too much, and saving the password file into an encrypted partition might
> be simpler.

Yes, it's meant for storage of keys on the client. I thought about an
encrypted filesystem container as well, but then the key is vulnerable
as long as that container is mounted. It also adds at least two more
steps to startup of my client. Of course, they can be automated by a
script. But that together with a whole encrypted container for 64 bytes
of data seems even more overkill to mee.

If the key is in an encrypted file all by itself, someone wanting to
extract it would need much more access than just mixed up filesystem
permissions.

> > The code looks as shown below (without the error checking for
> > readability). It works fine, but my questions are:
> > 
> > - Is this at all sensible or (will it break|is it braindead|other
> >   reason for never ever doing it)?
> I don't like pkcs-12 due to it's complexity, but nevertheless there is
> nothing (else) wrong with it and pretty much seems to fit here.

What SSH does with it's identities is much what I'd like. After looking
at their code, I despaired of being able to get it implemented without
major breakage.

PKCS12 might be complex on the inside but GNUTLS's PKCS12 API to me as
developer is nicely simple. If there were something similarly simple
API-wise with support for stronger ciphers and perhaps even a simpler
internal structure, I'd jump on it. :)

> > - Can I use something stronger than RC4-128 for encryption?
> I believe PKCS-12 supports 3DES as well.

Is there a way of adding something like AES-256?
-- 
Thanks,
Micha