[Authentication] Fwd: Re: Session negotiation

[Brad Hards]

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.

Brad