[jira] [Updated] (CAMEL-7052) PGPDataFormat: Unable to encrypt using subkey

["Daniel Gredler (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Gredler updated CAMEL-7052:
----------------------------------

    Attachment: camel-7052.patch

All tests (including the ignored Elgamal test) pass for me with this patch.

> PGPDataFormat: Unable to encrypt using subkey
> ---------------------------------------------
>
>                 Key: CAMEL-7052
>                 URL: https://issues.apache.org/jira/browse/CAMEL-7052
>             Project: Camel
>          Issue Type: Bug
>          Components:  camel-crypto
>    Affects Versions: 2.12.2
>            Reporter: Daniel Gredler
>         Attachments: camel-7052.patch
>
>
> Generate a keyring with a DSA key for signing and an Elgamal key for encryption, using the password "secret":
> {code}>gpg --gen-key
> gpg (GnuPG) 2.0.17; Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Please select what kind of key you want:
>    (1) RSA and RSA (default)
>    (2) DSA and Elgamal
>    (3) DSA (sign only)
>    (4) RSA (sign only)
> Your selection? 2
> DSA keys may be between 1024 and 3072 bits long.
> What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits
> Please specify how long the key should be valid.
>          0 = key does not expire
>       <n>  = key expires in n days
>       <n>w = key expires in n weeks
>       <n>m = key expires in n months
>       <n>y = key expires in n years
> Key is valid for? (0) 0
> Key does not expire at all
> Is this correct? (y/N) y
> GnuPG needs to construct a user ID to identify your key.
> Real name: Testing
> Email address: testing@foo.com
> Comment:
> You selected this USER-ID:
>     "Testing <te...@foo.com>"
> Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
> You need a Passphrase to protect your secret key.
> 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: WARNING: some OpenPGP programs can't handle a DSA key with this digest size
> 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: key C49B82A0 marked as ultimately trusted
> public and secret key created and signed.
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> pub   2048D/C49B82A0 2013-12-09
>       Key fingerprint = AB15 5E15 768E E6FE 96AB  2423 6488 CEA7 C49B 82A0
> uid                  Testing <te...@foo.com>
> sub   2048g/361D9AA1 2013-12-09{code}
> List the keys to make sure they look OK:
> {code}>gpg --list-keys
> pubring.gpg
> ---------------
> pub   2048D/C49B82A0 2013-12-09
> uid                  Testing <te...@foo.com>
> sub   2048g/361D9AA1 2013-12-09{code}
> Export to a file and then check the contents of the file:
> {code}>gpg --export > pubring.pgp
> >gpg pubring.pgp
> pub  2048D/C49B82A0 2013-12-09 Testing <te...@foo.com>
> sub  2048g/361D9AA1 2013-12-09{code}
> We now have a keyring that contains a primary DSA key for signing, and an Elgamal subkey for encryption. The subkey does not have a user ID associated with it, because the user ID is associated with the corresponding primary / master key.
> The latest code in {{PGPDataFormatUtil.findPublicKeys(InputStream, List<String>, boolean)}} cannot handle this scenario, because it expects the subkey to also have a user ID. Only the first key in a keychain (which is the primary / master key) will have a user ID. The subkeys don't have user IDs directly associated with them, and so they are not recognized as usable by Camel, when in fact they are usable.
> See this discussion for more info on how primary keys and subkeys are represented in the BouncyCastle model, and how this relates to user IDs:
> http://bouncy-castle.1462172.n4.nabble.com/How-to-find-PGP-subkeys-td1465289.html



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)