Write introductory post

[strogonoff]

@dewyatt, here are a few questions about rnp covering some info needed for a decent introductory post:

• The major differentiating factor of rnp as compared to its ancestor NetPGP seems to be the ability to run under more systems (assuming NetPGP is NetBSD-only) and the fact that it is maintained in organized manner (NetPGP itself seems to be not updated since 2014). Are there any other aspects it is different from NetPGP?
• It appears that OpenPGP is the only other implementation, so rnp sort of breaks the monopoly which is always a desirable thing. Are there any other implementations that you aware of? How does rnp compare to them?
• What would be the focus of rnp if you had to name one? Some examples could be ease of use, extensibility, embeddability, universality (wide OS support), etc.
• Project name seems to be stylized primarily as lowercase rnp, as opposed to RNP, RnPGP or such. Is rnp the preferred way?

Feel free to reply here—alternatively, a call might be a good way to deal with this without adding to your TODO list, though it’d block about 15 minutes off your calendar. In that case the above items would constitute the majority of call’s agenda.

[ronaldtse]

• We probably want to fully differentiate with NetPGP since the codebase is almost fully different (now).
• RNP was created in the library approach and is for use in servers, for heavy-duty usage. GnuPG was designed as a command-line tool and it is not easy for software to link to it or use its functionality without using a shell. Using GnuPG in the library approach (through a 'library-faking' component called GPGME) often causes heavy memory leakage and affects stability of long running processes (such as on servers).
• OpenPGP is the name of the standard, GnuPG is the market leader implementation of OpenPGP.
• In a number of cases RNP outperforms GnuPG.
• RNP and GnuPG were the first interoperable implementations to utilize AEAD OCB (this was announced on the IETF OpenPGP mailing list).
• RNP also has a very small footprint.
• In general we aim to be a high-performing, stable OpenPGP implementation that applies cutting edge cryptography.
• RNP supports the Chinese cryptography algorithms SM2, SM3 and SM4, i.e. the only legal OpenPGP implementation for use in China.

[dewyatt]

I think Ronald answered everything better than I would have. :thumbsup:

[strogonoff]

Thanks @ronaldtse & @dewyatt. Here’s more, could you answer each point individually please

1. Can you clarify what name stylization is officially adopted? It’s written in lowercase “rnp” in some places and uppercase RNP in others.

2. What is a complete list of ciphers rnp supports?

3. Do any performance benchmarks exist?

4. Leaving aside SM cipher support, what would be the top focus of rnp if you had to come up with just one?

[ronaldtse]

1. We don't have an existing policy, but given "rnp" always gets caught by autocorrect and does not stand out, perhaps we should use the capitalized "RNP".

2 & 3. @dewyatt and @ni4 are in better position to elaborate them.

4. (in terms of marketing point of view) Cutting-edge > Stable > Fast > Complete.

[ni4]

@strogonoff

2. RNP supports algorithms which usage in OpenPGP is defined in RFC 4880, RFC 5581 and RFC 4880-bis:
   • symmetric: IDEA, Triple DES, CAST5, Blowfish, AES-128, AES-192, AES-256, Twofish, Camellia-128, Camellia-192, Camellia-256. In addition Chinese SM4 algorithm is supported.
   • symmetric encryption modes: CFB, AEAD-EAX, AEAD-OCB.
   • hash: MD5, SHA1, RIPEMD160, SHA-256, SHA-384, SHA-512, SHA-224, SM3
   • asymmetric: RSA, ElGamal, DSA, so-called DSA2 (i.e. DSA with keys larger then 1024 bits), ECDSA/ECDH (with some subset of curves which later on will be expanded), EdDSA, SM2.
   • compression: Zlib, ZIP, BZip2.

Weak and weaker algorithms (like MD5, SHA1, IDEA, Triple DES, ElGamal signatures) are supported for backward compatibility with older implementations (say, to be able to decrypt file encrypted 15 years ago).

[strogonoff]

Sweet, thanks! Cipher support looks comprehensive compared with other maintained competitors. Just a few more questions left I think.

