Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CV25519 support is broken #84

Open
michaelni opened this issue Jan 10, 2023 · 2 comments
Open

CV25519 support is broken #84

michaelni opened this issue Jan 10, 2023 · 2 comments

Comments

@michaelni
Copy link

I tried using my ledger for secure gpg key storage. And short and simple this app is just too buggy. Especially if "secure" is the goal. Now the details
I tried generating ed25519/cv25519 keys on the ledger (refusing the default option of a backup). This results in 2 working ed25519 keys for signatures and authentication on the "card" but the decryption key which should be a CV25519 key. Simply doesnt work. The ledger asks for the pin and all but it fails.
in the logs one sees:

operation decipher result: Card error
app_decipher failed: Card error
DBG: chan_7 -> ERR 100663404 Card error <SCD>

Then one tries this again and picks the default like probably most people do, "do the whatever backup". And that works with ed/cv25519 keys or does it? It sure looks like its working signing is perfectly fine it asks for the pin and all same as without the backup but then with decryption it works a little too well. It doesnt ask for the pin, it doesnt even need the ledger to be connected. And it keeps working if one kills all agents and caches. Yes the unencrypted private key seems simply left on the disk silently after asking the user for a password to encrypt a copy of it. And it works not all with the ledger but with the key on disk.
I want to be wrong. Please someone tell me this is not so and iam an idiot and am missing something.
Ohh and btw RSA4096 keys do seem to work for encryption. Iam just not sure how much i trust anything from this app anymore.
I tried this with

gpg (GnuPG) 2.2.19
libgcrypt 1.8.5

and

gnupg2 (2.2.41), gnutls28 (3.7.3), gpgme1.0 (1.17.0), libassuan (2.5.5), libgcrypt20 (1.8.9)

The versions didnt make a difference

@Infernogeek1
Copy link

Can confirm on
gpg (GnuPG) 2.3.7
libgcrypt 1.10.1-unknown
scdaemon log: https://pastebin.com/Wpy5Ahk5
gpg-agent log: https://pastebin.com/wDk3QRUK
Note lines from scdaemon log

2023-03-21 01:00:27 scdaemon[2623] DBG:  response: sw=6F42  datalen=4
2023-03-21 01:00:27 scdaemon[2623] operation decipher result: Card error
2023-03-21 01:00:27 scdaemon[2623] app_decipher failed: Card error

@cedelavergne-ledger cedelavergne-ledger mentioned this issue Jun 25, 2024
3 tasks
@yankeguo
Copy link

I spent the whole afternoon debugging and found out it was a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants