[Authentication] Fwd: Re: Session negotiation
bradh at frogmouth.net
Thu Jul 16 04:52:57 PDT 2009
On Thursday 16 July 2009 20:47:51 Michael Leupold wrote:
> > We need to generate the key from some kind of passphrase (or other
> > source, but passphrase is what I expect from this). So we need to define
> > how to produce the key, and we need to store the IV with the ciphertext
> > version of the secret. I think each secret should be encrypted separately
> > (and so have a different IV).
> As I imagine it, the symkey used for secret transport will be assembled
> from random values using diffie-hellman. And yes, due to the constraints
> mentioned above we'd really have to send ivs along each of the secrets.
I think there are two different issues here.
Are the secrets going to be transferred in encrypted or decrypted form? That
is, does the application-side library do the decryption, or is it done on the
storage side? I'm assuming that the storage side will decrypt them from
whatever disk encryption is used, and they will be transferred using dbus to
the application in a decrypted (but optionally covered by DH) form. In
addition, the decryption key (or passphrase analog) for the disk encryption
needs to go across dbus.
So there is a need to protect the session using some kind of transport
security (e.g. DH, per the spec), but also to provide the key to decrypt the
store. I note http://www.gnome.org/~stefw/secrets/html/ch08.html says "This
specification does not mandate the use of master passwords to lock a collection
of secrets. The service may choose to implement any method for authenticating
secrets." but if the service is not required to provide secure storage, then
what is it offering? If it might need to use an interoperable passphrase to
provide key for the storage side, we need to define that approach.
More information about the Authentication