GNOME Bugzilla – Bug 778357
Inconsistent shared key derivation between libsecret and gnome-keyring.
Last modified: 2018-03-22 13:56:17 UTC
This can be observed on libsecret side after failing to unpad the payload: GLib.Error: secret-error: Received invalid secret from the secret storage (1) ** Message: received an invalid or unencryptable secret Essentially the difference boils down to libsecret not performing any padding on shared secret obtained from DH, while gnome-keyring does prepend null bytes. Not sure which behavior is correct one, so this could apply to gnome-keyring instead.
Here's a description of the specs in play: https://standards.freedesktop.org/secret-service/ch07s03.html . If I understand you correctly, then following HKDF here is the goal.
The question is how to represent shared secret number obtained from DH (i.e., pad it to the full length of prime with zero bytes, or not). Actually it is not clear to me that specification actually gives an answer. The HKDF RFC does not have anything to say about that. On the other hand, the DH specification describes a method for generation of keying material that does require preserving leading zeros so that obtained shared secret number occupies the same number of octets as prime. Though, Secret Service API does NOT use this particular method (instead referring to HKDF). The padding code itself is here (and is missing from libsecret): https://git.gnome.org/browse/gnome-keyring/tree/pkcs11/gkm/gkm-dh-mechanism.c#n261 So actual fix would be quite trivial.
Created attachment 345294 [details] [review] Ensure that generated secret occupies the same number of bytes as prime. BTW, the issue is a duplicate of those: - https://bugzilla.gnome.org/show_bug.cgi?id=769666 - https://bugzilla.gnome.org/show_bug.cgi?id=776006 And following error message is indicative of the same problem when secret is transferred in other direction (libsecret -> gnome-keyring-daemon) > Couldn't create item: The secret was transferred or encrypted in an invalid way. Attached patch addresses the issue by padding the shared secret in libsecret. The egg/egg-dh.c looks like a reasonable place to do that, though files in egg/* seems to be replicated across different projects and this would make them diverge more (gnome-keyring one for example has a memory leak that is already fixed in others, see diff between those for details). Note that there are potential memory leaks when libgcrypt routines fails, I didn't try to address those.
Thanks merged to libsecret and gnome-keyring.
*** Bug 769666 has been marked as a duplicate of this bug. ***
*** Bug 776006 has been marked as a duplicate of this bug. ***
I just received this error in an up to date Fedora rawhide, which uses: libsecret-0.18.5-7.fc28.x86_64 gnome-keyring-3.28.0.1-1.fc29.x86_64 gcr-3.28.0-1.fc29.x86_64 The observation: a) after cold start login to GNOME under Wayland from gdm b) run terminal c) start `evolution` from the terminal - everything is okay d) close evolution e) start `evolution` from terminal again - the error is shown (I see it multiple times): ** Message: 11:12:49.821: received an invalid or unencryptable secret f) close/kill evolution g) start `evolution` from terminal again - everything is okay The above is just the observation, not the steps, showing that the background services/daemons didn't change at all, it was only the application which had been started multiple times where the connection to libsecret (or what the error was about) either worked or not. Should I reopen the bug, or you prefer a new one?
Afaik libsecret 0.18.5 doesn't contain this fix, while gnome-keyring does. I can create a new release if it makes sense.
Oh, I expected, when using Fedora rawhide, thus the bleeding edge, that the core parts like libsecret had been updated, especially due to this bug, which had been closed more than a year ago. I just realized that libsecret 0.18.5 reached Fedora in time of Fedora 25, precisely 2016-03-25 10:36:39. That's quite ancient version. I believe this issue is important enough and quite nasty that it deserves a release of libsecret. Thus, please, do the release. Thanks in advance.