Re: gnome-keyring Short introduction
- From: Stef <stef-list memberwebs com>
- To: Michael Leupold <lemma confuego org>
- Cc: gnome-keyring-list gnome org
- Subject: Re: gnome-keyring Short introduction
- Date: Sat, 21 Feb 2009 02:24:03 +0000 (UTC)
Michael Leupold wrote:
> On Thursday 19 February 2009 17:00:04 Stef wrote:
>> * Use a key agreement protocol to establish session keys, and then
>> transfer secrets encrypted while in DBus.
>> Pros: Simple conceptually.
>> Cons: Complex practically, need libgcrypt or other crypto library
>> dependency.
>
> I've been toying around with that today. What I got was a simple
> implementation of the Diffie-Hellman(-Merkle) key exchange.
Awesome. I was looking at DH and it seemed very doable. I haven't had
time to work on this just yet.
> Drawbacks this method has:
> - The encryption is layered above DBus. I haven't found a way to somehow make
> this transparent (in Qt). This means based on the protocol specification
> client and server have to encrypt/decrypt arguments accordingly.
I imagine we'd only encrypt the secret. That is each time we send a
secret, we send an IV and and an encrypted packet. The rest of the
protocol would be fully debuggable and untouched.
> Overall this seems pretty viable. Of course being a KDE guy I implemented this
> using Qt. Without knowing a lot about glib I assume it would be equally easy
> to implement there (not for me but for someone who actually knows glib :)).
A train of thought that came up when I've been ruminating on this
implementation:
* Implementing this on the glib side would mean linking a crypto
library, into the gnome-keyring public libraries.
* The politics between the major crypto libraries are almost as bad
between the desktops :)
* If libgnome-keyring links to (for example) libgcrypt will that
stymie adoption of our brand spanking new cross desktop secret
storage by people like the mozilla folks?
* Or would the mozilla folks just use our DBus interface directly
and make their own implementation?
* If so, and everyone makes their own implementations, then will they
balk at a possibly seemingly superfluous use of crypto and the
complexity?
* 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.
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 :)
Cheers,
Stef
P.S: I'll be away for much of the next couple days.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]