Add compatibility tests with other OpenPGP implementations

[ronaldtse]

We need to create test suites to test rnp functionality with other OpenPGP implementations and versions, such as:

• GnuPG
• Enigmail
• Sequoia
• etc.

Specifically we need to test key import/export, signing/verification and encryption/decryption.

I remember Sequoia has a compatibility test suite we could take inspiration from.

This task probably needs to be split into smaller tasks.

[teythoon]

We'd like to invite you to join our testing effort. The OpenPGP Interoperability Test Suite allows us to write tests once, and test any number of OpenPGP implementations at the same time with no additional effort. The results and pointers to the code are here: https://tests.sequoia-pgp.org/

Currently, there is a custom driver for RNP in the test suite. RNP was one of the first implementations we included in the test results, and the glue code predates the Stateless OpenPGP Command-Line Interface (https://gitlab.com/dkg/openpgp-stateless-cli) that we use now to drive most implementations. A native implementation of SOP using RNP would be really helpful so that we can get rid of the legacy RNP driver.

I just updated RNP and noticed a minor problem impacting the test suite: #1209

[func0der]

I do not know, if I should open up a new bug for this, because my problem is related to this.

I created a EDDSA + X25519 keypair in RNP and tried to use the private key with gpg (GnuPG) 2.2.19/libgcrypt 1.8.5 which either fails with a bad passphrase or bad secret key.

I tried:

1. Created a key with rnpkeys
   Then:
2. Exporting the private key with rnpkeys
3. Importing it to gpg. -> Bad secret key, but it got somehow imported
   or
4. Use the keystore (pubring.gpg + secring.gpg) directly with gpg -> bad passphrase on export of private key, But displaying worked fine.

Should I open a dedicated but report?

[nwalfield]

@func0der: Could you provide an example? (The exported private key, and the otherwise empty secring.gpg.) Thanks.

[func0der]

I tried to create a docker.sh file that could simulate the problem, but CentOS 7 has such an outdated libgcrypt version, that gpg does not support elliptic curves yet.
So you have to try it the manual way, sorry.

Commands ran:

export keydir=/tmp
rnpkeys --version -> rnp 0.12.0
rnpkeys --generate-key --expert --userid=foo@bar.de --homedir=${keydir} 
  -> Choose (22) EDDSA + X25519
  -> Passphrase: test123
rnpkeys --export-key --userid foo@bar.de --secret --homedir=${keydir}
(output in attached file `foo@bar.de.asc`)

privkey+secring.gpg.zip

[ronaldtse]

Thanks @func0der for the report! I've copied this particular issue over to #1383, we will deal with it there.

[ni4]

Thank for reporting! This is actually an issue of the GnuPG, I reported it some time ago: https://dev.gnupg.org/T5114

[teythoon]

I just wanted to mention that I have implemented a SOP frontend for RNP. It uses RNP's library interface.

https://gitlab.com/sequoia-pgp/rnp-sop/

I implemented it so that I can use it in the OpenPGP interoperability test suite. RNP was the only implementation left that had a custom driver, and I wanted to get rid of the custom driver, so that I can better utilize the SOP interface. I'd be thrilled if you would build a SOP frontend of your own, but will use my implementation in the mean time.