Skip to content
This repository has been archived by the owner on Dec 16, 2019. It is now read-only.

lega-cryptor can't use PGP keys generated by BouncyCastle while GPG tool can #322

Open
dtitov opened this issue Jul 20, 2018 · 3 comments
Open
Labels

Comments

@dtitov
Copy link

dtitov commented Jul 20, 2018

I didn't know where to create this issue, here or in the lega-cryptor's repo, but since it affects my current task in this repo, I placed it here. Feel free to create a copy there.

I'm writing Gradle script for Docker Swarm bootstrapping and deployment and I'm generating PGP keys there using BouncyCastle.

The problem is that lega-cryptor is not able to use those keys for encryption:

$ lega-cryptor encrypt --pk /Users/dmytrot/GitHub/LocalEGA/deployments/swarm/lega/.tmp/pgp/ega.pub -i data.raw -o data.raw.c4ga
/Users/dmytrot/GitHub/LocalEGA-cryptor/legacryptor/crypt4gh.py:110: UserWarning: Key CD40C41BEE96FA83 does not have the required usage flag EncryptStorage, EncryptCommunications; using subkey CB74E30B5D009E95
  data = bytes(pubkey.encrypt(msg))
list index out of range

The first thing that I don't like here is the warning about EncryptStorage and EncryptCommunications flags. I believe that it should be suppressed. In my case, the master key is the signing key and then there's subkey for encryption, which is being used. But anyway, it's just a warning, not the real problem.

The real problem is list index out of range. I have no idea what does it mean and why is it thrown.

To prove that the key itself is fine I double-checked encryption with both: Java implementation of Crypt4GH and with standard GPG tool. In both cases encryption was successful. Here's example with GPG:

$ gpg --recipient CD40C41BEE96FA83 --output doc.gpg --encrypt data.raw
gpg: CB74E30B5D009E95: There is no assurance this key belongs to the named user
sub  rsa1024/CB74E30B5D009E95 2018-07-20 ega
 Primary key fingerprint: 1126 4521 0A0E E3F3 3BD9  FD5F CD40 C41B EE96 FA83
      Subkey fingerprint: 886B D080 DF7D 8CA8 9E4B  976C CB74 E30B 5D00 9E95

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y
$ 

Here's an example of key being used:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: BCPG v1.59

mI0EW1Ho1QMEALEnbX/zGcC24JzevukRQVG4gviMzZW/i05nkJO95sK2lT3uEec5
n7GiwX9NjXewiknsoU7f0ry9vEDNrpyUvRcJocqnEU0lYKXl3jR0t0q1yJZ50JzR
J3NI5zsQRr+bV+A3ohWRqdon1hTO5IwrFMBd2dlTUvfZtI/pUWaonFi5ABEBAAG0
A2VnYYiiBBEDCgAMBQJbUejVAhsDAh4BAAoJEM1AxBvulvqDgs4D/j+6ZrFJG8kp
1g3dnjdAlwIGVg7KzyZ1tS7ujKwNgLkXoBfnQEk2mP1BYlPawkRenPtRtGCwMhzY
StU0wg6acBe2EaD4ApbUHnnOqsBGiygJESnMTDL8FEUyyUUl3TPTgKSIRL00SPTk
4Hh/i3CehBw7SbS68rOszHfT1/nC69YXuI0EW1Ho1QIEAN1iGWLY2t7QVsaOtj7s
QY7jqJCcL37oSZsmg5LbpcLXECsrNS0OTrM410sQ1nmsTKSiyrfVP3G3BLysnPy4
/C2lr26TDhrOFNiDJeAbQIy7Dv4VNUJFv3vt86nJAmUrpmKKztRz+EqDQuObpIIL
YnBM8pKpdi2lieqCGJWZARtPABEBAAGInwQYAwoACQUCW1Ho1QIbDAAKCRDNQMQb
7pb6g/6qA/wLhUmuqylKIcFAJvARIuygUjJonjAJB02nD3thC/7LMeXAh88/6ED0
papuuDy86J63xseIXkXyvHWhNj6EpbYWmkV98RJMq3DtCbFMAL8OYS8LKCBKn3e1
iepC+dZb4OSuvHU+/YiXPeVGeKZQw6J6PbmML9zQcLEVnnKlMUdcYw==
=JBva
-----END PGP PUBLIC KEY BLOCK-----

It's possible that I'm doing something wrong during the key generation. But two successful encryptions with other tools make me beleive that the generated key is fine.

@silverdaz, could you, please, assess and help with figuring out what can be wrong here?

@dtitov dtitov added the bug label Jul 20, 2018
@dtitov dtitov added this to the Sprint 29 milestone Jul 20, 2018
@silverdaz
Copy link
Contributor

I can have a look on Monday.

@dtitov
Copy link
Author

dtitov commented Jul 20, 2018

Same problem with the keys service: key server is not able to return key by subkey ID. Read more about subkeys: https://wiki.debian.org/Subkeys

For instance, I generate PGP key with primary key (2FD9AF1FBFD7B257) and subkey (CFC24A1FC03D5658). While encrypting with Crypt4GH (Java implementation, because Python implementation doesn't support it, as far as I understand), the subkey ID used for encryption will be placed to the header (CFC24A1FC03D5658). But in the key server the key will be cached by master key ID (2FD9AF1FBFD7B257). So it can't be returned to decrypt the file in verify...

@blankdots, could you, please, take a look to confirm it? We'd probably need separate issue for this problem.

@blankdots blankdots removed this from the Sprint 33 milestone Aug 23, 2018
@silverdaz silverdaz removed their assignment Sep 5, 2018
@juhtornr
Copy link
Collaborator

@dtitov Is the still valid?

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

No branches or pull requests

4 participants