[BUG] "No working decryption method found" on 2.x, with key-pairs generated by very old GnuPG versions #2340
Comments
raxod502
added
C-bug
|
Your GPG key has two identities, both of which share a name and differ in emails, but your |
I am not an expert on PGP, but I do not believe it is necessary to disambiguate between identities when encrypting a message. I believe that one encrypts a message to a public key, and not to a particular identity. I don't think that information about the identity is even included in the encrypted message, but only the public key fingerprint. So, whether I instruct GPG/Pass to use When I decrypt a message, the identity is shown: However, if I do not have the private key available, then no identity is shown. I would presume that if the message content included any information about which identity it was intended for, then this would be displayed by GPG: So in other words, I think GPG encrypts my password files to my single public key, regardless of what identity or identities may be associated with it. Like I said, I'm not very familiar with the details of PGP and its implementations, so what I said above could be wrong. Please let me know if I made a mistake! |
|
You're right, I had a bit of a brainfart on the multiple identities front. Can you reproduce this by generating a fresh throwaway key and uploading it here? That'll let me test it myself and then be included in the regression test suite. |
msfjarvis
added
S-waiting-on-reporter
|
Done: https://github.com/raxod502/test-password-store And I confirmed that the problem is indeed with the multiple identities. The first time around, I created the key, added a second identity, and then encrypted my password. Import key and repo into app, it works. But the second time, I created the key, encrypted my password, and then added the second identity. Import key and repo into app, I get the error above. |
|
Actually, I take that back. The second time I tested, I made a mistake and forgot to copy the updated private key. When I did it correctly, it worked. So I have not yet been able to reproduce the problem with a separate key-pair. I will keep working on this and get back to you when I figure out how to reproduce it separately from my primary key-pair. (And I forgot to mention the passphrase for the key-pair in the repo linked above is |
|
Still working on this... I found something interesting using the commands in https://davesteele.github.io/gpg/2014/09/20/anatomy-of-a-gpg-key/ though. As far as I can tell my existing keypair and the new one are almost identical: However, if I look carefully at the packet descriptions, I can see a few differences, probably because the original keypair was generated so many years ago (and especially that the original identity signature was generated at keypair creation, while the added identity signature was generated recently). Note the two identity signatures on the new key, with identical key options: But if I look at the original keypair, only the second (recent) signature packet matches up: While the first (older) one is different: Note it is missing an All testing done with the latest release as of ce54200, by the way. I'll continue investigating and see if I can manufacture a key that triggers the same behavior, but that I can share publicly. |
|
@vanitasvitae anything that jumps out to you as a reason for BC not finding a decryption method in the key? |
|
Hm, this is not trivial to debug without deeper knowledge of the key material (or even better, the ciphertext), but of course it is not always possible to share those. PGPainless includes some logging (e.g. here) which could help identify the issue, but it appears APS does not output these messages? |
APS does not set an explicit global logger so SLF4J defaults to a no-op implementation. We do have an existing implementation of an SLF4J Logger (for SSHJ) that forwards to Android's logcat stream so I can probably just set that globally. |
|
I've wired up our internal logger to SLF4J. @raxod502 please try decrypting again with your key on the latest snapshot and capture a log following the steps here. |
|
Aha, yep, got some more interesting logs indeed: |
|
So now we only need to find out why the key cannot be used for decryption :P I really should add an error message containing the reason for why the key cannot be used :D |
|
I'll continue working on getting a working key-pair to reproduce the issue. |
|
Got it! 🙂 I booted up an Ubuntu 14.04 container running GnuPG 2.0.22 of 2013-10-04, generated the key with that ancient version, exported it out of the container, and then used that to init a password repository. It works fine with Pass, but produces exactly the same error on Android as with my personal key, so I can share it. Steps to repro:
|
raxod502
changed the title
msfjarvis
added
S-blocked
|
That's quite helpful, thank you! The fix for this seems to be required on PGPainless' side so I'll let @vanitasvitae have a look at it when they're able to and go from there. |
|
I find it hard to debug this to be honest. My suspicion is, that your key is simply no longer up to standards however. |
|
@vanitasvitae You can take a look directly at a key which reproduces the issue in the repo that I posted publicly here! #2340 (comment) However, when running the tool you linked (package That in itself is a good enough reason to replace my private key, so I will do so. Perhaps it is the case that all keys old enough to be incompatible with PGPainless are also old enough to use deprecated encryption algorithms, in which case it may be acceptable to simply say they are not supported since they should not be used in any case. |
|
The presence of an SHA-1 key confirms my suspicions, the key is being rejected by PGPainless due to its hash policy and for good reasons. I'll close this issue now since this is intended behaviour, though it's probably worth improving the logging around this in PGPainless. |
msfjarvis
added
S-unactionable
|
At the very least, it might be nice to print a different error message in APS when the user gives an invalid password, versus when PGPainless returns an unknown error. |
|
In any case, I've generated a new key-pair and rotated it on all my devices and documents: The new key works fine with APS. |
|
|
@raxod502 glad to hear that the new key works :) |
|
As a sidenote (I just did some further testing using the test key from #2340 (comment)): |
Describe the bug
I've just tried out 2.x from the snapshot apk of 2023-01-20, to get #1922 for #1982. Repo cloning, key import, and password list works fine, but passwords cannot be decrypted.
When selecting any password file, a dialog is immediately displayed requesting I enter a password. Regardless of whether the entered password is correct or incorrect, on submission an error
Wrong passwordis displayed. With debug logs enabled, the following stacktrace (No working decryption method found) is displayed via logcat on error:In the
PGP Key Managerpanel, I can see that I've imported one PGP key, which is displayed asRadon Rosborough <radon.neon@gmail.com>. The file I imported was generated viagpg --export-secret-key radon@intuitiveexplanations.com. Here is the fingerprint (note, there are two identities attached to the key):My
~/.password-store/.gpg-idfile has a single line,Radon Rosborough.Steps to reproduce
Steps to reproduce the behavior:
Update: comment #2340 (comment) has a sample key-pair and public repo on GitHub that reproduce the issue.
Expected behavior
In v1.13.5 using the same repo and GPG key, decryption (via OpenKeychain) works as expected - passphrase is read from the user and then used for decryption; cached according to configuration.
I noticed that, in 2.x, there is no selection dialog for how long to cache the passphrase for, unlike in v1.13.5. From #1523 I am guessing this is just not implemented yet.
Screenshots
Happy to add screenshots of the relevant UI elements if it would be helpful.
Device information
Additional context
My main (selfish) motivation is getting #1922 into my local apk; looks like upgrading to 2.x is a necessary first step there.
The text was updated successfully, but these errors were encountered: