Skip to content

Commit 08284a7

Browse files
committed
feat: add 0.18.1 post
1 parent f93d334 commit 08284a7

File tree

2 files changed

+413
-0
lines changed

2 files changed

+413
-0
lines changed
Lines changed: 225 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,225 @@
1+
---
2+
layout: post
3+
title: "RNP version 0.18.0 released"
4+
categories: release
5+
authors:
6+
- name: Nickolay Olshevsky
7+
email: o.nickolay@gmail.com
8+
social_links:
9+
- https://github.com/ni4
10+
excerpt: >-
11+
Enhanced key generation defaults, improved signature validation with error
12+
reporting, expanded FFI capabilities for certifications, and better
13+
cryptographic security practices.
14+
---
15+
16+
The RNP 0.18.0 release brings significant improvements to key generation
17+
defaults, signature validation, and FFI capabilities while strengthening
18+
cryptographic security practices.
19+
20+
This release enhances RNP's security posture by discouraging weak cryptographic
21+
modes, improving key generation defaults, and providing better tools for
22+
signature validation and certification management.
23+
24+
== Introduction
25+
26+
RNP continues to evolve as a modern OpenPGP implementation, and this release
27+
focuses on improving security defaults, expanding API capabilities, and
28+
enhancing compatibility with various OpenPGP implementations.
29+
30+
The updates to key generation defaults, signature validation error reporting,
31+
and certification management provide developers with more powerful tools while
32+
maintaining backward compatibility and improving overall security.
33+
34+
== Key generation enhancements
35+
36+
=== RSA 3072-bit keys by default
37+
38+
RNP now generates https://en.wikipedia.org/wiki/RSA_(cryptosystem)[RSA]
39+
3072-bit keys by default, moving away from the previous 2048-bit default.
40+
41+
This change reflects current best practices in cryptographic key strength:
42+
43+
* 3072-bit RSA keys provide approximately 128-bit security level
44+
45+
* Aligns with modern security recommendations from
46+
https://www.keylength.com/[cryptographic research]
47+
48+
* Better future-proofs keys against advances in computational power
49+
50+
* Maintains good performance while significantly improving security
51+
52+
This enhancement ensures that users benefit from stronger cryptographic
53+
protection without needing to explicitly configure key generation parameters.
54+
55+
=== DSA 4096-bit key support
56+
57+
Support for https://en.wikipedia.org/wiki/Digital_Signature_Algorithm[DSA]
58+
4096-bit keys has been added to accommodate existing keys used by various
59+
entities.
60+
61+
While DSA is generally being phased out in favor of more modern algorithms,
62+
this support ensures:
63+
64+
* Compatibility with legacy systems and keys
65+
* Proper handling of existing 4096-bit DSA keys
66+
* Smooth migration paths for organizations with established key infrastructure
67+
68+
== Cryptographic security improvements
69+
70+
=== Discouraging EAX AEAD mode
71+
72+
The release actively discourages the use of
73+
https://en.wikipedia.org/wiki/EAX_mode[EAX AEAD mode] due to security
74+
considerations.
75+
76+
EAX mode has several limitations compared to more modern AEAD modes:
77+
78+
* Limited adoption in the OpenPGP ecosystem
79+
* Potential security concerns with certain usage patterns
80+
* Better alternatives available (such as OCB or GCM)
81+
82+
This change helps guide users toward more secure and widely-supported
83+
cryptographic modes.
84+
85+
=== 64-bit cipher restrictions
86+
87+
RNP no longer allows 64-bit ciphers for encryption without an explicit option.
88+
89+
This restriction addresses security concerns:
90+
91+
* 64-bit block ciphers are vulnerable to birthday attacks
92+
* https://sweet32.info/[SWEET32 attack] demonstrates practical exploits
93+
* Modern alternatives provide better security
94+
95+
Users who specifically need 64-bit ciphers for compatibility can still enable
96+
them explicitly, but the default behavior now promotes better security.
97+
98+
=== Hash function updates on key expiration changes
99+
100+
When changing key expiration dates, RNP now automatically updates the hash
101+
function if the current one is considered weak.
102+
103+
This enhancement ensures:
104+
105+
* Keys don't retain weak hash functions during updates
106+
* Automatic migration to stronger algorithms
107+
* Improved long-term security without manual intervention
108+
109+
== Signature validation enhancements
110+
111+
=== Signature error reporting
112+
113+
New FFI functions have been added to provide detailed signature validation
114+
error information:
115+
116+
* `rnp_signature_error_count()`: Returns the number of errors encountered during
117+
signature validation
118+
119+
* `rnp_signature_error_at()`: Retrieves specific error details at a given index
120+
121+
These functions enable developers to:
122+
123+
* Understand exactly why signature validation failed
124+
* Provide detailed error messages to users
125+
* Make informed decisions based on specific validation failures
126+
* Implement more sophisticated error handling
127+
128+
=== Invalid signatures from encrypt-only keys
129+
130+
Signatures produced by encrypt-only keys or subkeys are now properly marked as
131+
invalid.
132+
133+
This enforcement ensures:
134+
135+
* Proper adherence to key usage flags
136+
* Prevention of cryptographic misuse
137+
* Better compliance with OpenPGP best practices
138+
139+
== Key certification management
140+
141+
=== New certification API
142+
143+
RNP now provides comprehensive functions for creating and customizing key
144+
certifications:
145+
146+
* `rnp_key_certification_create()`: Creates new key certifications
147+
148+
* `rnp_key_signature_set_*` family: Functions to set various certification properties
149+
150+
* `rnp_key_signature_get_*` family: Functions to retrieve certification properties
151+
152+
These API enhancements enable:
153+
154+
* Programmatic creation of key certifications
155+
* Fine-grained control over certification properties
156+
* Better integration with key management workflows
157+
* Support for advanced certification scenarios
158+
159+
== Format and compatibility improvements
160+
161+
=== GnuPG armored file support
162+
163+
RNP now supports dearmoring of GnuPG-armored files that use the `ARMORED FILE`
164+
header.
165+
166+
This enhancement improves interoperability with
167+
https://gnupg.org/[GnuPG] and other OpenPGP implementations that use this
168+
header format.
169+
170+
=== Flexible armored key import
171+
172+
The armored key import process now allows extra spaces, improving compatibility
173+
with various formatting styles produced by different OpenPGP implementations.
174+
175+
This tolerance for whitespace variations ensures:
176+
177+
* Robust handling of keys from diverse sources
178+
* Reduced import failures due to formatting differences
179+
* Better user experience when working with keys from multiple systems
180+
181+
== Backend and build improvements
182+
183+
=== Botan 3.5.0+ support
184+
185+
Enhanced support for https://botan.randombit.net/[Botan] 3.5.0 and later
186+
versions ensures compatibility with the latest cryptographic library releases.
187+
188+
=== Generated version header
189+
190+
RNP now generates an `rnp_ver.h` header file, providing:
191+
192+
* Compile-time version information
193+
* Better integration with build systems
194+
* Easier version checking in dependent projects
195+
196+
=== Cross-platform compatibility
197+
198+
Numerous compatibility fixes have been implemented for different operating
199+
systems and platforms, ensuring RNP works reliably across diverse environments.
200+
201+
== Performance and code quality
202+
203+
=== Internal refactoring
204+
205+
Significant internal refactoring has been conducted to improve:
206+
207+
* Code maintainability and readability
208+
* Long-term project sustainability
209+
* Easier contributions and extensions
210+
211+
=== Performance updates
212+
213+
Various performance optimizations have been implemented throughout the codebase,
214+
improving efficiency in common operations.
215+
216+
== Looking ahead
217+
218+
This release demonstrates RNP's continued commitment to security best practices,
219+
API extensibility, and broad compatibility. The improved key generation
220+
defaults, comprehensive signature validation error reporting, and expanded
221+
certification management capabilities provide a solid foundation for
222+
applications requiring robust OpenPGP functionality.
223+
224+
For detailed technical information and the complete list of changes, please
225+
visit the https://github.com/rnpgp/rnp/releases/tag/v0.18.0[release page].

0 commit comments

Comments
 (0)