RNP Blog

RNP version 0.18.1 released

Thu, 20 Nov 2025 00:00:00 GMT

The RNP 0.18.1 release is a critical security update that addresses CVE-2025-13470, a high-severity vulnerability in session key generation for public key encryption introduced in version 0.18.0.

All users of RNP 0.18.0 should upgrade immediately to version 0.18.1.

Security vulnerability: CVE-2025-13470

Summary

RNP version 0.18.0 contains a critical vulnerability in session key generation for PKESK (Public Key Encrypted Session Key) packets. Session keys were generated without cryptographically random values.

CVE: CVE-2025-13470
Severity: High (CVSS 7.5)
Affected Version: 0.18.0 ONLY
Fixed Version: 0.18.1

Technical details

During refactoring work in version 0.18.0, the session key initialization for SKESK (passphrase-based encryption) was correctly updated. However, the corresponding initialization for PKESK (public key encryption) was not implemented, resulting in vulnerable session keys.

The vulnerability affects only public key encryption (PKESK packets). Passphrase-based encryption (SKESK packets) is not affected.

Root cause: Vulnerable session key buffer used in PKESK packet generation.

CWE: CWE-330: Use of Insufficiently Random Values
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (Base Score: 7.5)

Impact

Messages encrypted with RNP 0.18.0 using public key encryption use vulnerable session key values. This is a confidentiality issue for PKESK-encrypted data.

Encryption types affected:

Public key encryption (PKESK) - AFFECTED
Passphrase-based encryption (SKESK) - NOT AFFECTED

Affected and unaffected versions

AFFECTED:

RNP 0.18.0 ONLY

NOT AFFECTED:

RNP 0.17.1 and all earlier versions
RNP 0.18.1 and later versions

Timeline

2025-06-19: RNP 0.18.0 released (vulnerability introduced)
2025-11-07: Vulnerability discovered and reported by Johannes Roth (MTG AG)
2025-11-19: CVE-2025-13402 assigned by Red Hat
2025-11-20: CVE-2025-13470 assigned by Ribose/MITRE
2025-11-20: Fix developed and tested
2025-11-21: RNP 0.18.1 released with fix
2025-11-21: Public disclosure (same day as release)

Affected distributions

Version 0.18.0 was released on 2025-06-19 and has been packaged by numerous distributions:

Debian 14, unstable
Devuan unstable
EPEL 8, 9, 10
Exherbo
Fedora 41, 42, 43, Rawhide
FreeBSD Ports
Homebrew
Kali Linux Rolling
nixpkgs unstable
OpenBSD Ports
openmamba
openSUSE Tumbleweed

RNP 0.17.1 and earlier versions are NOT affected by this vulnerability.

Thunderbird status

Thunderbird's affected status depends on distribution packaging:

UPSTREAM THUNDERBIRD (NOT AFFECTED):

Upstream Thunderbird binaries bundle RNP version 0.17.1, which is not affected.

DISTRIBUTION-PACKAGED THUNDERBIRD (VARIES):

Some distributions build Thunderbird to use system-installed RNP libraries instead of the bundled version. Thunderbird’s affected status depends on:

Whether the distribution builds Thunderbird with system RNP or bundled RNP
If using system RNP, which version of RNP is installed

Known configurations:

Gentoo: Uses system RNP (via +system-librnp USE flag). If system RNP is version 0.18.0, Thunderbird IS AFFECTED.
Most other distributions: Use bundled RNP 0.17.1, NOT AFFECTED.

Distributions should verify their Thunderbird packaging:

Check if Thunderbird is built with --enable-system-rnp or similar flags
Check if Thunderbird package has a dependency on system RNP libraries
If Thunderbird uses system RNP 0.18.0, it is AFFECTED

Mitigation and recommendations

For standalone RNP users

Upgrade to RNP 0.18.1 immediately.

For distributions that have packaged 0.18.0

Please update to 0.18.1 when released, or consider providing 0.17.1 as an interim option.

For Thunderbird packages using system RNP

If your Thunderbird package is built with system RNP support and RNP 0.18.0 is installed, update RNP to 0.18.1 or 0.17.1. Consider whether Thunderbird should continue using system RNP or switch to bundled RNP.

For users

Users who encrypted sensitive data using RNP 0.18.0 (standalone or via Thunderbird with system RNP 0.18.0) should re-encrypt that data with RNP 0.18.1 or 0.17.1 based on their security requirements.

Additional improvements

In addition to the critical security fix, this release includes:

Botan 3.7.0 compatibility

Full compatibility with Botan 3.7.0 has been ensured, addressing API changes introduced in the latest Botan release.

Bug fixes

Various bug fixes and minor improvements enhance RNP’s stability and reliability.

Credits

The vulnerability was discovered and reported by Johannes Roth of MTG AG.

We thank Johannes for the responsible disclosure and coordination.

References

CVE: CVE-2025-13470
Red Hat CVE: https://access.redhat.com/security/cve/cve-2025-13402
Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2415863
Red Hat CSAF: https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-13402.json
Ribose CNA Advisory: https://open.ribose.com/advisories/ra-2025-11-20/
Release 0.18.1: https://github.com/rnpgp/rnp/releases/tag/v0.18.1

Contact

For security-related questions or coordination: open.source@ribose.com

For detailed technical information and the complete list of changes, please visit the release page.

RNP version 0.18.0 released

Thu, 19 Jun 2025 00:00:00 GMT

The RNP 0.18.0 release brings significant improvements to key generation defaults, signature validation, and FFI capabilities while strengthening cryptographic security practices.

This release enhances RNP’s security posture by discouraging weak cryptographic modes, improving key generation defaults, and providing better tools for signature validation and certification management.

Introduction

RNP continues to evolve as a modern OpenPGP implementation, and this release focuses on improving security defaults, expanding API capabilities, and enhancing compatibility with various OpenPGP implementations.

The updates to key generation defaults, signature validation error reporting, and certification management provide developers with more powerful tools while maintaining backward compatibility and improving overall security.

Key generation enhancements

RSA 3072-bit keys by default

RNP now generates RSA 3072-bit keys by default, moving away from the previous 2048-bit default.

This change reflects current best practices in cryptographic key strength:

3072-bit RSA keys provide approximately 128-bit security level
Aligns with modern security recommendations from cryptographic research
Better future-proofs keys against advances in computational power
Maintains good performance while significantly improving security

This enhancement ensures that users benefit from stronger cryptographic protection without needing to explicitly configure key generation parameters.

DSA 4096-bit key support

Support for DSA 4096-bit keys has been added to accommodate existing keys used by various entities.

While DSA is generally being phased out in favor of more modern algorithms, this support ensures:

Compatibility with legacy systems and keys
Proper handling of existing 4096-bit DSA keys
Smooth migration paths for organizations with established key infrastructure

Cryptographic security improvements

Discouraging EAX AEAD mode

The release actively discourages the use of EAX AEAD mode due to security considerations.

EAX mode has several limitations compared to more modern AEAD modes:

Limited adoption in the OpenPGP ecosystem
Potential security concerns with certain usage patterns
Better alternatives available (such as OCB or GCM)

This change helps guide users toward more secure and widely-supported cryptographic modes.

64-bit cipher restrictions

RNP no longer allows 64-bit ciphers for encryption without an explicit option.

This restriction addresses security concerns:

64-bit block ciphers are vulnerable to birthday attacks
SWEET32 attack demonstrates practical exploits
Modern alternatives provide better security

Users who specifically need 64-bit ciphers for compatibility can still enable them explicitly, but the default behavior now promotes better security.

Hash function updates on key expiration changes

When changing key expiration dates, RNP now automatically updates the hash function if the current one is considered weak.

This enhancement ensures:

Keys don’t retain weak hash functions during updates
Automatic migration to stronger algorithms
Improved long-term security without manual intervention

Signature validation enhancements

Signature error reporting

New FFI functions have been added to provide detailed signature validation error information:

rnp_signature_error_count(): Returns the number of errors encountered during signature validation
rnp_signature_error_at(): Retrieves specific error details at a given index

These functions enable developers to:

Understand exactly why signature validation failed
Provide detailed error messages to users
Make informed decisions based on specific validation failures
Implement more sophisticated error handling

Invalid signatures from encrypt-only keys

Signatures produced by encrypt-only keys or subkeys are now properly marked as invalid.

This enforcement ensures:

Proper adherence to key usage flags
Prevention of cryptographic misuse
Better compliance with OpenPGP best practices

Key certification management

New certification API

RNP now provides comprehensive functions for creating and customizing key certifications:

rnp_key_certification_create(): Creates new key certifications
rnp_key_signature_set_* family: Functions to set various certification properties
rnp_key_signature_get_* family: Functions to retrieve certification properties

These API enhancements enable:

Programmatic creation of key certifications
Fine-grained control over certification properties
Better integration with key management workflows
Support for advanced certification scenarios

Format and compatibility improvements

GnuPG armored file support

RNP now supports dearmoring of GnuPG-armored files that use the ARMORED FILE header.

This enhancement improves interoperability with GnuPG and other OpenPGP implementations that use this header format.

Flexible armored key import

The armored key import process now allows extra spaces, improving compatibility with various formatting styles produced by different OpenPGP implementations.

This tolerance for whitespace variations ensures:

Robust handling of keys from diverse sources
Reduced import failures due to formatting differences
Better user experience when working with keys from multiple systems

Backend and build improvements

Botan 3.5.0+ support

Enhanced support for Botan 3.5.0 and later versions ensures compatibility with the latest cryptographic library releases.

Generated version header

RNP now generates an rnp_ver.h header file, providing:

Compile-time version information
Better integration with build systems
Easier version checking in dependent projects

Cross-platform compatibility

Numerous compatibility fixes have been implemented for different operating systems and platforms, ensuring RNP works reliably across diverse environments.

Performance and code quality

Internal refactoring

Significant internal refactoring has been conducted to improve:

Code maintainability and readability
Long-term project sustainability
Easier contributions and extensions

Performance updates

Various performance optimizations have been implemented throughout the codebase, improving efficiency in common operations.

Looking ahead

This release demonstrates RNP’s continued commitment to security best practices, API extensibility, and broad compatibility. The improved key generation defaults, comprehensive signature validation error reporting, and expanded certification management capabilities provide a solid foundation for applications requiring robust OpenPGP functionality.

For detailed technical information and the complete list of changes, please visit the release page.

RNP proudly supports LibrePGP

Mon, 22 Jul 2024 00:00:00 GMT

At RNP, we are excited to announce our support for LibrePGP, a new specification of the OpenPGP encryption standard that builds on the lessons learned from the 20 years of experience with OpenPGP, allowing secure messages in the past to remain secure in the future.

What is LibrePGP?

LibrePGP is a new specification of the OpenPGP secure email standard that is designed to ensure the long-term stability, compatibility and security of protection communication.

LibrePGP is conceived and backed by g10 Code, Ribose, and Intevation, and is maintained by a study group consisting of the founding group with other interested implementers.

What is the vision of LibrePGP?

"Libre" is derived from the Latin word for "free". It emphasizes freedom, openness, and unrestricted use.

"PGP" stands for Pretty Good Privacy, the original encryption program developed by Phil Zimmermann in 1991 that became the basis for the OpenPGP standard.

LibrePGP represents the next step for the future of OpenPGP:

Free and open: LibrePGP aims to keep encryption technology accessible to all, free from proprietary restrictions or government interference.
Stable and compatible: It builds on 20+ years of OpenPGP experience, ensuring long-term stability and compatibility with existing systems.
Security-focused: LibrePGP prioritizes real-world security concerns over purely academic interests, making it suitable for deployments in critical sectors.
Forward-looking: LibrePGP represents a future for encrypted communication that supports rapid evolution, incorporating new algorithms like OCB when beneficial.
Trusted: With its commitment to open-source and collaboration among respected developers, LibrePGP aims to be a globally trusted standard for secure communication.

The vision for LibrePGP is to ensure that strong, reliable encryption remains freely available to defend privacy and secure communication worldwide. It seeks to balance innovation with stability, ensuring that the technology evolves to meet new challenges while maintaining the interoperability and reliability that have made PGP a cornerstone of digital security for decades.

Why is RNP Supporting LibrePGP?

We believe that LibrePGP is an essential step forward in preserving the core principles of openness and compatibility in secure communication.

We share the concerns that sparked the LibrePGP initiative: changes made to the OpenPGP specification by a subgroup within the IETF OpenPGP working group were perceived as potentially disrupting existing implementations, raising concerns about interoperability and security.

As a developer of OpenPGP tools, we believe that LibrePGP is a vital effort to ensure the long-term stability and compatibility of secure communication protocols. Our involvement in LibrePGP reflects our commitment to preserving the security, reliability, and flexibility of the OpenPGP standard.

GnuPG (GNU Privacy Guard) has been the de-facto reference implementation of OpenPGP for over two decades. Its widespread adoption and use have provided valuable insights into the needs and requirements of secure communication protocols. LibrePGP builds on these lessons learned, providing a robust and flexible specification that is designed to meet the evolving needs of secure communication.

LibrePGP is not just a specification. It is a movement — a collaborative effort to protect digital rights, support freedom of speech, and provide a robust foundation for secure communication in an increasingly digital world.

LibrePGP is our bulwark against attempts to weaken encryption standards, ensuring that individuals, journalists, activists, and organizations always have access to strong, trustworthy encryption tools.

This is exactly why we are proud to support LibrePGP and contribute to its contributions to its development and adoption.

Long-term collaboration with g10 Code and Intevation

As the developer of RNP, Ribose works closely with g10 Code, the developer of GnuPG, and Intevation, the developer of Gpg4win, the most prevalent OpenPGP implementation available on Windows. Our teams perform a significant amount of interoperability testing to ensure that our implementations are compatible and secure.

Together, we defend internet mail and sensitive information internationally in a trusted manner, all through a commitment to open-source. Our shared goal is to ensure that secure communication is accessible to everyone, regardless of platform or system.

In fact, RNP and GnuPG were the first two implementations that supported OCB (Offset Codebook) encryption, a high-performance and secure encryption algorithm designed by Prof. Phillip Rogaway.

We successfully interoperated with OCB encryption since 2018, demonstrating our commitment to implementing and testing new encryption algorithms. OCB encryption is now a mandatory part of the LibrePGP specification, and we are proud to have played a key role in its adoption.

What does this mean for RNP users?

As a user of RNP, you can rest assured that our commitment to LibrePGP will ensure that our software remains compatible with existing OpenPGP implementations. This includes the GnuPG and Gpg4win projects, which are also supporters of LibrePGP.

What’s next?

We will continue to work closely with the LibrePGP community to ensure that the RNP implementation meets the evolving needs of secure communication.

About RNP

RNP is a set of openly-licensed LibrePGP / OpenPGP tools that work on all major platforms. RNP provides end-to-end encryption for secure communication, including email and file encryption.

Learn more about our projects and how we are committed to preserving the security and compatibility of OpenPGP standards.

About LibrePGP

LibrePGP is a new specification of the OpenPGP encryption standard that builds on the lessons learned from global deployment of OpenPGP technology backed with over 20 years of experience.

It is designed to ensure the long-term stability and compatibility of secure communication protocols. Visit the LibrePGP website to learn more about the initiative.

RNP version 0.17.1 released

Fri, 03 May 2024 00:00:00 GMT

The RNP 0.17.1 release marks a significant step forward in cryptographic backend support, introducing compatibility with Botan 3 while enhancing OpenSSL 3 integration.

This release strengthens RNP’s position as a flexible OpenPGP implementation by expanding its cryptographic backend options and improving interoperability.

Introduction

RNP continues to evolve as a modern OpenPGP implementation, and this release focuses on ensuring broad compatibility with major cryptographic libraries.

The addition of Botan 3 support alongside enhanced OpenSSL 3 capabilities gives users and developers more flexibility in choosing their preferred cryptographic backend while maintaining RNP’s high security standards.

Cryptographic backend enhancements

Botan 3 support

The introduction of Botan 3 support represents a major advancement for RNP.

Botan 3 brings several improvements over its predecessor:

Modern C++17 codebase for better type safety and performance
Improved side-channel resistance
Enhanced platform support
Updated cryptographic algorithms and implementations

This addition ensures that RNP users can leverage the latest features and security improvements from the Botan cryptographic library while maintaining backward compatibility.

OpenSSL 3 improvements

The enhanced OpenSSL 3 support builds upon RNP’s existing OpenSSL backend integration. OpenSSL 3 introduced significant changes in its architecture and API, including:

Provider-based architecture for better modularity
FIPS 140-3 support (OpenSSL FIPS statement)
Improved algorithm policy management
Enhanced performance for various cryptographic operations

Our improvements ensure smooth operation with OpenSSL 3, taking advantage of its modern features while maintaining compatibility with existing systems.

Format and encoding enhancements

MIME mode support

RNP now includes comprehensive support for MIME mode in literal data packets, addressing a key aspect of email-based OpenPGP implementations. This enhancement aligns with the RFC 4880 specification for literal data packet handling.

MIME mode support is particularly crucial for email applications where OpenPGP is commonly used. It ensures proper handling of different text encodings and line endings, which is essential for maintaining message integrity across various email clients and systems.

The implementation focuses on:

Correct interpretation of Content-Type headers
Proper handling of multipart messages
Preservation of original message formatting
Improved compatibility with popular email clients like Thunderbird and Outlook

This addition strengthens RNP’s position as a versatile OpenPGP implementation, particularly for email-centric applications and systems requiring robust MIME handling capabilities.

Base64 improvements

The release includes a more flexible Base64 decoding implementation that now allows spaces after the checksum. This enhancement improves compatibility with various OpenPGP implementations and makes the decoder more robust when handling different formatting styles.

API enhancements

The FFI (Foreign Function Interface) has been expanded with the addition of the rnp_signature_get_features() function.

This new API allows developers to:

Query signature features programmatically
Better integrate RNP into their applications
Make informed decisions based on signature capabilities

Additional features and improvements

Enhanced signature handling and encryption

More flexible SHA-1 signature handling has been implemented, allowing clear distinction between key and data signatures. Support for SHA-1 key signatures has been extended until 2024-01-19 by default.
Optional raw encryption capability has been added, enabling encryption of already signed data.
A new option to override the current timestamp provides more flexibility in signature creation and validation.
Improved packet handling ensures the system doesn’t fail completely when encountering packets with unknown versions.

Backend and key management improvements

Automatic backend feature detection during the build process enhances system compatibility and setup.
Added support for importing and exporting base64-encoded keys, particularly useful for Autocrypt headers.
Implemented a default 2-year key expiration time for better key lifecycle management.

Looking ahead

This release continues RNP’s commitment to providing a robust, flexible, and modern OpenPGP implementation. The expanded backend support, enhanced signature handling, and improved format handling lay the groundwork for future enhancements while maintaining strong compatibility with existing systems.

For detailed technical information and the complete list of changes, please visit the release page.

RNP version 0.17.0 released

Mon, 01 May 2023 00:00:00 GMT

RNP 0.17.0 brings significant enhancements to encryption capabilities, key management, and overall functionality.

This release introduces AEAD-OCB support for the OpenSSL backend, improves hidden recipient handling, and adds compatibility with newer GnuPG key storage formats.

Introduction

This release represents a major step forward in RNP’s evolution, focusing on enhanced security features, improved compatibility with other OpenPGP implementations, and better key management capabilities. The changes make RNP more versatile while maintaining its commitment to security and usability.

Key highlights:

AEAD-OCB encryption support for improved performance and security
Enhanced hidden recipient handling for better privacy
GnuPG 2.3+ key storage format compatibility
Improved offline secret key handling

Other highlights:

SExp parsing code moved to a separate library (SEXPP)
New FFI capabilities for signature export and key verification
Enhanced CLI features for key management and encryption
Configurable compile-time options for legacy algorithm support

Enhanced encryption capabilities

AEAD-OCB encryption support

A major highlight of this release is the addition of AEAD-OCB (Authenticated Encryption with Associated Data - Offset Codebook) mode support for the OpenSSL backend.

OCB mode offers several advantages over traditional encryption modes:

Provides both confidentiality and authenticity in a single pass
Offers better performance compared to other AEAD modes like EAX
Allows parallel processing of encrypted data
Reduces overhead in encrypted messages

The implementation now defaults to using OCB instead of EAX when AEAD encryption is selected, providing better performance without compromising security.

Hidden recipient handling

The release introduces comprehensive support for "hidden recipients" during decryption operations. Hidden recipients, also known as anonymous recipients in the OpenPGP specification, allow encrypting messages without revealing the intended recipient’s key information in the message metadata.

When using hidden recipients, the message’s recipient key IDs are replaced with zeroes, making it more difficult for third parties to determine who can decrypt the message. This is particularly valuable in environments where metadata analysis could reveal sensitive communication patterns or relationships between parties.

RNP now fully supports decrypting messages with hidden recipients and includes new API capabilities through the RNP_VERIFY_ALLOW_HIDDEN_RECIPIENT flag. This allows applications to explicitly control whether messages with hidden recipients should be accepted during decryption operations.

This feature:

Enhances privacy by concealing the intended recipients of encrypted messages
Maintains compatibility with other OpenPGP implementations that use this feature
Provides better security for sensitive communications where recipient privacy is crucial

Key management improvements

GnuPG 2.3+ compatibility

This release adds support for modern key storage formats used by GnuPG 2.3 and later versions, described in its specification.

The new format, based on S-Expressions (SExp) (original specification from 1997), provides a more structured and extensible way to store OpenPGP keys and their metadata.

RNP can now read and write keys in this format, ensuring smooth interoperability with recent GnuPG versions. This is particularly important for users and organizations that maintain mixed environments or need to migrate between different OpenPGP implementations.

When GnuPG 2.3 was released, it introduced changes in how secret keys are stored, moving away from the legacy OpenPGP packet format to S-expressions. This change improved security and flexibility but required other implementations to adapt. RNP now fully supports this modern approach while maintaining backward compatibility.

This enhancement:

Enables seamless key sharing between RNP and GnuPG 2.3+
Supports modern key storage practices
Maintains backward compatibility with older formats

Offline key handling

The release includes significant improvements in handling offline secret keys - keys that are stored separately from the main keyring for enhanced security. This feature is particularly important for organizations implementing the air-gapped security model where signing keys are kept on isolated systems.

With these improvements, RNP now provides better support for:

Automatically distinguishing between online and offline keys during operations
Smart fallback to available keys when preferred keys are offline
Integration with hardware security tokens and smart cards
Support for detached secret key storage on separate secure systems

This enhancement is especially valuable for users who follow security best practices by keeping their primary keys offline and only using subkeys for day-to-day operations. The improved handling reduces friction when working with such configurations while maintaining strong security boundaries.

Users can expect:

Improved ease of management for keys stored on separate secure storage
Enhanced implementation of security best practices for key management
Better support for handling keys stored on hardware security devices

Developer improvements

S-Expression library separation to SEXPP

S-Expressions (SExp), was originally defined in a (specification from 1997), that provides a structured format for storing cryptographic data. This format is oft-used in security applications, including GnuPG’s modern key storage system.

The RNP team has created a reusable C++ Library for working with SEXP data called SEXPP.

By separating the SExp parsing code into its own library, RNP achieves better code organization and enables other projects to benefit from this implementation. The library provides a robust parser for both canonical and advanced transport S-expression formats, making it valuable for projects dealing with GnuPG keys or other cryptographic data storage.

The separation also simplifies RNP’s core codebase while maintaining full compatibility with GnuPG 2.3+ key storage formats through this dedicated component. Users and developers can expect better maintainability, easier updates to the S-expression handling code, and improved performance during cryptographic operations.

This modularization:

Improves code maintainability
Allows independent development of SExp parsing functionality
Reduces the core RNP codebase complexity

FFI improvements

New FFI capabilities have been added, including:

rnp_signature_export() for exporting key signatures
Support for hidden recipient verification via RNP_VERIFY_ALLOW_HIDDEN_RECIPIENT flag
Enhanced key-related checks for better security validation

Command-line interface improvements

The CLI has been improved with several new features:

Default armor message type for --enarmor command
New --set-filename command for specifying stored file names
Enhanced key management with --add-subkey and set-expire subcommands
Additional S2K configuration options with --s2k-iterations and --s2k-msec
Support for weak hash algorithms via --allow-weak-hash

Security and performance improvements

Configurable features

New compile-time options have been added to disable support for legacy algorithms:

ENABLE_BLOWFISH for Blowfish algorithm support
ENABLE_CAST5 for CAST5 algorithm support
ENABLE_RIPEMD160 for RIPEMD160 hash function

This allows users to create builds that exclude potentially vulnerable or unnecessary algorithms, reducing the attack surface.

Looking ahead

RNP 0.17.0 sets a strong foundation for future development with its improved encryption capabilities, better key management, and enhanced developer tools. The modularization of components and addition of modern encryption modes demonstrate RNP’s commitment to maintaining a secure, efficient, and user-friendly OpenPGP implementation.

For complete technical details and the full changelog, please visit the release page.

RNP version 0.16.3 released

Thu, 13 Apr 2023 00:00:00 GMT

RNP 0.16.3 is a critical security release that addresses two important vulnerabilities. This release focuses on strengthening RNP’s robustness against malformed inputs and improving the security of secret key handling.

Introduction

Security is a paramount concern in cryptographic software, and this release demonstrates RNP’s commitment to maintaining a secure OpenPGP implementation. The fixes address potential denial of service and key material exposure risks, making this an important update for all RNP users.

Key highlights:

Fixed input validation vulnerability (CVE-2023-29479) preventing denial of service
Improved secret key handling (CVE-2023-29480) for better security

Other highlights:

Enhanced security best practices implementation
Improved key lifecycle management
Updated input processing safeguards
Strengthened memory handling for sensitive data

Security improvements

Input validation vulnerability (CVE-2023-29479)

The first security fix addresses a vulnerability where malformed inputs could cause RNP to hang indefinitely. This issue could potentially be exploited to create a denial of service condition.

The vulnerability:

Could be triggered by specially crafted OpenPGP messages
Had the potential to make applications using RNP unresponsive
Affected all operations involving message parsing

The fix implements proper input validation and adds safeguards against malformed data, ensuring RNP handles invalid inputs gracefully without entering infinite processing loops.

Secret key handling vulnerability (CVE-2023-29480)

The second security fix resolves an issue where secret keys could remain unlocked after their intended use.

This vulnerability:

Could potentially expose sensitive key material in memory
Affected scenarios where keys were temporarily unlocked for operations
Created a risk of key material being accessible longer than necessary

The fix ensures that secret keys are properly locked immediately after use, implementing a more robust key lifecycle management system.

This enhancement:

Improves the security of secret key handling
Reduces the window of vulnerability for key material
Follows the principle of least privilege more strictly

Security impact and mitigation

These vulnerabilities could affect any application using RNP for OpenPGP operations.

Users should:

Update to RNP 0.16.3 as soon as possible
Review their applications for any cached or stored key material
Ensure proper key handling practices are followed

Security best practices

To maintain security when using RNP, we recommend:

Regular updates to the latest version
Proper input validation in applications using RNP
Implementation of secure key handling procedures
Regular security audits of systems using RNP

Looking ahead

This release reinforces RNP’s security foundation and demonstrates our commitment to addressing security issues promptly.

We continue to:

Monitor for potential security issues
Implement proactive security measures
Maintain transparency in security-related communications

For detailed technical information and the complete list of changes, please visit the release page.

RNP version 0.16.2 released

Thu, 22 Sep 2022 00:00:00 GMT

RNP 0.16.2 addresses important build system configuration issues that affected the customization of cryptographic algorithm support.

This maintenance release ensures proper functionality of build-time options, particularly for IDEA cipher and Brainpool elliptic curves, where the ENABLE_IDEA and ENABLE_BRAINPOOL options caused incorrect behavior.

Introduction

Build system reliability is crucial for cryptographic software, as it ensures users can properly customize their builds to meet specific security requirements and compliance standards. This release fixes issues in the CMake configuration system that affected how certain cryptographic algorithms could be enabled or disabled during compilation.

Key highlights:

Fixed CMake configuration for IDEA cipher and Brainpool curves support
Improved build-time algorithm customization for compliance requirements

Other highlights:

Enhanced build configuration verification
Improved documentation for build options
Better support for regulated environments
Streamlined build customization process

Build system improvements

CMake configuration fixes

The release resolves issues with two important build configuration options:

ENABLE_IDEA: Controls support for the IDEA (International Data Encryption Algorithm) cipher
ENABLE_BRAINPOOL: Controls support for Brainpool elliptic curves

These options previously exhibited incorrect behavior, which could lead to:

Unintended inclusion or exclusion of algorithm support
Inconsistent build configurations
Potential compliance issues in regulated environments

Algorithm support improvements

IDEA cipher implementation

The IDEA (International Data Encryption Algorithm) cipher is a significant component in OpenPGP implementations, particularly for:

Historical compatibility with legacy PGP systems and older encrypted data
Interoperability with systems that require IDEA for regulatory compliance
Supporting users who need to decrypt messages from legacy PGP implementations

RNP’s implementation of IDEA provides:

Full compliance with the OpenPGP RFC 4880 specification
Controlled enablement through CMake for organizations with specific compliance needs
Proper key handling and encryption/decryption operations for IDEA-encrypted content

While newer algorithms are recommended for modern applications, IDEA support remains important for:

It was one of the original algorithms supported by PGP
Some organizations still require it for backwards compatibility
It may be subject to patent restrictions in certain jurisdictions
It is critical in certain legacy systems where PGP is still used

The fix ensures that the ENABLE_IDEA option correctly controls the inclusion of IDEA cipher support, allowing organizations to make informed decisions about its use.

Brainpool curves implementation

Brainpool elliptic curves are important for:

Meeting specific security requirements, particularly in European standards
Providing alternative curves to NIST standards
Supporting high-security applications that require specific curve characteristics

The fix ensures proper control over Brainpool curve support, allowing users to accurately configure their builds according to their security requirements.

Build configuration best practices

When building RNP with these options, users should:

Explicitly set ENABLE_IDEA and ENABLE_BRAINPOOL according to their requirements
Verify the final build configuration through RNP’s feature reporting
Document their build-time choices for compliance purposes

Looking ahead

This release reinforces RNP’s commitment to providing a flexible and reliable build system. Users can now confidently customize their builds to:

Meet specific security requirements
Comply with regulatory standards
Optimize the library for their specific use cases

For detailed technical information and the complete list of changes, please visit the RNP v0.16.2 release page.

RNP now with updated approach to OpenPGP signature verification

Wed, 07 Sep 2022 00:00:00 GMT

RNP version 0.16.1 introduces a fundamental change to OpenPGP signature verification behavior, making it better aligned with real-world use cases and user expectations while maintaining robust security guarantees.

This change significantly impacts how RNP validates OpenPGP signatures through its Foreign Function Interface (FFI).

RNP now requires only one valid signature to succeed (or zero, if data was just encrypted). Previously, it required all signatures to be valid. To change the default behaviour, the new function rnp_op_verify_set_flags() may be used.

Understanding OpenPGP signature verification

What is OpenPGP signature verification?

OpenPGP signature verification is a fundamental cryptographic process in secure communications. It serves as a cornerstone of the RFC 4880 standard, providing essential security guarantees for digital communications and document authenticity.

At its core, signature verification ensures three critical aspects of secure communication:

Authentication: Verifies the identity of the sender by confirming that the message was created by someone with access to a specific private key
Integrity: Guarantees that the message content hasn’t been modified since it was signed
Non-repudiation: Provides cryptographic proof that the sender cannot later deny creating the message

The verification process works through public-key cryptography. When sending a message, the sender creates a digital signature using their private key. This signature is a unique cryptographic hash that combines the message content with the sender’s private key. The recipient then uses the sender’s public key to verify this signature, confirming both the sender’s identity and message integrity.

In RNP’s implementation, signature verification is handled through the FFI (Foreign Function Interface) layer, making it accessible to various programming languages and applications. The process is designed to be both secure and flexible, accommodating different use cases from simple document signing to complex multi-signature scenarios.

For technical details on implementing verification in your applications, see the RNP documentation.

Evolution of verification approaches

Previous implementation: All-or-nothing

Prior to version 0.16.1, RNP adhered to a strict verification model based on traditional OpenPGP implementations like GnuPG.

This approach prioritized maximum security through rigid verification requirements, reflecting early cryptographic practices in the OpenPGP standard.

The original implementation required that all signatures present in a message be valid for the verification process to succeed. This meant:

Every single signature in a message had to be successfully verified
If any signature failed verification, the entire process would fail
No distinction was made between encrypted-only content and signed content
Verification requirements were fixed and couldn’t be adjusted for different use cases

While this stringent approach provided strong security guarantees, it led to several practical challenges in real-world applications:

Multi-signer documents became problematic when not all public keys were immediately available in the keyring
Mixed content handling (combining both signed and encrypted data) was complicated and often unintuitive
The system lacked flexibility to accommodate different verification scenarios or security requirements
Legacy signatures or situations with partial key availability could cause unnecessary verification failures

These limitations became particularly apparent in modern usage scenarios, such as in continuous integration pipelines, automated document processing, or situations where keys might be stored in different locations or hardware security modules (HSMs).

The strict verification model also posed challenges for FFI users of RNP, who often needed more granular control over the verification process or better feedback about the verification status of individual signatures.

New paradigm: Flexible and practical

Version 0.16.1 of RNP introduces a modernized verification model through the rnp_op_verify_execute() function, representing a significant shift from the traditional approach used in OpenPGP implementations. This new model responds to real-world challenges faced by users of cryptographic software while maintaining strong security guarantees.

Key features of the new model

At its core, the new verification approach introduces four major improvements:

It considers verification successful when at least one valid signature is present, making it more practical for scenarios with multiple signers
It properly handles encrypted-only data that contains no signatures, addressing a common use case in secure communications
It provides a more intuitive way to handle multiple signers, aligning with how most users expect the software to behave
It offers flexible verification policies that can be adjusted based on specific security requirements through the verification API.

Practical benefits

The updated verification approach in RNP 0.16.1 reflects modern cryptographic system requirements while maintaining strong security. This change particularly benefits organizations dealing with distributed systems and complex key management scenarios.

Distributed key management

In distributed systems where public keys might be stored across different locations or hardware security modules, the new approach significantly improves operational efficiency.

Modern enterprises often use Hardware Security Modules (HSMs) or distributed key management systems, making immediate access to all keys challenging.

Flexible key availability

The new model accommodates situations where immediate access to all signers' public keys isn’t practical or possible.

This is particularly relevant in scenarios involving multiple organizations or when dealing with legacy signatures where some keys might no longer be readily available.

Customizable verification requirements

Different types of documents often require varying levels of verification stringency. For example, internal documentation might need less strict verification compared to financial transactions.

RNP now supports this through configurable verification policies, allowing organizations to match their security requirements precisely.

Enhanced feedback mechanisms

The updated system provides detailed feedback about the verification status, crucial for modern application logic and automation.

This improvement is especially valuable in continuous integration/continuous deployment (CI/CD) pipelines and automated document processing systems where detailed verification status information drives subsequent processing steps.

Improved interoperability

The new approach enhances compatibility with other OpenPGP implementations like GnuPG, making RNP more practical for integration into existing cryptographic ecosystems. This compatibility is essential for organizations transitioning between different OpenPGP implementations or maintaining hybrid systems.

These changes position RNP as a more versatile solution for modern cryptographic applications while maintaining the robust security guarantees expected from an OpenPGP implementation. The flexibility introduced allows for better integration with contemporary software architectures and deployment patterns without compromising on security fundamentals.

Technical implementation details

Core changes in the FFI

The new verification behavior is implemented through several key components:

rnp_op_verify_execute(): The main verification function that implements the new behavior
rnp_op_verify_set_flags(): Allows fine-tuning of verification requirements
Enhanced status reporting providing detailed information about each signature
Improved error handling and feedback mechanisms

Verification policies and their implementation

The new verification system in RNP introduces a flexible policy framework that allows users to choose how strictly they want to enforce signature verification. This framework is particularly important for organizations that need to balance security requirements with practical operational needs.

Default policy: Single valid signature

The default policy implements a pragmatic approach to signature verification. It considers a verification operation successful when at least one valid signature is present in the message. This aligns with most real-world use cases where the presence of a trusted signature is sufficient to establish authenticity.

Key aspects of the default policy include:

Success criteria based on finding at least one valid signature
Proper handling of encrypted-only content without signatures
Comprehensive status reporting for all signatures present

Strict policy: Complete verification

For scenarios requiring maximum security, RNP maintains a strict verification policy option. This policy, similar to traditional OpenPGP implementations, requires all present signatures to be valid for the verification to succeed.

This policy is particularly useful for:

High-security environments where complete verification is mandatory
Maintaining compatibility with legacy systems
Scenarios where all signers must be verified

Custom verification requirements

RNP provides extensive customization options through its verification flags system, implemented via the rnp_op_verify_set_flags() function. This allows organizations to:

Define specific verification requirements matching their security policies
Implement complex verification workflows
Balance security needs with operational requirements

These policies are documented in detail in RNP documentation. The flexibility of this system makes RNP suitable for a wide range of applications, from simple document signing to complex enterprise security systems.

Security considerations and best practices

Maintaining security with flexibility

While RNP’s new verification approach offers greater flexibility, it’s crucial to maintain robust security practices throughout the verification process. This balance between flexibility and security ensures that the system remains both practical and trustworthy.

Security fundamentals

The core security principles in OpenPGP signature verification must be preserved even with a more flexible approach. Modern cryptographic standards, as recommended by NIST or IETF, must be rigorously applied when validating signature quality and strength. Organizations should establish and maintain a robust web of trust or PKI infrastructure to verify the trust level of signing keys. Additionally, comprehensive key management practices that adhere to industry standards are essential, encompassing proper key rotation schedules, effective revocation handling procedures, and secure storage protocols. For compliance and security analysis purposes, maintaining detailed verification logs is imperative.

Implementation recommendations

When implementing OpenPGP signature verification in your applications using RNP, several key considerations should guide your approach.

These implementation guidelines ensure that RNP’s flexible verification approach can be deployed securely and effectively in production environments while meeting stringent security requirements.

Standard implementations

For most use cases, the default behavior provides an optimal balance of security and usability. Organizations should implement the standard single-signature verification approach, which effectively addresses common requirements for document signing and secure communication. It’s essential to develop clear and comprehensive feedback mechanisms that provide users with detailed information about the verification status of each signature. Furthermore, proper handling of both signed and encrypted content must strictly follow the OpenPGP specification to ensure compliance and security.

Enhanced security requirements

In scenarios demanding heightened security measures, organizations should leverage the rnp_op_verify_set_flags() function to implement more stringent verification policies. For critical documents, supplementary validation checks should be incorporated, including timestamp verification and organizational policy compliance assessments. The implementation should be carefully aligned with specific organizational security policies and compliance requirements to ensure comprehensive protection.

Robust error handling

Error handling forms a critical component of secure operations. Organizations must implement sophisticated feedback systems that provide detailed information regarding verification failures and their underlying causes. Comprehensive logging of all verification attempts, results, and anomalies should be maintained for security auditing purposes. Furthermore, carefully designed fallback mechanisms should be implemented to handle edge cases and unexpected situations while maintaining security integrity.

Future implications

This architectural change positions RNP for:

Better integration with modern cryptographic workflows
Improved compatibility with other OpenPGP implementations
More flexible security policies that can adapt to different needs
Enhanced user experience without compromising security

The new verification behavior represents a significant step forward in making OpenPGP more accessible while maintaining its security guarantees. It demonstrates RNP’s commitment to balancing security requirements with practical usability.

For detailed technical information about the new verification behavior and available options, please refer to RNP documentation.

RNP version 0.16.1 released

Tue, 06 Sep 2022 00:00:00 GMT

RNP 0.16.1 brings significant improvements in security policies, operational flexibility, and platform support.

Introduction

The release marks a major milestone in RNP’s evolution with comprehensive support for OpenSSL 3.0, enabling seamless integration with the latest enterprise Linux distributions.

Additionally, it introduces more nuanced security policies and several user-requested features that improve flexibility and ease of use.

Key highlights:

OpenSSL 3.0 support for RHEL 9 and Fedora 36 compatibility
Enhanced SHA1 signature handling for key and data signatures
Raw encryption support for flexible data processing

Other highlights:

Configurable timestamp override functionality
Improved handling of unknown packet versions
Automatic backend feature detection during build
Base64-encoded key import/export for Autocrypt
Two-year default key expiration time

Platform support improvements

OpenSSL 3.0 compatibility

OpenSSL 3.0 has been recently released and RNP 0.16.1 is the only OpenPGP implementation that fully supports it.

This feature enables:

Native compatibility with RHEL 9, CentOS Stream 9, and Fedora 36
Support for OpenSSL’s new provider architecture
Improved FIPS compatibility through OpenSSL 3.0’s FIPS provider
Enhanced performance through OpenSSL 3.0’s optimizations

The implementation ensures that RNP works seamlessly with these platforms' default cryptographic backends, eliminating the need for custom builds or external dependencies.

Security policy enhancements

SHA1 signature handling improvements

This release introduces a more sophisticated approach to SHA1 signatures:

Allows distinguishing between data and key signatures
Extended support for SHA1 key signatures until January 19, 2024 (2024-01-19)
More granular control over signature acceptance policies
Better compatibility with existing key infrastructure

This change allows organizations to maintain compatibility with legacy systems while gradually transitioning to stronger algorithms.

Key expiration defaults

A new security-focused default has been implemented:

Automatic 2-year expiration time for newly generated keys
Encourages regular key rotation practices
Aligns with modern security recommendations
Helps prevent the use of outdated keys

Operational improvements

Raw encryption support

The addition of raw encryption capabilities provides:

Ability to encrypt already-signed data
More flexible processing pipelines
Better integration with existing workflows
Improved performance for certain use cases

Timestamp control

New timestamp override functionality enables:

Testing of time-dependent operations
Reproduction of specific scenarios
Validation of expiration handling
Better debugging capabilities

Enhanced format handling

Several improvements make RNP more robust when dealing with various OpenPGP implementations:

Graceful handling of unknown packet versions
Support for base64-encoded keys in Autocrypt headers
More flexible packet processing
Improved interoperability

Developer improvements

Build system feature detection

The new automatic backend feature detection during build:

Simplifies configuration
Ensures optimal use of available crypto features
Reduces build-time errors
Improves portability

API enhancements

New FFI capabilities have been added:

rnp_op_encrypt_set_flags() with RNP_ENCRYPT_NOWRAP for raw encryption
Base64 encoding options for key import/export
Timestamp override functionality
Updated security rule functions

Looking ahead

RNP 0.16.1 sets a strong foundation for future development with its improved platform support and security policies. The changes demonstrate RNP’s commitment to:

Maintaining broad platform compatibility
Implementing flexible security policies
Improving usability and integration capabilities
Supporting modern cryptographic practices

For detailed technical information and the complete list of changes, please visit the RNP v0.16.1 release page.

RNP version 0.16.0 released

Thu, 20 Jan 2022 00:00:00 GMT

RNP 0.16.0 represents a major milestone in the project’s evolution, introducing OpenSSL backend support and customizable security profiles.

This release significantly enhances RNP’s flexibility, security, and compatibility with other OpenPGP implementations.

Introduction

This release marks a transformative moment for RNP, introducing two major features that expand its utility and security capabilities. The addition of OpenSSL backend support broadens deployment options, while the new security profiles system enables fine-grained control over cryptographic policies.

Key highlights:

OpenSSL backend support for flexible deployment options
Customizable security profiles for granular cryptographic control
Enhanced hash algorithm policies for improved security

Other highlights:

Configurable compile-time feature switches
Improved signature validation mechanisms
Enhanced cross-platform compatibility
Extended FFI capabilities
Optimized CLI tools with better usability
Performance improvements for large-scale operations

Major feature improvements

OpenSSL backend support

The introduction of OpenSSL backend support is a game-changing addition that offers several advantages.

OpenSSL is the most widely deployed and used cryptographic library in the world, powering the majority of HTTPS connections on the internet. It provides a robust, commercial-grade, full-featured toolkit for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, as well as a general-purpose cryptography library.

Eliminates the requirement for Botan installation
Enables RNP usage on systems with OpenSSL as the primary cryptographic library
Provides alternative implementation choices for different deployment scenarios
Improves integration with existing OpenSSL-based systems

This feature allows RNP to be built and used on systems without Botan installed, making it more accessible and easier to deploy in various environments.

Security profile system

The new security profiles system provides unprecedented control over cryptographic policies:

Customizable security rules for different usage scenarios
Fine-grained control over algorithm acceptance
Temporal validation of cryptographic algorithms
Configurable policy enforcement

This system helps organizations implement and maintain their specific security requirements while ensuring compliance with evolving cryptographic standards.

Security enhancements

Hash algorithm policy improvements

Stricter policies have been implemented for older hash algorithms:

SHA1 signatures produced after January 19, 2019 (2019-01-19), are now marked as invalid
MD5 signatures produced after January 1, 2012 (2012-01-01), are now marked as invalid
SHA1 and 3DES have been removed from default key preferences
SHA1 collision detection code has been implemented

Signature validation enhancements

Several enhancements to signature validation have been made:

Signatures with unknown critical notation are now marked as invalid
Secret key validation occurs before first operation
More robust key material validation procedures
Limited number of possible message recipients/signatures to 16k

Compatibility improvements

Cross-platform support enhancements

The release includes several important compatibility fixes:

Resolved x25519 secret key export compatibility with GnuPG
Fixed support for Gnu/Hurd systems lacking PATH_MAX
Improved support for old RSA sign-only/encrypt-only keys
Enhanced ElGamal key support for sizes larger than 3072 bits

Build system improvements

New compile-time options provide better control over feature sets:

ENABLE_AEAD for AEAD encryption support
ENABLE_SM2 for SM2/SM3/SM4 algorithm support
ENABLE_BRAINPOOL for Brainpool curves
ENABLE_TWOFISH for Twofish algorithm

Developer improvements

FFI enhancements

New FFI functions have been added to support the latest features:

rnp_backend_string() and rnp_backend_version()
rnp_key_25519_bits_tweaked() and rnp_key_25519_bits_tweak()
Security profile manipulation functions
rnp_signature_get_expiration()

Command-line interface improvements

The CLI has been significantly improved:

New detailed help messages for both rnp and rnpkeys
Support for stdin/stdout/env input/output specifiers
New --notty option for batch processing
Enhanced key editing capabilities with --edit-key

Performance improvements

Several optimizations have been implemented:

Reduced memory usage for keys with many signatures
Improved key import performance
Better handling of large ElGamal keys
Optimized signature subpacket processing

Looking ahead

RNP 0.16.0 establishes a strong foundation for future development with its flexible backend support and customizable security policies. The improvements in this release demonstrate RNP’s commitment to:

Providing deployment flexibility
Maintaining strong security standards
Improving compatibility with other implementations
Enhancing developer experience

For detailed technical information and the complete list of changes, please visit the RNP v0.16.0 release page.

RNP version 0.15.2 released

Fri, 06 Aug 2021 00:00:00 GMT

Version: RNP 0.15.2 Release date: 2021-08-05

RNP 0.15.2 introduces significant improvements to key validation, signature handling, and expiration time calculations. This release focuses on enhancing compatibility with other OpenPGP implementations while maintaining robust security practices.

Introduction

Key and signature validation are fundamental aspects of any OpenPGP implementation. This release refines RNP’s approach to these critical functions, making it more practical while maintaining security. The changes reflect real-world usage patterns and improve interoperability with other OpenPGP software.

Key highlights:

Enhanced user ID validation for expired self-signatures
Improved signature validation based on historical key status
Fixed expiration time calculations for better key lifecycle management

Other highlights:

New FFI function for intelligent key selection
Enhanced user ID management in FFI
Improved CLI error reporting
Better encryption subkey selection
New key generation options for expiration

Key validation improvements

User ID validation enhancements

A major enhancement in this release is the more flexible approach to user ID validation. The changes include:

Support for user IDs with expired self-signatures
Better handling of historical validity periods
Improved compatibility with existing key infrastructure
More intuitive behavior for end users

This refinement helps users maintain access to their identities while preserving the security benefits of key expiration mechanisms.

Signature validation improvements

RNP now recognizes historical validity of keys during signature verification.

Signatures are now validated based on the key’s status at the time of signing. This means a signature is not considered as "invalid" if the key which produced it was valid during signing, even when it is expired at verification time.

Expired keys no longer invalidate their previously valid signatures. This approach better aligns with OpenPGP specification requirements and other implementations.

This change ensures that valid signatures remain verifiable even after key expiration, which is particularly important for long-term document verification.

Expiration time handling

Several improvements have been made to key expiration handling:

Fixed incorrect expiration time calculations in edge cases
More accurate handling of certification expiration dates
Better synchronization between primary keys and user IDs
Improved handling of overlapping validity periods

These fixes ensure more reliable key lifecycle management and prevent unexpected key invalidation.

Developer improvements

FFI enhancements

New FFI capabilities have been added to improve integration flexibility:

rnp_key_get_default_key() function for intelligent key selection
- Automatically selects appropriate subkeys for operations
- Considers key capabilities and validity
- Improves application usability
Enhanced user ID management
- NULL hash parameter support in rnp_key_add_uid()
- Automatic selection of appropriate hash algorithms
- Simplified API usage
Consistent encryption subkey selection
- Unified approach across different encryption operations
- Improved Autocrypt compatibility
- More predictable behavior for developers

Command-line interface improvements

The CLI tools have received important usability improvements:

Better error reporting for encryption operations in rnp
- Clear error messages when encryption fails
- Improved debugging capabilities
- Better user experience
New key generation options in rnpkeys
- rnpkeys now provides an --expiration option for setting key validity periods
- More flexible key lifecycle management
- Better control over key properties

Looking ahead

RNP 0.15.2 represents an important step in improving the usability and reliability of OpenPGP implementations. The changes demonstrate RNP’s commitment to:

Practical security measures
Enhanced compatibility
Improved developer experience
Better end-user usability

For detailed technical information and the complete list of changes, please visit the release page.

RNP version 0.15.1 released

Mon, 31 May 2021 00:00:00 GMT

Version: RNP 0.15.1 Release date: 2021-05-28

RNP 0.15.1 delivers critical security fixes and important improvements to key expiration handling, particularly addressing the Year 2038 problem in cryptographic applications.

This release also enhances build system flexibility and API robustness.

Introduction

This release addresses several important areas: a security vulnerability in key protection, long-term key expiration handling, and build system improvements. These changes strengthen RNP’s security while improving its usability in various deployment scenarios.

Key highlights:

Fixed key protection vulnerability (CVE-2021-33589)
Implemented "Year 2038" compatibility for long-term key validity
Enhanced key expiration handling for complex PKI deployments

Other highlights:

man pages building is now optional for flexible deployment
Improved FFI feature detection mechanisms
Enhanced timestamp handling throughout codebase
Better support for keys with multiple user IDs
Improved direct-key signature support

Security improvements

Key protection vulnerability fix (CVE-2021-33589)

A significant security fix addresses a vulnerability in key protection functions:

Issue: Cleartext key material could remain accessible after rnp_key_unprotect()/rnp_key_protect() calls
Impact: Potential exposure of sensitive key data in memory
Fix: Proper clearing of sensitive data after key operations
Importance: Critical for maintaining key confidentiality

For detailed information about this security fix, please refer to the RI 2021-001/CVE-2021-33589 advisory.

Year 2038 compatibility improvements

Long-term cryptographic operations

The Year 2038 problem presents unique challenges for cryptographic software:

The 32-bit time_t will overflow on January 19, 2038
Critical for long-term key validity and expiration
Particularly important for infrastructure and root certificates
Affects both key generation and validation

Post-2038 date handling

This release implements several improvements to handle post-2038 dates:

New rnp_key_valid_till64() function for 64-bit time handling
Fixed key expiry checks for dates beyond 2038
Improved timestamp handling throughout the codebase
Better support for long-term key validity

These changes ensure that RNP can properly handle keys and certificates with validity periods extending beyond 2038, which is crucial for:

Long-term infrastructure planning
Root certificate management
Compliance with modern security practices
Future-proofing cryptographic operations

Key management improvements

Expiration time handling

The release includes several improvements to key expiration management:

Better handling of keys with multiple user IDs
Improved expiration time updates
Support for direct-key signatures
Enhanced primary user ID certification handling

These changes provide more accurate and reliable key lifecycle management, particularly important for:

Enterprise key management
Certificate authority operations
Long-term document signing
Complex PKI deployments

Build system improvements

Documentation building options

The release makes man pages building optional, which:

Reduces build dependencies when documentation isn’t needed
Simplifies minimal installations
Improves build system flexibility
Enables faster builds in development environments

Developer improvements

FFI enhancements

New FFI features improve integration capabilities:

RNP_FEATURE_* defines replace raw strings
- More robust feature detection
- Better compile-time checking
- Improved IDE support
- Clearer API documentation
64-bit time handling functions
- Future-proof timestamp operations
- Better support for long-term keys
- Improved platform compatibility

Looking ahead

RNP 0.15.1 strengthens the foundation for secure and reliable OpenPGP implementations by:

Addressing critical security concerns
Preparing for future compatibility challenges
Improving build system flexibility
Enhancing developer experience

These improvements demonstrate RNP’s commitment to maintaining a robust, secure, and future-proof OpenPGP implementation.

For detailed technical information and the complete list of changes, please visit the release page.

RNP version 0.15 released

Mon, 05 Apr 2021 00:00:00 GMT

Version: RNP 0.15.0 Release date: 2021-04-04

RNP 0.15.0 represents a significant milestone in the project’s evolution, introducing important changes to library versioning, build system improvements, and enhanced message format handling.

This release focuses on making RNP more accessible to developers while improving compatibility and usability.

Introduction

This release brings substantial improvements to RNP’s build system, library organization, and developer documentation. It also addresses several format handling issues to improve interoperability with other OpenPGP implementations.

Key highlights:

Offline build support for secure environments
Enhanced cleartext signature handling for better compatibility
Simplified library versioning for easier integration

Other highlights:

Improved MSVC build support and documentation
Better 32-bit platform compatibility
Enhanced armored message processing
New FFI functions for key management
Improved CLI tools with new commands
Updated manual pages and documentation

Build system improvements

Offline build support

A major enhancement to the build system enables offline builds:

New CMake options for building without external downloads:
- Googletest can be skipped during build
- ruby-rnp can be skipped during build
Better support for air-gapped environments
Improved build reproducibility

This change is particularly important for:

Security-conscious environments
Regulated development environments
Automated build systems
Package maintainers

Library versioning improvements

The library naming scheme has been simplified:

Changed from librnp-0.{so,dll} to librnp.{so,dll}
Simplified dependency specifications
Better alignment with common library naming practices
Improved package management integration

MSVC build support

Enhanced Microsoft Visual Studio support includes:

Updated build instructions for MSVC
Better Windows integration
Improved development experience on Windows
More consistent cross-platform builds

Format handling improvements

Cleartext signature enhancements

Significant improvements have been made to cleartext signature handling:

Better handling of whitespace in empty lines between headers and content
Improved compatibility with various email clients
More robust processing of formatted text
Enhanced interoperability with other OpenPGP implementations

Armored message handling

The release includes more flexible handling of armored messages:

Relaxed CRC requirements
Warning-based approach instead of hard failures
Better handling of legacy messages
Improved error reporting

These changes make RNP more resilient when processing messages from different sources while maintaining security.

Platform compatibility improvements

32-bit platform support

Continued improvements for 32-bit systems include:

Better handling of the Year 2038 problem
Enhanced timestamp processing
Improved compatibility with legacy systems
Future-proofing for long-term key validity

Documentation improvements

Manual page enhancements

New and updated manual pages provide better documentation:

Complete rnp and rnpkeys command documentation
Detailed librnp API reference
Usage examples and best practices
Implementation guidelines

Developer improvements

Key management enhancements

New FFI functions enhance key management capabilities:

rnp_signature_remove for individual signature removal
rnp_uid_remove for user ID management
rnp_key_remove_signatures for batch operations

These additions provide:

More granular control over key data
Better key cleanup capabilities
Improved key maintenance workflows
Enhanced key lifecycle management

Command-line interface improvements

The CLI has been enhanced with:

New --remove-key command in rnpkeys
Better key management capabilities
Improved user experience
More consistent command behavior

Looking ahead

RNP 0.15.0 establishes a stronger foundation for future development by:

Simplifying the build process
Improving cross-platform support
Enhancing developer documentation
Providing better key management tools

These improvements demonstrate RNP’s commitment to being a developer-friendly, robust OpenPGP implementation.

For detailed technical information and the complete list of changes, please visit the release page.

RNP proposal for Google's Season of Docs 2021

Fri, 26 Mar 2021 00:00:00 GMT

This is our proposal for Google’s Season of Docs 2021.

Technical writers: please contact us if you are interested in helping improve RNP documentation!

Figure 1. Google Season of Docs 2021 logo

This is the proposal for Google’s Season of Docs 2021.

About RNP

