Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Mon, 9 Dec 2013 23:44:08 +0000 (UTC)
From: "Daniel Gredler (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.12683690.1386624332728.6114.1386632648696@arcas>
In-Reply-To: <JIRA.12683690.1386624332728@arcas>
References: <JIRA.12683690.1386624332728@arcas>
Subject: [jira] [Commented] (CAMEL-7052) PGPDataFormat: Unable to encrypt
 using subkey
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CAMEL-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843706#comment-13843706 ] 

Daniel Gredler commented on CAMEL-7052:
---------------------------------------

I think the PGPDataFormatElGamalTest is failing in master, but it's not visible in the build because the test is marked with the Ignore annotation (because JCE unlimited strength isn't on the build server). I'll provide a proposed patch soon.

> 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
>
> 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 <testing@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 <testing@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 <testing@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 <testing@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)