OpenKeyChain ECDSA Public Keys don't import

koto commented 9 years ago

From sirdarckcat on October 26, 2014 21:22:00

== PLEASE DONT PUT ANY KEYS HERE ==

Debug instructions:

Please build the extension and go to chrome-extension://<extension-
id>/prompt.html and try to encrypt, decrypt or import a key from there.

2. Note the error shown in red (if any)

Key Binding Signature Verification Failed

Open the JavaScript console (Tools -> JavaScript Console)
4. Copy the output from the console here.

"CustomError: Binding signature verification failed.
at e2e.openpgp.error.Error (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/launcher_binary.js:5597:20)
at new e2e.openpgp.error.ParseError (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/launcher_binary.js:5601:27)
at JSCompiler_prototypeAlias.addBindingSignature (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/launcher_binary.js:12468:13)
at JSCompiler_prototypeAlias.parse (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/launcher_binary.js:13207:18)
at Object.e2e.openpgp.block.factory.parseBlock (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/launcher_binary.js:13298:380)
at Object.e2e.openpgp.block.factory.parseByteArrayMulti (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/launcher_binary.js:13319:43)
at e2e.openpgp.ContextImpl.getKeyDescription (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/launcher_binary.js:16096:44)
at e2e.ext.actions.GetKeyDescription.e2e_ext_actions_Action_prototype$execute (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/settings_binary.js:7500:38)
at e2e.ext.actions.ImportKey.e2e_ext_actions_Action_prototype$execute (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/settings_binary.js:7517:144)
at null. (chrome-extension://okgecdkahgdmfcliiklafejolcocgcpe/settings_binary.js:18473:16)"

Have you tested if this key/message works in other implementations? (PGP
Desktop, GnuPG, etc..)

OpenKeyChain works ;)

If you can, please copy the output of gpg --list-packets .

Original issue: http://code.google.com/p/end-to-end/issues/detail?id=156

koto commented 9 years ago

From koto@google.com on December 04, 2014 06:18:18

gpg --import

gpg: key 35441423: no valid user IDs gpg: this may be caused by a missing self-signature

koto commented 9 years ago

From sirdarckcat on December 04, 2014 10:17:40

is that gpg 2.1? it's an ECC key

dlg-yahoo commented 9 years ago

Here's the output of pgpdump:

Old: Public Key Packet(tag 6)(82 bytes)
    Ver 4 - new
    Public key creation time - Sun Oct 26 13:16:43 PDT 2014
    Pub alg - Reserved for ECDSA(pub 19)
    Unknown public key(pub 19)
Old: User ID Packet(tag 13)(41 bytes)
    User ID - Eduardo Vela Nava <sirdarckcat@gmail.com>
Old: Signature Packet(tag 2)(121 bytes)
    Ver 4 - new
    Sig type - Positive certification of a User ID and Public Key packet(0x13).
    Pub alg - Reserved for ECDSA(pub 19)
    Hash alg - SHA512(hash 10)
    Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes)
        Sym alg - AES with 256-bit key(sym 9)
        Sym alg - AES with 192-bit key(sym 8)
        Sym alg - AES with 128-bit key(sym 7)
        Sym alg - CAST5(sym 3)
    Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
        Hash alg - SHA512(hash 10)
        Hash alg - SHA384(hash 9)
        Hash alg - SHA224(hash 11)
        Hash alg - SHA256(hash 8)
        Hash alg - RIPEMD160(hash 3)
    Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
        Comp alg - ZLIB <RFC1950>(comp 2)
        Comp alg - BZip2(comp 3)
        Comp alg - ZIP <RFC1951>(comp 1)
    Hashed Sub: primary User ID(sub 25)(1 bytes)
        Primary - Yes
    Hashed Sub: signature creation time(sub 2)(critical)(4 bytes)
        Time - Sun Oct 26 13:16:44 PDT 2014
    Hashed Sub: features(sub 30)(critical)(1 bytes)
        Flag - Modification detection (packets 18 and 19)
    Hashed Sub: key flags(sub 27)(critical)(1 bytes)
        Flag - This key may be used to certify other keys
        Flag - This key may be used to sign data
        Flag - This key may be used for authentication
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0x04847D5C35441423
    Hash left 2 bytes - 16 10
    Unknown signature(pub 19)
Old: Public Subkey Packet(tag 14)(86 bytes)
    Ver 4 - new
    Public key creation time - Sun Oct 26 13:16:44 PDT 2014
    Pub alg - Reserved for Elliptic Curve(pub 18)
    Unknown public key(pub 18)
Old: Signature Packet(tag 2)(97 bytes)
    Ver 4 - new
    Sig type - Subkey Binding Signature(0x18).
    Pub alg - Reserved for ECDSA(pub 19)
    Hash alg - SHA512(hash 10)
    Hashed Sub: signature creation time(sub 2)(critical)(4 bytes)
        Time - Sun Oct 26 13:16:44 PDT 2014
    Hashed Sub: key flags(sub 27)(critical)(1 bytes)
        Flag - This key may be used to encrypt communications
        Flag - This key may be used to encrypt storage
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0x04847D5C35441423
    Hash left 2 bytes - 1e 38
    Unknown signature(pub 19)

koto commented 9 years ago

For this key the subkey binding signature does not verify.

koto commented 9 years ago

OpenKeyChain generates RSA keys by default. I created ECDSA/ECDH keys using OpenKeyChain 3.2. Keys using P-256 curve import into e2e correctly, keys with P-521 don't. Pasting the keys here for investigation.

All keys have password: q

koto commented 9 years ago

OK, found the underlying issue(s):

Our P_521 implementation is incomplete.
https://github.com/open-keychain/open-keychain/issues/1353 - when verifying signatures. we currently enforce the hash algo based on the curve, instead of reading the signature packet. Fixing this.

Valodim commented 9 years ago

so you're no longer going to enforce this? It's a SHOULD, but if we have the chance here we might want to stick to a stricter policy, to avoid downgrade attacks.

koto commented 9 years ago

If all implementations agree, I'm fine with only allow what's a SHOULD. We just should not be generating wrong keys.

Valodim commented 9 years ago

being liberal in what is accepted is the reason even things like MDC aren't fully deployed. if we have a chance to eliminate a weakest link I'm all for it.

Looking at g10/sign.c:1498, gnupg picks the default algorithm correctly based on curve size (unless instructed otherwise), so keys generated from there shouldn't be a problem.

google / end-to-end

OpenKeyChain ECDSA Public Keys don't import #193