Can’t I have two keys with same email address?
error message and log:
IMEX failed to complete “validating certificate with a non matching key (ID XXX != YYY)”
The OpenKeychain app has no problem importing the file.
latest version from F-Droid 1.42.4 6752
Before version 1.42.6 old keys were saved, but not used for decryption. Starting with Delta Chat Android 1.42.6 this bug is fixed:
The problem you have is about importing the key though. XXX is the address and YYY is the “certificate issuer”, if they don’t match Delta Chat complains. Maybe it is actually a wrong check as it only allows “self-signed” keys:
Delta Chat supports simple keys where the key is signed with itself. If you have something more complicated, this is not tested and may fail, in this case we need more details about the structure of the key file you are trying to import.
Here is an example key:
$ gpg --list-packets alice-secret.asc
# off=0 ctb=94 tag=5 hlen=2 plen=88
:secret key packet:
version 4, algo 22, created 1582855645, expires 0
pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1)
pkey[1]: [263 bits]
skey[2]: [256 bits]
checksum: 1037
keyid: 64B08F61A9ED9443
# off=90 ctb=b4 tag=13 hlen=2 plen=25
:user ID packet: "Alice <alice@example.org>"
# off=117 ctb=88 tag=2 hlen=2 plen=144
:signature packet: algo 22, keyid 64B08F61A9ED9443
version 4, created 1582855645, md5len 0, sigclass 0x13
digest algo 8, begin of digest 13 7a
hashed subpkt 33 len 21 (issuer fpr v4 2E6FA2CB23B532D728634B5864B08F61A9ED9443)
hashed subpkt 2 len 4 (sig created 2020-02-28)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 64B08F61A9ED9443)
data: [254 bits]
data: [249 bits]
# off=263 ctb=9c tag=7 hlen=2 plen=93
:secret sub key packet:
version 4, algo 18, created 1582855645, expires 0
pkey[0]: [88 bits] cv25519 (1.3.6.1.4.1.3029.1.5.1)
pkey[1]: [263 bits]
pkey[2]: [32 bits]
skey[3]: [255 bits]
checksum: 106f
keyid: E6DABADE14DE79B0
# off=358 ctb=88 tag=2 hlen=2 plen=120
:signature packet: algo 22, keyid 64B08F61A9ED9443
version 4, created 1582855645, md5len 0, sigclass 0x18
digest algo 8, begin of digest 2e 8f
hashed subpkt 33 len 21 (issuer fpr v4 2E6FA2CB23B532D728634B5864B08F61A9ED9443)
hashed subpkt 2 len 4 (sig created 2020-02-28)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 64B08F61A9ED9443)
data: [256 bits]
data: [256 bits]
In the signature packet issuer key ID 64B08F61A9ED9443 of the signature packet matches the secret key ID. If this is not the case for your key, importing fails.
Actually the key contains a signature with the ID of my previous/older key. But why should this be a problem?
I removed that signature and tried again to import it. Now I get: “IMEX failed to complete: incomplete input: Size(2320)”. The file is complete and bigger than 2320.
How did you delete the signature? Could you write down the steps that result in creation of the key with the same structure as yours to reproduce this “incomplete input” issue?
This is probably a bug in rPGP if the key is valid. “Incomplete input” is a parser error, size is the number of bytes expected when end of the file was reached.
I created a key pair via gpg --quick-gen-key and then added a signature via the “seahorse” gui, which used my default ID (old key). So I had a signature with my old ID.
I deleted the sig with gpg --edit-key.
So I am creating a key with:
$ gpg --quick-gen-key alice@example.org
About to create a key for:
"alice@example.org"
Continue? (Y/n)
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: revocation certificate stored as '/home/user/.gnupg/openpgp-revocs.d/FF2892D1DB3FF0FED28A87FFF0A82A638ED0F640.rev'
public and secret key created and signed.
pub ed25519 2023-12-08 [SC] [expires: 2026-12-07]
FF2892D1DB3FF0FED28A87FFF0A82A638ED0F640
uid alice@example.org
sub cv25519 2023-12-08 [E]
Then I run --edit-key:
$ gpg --edit-key FF2892D1DB3FF0FED28A87FFF0A82A638ED0F640
gpg (GnuPG) 2.4.3; Copyright (C) 2023 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec ed25519/F0A82A638ED0F640
created: 2023-12-08 expires: 2026-12-07 usage: SC
trust: ultimate validity: ultimate
ssb cv25519/1DD28ADB14B5C842
created: 2023-12-08 expires: never usage: E
[ultimate] (1). alice@example.org
gpg> uid 1
sec ed25519/F0A82A638ED0F640
created: 2023-12-08 expires: 2026-12-07 usage: SC
trust: ultimate validity: ultimate
ssb cv25519/1DD28ADB14B5C842
created: 2023-12-08 expires: never usage: E
[ultimate] (1)* alice@example.org
gpg> delsig
uid alice@example.org
sig!3 F0A82A638ED0F640 2023-12-08 [self-signature]
Delete this good signature? (y/N/q)y
Really delete this self-signature? (y/N)y
Deleted 1 signature.
gpg> save
I export the key:
$ gpg --armor --export-secret-keys FF2892D1DB3FF0FED28A87FFF0A82A638ED0F640
-----BEGIN PGP PRIVATE KEY BLOCK-----
lFgEZXN7vhYJKwYBBAHaRw8BAQdAfkr84guRcAVCSK3NpS5vlqXBg04+y28mZ6hu
3MxVfhYAAQDDqxDd75+NfHT2XiXzHRh4nityqdxxHU/piWdHNQLOMg90tBFhbGlj
ZUBleGFtcGxlLm9yZ5xdBGVze74SCisGAQQBl1UBBQEBB0BTktPN/mWzt9XjFitw
i0DBOjVBRh6HyVRZDSNUseJqdAMBCAcAAP9ytIdby2BidflOyD1pIm41Rt7CfNr3
onv3LEpJdLk5eBFniHgEGBYIACAWIQT/KJLR2z/w/tKKh//wqCpjjtD2QAUCZXN7
vgIbDAAKCRDwqCpjjtD2QAdrAP9ZDINPMlx1jQaf9W35gRl893wFgN5o9M4MRirw
9+SwVwEAjJ90DJEWMjSWiGZVnKVnEFdVRsodxqt/Xzo92c6cEQ8=
=h/01
-----END PGP PRIVATE KEY BLOCK-----
This has no UserID signature:
$ sq packet dump alice.asc
Secret-Key Packet, old CTB, 88 bytes
Version: 4
Creation time: 2023-12-08 20:25:34 UTC
Pk algo: EdDSA
Pk size: 256 bits
Fingerprint: FF2892D1DB3FF0FED28A87FFF0A82A638ED0F640
KeyID: F0A82A638ED0F640
Secret Key:
Unencrypted
User ID Packet, old CTB, 17 bytes
Value: alice@example.org
Secret-Subkey Packet, old CTB, 93 bytes
Version: 4
Creation time: 2023-12-08 20:25:34 UTC
Pk algo: ECDH
Pk size: 256 bits
Fingerprint: C91ED0554F5B618A96C423371DD28ADB14B5C842
KeyID: 1DD28ADB14B5C842
Secret Key:
Unencrypted
Signature Packet, old CTB, 120 bytes
Version: 4
Type: SubkeyBinding
Pk algo: EdDSA
Hash algo: SHA256
Hashed area:
Issuer Fingerprint: FF2892D1DB3FF0FED28A87FFF0A82A638ED0F640
Signature creation time: 2023-12-08 20:25:34 UTC
Key flags: EtEr
Unhashed area:
Issuer: F0A82A638ED0F640
Digest prefix: 076B
Level: 0 (signature over data)
Trying to import results in a panic for which I filed an issue Panic when attempting to extract public key from a secret key with no signed user ID. · Issue #259 · rpgp/rpgp · GitHub
But I cannot reproduce the “incomplete input” error.
Do you have some other signatures on the key and other UserID packets? Could you show the result of sq packet dump key.asc or gpg --list-packets key.asc (with key IDs etc. edited out if needed)?
No I didn’t delete the self-signature, just the additional signature from the old key. You would first have to sign it with a different key → error “non matching key”.
Then delsig this foreign key → error “incomplete input”.
Both states should not result in an error.
I have tried to reproduce this. First, created two keys, signed second one (Bob) with the first one (Alice):
gpg --quick-gen-key alice@example.org
gpg --quick-gen-key bob@example.net
gpg --local-user alice@example.org --sign-key bob@example.net
gpg --armor --export-secret-keys bob@example.net > bob.asc
Delta Chat REPL when asked to import with import-keys bob.asc fails with error:
IMEX failed to complete: "validating certificate with a non matching Key ID KeyId(e325f7dfe442b4bd) != KeyId(839be8a4097aab5a)"
Then I edited the key to remove the signature:
$ gpg --local-user alice@example.org --edit-key bob@example.net
gpg (GnuPG) 2.4.3; Copyright (C) 2023 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec ed25519/E325F7DFE442B4BD
created: 2023-12-09 expires: 2026-12-08 usage: SC
trust: ultimate validity: ultimate
ssb cv25519/E8F9A694C240CE27
created: 2023-12-09 expires: never usage: E
[ultimate] (1). bob@example.net
gpg> uid 1
sec ed25519/E325F7DFE442B4BD
created: 2023-12-09 expires: 2026-12-08 usage: SC
trust: ultimate validity: ultimate
ssb cv25519/E8F9A694C240CE27
created: 2023-12-09 expires: never usage: E
[ultimate] (1)* bob@example.net
gpg> delsig
uid bob@example.net
sig!3 E325F7DFE442B4BD 2023-12-09 [self-signature]
Delete this good signature? (y/N/q)
uid bob@example.net
sig! 839BE8A4097AAB5A 2023-12-09 alice@example.org
Delete this good signature? (y/N/q)y
Deleted 1 signature.
gpg> save
gpg --armor --export-secret-keys bob@example.net > bob2.asc
bob2.asc imports successfully in Delta Chat. I have tested both with the core 1.131.7 used in Android release 1.42.4 and with the current main branch.
There must be something else special about the key you are trying to import. Could you check the structure of the key you are trying to import with gpg --list-packets key.asc or sq packet dump key.asc?
I did another test. Create test@key, sign with my default ID, delete that sign:
same error “incomplete input” for this:
$ gpg --list-packets test2.asc
# off=0 ctb=95 tag=5 hlen=3 plen=1862
:secret key packet:
version 4, algo 1, created 1702073555, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: CBEC94F4B7665BA2
protect count: 65011712 (255)
protect IV: a4 0f e5 08 d6 7f fd 91 36 ca ca a2 38 76 44 2d
skey[2]: [v4 protected]
keyid: 12767A10CCEFCBD5
# off=1865 ctb=b4 tag=13 hlen=2 plen=8
:user ID packet: "test@key"
# off=1875 ctb=89 tag=2 hlen=3 plen=599
:signature packet: algo 1, keyid 12767A10CCEFCBD5
version 4, created 1702073555, md5len 0, sigclass 0x13
digest algo 8, begin of digest 34 7c
hashed subpkt 33 len 21 (issuer fpr v4 D6A9E84EEDE42CB8E295218812767A10CCEFCBD5)
hashed subpkt 2 len 4 (sig created 2023-12-08)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 9 len 4 (key expires after 3y0d0h0m)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 34 len 1 (pref-aead-algos: 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 07)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 12767A10CCEFCBD5)
data: [4095 bits]
If it is a test key anyway, could you post the contents of test2.asc here? I will try to reproduce myself, but if you already created a test key it’s easier to use it.
This actually indicates that the key is password-protected:
iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: CBEC94F4B7665BA2
protect count: 65011712 (255)
protect IV: a4 0f e5 08 d6 7f fd 91 36 ca ca a2 38 76 44 2d
Importing password-protected keys is not supported. This should not fail with a weird parser error though.
gpg automatically asks for a password on --quick-generate-key - is this meant by
“password-protected”?
The password is requested on --export-secret-keys, so the result should be password-free?
My default key I use with DeltaChat has this kind of password, too. I don’t remember being asked for it …
> cat test2.asc
-----BEGIN PGP PRIVATE KEY BLOCK-----
lQdGBGVzlNMBEAC/QUdo9JE/np/EHzKCR6roF4d07pgd14HrQ88RpLj5ZKDNxt0C
ZhDVGfm4Z27sJvH/xYMuSh162PHCdwOazvVobD/YkQrhcjevd3g3zMurI0JKhDvn
2KINLxuZGUfIl9n9DFXXR1r3wBQE3JP9zyqRDWkdHsZUXr2MIuWzBFh/Ir4m/rks
YwCD4CSvTkFrH27RWvvDS4TBFxI+r4MaNs3lY0gvq9S/PXjEqN212pkqCblM5oNd
NrLcs83BR1YoOgg9GWXGtL8mDiF1AgSGKgQV9SJsRLdDghqn42YBqVIxaDqQl4tH
LUIuGWMMdDuataW66xjRcCNg+Rmk8xMyZNstpndCwSrlJXgc/yTxkIFSM/+Q5UQD
8ojyJyvpwDENl4JHCmFUshaAv5gYvSFwmcYarPth2LsmiUFWeFCq65V6g6j1YYXZ
XvIqrAOvTTW9/4XM3bMQsQ2vOb6403aNnLMQZvIiJiMLPYgUlbWLSPgMofvo8DGi
t94mLs6tZzuaVb0j+HdWzYryd0zPKDEPt8AfqBXdzyEyHDtIzAs6uvipFDMramLp
Ns3UKJ0795fGBt1hyMo0Ln1efBwPfnnzmWZy4uhD7hPB6NgDg9Tyf3OzlBFH4XSz
JUG9zUpRd1EsqN5i6urniS3YwyC4ERjisHcdcgKqX8ss70/ZxVOScpymdwARAQAB
/gcDAsvslPS3Zlui/6QP5QjWf/2RNsrKojh2RC0xUMJOOY/lOxLA05818CJm0AF0
1KwA5VMg9jIyKu54HKxVWglMt8VRU0U9CYSqq0GmizpU6RFLsWbgqAYt9oXObB1N
Rk+3eXhXomXKr8StOL2B0mO3EDtW7RPONY0Tg76x4khE4fBjTHUdWkB5cW+bdcOC
oy1oWJrAx3oAXFIcWJR4i5h2iLbfVVrLaJECAHnuPysD5O3tpYezaI0kg9hr/jXW
a+BCmW8b0YHAGoWIdQvUv7dIIbPRSHz/3HD7HviHGScyQCmi/d356f92vGXKs543
cHcV/+/rnmsAZnJH8sLepvES+BiKj5RTTsaUhOViXYIbITXs689JYc1YV9Oz2yR0
uxtIUdt7b/4w9O9hqma7OoVM4odZQGM1FhMrHtwBBZGO7Ibs9ZohGH/Z2PJcJmAI
w6VV13ty//WIcaYSUhKZKWIkBa2xAS5ybH1o9jYvARbG3z6P1ww0ZAuKkTdQItZO
wPLPDReU68INCzlgGD0ZqyPtRpnaWohvFcrASSc6J0bip+/feBqTrTTIg8u2byyw
10HP6eH9GlNLheRh5O+s4EswtRoFdlBAQ4tbkokE7jqQhgSiKjQqTfjsScNk0gte
XSZKq0gts71qetEm3dp+YcMb07ZDRLDMWNH2RmbEPZ1ZfVh/NgdXTSS5ClX3nC+d
9og/WcYnGal6pf1uGsbWHiSFh6FvxzqYQN1o+APgic959iMrdWfSdnPUEJACmhkl
1Qmz+jIcEX4k7u7WeV09Yh94QueGRdvtfqyFDlQzWetbj1zNfE+FkRvxHX+MC/0C
l3vsDzxI4aKM6eZFSt6bgcL1Bgyaw+IOscaFednpJv2sbDzPBZhyOz0yi9INzg/d
YA9bZZb3qYb8nxbIVo3sSO7pWFs90zDh8IvA6zkPJOIEjCU7LepB9zdzHPggi6aQ
b8gy3zsZGnfwr0HyDXCTa1ANsQXxyJAdGpXERXX2EzTqAgT9Ovi5VhwAPaRRD7qH
NwWPvjK6x5M3BQEijF5/vRKtKmsdzdKY88cqOm844TMClIwVuNer03Jk2155GD3W
WqkJbu0jK4rG63CWSHYx37irsKO4NLK00JLgy8iXgzHVTNBubxBRNnTCdtwHLQeA
wmepknOuT+42wW6AUG8rh+xQnvr00Nr22V8yHZ6sJnQCYQRFdl6cir4nl9OCq75z
OehmWKUTqKs8Unu/+0yP9y+Xn3qCP1mID52vpa46KBonkPc1Ah8lp07a61PnMAe3
92w1GzHWBbkLgcPKbiEqauwK4C0OhzzLSjFNAkN5vOwB/HFoMfWvjug5sDM5CHoe
9WBonCW1LOG6Ndw9AJ8C8/KwAbeNheeplzj0OSGwcNQKQo9wN/xtHX97UnmGkU1Q
GeInJlfqNuD9aXPqTwvRXmC5ht0kLitp6fCtvjb9YifSDBoW1M99gLAfcnKnj6Zq
Hfa9I5dih9w9NbW1n1VSzy8lpuEKBLduoRVasZd+qaLXoVDUu8cU6Qpfn45Hb/9B
Axgox0SkPYRYOHhNnjKaPoFJ5QhKnLq1NnN2w/p0NHyMGHNibu2/paCPEhH83rPa
6BgVCG0iHQbxkJ0NMSjdKLgJj8wIb8yPNPjbYv/e7/GmkyPHZQSiWCWVmUw2hw9q
G757/aRcyGzTwa+59RYaV58MkjTF/yYAOS3Y1d8vc2hHa13iqSXTkdUP/fMAacvJ
WtEV6QIDW/1SAlvA92c7ibNUVnSjbAbvHYaSD8YrYb9K3lBr5v9CAJi0CHRlc3RA
a2V5iQJXBBMBCABBFiEE1qnoTu3kLLjilSGIEnZ6EMzvy9UFAmVzlNMCGwMFCQWj
moAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQEnZ6EMzvy9U0fA//XR+d
QMw3k5ePP4NC+VxvAc9Im4QBuP7JdX2ZdWdOhU7kRI7UzpTJGZL6QMNDviVLQDhP
ywjNM83XJknSQCQh5Mc9mpvehKWEGUzpQfw03g1mD1OtFwN5LpndqNjOIt0owK1a
on/6eZjysWJCAJEi4uAA9vuMYZSLgrCWswEgGS0Xa5XuJN30aEUB/cS/3Arr0iNl
WChCScIOuN4uAFFzXzT7FT5nn6hS2bvjtsJDtMkUU7LMNMiIi3glILlXR4IgVxdK
8vG5ezYXLCCn2gpWK3zEqgPQXl4MUK/+OrGnHbCetAEJWuDwM61LElAD0WrbnvT5
CoCDW7lCfZgNpGd0pnYa/PUYdG9HxmsdWuVFgajOAWbXixIcGIBlr8nKQtQ+fSIY
4BScSMX2HSac/datcr0/vqJMaamW/WAwoROSBglYSlgXyKP1DBkXMyAMGJzUjyx2
EyeP598WVvFw+ybhdZK+13tjBTOQODYqVfn/ldAWfP2V3/vPpP/BXfTQCHnxouw8
lQ2RawPCJS6e0W5MgCJQENoZDM1W0WKEUUyTs66HWAhGcsJ8WLZbCNvQBJ68mNIY
M6+zFzNIw0SgBRz2cb+86t7XU2F4CefR44E8cCBXtP0xopOpgTodcLJGK0NuDMi2
9RLXdalSSrILrJPI5gj44M6PXDdLD4XPUMoif/k=
=wDXa
-----END PGP PRIVATE KEY BLOCK-----
Yes, leave it empty when generating a new key.
No, the key is still encrypted.
For test2.asc:
$ sq inspect encrypted.asc
encrypted.asc: Transferable Secret Key.
Fingerprint: D6A9E84EEDE42CB8E295218812767A10CCEFCBD5
Public-key algo: RSA
Public-key size: 4096 bits
Secret key: Encrypted
Creation time: 2023-12-08 22:12:35 UTC
Expiration time: 2026-12-07 22:12:35 UTC (creation time + P1095D)
Key flags: certification, signing
UserID: test@key
Looks like with GnuPG you need to change passphrase to empty first, then export it.
Alternatively, use sq:
$ sq key password encrypted-key.asc
Enter password to unlock E325F7DFE442B4BD (blank to skip):
New password:
Repeat new password:
-----BEGIN PGP PRIVATE KEY BLOCK-----
If you mean the key Delta Chat itself generated when you setup it, it is not passphrase-protected. Could be you added a passphrase after importing it in GnuPG. Delta Chat itself has no code to encrypt the key.
I have opened a bugreport about the failure to import encrypted keys:
My default key is gpg-generated and on the desktop I have to enter the password on every startup. Maybe it was possible in D.C when I imported it years ago …
Now I removed the password and was able to import the test key. The problem now is that the old key is not working anymore so I can’t read messages anymore. And I have to remove its password to import it again!
And after key import the undecrypted message will stay undecrypted …
so many bugs on one single action.
This is a known bug Importing pgp keys and the existing one went away · Issue #5046 · deltachat/deltachat-core-rust · GitHub, fixed in core 1.131.9.