Re: gnome-keyring Short introduction

[Stef <stef-list memberwebs com>]

Michael Leupold wrote:
> On Saturday 21 February 2009 03:24:03 Stef wrote:
>>  * Implementing this on the glib side would mean linking a crypto
>>    library, into the gnome-keyring public libraries.
> 
> We could make linking a crypto library on the bindings optional by having a 
> small implementation of a supported cipher in the client library. Eg. kwallet 
> has a small part for blowfish-cbc encryption (which is currently used in 
> encrypting the file with the secrets).

Certainly an option. We used to do that in gnome-keyring-daemon (AES and
SHA1), but some of our downstreams didn't like that because they have to
do legal work for each crypto implementation, and had already done it
for libraries.

But I don't think linking to a crypto library is a show stopper in any case.


>>  * If so, and everyone makes their own implementations, then will they
>>    balk at a possibly seemingly superfluous use of crypto and the
>>    complexity?
> 
> I think if we do it right the overhead introduced by the encryption layer 
> should be low enough to allow for easy implementation.

Yes, that's true.

We'll also need some algorithm negotiation. Perhaps the client tells the
daemon which algorithms it wants (DH Group, and block cipher). In theory
that could allow certain clients to tell the daemon they want "no
encryption".

>>  * We're supposed to be protecting secrets, is it superfluous to use
>>    crypto to protect secrets while passing through the same system
>>    they'll be used on? ... Very likely by apps in unpaged memory.
>>
>> I guess what it comes down to, is before we go to all the complexity, we
>> need to convince ourselves that it's really worth it and be able to back
>> up our decisions on this topic.
> 
> Generally encrypting the secrets if running on DBus seems like a good idea as 
> the specification allows for different transports (afaik currently a local TCP 
> socket is used on windows). 

True good point. However I feel that protecting against active attackers
shouldn't be our goal. Remember that encryption with authentication is
useless against an active attacker (MITM).

In case of Mozilla the hard part doesn't seem to
> be to convince them that the encryption isn't superfluous but that it's worth 
> implementing an interface to keyring at all :-)

I believe that a standard DBus interface used by both KDE and GNOME
would be a very compelling reason.

>> Coming back to the topic of linking a crypto library into our client
>> libraries (ie: libgnome-keyring.so in our case)... Off topic idea:
>>
>> Windows does this interesting thing, where you pass data to a special
>> black box function and it encrypts it in such a way that only the
>> application, user and computer that made the call can then decrypt it
>> later again. This may be something we want to offer as well, and would
>> also require a crypto library linked into our client libraries.
>>
>> Anyway, sorry for the brain dump. I hope I've said something coherent :)
> 
> Do you mean for allowing to store secrets client-side without communicating 
> with the daemon or for storing secrets daemon-side without any other client 
> being able to read them?

Well this idea was for an easy way to store secrets client side, which
could be perhaps large blocks of data. But this is orthogonal to daemon
stored secrets, and is just a random idea.

Cheers,

Stef