You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 16, 2019. It is now read-only.
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
$
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?
The text was updated successfully, but these errors were encountered:
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.
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:The first thing that I don't like here is the warning about
EncryptStorage
andEncryptCommunications
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:
Here's an example of key being used:
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?
The text was updated successfully, but these errors were encountered: