|
| 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