On Saturday 21 February 2009 03:24:03 Stef wrote: > Michael Leupold wrote: > > 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. 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). > * 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? I think if we do it right the overhead introduced by the encryption layer should be low enough to allow for easy implementation. > * 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). 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 :-) > 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? Regards, Michael
Attachment:
signature.asc
Description: This is a digitally signed message part.