RNP (https://www.rnpgp.org) is an open-source, openly-licensed (BSD-3) cryptography suite, which aims to facilitate usable end-to-end encryption based on zero-trust. Its high-performance C++ library provides a set of cryptographic primitives fully compliant with the OpenPGP standard (IETF RFC 4880).

First created in 2017, RNP is now used by Mozilla’s Thunderbird to enable end-to-end encryption across its 35+ million users, enabling Thunderbird to be the world’s most popular mail client that supports end-to-end encryption. RNP has undergone heavy security testing by Mozilla and Cure53, with public security reports provided on the Internet.

The RNP suite is officially supported and funded by the Mozilla Open Source Support (MOSS) Foundational Technology and Secure Open Source funds, and the EU Horizons 2020 program through NLNet’s Next Generation Internet initiative.

The following individuals of the project community have offered to act as volunteer mentors for this project:

Daniel Wyatt, Lead Developer of the RNP OpenPGP library. IETF standards participant, previously at FEMA. Contributor to multiple cryptographic tools including OpenSSL, LibreSSL, Botan. 3 times Google Summer of Code participant.
Dr. Wai Kit Wong, Head of Research at Ribose. Published heavily in cryptographic cloud systems. Former Associate Professor in Computer Science and Head of the Department of Computing at Hang Seng University of Hong Kong.

Project description

Current status

Due to rising popularity of the RNP project, the speedy growth of its userbase (and the need to address user needs) has caused development at RNP to outpace documentation efforts.

There are two aspects in RNP that need better documentation: the CLI and the API.

Currently, RNP provides minimal API documentation as an integrated library, which is insufficient for most developers who need to perform native integration, and inadequate for those who utilize RNP from the command line.

Better documentation will aid more pairs of eyes to review and improve adoption of the RNP library, which will help expose undiscovered problems in RNP.

This category of work aims to provide a reference guide for both the library and CLI, and provide a set of guides for easier adoption of the RNP components.

Identified issues

Documentation of code with on-going development is an ongoing challenge for developers.
- This issue becomes especially pronounced when the development team is paced by user needs, where time constraints generally leave code documentation at a dismal and outdated state. Developers are known not to be best at technical writing and it is important that the right skill set is applied for this problem.
Existing documentation is outpaced by development efforts.
- Outdated documentation causes problems ranging from minor inconveniences (e.g. users need to search for code changes) to potential security risks (e.g. users utilize outdated cryptographic code).
Streamlining automated documentation for code documentation.
- Maintaining documentation separate from the codebase requires context-switching and creates friction between the programming and documenting processes.

Project scope

Deliverable: Audit report of the current state of documentation

Familiarize and audit existing documentation and software
Develop an understanding of existing community needs
Strengths and weaknesses of current documentation
Perform usability test on existing documentation and identify parts most difficult to follow

Deliverable: Information architecture and use case prioritization

Prioritize use case focus by using the usability test results to develop more comprehensive documentation
The desired information architecture should:
- Allow the audience to discover the information they need;
- Use a layered approach, where the audience can learn more detailed information step-by-step, allowing the novice to progress in knowledge without being overwhelmed; and
- Be understandable to the suitable audience. Documentation for CLI is geared towards the normal user, while documentation for API is geared towards the software developer. We need to ensure that these audiences can find what they need.

Deliverable: Library API documentation

Author a detailed library API reference guide for each component to allow users the ability to find details of library API usage
Documentation should be built in an automated way through code annotations

Deliverable: CLI documentation

Author a detailed CLI reference guide to allow users the ability to utilize the CLI
Documentation should be built in an automated way through code annotations

Deliverable: How-to guides

Author how-to guide to allow users to easily adopt RNP on a personal computer or for an organization
Documentation should be built in a code-centric manner for better automation

Deliverable: GSoD project case study

Authored by the technical writer and interested project mentors
Describes the success and challenges faced during the GSoD project for future reference

Work considered out-of-scope:

This project is of a pilot nature due to the budget amount - we do not expect every available API signature to be documented to the brim.
This project will not address documentation on how RNP can be used with other systems (e.g. software that rely on RNP)

We are seeking a competent open-source technical writer who has an interest in information security and willing to learn about the topic.

Potential impact of the project

RNP powers 35+ million installs of Mozilla Thunderbird, and its adoption as an open alternative to existing OpenPGP tools is going strong, especially for civil society and for those that depend on privacy for safety.

Improved documentation for RNP will enable both typical Internet users and power users to better protect their privacy through adopting RNP.

Measuring project’s success

Expected results

The developed documentation will be published on the RNP project website at https://www.rnpgp.org.

Goal: A layman user can read the CLI user guide to install, setup, generate keys, and utilize RNP to protect information and send signed/encrypted emails; a developer can read the API guide to compile, setup and utilize RNP in the developer’s application.
- Indication metric: Amount of people referring to the user guides.
Goal: Allow code annotations to be developed into documentation in an automated fashion
- Indication metric: Number of times that developers have to switch from code annotations to document content on the official website

Measurable project metrics

Two goals are sought of the project:

provide detailed and updated documentation to bring more users into the community.
- This can be reflected by the number of new users of project documentation.
make updating documentation as automated and as easy as possible.
- This can be reflected by the number of PRs on rnpgp.org for contributing documentation that did not originate from code annotations.

The project would be considered successful if, after the project:

Unique traffic to project documentation increases by 10%; and
Number of code-documentation PRs to rnpgp.org decreases by 20%.

Project schedule

Project Length

3 months

Project Plan

Item	Duration (month)
Technical writer acclimatizes to existing project documentation and seeks clarifications from mentors.	0.5
Technical writer develops a high-level structure of deliverables under mentorship.	0.5
Technical writer develops contents of deliverables with progress overseen by mentors.	1.5
Technical writer facilitates testing of the developed deliverables by seeking public feedback and project contributors. Finalizes deliverables addressing community feedback.	0.5
Total	3

Budget

Item	Amount	Running Total	Notes/justifications
Technical writer	4,800.00	4,800.00
Swag	200	5,000.00	Project T-shirts (with shipping)
	TOTAL	5,000.00

Additional Information

The RNP project has mainly been documented by its technical contributors. One of our mentors, Daniel Wyatt, has participated in the Google Summer of Code program as a participant three times!

RNP 0.14.0 released

Thu, 21 Jan 2021 00:00:00 GMT

RNP 0.14.0 represents a major milestone in the project’s evolution, introducing Windows support and comprehensive improvements across key validation, compatibility, and security.

This release significantly expands RNP’s platform support while enhancing its robustness and usability.

Introduction

This release marks a transformative moment for RNP, bringing Windows platform support through both MSVC and MinGW/MSYS2 build systems. Additionally, it introduces substantial improvements to key validation, memory management, and compatibility with other OpenPGP implementations.

Key highlights:

Windows platform support via MSVC and MinGW/MSYS2
Enhanced key validation with stricter requirements
Improved security measures and memory management

Other highlights:

Comprehensive FFI enhancements for better integration
Improved CLI tools with new key management features
Better compatibility with other OpenPGP implementations
Optimized memory usage and performance
Enhanced error handling and logging
Migration to C++ and Python 3 for testing

Platform support improvements

Windows build system support

A major achievement in this release is the addition of comprehensive Windows support:

Build system support for both MSVC and MinGW/MSYS2
Native Windows file system compatibility
Support for widechar parameters and file names
Integration with Windows development tools

This expansion makes RNP a truly cross-platform solution, enabling:

Broader deployment options
Better integration with Windows applications
Consistent behavior across operating systems
Enhanced developer experience on Windows

Key management improvements

Key validation

Improved key validation: require to have at least one valid, non-expiring self signature
Added support for 'stripped' keys without userids and certifications but with valid subkey binding signature
Fixed secret key locking when it is updated with new signatures/subkeys
Fixed key expiry/flags calculation (take in account only the latest valid self-signature/subkey binding)
Implemented userid validity checks so only certified/non-expired/non-revoked userid may be searched
Changed behaviour to use latest encryption subkey by default

Smart card integration

Added basic support for GnuPG’s offline primary keys (gnupg --export-secret-subkeys) and secret keys stored on card

Security improvements

Memory management enhancements

Several improvements reduce memory usage and improve efficiency:

Optimized memory usage for keys with many signatures
Improved key/uid signatures access performance
Better memory handling during packet processing
Reduced memory leaks in error conditions

Security hardening

Multiple security improvements:

Removed version headers from armored messages
Enhanced fuzzing coverage via oss-fuzz
Fixed static analyzer issues
Updated to Botan 2.14.0 minimum requirement

Other issues

Fixed MDC reading if it appears on 8k boundary
Fixed leading zeroes for secp521r1 b & n field constants
Allowed keys and signatures with invalid MPI bit count
Fixed support for old RSA sign-only/encrypt-only and ElGamal encrypt-and-sign keys
Fixed support for ElGamal keys larger than 3072 bits
Replaced usage of deprecated botan_pbkdf() with botan_pwdhash()

Compatibility improvements

Legacy algorithm support

Enhanced support for various key types and algorithms:

Improved handling of RSA sign-only and encrypt-only keys
Better support for ElGamal keys larger than 3072 bits
Fixed secp521r1 curve parameter handling
Support for private/experimental signature subpackets, used by GnuPG and other implementations
Support for reserved/placeholder signatures

These improvements ensure:

Better interoperability with older systems
Support for legacy key formats
Improved compatibility with other OpenPGP implementations
More robust key processing

Format handling improvements

Significant improvements in message format handling:

Better processing of armored messages
Support for zero-size userid/attr packet
Support for unknown experimental s2ks
Improved text-mode signature handling
Enhanced CR character handling in text documents

Other issues

Fixed GnuPG compatibility issues with CR (\r) characters in text-mode and cleartext-signed documents
Fixed support for widechar parameters/file names on Windows

Performance optimizations

Memory management

Several improvements reduce memory usage and improve efficiency:

Significantly reduced memory usage for keys with large number of signatures
Improved performance of the key/uid signatures access
Fixed multiple memory leaks related to invalid algorithms/versions/etc.
Fixed symbol visibility so only FFI functions are exposed outside of the library

Robustness improvements

Enhanced error handling and stability:

Limited allowed nesting levels for OpenPGP packets
Relaxed packet dumping, ignoring invalid packets and allowing to find wrong packets easier
Improved logging of errored keys/subkeys information for easier debugging
Disabled logging by default in release builds and added support for environment variable RNP_LOG_CONSOLE to enable it back

Command-line interface enhancements

Key management

New key management capabilities:

Flexible password handling options
- Do not load keyring when it is not required, avoiding extra keyring not found output.
- Input/output data via the tty, if available, instead of stdin/stdout.
- Fixed possible crash when HOME variable is not set.
rnpkeys
- New --import-sigs argument and changed behavior of --import to check whether input is key or signature.
- New --export-rev command to export key’s revocation, parameters --rev-type, --rev-reason.
- New --revoke-key command.
- New --permissive parameter to --import-keys command.
- New --password options, allowing to specify password and/or generate unprotected key.

Usability improvements

Better user experience through:

Smarter keyring loading
Improved TTY handling
Better error messages
More flexible import options

Developer interface improvements

Enhanced FFI capabilities

Comprehensive new FFI functions for:

Key validation and status checking
Signature management
Protection information retrieval
Autocrypt compatibility

New keystore type constants:

RNP_KEYSTORE_*

New FFI functions:

rnp_import_signatures.
rnp_key_export_revocation.
rnp_key_revoke.
rnp_request_password.
rnp_key_set_expiration to update key’s/subkey’s expiration time.
rnp_op_verify_get_protection_info to check mode and cipher used to encrypt message.
functions to retrieve recipients information (rnp_op_verify_get_recipient_count, rnp_op_verify_get_symenc_count, etc.).
rnp_output_pipe allowing to write data from input to the output.
rnp_output_armor_set_line_length allowing to change base64 encoding line length.
rnp_key_export_autocrypt to export public key in autocrypt-compatible format.
functions to retrieve information about the secret key’s protection (rnp_key_get_protection_type, etc.).
rnp_uid_get_type, rnp_uid_get_data, rnp_uid_is_primary.
rnp_uid_is_valid.
rnp_key_get_revocation_signature and rnp_uid_get_revocation_signature.
rnp_signature_get_type.
rnp_signature_is_valid.
rnp_key_is_valid and rnp_key_valid_till.

New FFI flags:

flag RNP_LOAD_SAVE_PERMISSIVE to rnp_import_keys, allowing to skip erroneous packets.
flag RNP_LOAD_SAVE_SINGLE, allowing to import keys one-by-one.
flag RNP_KEY_REMOVE_SUBKEYS to rnp_key_remove function.

Others:

Fixed documentation for the rnp_unload_keys function.

Improved integration

Better integration support through:

Added exception guards at FFI boundary
Cleaner symbol visibility
Better documentation
More consistent API behavior

Security enhancements

Hardening measures

Multiple security improvements:

Removed version headers from armored messages
Enhanced fuzzing coverage
Fixed static analyzer issues
Updated cryptographic dependencies

Cryptographic improvements

Better cryptographic operations:

Updated to Botan 2.14.0
Improved key protection
Enhanced signature validation
Better random number generation

Technical improvements

Code modernization

Major technical improvements:

Migrated most of the internal code to C++
Updated test suite to Python 3
Better string handling
- Replaced strcpy calls with std::string and memcpy where applicable
Improved temporary file management
- Removed usage of mktemp, replacing it with mkstemp

Bug fixes

Fixed crash with non-detached signature input, fed into the rnp_op_verify_detached_create()
Fixed long armor header lines processing
Fixed primary key binding signature validation when hash algorithm differs from the one used in the subkey binding signature
Fixed possible crashes during processing of malformed armored input
Fixed support for text-mode signatures
Fixed armored message contents detection (so armored revocation signature is not more reported as the public key)

Looking ahead

RNP 0.14.0 establishes a stronger foundation for future development through:

Expanded platform support
Enhanced security measures
Improved developer interfaces
Better compatibility

These improvements demonstrate RNP’s commitment to being a robust, secure, and user-friendly OpenPGP implementation.

For detailed technical information and the complete list of changes, please visit the release page.

RNP 0.13.0 released

Fri, 03 Jan 2020 00:00:00 GMT

RNP 0.13.0 brings substantial improvements to the Foreign Function Interface (FFI) and command-line tools, while also addressing important stability and security issues. This release focuses on providing developers with more powerful and flexible APIs while improving the overall robustness of the library.

Introduction

This release represents a significant step forward in RNP’s evolution as a developer-friendly OpenPGP implementation. The extensive FFI enhancements provide developers with more granular control over cryptographic operations, while stability improvements ensure reliable operation in various scenarios.

Key highlights:

New key generation API for improved programmatic control
Enhanced armor handling with better stability and security
Comprehensive key management functions in FFI

Other highlights:

Streamlined CLI interface with better organization
Improved RPM package structure
Enhanced debugging capabilities
Better version control integration
Optimized key validation process
New output handling functions
Improved feature detection system

Command-line interface updates

`rnp`

Added --list-packets parameters (--json, etc.)
Removed --show-keys

`rnpkey`

Removed a few redundant commands (--get-key, --print-sigs, --trusted-keys, …)
Added --secret option
Display 'ssb' for secret subkeys

Foreign Function Interface (FFI) enhancements

Key generation and management

New functions:

A new (non-JSON) key generation API (rnp_op_generate_create etc.)
rnp_unload_keys function to unload all keys
rnp_key_remove to unload a single key
rnp_key_get_subkey_count/rnp_key_get_subkey_at
Various key property accessors (rnp_key_get_bits, rnp_key_get_curve)
rnp_op_generate_set_protection_password
rnp_key_get_creation, rnp_key_get_expiration
rnp_key_get_uid_handle_at, rnp_uid_is_revoked, etc.
rnp_key_is_revoked and related functions to check for revocation
rnp_key_get_primary_grip
rnp_op_generate_set_request_password
rnp_import_keys

Modified function:

Expanded bit length support for JSON key generation

Output and data handling

New functions:

rnp_output_to_path and rnp_output_finish
rnp_output_to_armor
rnp_dump_packets_to_output
rnp_output_write
rnp_guess_contents
rnp_key_packets_to_json/rnp_dump_packets_to_json
rnp_signature_packet_to_json
rnp_op_set_file_name/rnp_op_set_file_mtime
rnp_op_encrypt_set_aead_bits
rnp_op_verify_signature_get_handle

System and debugging

New functions:

rnp_version_commit_timestamp to retrieve the commit timestamp (for non-release builds)
rnp_calculate_iterations
rnp_supports_feature/rnp_supported_features
rnp_enable_debug/rnp_disable_debug

Package management

RPM: Split packages into librnp0, librnp0-devel, and rnp0

General stability fixes

Fixed a double-free on invalid armor headers
Fixed broken versioning when used as a git submodule
Fixed an infinite loop on parsing truncated armored keys
Fixed armored stream parsing to be more flexible and allow blank lines before trailer
Fixed the armor header for detached signatures (previously MESSAGE, now SIGNATURE)
Improved setting of default qbits for DSA
Fixed a crash when retrieving signature revocation reason
Stopped using expensive tests for key material validation

Looking ahead

RNP 0.13.0 establishes a stronger foundation for developers through:

More comprehensive FFI capabilities
Better stability and security
Improved packaging
Enhanced usability

These improvements demonstrate RNP’s commitment to providing a robust and developer-friendly OpenPGP implementation.

For detailed technical information and the complete list of changes, please visit the release page.

RNP 0.12.0 released

Mon, 14 Jan 2019 00:00:00 GMT

RNP 0.12.0 significantly expands cryptographic capabilities with support for additional elliptic curves, introduces AEAD encryption support, and enhances both the FFI and CLI interfaces.

This release also includes important fixes for key handling and signature validation.

Introduction

This release marks a major expansion in RNP’s cryptographic capabilities, particularly in the area of elliptic curve cryptography. The addition of new curves and AEAD support, combined with improved developer interfaces, makes RNP more versatile and secure for a wider range of applications.

Key highlights:

Added support for extra ECC curves (Brainpool p256, p384, p512, secp256k1, x25519).
CLI functionality extended with -f command, allowing to load keys directly from a file.
FFI enhancements for AEAD support.

Other highlights:

Dependency upgrade: Botan 2.8+.
Enhanced key grip calculations across various key types.
Improved handling of SM2 signatures for hashing the message. See comment in issue #436.
Added support for G10 ECC keys.
Enhanced dumping logic for partial-length packets, ensuring accurate handling.

Cryptographic enhancements

Extended ECC support

The release adds support for several important elliptic curves.

RNP supports the RFC 6637 specification which details the implementation and usage of ECC curves in OpenPGP.

The new implemented curves provide:

More flexibility in curve selection
Better compliance with various standards
Enhanced interoperability
Improved performance options

Brainpool curves

The Brainpool curves (p256, p384, p512) are standardized elliptic curves developed by the German Federal Office for Information Security (BSI) as specified in RFC 5639. These curves were designed to provide verifiably pseudo-random parameters, offering an important alternative to the NIST curves.

Key characteristics of Brainpool curves include:

Rigorous security verification through public, transparent generation processes
Three security levels (256-bit, 384-bit, and 512-bit) matching or exceeding RSA 3072-bit to 15360-bit security
Widespread adoption in European cryptographic applications and standards
Official approval by BSI for use in high-security applications

In OpenPGP applications, Brainpool curves are particularly valuable when regulatory compliance or specific security requirements mandate the use of BSI-approved algorithms. Their implementation in RNP follows the RFC 5639 and enables both ECDSA (for signatures) and ECDH (for encryption) operations.

The inclusion of Brainpool curves enhances RNP’s ability to serve European markets and organizations requiring BSI-approved cryptographic algorithms while maintaining full interoperability within the OpenPGP ecosystem.

secp256k1

The secp256k1 curve, defined by Standards for Efficient Cryptography (SEC), is a specialized elliptic curve that has gained widespread recognition primarily through its use in Bitcoin’s cryptographic operations. This Koblitz curve over a prime field offers unique mathematical properties that make it particularly efficient for cryptographic operations while maintaining strong security characteristics.

Key characteristics of secp256k1 include:

256-bit security level, comparable to 3072-bit RSA
Exceptional performance for ECDSA operations
Mathematically elegant structure that enables efficient implementation
Strong resistance to known cryptographic attacks
Widespread adoption and extensive security analysis

In OpenPGP applications, secp256k1 serves dual purposes - it can be used both for ECDSA digital signatures and ECDH key exchange operations, following the RFC 6637 specifications. Its implementation in RNP enables users to leverage the same high-performance cryptographic primitives used in blockchain applications while maintaining full compatibility with the OpenPGP ecosystem.

The curve’s efficiency comes from its specific parameters that enable particularly fast implementation of scalar multiplication operations, making it ideal for resource-constrained environments. While initially controversial due to its unusual generation process compared to NIST curves, secp256k1 has undergone extensive scrutiny and real-world testing through its use in cryptocurrency systems, establishing itself as a trusted option for high-security applications.

x25519

The x25519 curve, designed by Daniel J. Bernstein, represents a significant advancement in elliptic curve cryptography. It is specifically optimized for the Montgomery ladder implementation of elliptic curve Diffie-Hellman (ECDH) key exchange, as specified in curve 25519.

Key characteristics of x25519 include:

Designed for high-speed key exchange operations while maintaining strong security
Provides 128 bits of security, comparable to 3072-bit RSA
Resistant to various side-channel attacks due to its constant-time implementation
Widely adopted in protocols like TLS 1.3, Signal, and Wireguard

In OpenPGP applications, x25519 is particularly valuable for secure key exchange operations, offering an excellent balance of security and performance. Its inclusion in RNP, following OpenPGP specification, enables modern, high-performance encrypted communications while maintaining compatibility with the OpenPGP ecosystem.

Additionally, the x25519 curve strengthens the overall security framework, ensuring efficient and robust encryption methods are employed across various applications. It also positions RNP as a leader in the adoption of contemporary cryptographic practices, facilitating secure communication in today’s digital landscape.

Dependency updates

Botan upgrade requirement

Starting with this release, RNP requires Botan 2.8 or higher as its cryptographic backend. This upgrade represents a significant step forward in RNP’s cryptographic capabilities and performance.

Botan 2.8+ brings several crucial improvements:

Modern cryptographic implementations, including optimized ECC operations and AEAD support
Enhanced security features and fixes for known vulnerabilities
Improved performance through optimized algorithms and better hardware acceleration
More comprehensive API support, enabling better integration and feature expansion

For users, this upgrade means:

Stronger security guarantees through up-to-date cryptographic implementations
Better performance in key operations, especially with modern CPU features
Access to newer cryptographic algorithms and modes
Improved stability and reliability

While this change requires updating existing Botan installations, the benefits in security and performance make this upgrade essential for modern cryptographic applications. For installation instructions, see the Botan installation guide.

Foreign Function Interface (FFI) enhancements

AEAD

Authenticated Encryption with Associated Data (AEAD) is now fully supported through FFI, having been available through the CLI. This expansion brings modern encryption capabilities to developers integrating RNP into their applications.

AEAD provides both confidentiality and authenticity of encrypted data, making it a crucial feature for secure communications. The implementation follows RFC 4880bis, ensuring interoperability while providing strong security guarantees.

The FFI enhancements in this release include:

Comprehensive AEAD support for programmatic encryption operations
New example code demonstrating common usage patterns
Fixed regression issues with direct subkey loading
Implementation of per-signature hash and timing controls
Extended API documentation and usage examples

These improvements particularly benefit:

Developers integrating RNP into their applications
Systems requiring high-performance authenticated encryption
Applications needing fine-grained control over cryptographic operations
Projects requiring modern encryption standards compliance

The expanded FFI capabilities make RNP more accessible as a cryptographic library while maintaining its security standards and OpenPGP compliance.

Extensive FFI-AEAD examples are provided to help developers quickly integrate AEAD encryption into their applications.

Other improvements

Fixed regression with loading subkeys directly.

Implemented support for per-signature hash and creation/expiration time

This release implements support for per-signature hash and creation/expiration time.

Specifically, the FFI provides fine-grained control over signature creation, allowing developers to specify:

Custom hash algorithms for individual signatures
Creation time for signatures
Expiration time for signatures

This enhancement follows RFC 4880 specifications for signature creation timestamps and provides greater flexibility in signature generation.

Key benefits include:

Better control over signature properties
Support for specific compliance requirements
Enhanced timestamp accuracy
Improved signature verification capabilities

The implementation is particularly valuable for:

Applications requiring precise signature timing
Systems with specific hash algorithm requirements
Compliance-focused implementations
Long-term document signing solutions

This feature enables developers to create more precise and compliant signature implementations while maintaining full OpenPGP compatibility. Example code demonstrating these capabilities is available in the FFI documentation.

Key handling improvements

Support for G10 ECC keys

This release adds support for G10 format ECC keys, expanding RNP’s compatibility with various OpenPGP implementations. G10 is the native key format used by GnuPG 2.x, making this addition particularly important for interoperability.

Key features of G10 ECC key support:

Full compatibility with GnuPG 2.x key storage
Support for all implemented ECC curves
Seamless import and export capabilities
Proper handling of secret key material

This enhancement is particularly beneficial for:

Systems migrating from GnuPG
Multi-implementation environments
Key management systems
Cross-platform applications

The implementation follows the GnuPG key storage specification, ensuring reliable key handling across different OpenPGP implementations while maintaining security standards.

Other improvements

Better key grip calculations
Improved subkey handling
More accurate key identification

Command-line interface enhancements

`rnp`

Direct key file loading with -f/--keyfile
Fixed issue with selecting G10 secret keys via userid.

`rnpkeys`

rnpkeys now supports SM2 with arbitrary hashes.
Improved key information display

`redumper`

Added -g option to dump fingerprints and grips.
Display key id/fingerprint/grip in packet listings.

Debugging tools

Enhanced debugging capabilities in redumper:

Fingerprint and grip dumping
Better packet listings
More detailed key information
Improved diagnostic output

Technical improvements

Significant codebase improvements:

Removed legacy code
Better packet handling
Improved error handling
Enhanced maintainability

Looking ahead

RNP 0.12.0 establishes a stronger foundation for modern cryptographic operations through:

Expanded curve support
Modern encryption modes
Better developer tools
Enhanced usability

These improvements demonstrate RNP’s commitment to providing a comprehensive and secure OpenPGP implementation.

For detailed technical information and the complete list of changes, please visit the release page.

RNP 0.11.0 released

Mon, 17 Sep 2018 00:00:00 GMT

RNP 0.11.0 introduces significant improvements to key management and security features, particularly in the areas of key protection and key operations. This release focuses on enhancing usability while maintaining strong security practices.

Introduction

This release brings important enhancements to how RNP handles key operations and protection mechanisms. The improvements to String-to-Key (S2K) calculations and key management make RNP more user-friendly while ensuring robust security.

Key highlights:

Dynamic S2K iteration calculation for optimal key protection
Enhanced key import and merge operations for better management
Improved key protection mechanisms for stronger security

Other highlights:

Configurable S2K iteration settings
Time-based iteration calculation options
Better key distribution workflows
Simplified key management processes
Modernized key format support
Enhanced CLI configuration options

Security improvements

Dynamic S2K iteration calculation

String-to-Key (S2K) is a critical security mechanism in OpenPGP that converts passphrases into cryptographic keys. With version 0.11.0, RNP introduces dynamic S2K iteration calculation that automatically determines the optimal number of iterations based on the system’s capabilities.

This feature significantly improves both security and usability by:

Automatically adjusting iteration counts to match system performance
Ensuring consistent protection levels across different hardware
Balancing security needs with practical usability
Adapting to varying computational resources

Users benefit from enhanced protection against offline attacks without manually tuning parameters. The system continuously provides optimal security by:

Maintaining strong protection against brute-force attempts
Delivering consistent performance across platforms
Automatically scaling with hardware improvements
Reducing configuration complexity

For technical details on S2K implementation, refer to RFC 4880.

The new dynamic calculation system also integrates with RNP’s key protection mechanisms to provide a comprehensive security solution that stays current with evolving hardware capabilities.

Key protection enhancements

The release includes several key protection improvements:

More sophisticated key derivation mechanisms
Better adaptation to system capabilities
Improved resistance to offline attacks
Configurable protection levels

Key management improvements

Public key extraction from secret keys

RNP 0.11.0 introduces a streamlined process for extracting public keys from secret keys, addressing a common need in OpenPGP key management. This feature simplifies the distribution of public keys while keeping secret keys secure.

The improved extraction mechanism provides several benefits:

Automated public key generation from existing secret keys
Simplified key sharing workflows that reduce manual steps
Built-in safeguards to prevent accidental secret key exposure
Better integration with key servers and distribution systems

This enhancement is particularly useful for users who need to:

Share their public keys with collaborators
Upload keys to keyservers
Maintain separate public and private key rings
Implement key rotation policies

The feature aligns with OpenPGP best practices as defined in RFC 4880, ensuring compatibility while improving the user experience.

Support for merging information between keys

Key merging is a critical operation in OpenPGP implementations, especially when dealing with key management across multiple systems or synchronizing with keyservers. RNP 0.11.0 significantly enhances its key merging capabilities, making the process more reliable and efficient while adhering to RFC 4880.

The improved merge operation intelligently combines key information from multiple sources, ensuring that:

Existing valid signatures are preserved while new signatures are properly added
User ID certifications are maintained according to the OpenPGP trust model
Subkey relationships and bindings remain intact during merges
Key metadata is combined without conflicts or data loss
Revocation certificates and updates are properly handled

These improvements are particularly valuable for:

Organizations managing keys across multiple systems
Users synchronizing their keyring with public keyservers
Collaborative environments where keys are shared among team members
Automated key management systems and PKI implementations

The enhanced merging capabilities align with modern OpenPGP implementations while providing better reliability and consistency in key management operations. Users can expect smoother key synchronization processes and reduced manual intervention when managing distributed keys.

Discontinuation of old SSH key support

Discontinued old SSH key support in RNP 0.11.0 includes the removal of legacy methods and interfaces to ensure better security and maintainability.

Command-line interface improvements

S2K configuration options

New CLI options provide better control over key protection:

Custom S2K iteration count settings
Time-based iteration calculation
Dynamic defaults for optimal security
Better user control over protection levels

Looking ahead

RNP 0.11.0 establishes better foundations for:

Robust key protection
Simplified key management
Improved usability
Modern security practices

These improvements demonstrate RNP’s commitment to providing secure and user-friendly OpenPGP implementations.

For detailed technical information and the complete list of changes, please visit the release page.

RNP 0.10.0 released

Mon, 20 Aug 2018 00:00:00 GMT

What is RNP?

Meet RNP, an RFC 4880-compliant OpenPGP library written in C++. As a modern implementation of the OpenPGP standard, RNP provides a robust foundation for secure communications and data protection.

Origins and development

RNP was born at Ribose and is continuously maintained under its initiative. While it originally stemmed from NetPGP, RNP has evolved significantly through a year of active development, resulting in a complete transformation of the codebase.

Key improvements

The development team has:

Thoroughly rewritten legacy code for modern systems
Resolved compatibility issues with GnuPG and other OpenPGP implementations
Enhanced performance across all operations
Added support for cutting-edge cryptographic features
Maintained strict RFC 4880 compliance

Licensing benefits

RNP stands out with its BSD 3-clause license, offering unique advantages for both academic and commercial projects:

Intentionally non-copyleft to enable broad integration options
Compatible with GPL, MPL, MIT, and most other open-source licenses
Suitable for commercial binary distributions
Flexible embedding options in academic research and proprietary software
No reciprocal licensing requirements unlike copyleft licenses

Whether you’re developing research software, an open-source tool, or a commercial application, RNP provides a reliable, well-maintained OpenPGP implementation that you can freely integrate into your software without licensing constraints.

Getting started with RNP

RNP is both a library for direct integration into applications and a set of command-line tools. You can use it in several ways:

As a library

If you are developing a Ruby application, there are official bindings (see ruby-rnp RubyDocs).

Since RNP is written in C++, you can also integrate it directly into:

C/C++ applications
Objective-C code
Python applications using ctypes

As command-line tools

The CLI tools rnp and rnpkeys can be installed via:

Homebrew on macOS
YUM on RPM-based Linux distributions
Debian packages (coming soon)

These tools provide similar functionality to GnuPG’s command-line interface (see supported flags and use cases in the README).

Why RNP?

True library architecture

RNP is designed as a proper library from the ground up, unlike GnuPG/GPGME which historically developed as a monolithic application (see GnuPG is not a library (2013)).

This architectural choice means you can easily integrate RNP into your applications without wrestling with process management or complex IPC mechanisms. The library provides clean APIs that allow direct integration at the code level.

Extensive language support

While RNP’s core is written in C++, it offers seamless integration across multiple programming languages. Official Ruby bindings are available and actively maintained. Python and Go bindings are under development, making RNP accessible to a wider range of developers. Thanks to its C++ foundation, you can also integrate RNP into any environment that supports native code calling conventions.

Optimized memory management

Built with modern C++, RNP implements efficient memory management that maintains a constant memory footprint even when processing large amounts of data. This makes it particularly suitable for environments with memory constraints or when handling large encrypted files. The implementation follows best practices for secure memory handling of cryptographic material.

Comprehensive cipher support

RNP stands out with its extensive cryptographic algorithm support, including unique implementation of the SM algorithm family - making it one of the few OpenPGP implementations suitable for deployment in mainland China. The SM series (including SM2, SM3, and SM4) meets Chinese national standards for cryptographic algorithms, opening opportunities for applications that need to comply with Chinese regulatory requirements.

Active development and innovation

The project maintains an active development cycle, focusing on implementing cutting-edge cryptographic features while ensuring backwards compatibility. Regular updates bring performance improvements, security enhancements, and support for new standards as they emerge. The development team actively engages with the community and responds to security considerations in the evolving cryptographic landscape.

Algorithm support in RNP

RNP provides comprehensive support for various cryptographic algorithms, ensuring compatibility with different security requirements and standards.

Symmetric encryption

RNP implements a wide range of symmetric encryption algorithms, offering different security levels and performance characteristics:

IDEA - A block cipher that was once used in early versions of PGP
Triple DES - A triple-application of the DES cipher, providing additional security over single DES
CAST5 - A block cipher offering good performance and security for legacy systems
Blowfish - A fast block cipher suitable for environments with limited resources
AES variants (128, 192, 256-bit) - The current industry standard for symmetric encryption
Twofish - A highly secure alternative to AES, offering excellent performance
Camellia variants (128, 192, 256-bit) - A cipher widely used in Japan and compatible with many international standards
SM4 - The Chinese national standard block cipher, essential for applications requiring Chinese regulatory compliance

Symmetric encryption modes

RNP supports multiple encryption modes that provide different security properties:

CFB (Cipher Feedback) - A traditional mode that converts block ciphers into stream ciphers
AEAD-EAX - An authenticated encryption mode providing both confidentiality and authenticity
AEAD-OCB - A high-performance authenticated encryption mode offering parallel processing capabilities

Hash functions

RNP implements various cryptographic hash functions for different use cases:

MD5 - While cryptographically broken, maintained for legacy compatibility
SHA1 - Maintained for backwards compatibility with older systems
RIPEMD160 - A hash function developed in Europe as an open alternative
SHA-2 family (SHA-224, SHA-256, SHA-384, SHA-512) - The current industry standard hash functions providing different security levels
SM3 - The Chinese national standard hash function, required for Chinese market compliance

Asymmetric cryptography

RNP supports a comprehensive set of public-key algorithms:

RSA - The widely-used public-key cryptosystem for encryption and digital signatures
ElGamal - An asymmetric algorithm particularly useful for encryption operations
DSA - The Digital Signature Algorithm, including support for key sizes beyond 1024 bits (DSA2)
ECDSA/ECDH - Elliptic curve cryptography offering strong security with shorter key lengths
EdDSA - Modern elliptic curve signatures providing high security and performance
SM2 - The Chinese national standard for public-key cryptography, essential for Chinese market compliance

Summary

RNP stands out as a unique solution in the OpenPGP ecosystem by combining:

True library architecture enabling direct integration without IPC overhead
High-performance implementation in modern C++
BSD 3-clause license allowing both open-source and commercial use
Comprehensive algorithm support including Chinese SM standards
Active development with regular updates and security improvements

Whether you’re building an open-source tool or a commercial application, RNP offers a reliable, high-performance OpenPGP implementation that seamlessly integrates into your software stack.