1. One of the strong points of RNP seems to be that it can be depended upon as a proper library. However, README seems a bit thin on that, mostly focusing on CLI tool usage. In brief how would one go about integrating it in their own project? Is there a typical use case or two you can outline?

2. Can I use it now if I develop a macOS/iOS app in Swift? a web app in Python? Will it be possible only when the respective bindings are published?

3. Are you aware of any major projects/organizations where RNP is used in some way now? Not counting Ribose itself, but affiliated initiatives are OK

4. Which major features were recently released and what are the biggest features planned next?

5. Are you planning on releasing a major version within the next week or two?

6. What is the current version of RNP? It’s hard to tell (I’d recommend maintaining a CHANGELOG file by the way, it’s never too late to start!)

[dewyatt]

I can try to answer some:

1. The only supported/public API is the the one in rnp2.h (installed as rnp.h, best not to mention the filename rnp2.h), which is also where the only API documentation really lives at the moment. One of the things we probably need to do is to add a doxygen cmake target and commit docs. As for use cases, it's generally useful for anything where one wants to interact with OpenPGP data in an automated/programmatic way. Maybe someone can expand on this point though.
2. I'll let @ni4 answer the macOS part. As for bindings, Python & Rust bindings are items I am working on. So as far as developing a web app in python and using rnp, it's not something you can do right now (actually if you're familiar with ctypes or similar, it's easy, but let's just say it's not currently supported). We do have Ruby bindings, so one can currently easily develop a web app in Ruby and make use of rnp.
3. I don't think anyone is using it yet. I think once we hit a 1.0 release we would want to do a bit of advertising.
4. I'm in a slight rush so maybe @ni4 can answer or I can come back to expand on this.
5. I would say no, not at the moment.
6. I get the confusion - we have a CHANGELOG.md in the release/0.x branch, where you can see our current release is 0.10.0.

[ni4]

Thanks, @dewyatt . I would add some notes:

2. There are no Swift bindings yet and I didn't dig into it. However, anyone may use C library from the Objective-C code (if familiar with C coding, of course).

3. As for me most of the previous year's work was updating the codebase to get rid of old NetPGP code, ensure compatibility with GnuPG and other implementations, add lacking basic features. Major pieces of work were:

   • support for SM2, SM3 and SM4 algorithms
   • EdDSA and ECC support
   • key flags support
   • streamed approach (i.e. constant memory footprint while processing large amounts of data)
   • authenticated encryption support (AEAD-EAX/AEAD-OCB). Actually we were the first, together with GnuPG, who implemented it and ensured interoperability
   • a lot of performance improvements
   • a lot of OpenPGP compatibility fixes and improvements
   • support for GnuPG's G10 keyrings
   • improved signature validation code
   • FFI interface which allows to add Ruby and later on other bindings.

Maybe @ronaldtse would like to add something to this list as well.

[strogonoff]

@dewyatt

2. Regarding Rust, while researching the post I’ve discovered Sequoia PGP which appears to be Rust-native and actively maintained—thought I’d mention it in case it helps prioritize binding delivery order perhaps. (I.e. given the existence of Sequoia the use case for Rust bindings may be less strong)

[strogonoff]

Regarding Ruby bindings, what would be a most minimal step-by-step example of (what I assume to be) a typical use case: generate a key[pair] -> encrypt a message -> decrypt a message?

Algorithm is not important—let’s assume a cipher that’d typically be used in secure P2P messaging :)

I suppose it would be a variation of below but I’d like to check for correctness or whether this is a valid supported use case (if not then maybe it’s something concerning password manager/key manager).

require 'rnp'
rnp = Rnp.new
key = rnp.generate_key(…)
rnp.load_keys(…)

plaintext = "Hello!"
ciphertext = rnp.encrypt(plaintext)
ciphertext_decrypted = rnp.decrypt(ciphertext)
ciphertext_decrypted == plaintext

cc @dewyatt @ni4 @ronaldtse

[strogonoff]

Would be good to mention the good practices as to how to store keys with RNP as well.

[dewyatt]

Would be good to mention the good practices as to how to store keys with RNP as well.

I really have nothing to say on this, I don't mean to ignore the question.

[strogonoff]

No worries, moving further questions to PR with post copy