diff --git a/.github/workflows/build_deploy.yml b/.github/workflows/build_deploy.yml index 65aa5e0..72ce689 100644 --- a/.github/workflows/build_deploy.yml +++ b/.github/workflows/build_deploy.yml @@ -4,7 +4,6 @@ on: push: branches: - main - # - staging pull_request: repository_dispatch: workflow_dispatch: @@ -22,50 +21,35 @@ concurrency: cancel-in-progress: false jobs: - # set_environment: - # outputs: - # my_env: ${{ steps.setenv.outputs.my_env }} - # my_url: ${{ steps.setenv.outputs.my_url }} - # runs-on: ubuntu-latest - # steps: - # - id: setenv - # run: | - # if [ "$GITHUB_REF" = "refs/heads/main" ] - # then - # echo "::set-output name=my_env::production" - # echo "::set-output name=my_url::https://www.tebako.org" - # elif [ "$GITHUB_REF" = "refs/heads/staging" ] - # then - # echo "::set-output name=my_env::staging" - # echo "::set-output name=my_url::https://staging-www.tebako.org" - # fi build: runs-on: ubuntu-latest - # needs: [set_environment] steps: - name: Checkout - uses: actions/checkout@v3 + uses: actions/checkout@v4 - name: Setup Ruby uses: ruby/setup-ruby@v1 with: - ruby-version: '3.1' + ruby-version: '3.3' bundler-cache: true - cache-version: 0 # Increment this number if you need to re-download cached gems + - name: Setup Pages id: pages - uses: actions/configure-pages@v3 + uses: actions/configure-pages@v5 + with: + enablement: true - name: Build with Jekyll # Outputs to the './_site' directory by default - run: make _site + run: bundle exec jekyll build --verbose --trace --baseurl "${{ steps.pages.outputs.base_path }}" env: JEKYLL_ENV: production + JEKYLL_LOG_LEVEL: debug - name: Upload artifact # Automatically uploads an artifact from the './_site' directory by default - uses: actions/upload-pages-artifact@v2 + uses: actions/upload-pages-artifact@v3 # Deployment job deploy: @@ -78,4 +62,4 @@ jobs: steps: - name: Deploy to GitHub Pages id: deployment - uses: actions/deploy-pages@v2 + uses: actions/deploy-pages@v4 diff --git a/.github/workflows/links.yml b/.github/workflows/links.yml index 1f09fef..cfa8c4d 100644 --- a/.github/workflows/links.yml +++ b/.github/workflows/links.yml @@ -4,43 +4,42 @@ on: push: branches: - main - - staging pull_request: jobs: link_checker: runs-on: ubuntu-latest steps: - - name: Checkout - uses: actions/checkout@v4 + - uses: actions/checkout@v4 - - name: Setup Ruby - uses: ruby/setup-ruby@v1 + - uses: ruby/setup-ruby@v1 with: - ruby-version: '3.1' + ruby-version: '3.3' bundler-cache: true - cache-version: 0 # Increment this number if you need to re-download cached gems + - name: Setup Pages id: pages uses: actions/configure-pages@v5 + with: + enablement: true - name: Build with Jekyll # Outputs to the './_site' directory by default - run: make _site + run: bundle exec jekyll build --verbose --trace --baseurl "${{ steps.pages.outputs.base_path }}" env: JEKYLL_ENV: production - name: Link Checker - uses: lycheeverse/lychee-action@v1.10.0 + id: lychee + uses: lycheeverse/lychee-action@v2 with: - args: --verbose --no-progress -- _site/**/*.html + args: --base _site/ --verbose --no-progress '_site/**/*.html' fail: true - env: - GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} - # - name: Create Issue From File - # uses: peter-evans/create-issue-from-file@v2 - # with: - # title: Link Checker Report - # content-filepath: ./lychee/out.md - # labels: report, automated issue + # - name: Create Issue From File + # if: steps.lychee.outputs.exit_code != 0 + # uses: peter-evans/create-issue-from-file@v5 + # with: + # title: Link Checker Report + # content-filepath: ./lychee/out.md + # labels: report, automated issue diff --git a/_posts/2018-08-20-rnp-010-released.adoc b/_posts/2018-08-20-rnp-010-released.adoc index de8bb2b..fbaea0f 100644 --- a/_posts/2018-08-20-rnp-010-released.adoc +++ b/_posts/2018-08-20-rnp-010-released.adoc @@ -5,76 +5,204 @@ date: 2018-08-20 20:37:38 +0700 categories: release authors: - name: Ronald Tse + email: tse@ribose.com + social_links: + - https://github.com/ronaldtse + - name: Nickolay Olshevsky email: o.nickolay@gmail.com social_links: - https://github.com/ni4 excerpt: >- - After a year since it stemmed off NetPGP, the OpenPGP library - shares little code in common with its ancestor. - Enjoy new features, better performance, and better - compatibility with other implementations. + RNP has evolved into a powerful, modern OpenPGP library with + significant improvements in features, performance, and compatibility. + This release marks a major milestone in RNP's development, + delivering a robust and versatile cryptographic solution. redirect_from: - /blog/08-20-2018/rnp-010-released/ --- :cpp: C++ +== What is RNP? + Meet RNP, an https://datatracker.ietf.org/doc/html/rfc4880[RFC 4880]-compliant -OpenPGP library written in {cpp}. +OpenPGP library written in {cpp}. 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 https://www.ribose.com[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 http://opensource.org/licenses/BSD-3-Clause[BSD 3-clause license], +offering unique advantages for both academic and commercial projects: -RNP was born at Ribose and is continuously maintained under its initiative. +* Intentionally non-copyleft to enable broad integration options -Originally stemmed from NetPGP, it now shares little in common with its -ancestor after a year of active development. A thorough rewrite of legacy code, -resolving compatibility issues with GnuPG and other implementations, -with improved performance and added cutting-edge features. +* Compatible with https://opensource.org/licenses/GPL-3.0[GPL], +https://opensource.org/licenses/MPL-2.0[MPL], +https://opensource.org/licenses/MIT[MIT], and most other open-source licenses -RNP also differs from other implementations -- it is offered under a -http://opensource.org/licenses/BSD-3-Clause[BSD 3-clause license], -which means it is compatible for embedded distribution within GPL, -MPL, MIT and most other open-source licenses, as well as being -included in commercial binary distributions. +* Suitable for commercial binary distributions -Feel free to use RNP in your software! +* 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 -If you are deploying OpenPGP in a Ruby-based application, -there are bindings +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 https://www.rubydoc.info/github/rnpgp/ruby-rnp[ruby-rnp RubyDocs]). -Since RNP written in {cpp}, you can call it from Objective-C code, -or with `ctypes` under Python. +Since RNP is written in {cpp}, you can also integrate it directly into: + +* C/C++ applications +* Objective-C code +* Python applications using `ctypes` -The RNP binaries `rnp` and `rnpkeys` can be installed via https://brew.sh[Homebrew] -or YUM, -with Debian packages coming next. -You can use the binaries similarly to GnuPG's command-line tools +=== As command-line tools + +The CLI tools `rnp` and `rnpkeys` can be installed via: + +* https://brew.sh[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 https://github.com/rnpgp/rnp[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 +https://news.ycombinator.com/item?id=5180217[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 {cpp}, it offers seamless integration across +multiple programming languages. Official +https://www.rubydoc.info/github/rnpgp/ruby-rnp[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 {cpp} foundation, you +can also integrate RNP into any environment that supports native code calling +conventions. + +=== Optimized memory management + +Built with modern {cpp}, 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: + +* https://en.wikipedia.org/wiki/International_Data_Encryption_Algorithm[IDEA] - A block cipher that was once used in early versions of PGP +* https://en.wikipedia.org/wiki/Triple_DES[Triple DES] - A triple-application of the DES cipher, providing additional security over single DES +* https://en.wikipedia.org/wiki/CAST-128[CAST5] - A block cipher offering good performance and security for legacy systems +* https://en.wikipedia.org/wiki/Blowfish_(cipher)[Blowfish] - A fast block cipher suitable for environments with limited resources +* https://en.wikipedia.org/wiki/Advanced_Encryption_Standard[AES] variants (128, 192, 256-bit) - The current industry standard for symmetric encryption +* https://en.wikipedia.org/wiki/Twofish[Twofish] - A highly secure alternative to AES, offering excellent performance +* https://en.wikipedia.org/wiki/Camellia_(cipher)[Camellia] variants (128, 192, 256-bit) - A cipher widely used in Japan and compatible with many international standards +* https://en.wikipedia.org/wiki/SM4_(cipher)[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: -* It is a proper library, in contrast to GnuPG/GPGME (see https://news.ycombinator.com/item?id=5180217[GnuPG is not a library (2013)]). +* 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 -* Ruby bindings are available with Python & Go bindings in the works, and you can use it wherever you can call {cpp} code. +=== Hash functions -* Implemented in {cpp} and offers constant memory footprint with large amounts of data. +RNP implements various cryptographic hash functions for different use cases: -* It offers comprehensive cipher support, including (uniquely) the SM algorithm family -- a desirable feature if you deploy cryptography in mainland Chinese market. +* MD5 - While cryptographically broken, maintained for legacy compatibility +* SHA1 - Maintained for backwards compatibility with older systems +* https://en.wikipedia.org/wiki/RIPEMD[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 +* https://en.wikipedia.org/wiki/SM3_(hash_function)[SM3] - The Chinese national standard hash function, required for Chinese market compliance -* Active development and focused on adding cutting-edge features. +=== Asymmetric cryptography +RNP supports a comprehensive set of public-key algorithms: -== Which algorithms does RNP support? +* https://en.wikipedia.org/wiki/RSA_(cryptosystem)[RSA] - The widely-used public-key cryptosystem for encryption and digital signatures +* https://en.wikipedia.org/wiki/ElGamal_encryption[ElGamal] - An asymmetric algorithm particularly useful for encryption operations +* https://en.wikipedia.org/wiki/Digital_Signature_Algorithm[DSA] - The Digital Signature Algorithm, including support for key sizes beyond 1024 bits (DSA2) +* https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm[ECDSA]/ECDH - Elliptic curve cryptography offering strong security with shorter key lengths +* https://en.wikipedia.org/wiki/EdDSA[EdDSA] - Modern elliptic curve signatures providing high security and performance +* https://datatracker.ietf.org/doc/html/draft-openpgp-oscca-02[SM2] - The Chinese national standard for public-key cryptography, essential for Chinese market compliance -The following ciphers, encryption modes and hash functions are supported: -* Symmetric: IDEA, Triple DES, CAST5, Blowfish, AES-128, AES-192, AES-256, Twofish, Camellia-128, Camellia-192, Camellia-256, SM4 +== Summary -* Symmetric encryption modes: CFB, AEAD-EAX, AEAD-OCB +RNP stands out as a unique solution in the OpenPGP ecosystem by combining: -* Hash: MD5, SHA1, RIPEMD160, SHA-256, SHA-384, SHA-512, SHA-224, SM3 +* True library architecture enabling direct integration without IPC overhead +* High-performance implementation in modern {cpp} +* 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 -* Asymmetric: RSA, ElGamal, DSA, so-called DSA2 (i.e. DSA with keys larger then 1024 bits), ECDSA/ECDH (with some subset of curves which later on will be expanded), EdDSA, SM2. +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. \ No newline at end of file diff --git a/_posts/2018-09-17-rnp-011-released.adoc b/_posts/2018-09-17-rnp-011-released.adoc index fb699b1..1b5a3f9 100644 --- a/_posts/2018-09-17-rnp-011-released.adoc +++ b/_posts/2018-09-17-rnp-011-released.adoc @@ -14,15 +14,157 @@ redirect_from: - /blog/17-09-2018/rnp-011-released/ --- -== General +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. -This update improves key import/merge operations and support for automating S2K iterations calculation. +== Introduction -* Remove some old SSH key support. -* Add support for dynamically calculating the S2K iterations. -* Add support for extracting the public key from the secret key. -* Add support for merging information between keys. +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. -== CLI +Key highlights: -* Add options for custom S2K iterations/times (dynamic by default). +* <> for optimal key protection +* <> for better management +* <> 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 + + +[[s2k-iterations]] +== 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 +https://tools.ietf.org/html/rfc4880[RFC 4880]. + +The new dynamic calculation system also integrates with RNP's +<> to provide a comprehensive security +solution that stays current with evolving hardware capabilities. + +[[key-protection]] +=== 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-operations]] +== 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 +https://tools.ietf.org/html/rfc4880[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 +https://tools.ietf.org/html/rfc4880[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 https://github.com/rnpgp/rnp/releases/tag/v0.11.0[release page]. diff --git a/_posts/2019-01-14-rnp-012-released.adoc b/_posts/2019-01-14-rnp-012-released.adoc index 82437d4..e6a586e 100644 --- a/_posts/2019-01-14-rnp-012-released.adoc +++ b/_posts/2019-01-14-rnp-012-released.adoc @@ -9,42 +9,329 @@ authors: social_links: - https://github.com/ronaldtse excerpt: >- - Added support for extra ECC curves (Brainpool p256, p384, p512, secp256k1, x25519). Extended FFI with AEAD support and a bunch of examples. CLI functionality extended with `-f` command, allowing to use the key loaded from a file. + Added support for extra ECC curves (Brainpool p256, p384, p512, secp256k1, + x25519). Extended FFI with AEAD support and a bunch of examples. CLI + functionality extended with `-f` command, allowing to load keys from a file. redirect_from: - /blog/14-01-2019/rnp-012-released/ --- -== General +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. -Added support for extra ECC curves (Brainpool p256, p384, p512, secp256k1, x25519). +This release also includes important fixes for key handling and signature +validation. -Extended FFI with AEAD support and a bunch of examples. +== Introduction -CLI functionality extended with `-f` command, allowing to use the key loaded from a file. +This release marks a major expansion in RNP's cryptographic capabilities, +particularly in the area of +https://en.wikipedia.org/wiki/Elliptic_curve_cryptography[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. -* We now require Botan 2.8+. -* Fixed key grip calculations for various key types. -* Fixed SM2 signatures hashing the hash of the message. See comment in https://github.com/rnpgp/rnp/issues/436[issue #436]. +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 https://github.com/rnpgp/rnp/issues/436[issue #436]. * Added support for G10 ECC keys. -* Fixed dumping of partial-length packets. -* Added support for extra ECC curves: -** Brainpool p256, p384, p512 ECDSA/ECDH -** secp256k1 ECDSA/ECDH -** x25519 -* Fixed AEAD with newer versions of Botan. -* Removed a lot of legacy code. - -== CLI - -* rnp: Added `-f`/`--keyfile` option to load keys directly from a file. -* rnp: Fixed issue with selecting G10 secret keys via userid. -* rnpkeys: Added support for SM2 with arbitrary hashes. -* redumper: Added -g option to dump fingerprints and grips. -* redumper: Display key id/fingerprint/grip in packet listings. - -== FFI - -* Added FFI examples. -* Fixed a regression with loading subkeys directly. -* Implemented support for per-signature hash and creation/expiration time. -* Added AEAD support. +* 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 https://datatracker.ietf.org/doc/html/rfc6637[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 +https://www.bsi.bund.de/EN/Home/home_node.html[German Federal Office for Information Security (BSI)] +as specified in +https://tools.ietf.org/html/rfc5639[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 +https://datatracker.ietf.org/doc/html/rfc5639[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 +http://www.secg.org/sec2-v2.pdf[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 +https://datatracker.ietf.org/doc/html/rfc6637[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 https://cr.yp.to/ecdh/curve25519-20060209.pdf[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 +https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh#name-curves-for-elliptic-curve-pu[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 https://botan.randombit.net/[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 +https://botan.randombit.net/handbook/building.html[Botan installation guide]. + + +== Foreign Function Interface (FFI) enhancements + +=== AEAD + +https://en.wikipedia.org/wiki/Authenticated_encryption[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 +https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis[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 https://tools.ietf.org/html/rfc4880[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 https://github.com/rnpgp/rnp/releases/tag/v0.12.0[release page]. diff --git a/_posts/2020-01-03-rnp-013-released.adoc b/_posts/2020-01-03-rnp-013-released.adoc index 74dc030..235def9 100644 --- a/_posts/2020-01-03-rnp-013-released.adoc +++ b/_posts/2020-01-03-rnp-013-released.adoc @@ -9,64 +9,129 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - Next version of the RNP library extends FFI and CLI interfaces, giving more flexibility and control to the user. + Next version of the RNP library extends FFI and CLI interfaces, giving more + flexibility and control to the user. redirect_from: - /blog/03-01-2020/rnp-013-released/ --- -== General - -Next version of the RNP library extends FFI and CLI interfaces, giving more flexibility and control to the user. - -* 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. -* Stop using expensive tests for key material validation. - -== CLI - -* rnpkeys: Removed a few redundant commands (`--get-key`, `--print-sigs`, `--trusted-keys`, ...). -* rnpkeys: Added `--secret` option. -* rnpkeys: Display 'ssb' for secret subkeys. -* rnp: Added `--list-packets` parameters (`--json`, etc.). -* rnp: Removed `--show-keys`. - -== FFI - -* Added `rnp_version_commit_timestamp` to retrieve the commit timestamp - (for non-release builds). -* Added a new (non-JSON) key generation API (`rnp_op_generate_create` etc.). -* Added `rnp_unload_keys` function to unload all keys. -* Added `rnp_key_remove` to unload a single key. -* Expanded bit length support for JSON key generation. -* Added `rnp_key_get_subkey_count`/`rnp_key_get_subkey_at`. -* Added various key property accessors (`rnp_key_get_bits`, `rnp_key_get_curve`). -* Added `rnp_op_generate_set_protection_password`. -* Added `rnp_key_packets_to_json`/`rnp_dump_packets_to_json`. -* Added `rnp_key_get_creation`, `rnp_key_get_expiration`. -* Added `rnp_key_get_uid_handle_at`, `rnp_uid_is_revoked`, etc. -* Added `rnp_key_is_revoked` and related functions to check for revocation. -* Added `rnp_output_to_path` and `rnp_output_finish`. -* Added `rnp_import_keys`. -* Added `rnp_calculate_iterations`. -* Added `rnp_supports_feature`/`rnp_supported_features`. -* Added `rnp_enable_debug`/`rnp_disable_debug`. -* Added `rnp_key_get_primary_grip`. -* Added `rnp_output_to_armor`. -* Added `rnp_op_generate_set_request_password`. -* Added `rnp_dump_packets_to_output`. -* Added `rnp_output_write`. -* Added `rnp_guess_contents`. -* Implemented `rnp_op_set_file_name`/`rnp_op_set_file_mtime`. -* Added `rnp_op_encrypt_set_aead_bits`. -* Added `rnp_op_verify_signature_get_handle`. -* Added `rnp_signature_packet_to_json`. - -== Packaging - -* RPM: Split packages into `librnp0`, `librnp0-devel`, and `rnp0`. +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: + +* <> for improved programmatic control +* <> with better stability and security +* <> 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 https://github.com/rnpgp/rnp/releases/tag/v0.13.0[release page]. diff --git a/_posts/2021-01-21-rnp-014-released.adoc b/_posts/2021-01-21-rnp-014-released.adoc index 6bfc9d1..132b163 100644 --- a/_posts/2021-01-21-rnp-014-released.adoc +++ b/_posts/2021-01-21-rnp-014-released.adoc @@ -9,97 +9,302 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - After a long delay the next version of the library and CLI was released. Major FFI, CLI and security improvements and compatibility fixes. Also now it can be built for Windows via MSVC and MinGW/MSYS2. + The long awaited new RNP is finally released with Windows support, major FFI, + CLI and security improvements and compatibility fixes. redirect_from: - /blog/21-01-2021/rnp-014-released/ --- -== General - -After a long delay the next version of the library and CLI was released. Major FFI, CLI and security improvements and compatibility fixes. Also now it can be built for Windows via MSVC and MinGW/MSYS2. - -* 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. -* Added support for Windows via MinGW/MSYS2. -* Added support for Windows via MSVC. -* 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). -* Fixed MDC reading if it appears on 8k boundary. -* Disabled logging by default in release builds and added support for environment variable `RNP_LOG_CONSOLE` to enable it back. -* Fixed leading zeroes for secp521r1 b & n field constants. -* Allowed keys and signatures with invalid MPI bit count. -* Added support for private/experimental signature subpackets, used by GnuPG and other implementations. -* Added support for reserved/placeholder signatures. -* Added support for zero-size userid/attr packet. -* Relaxed packet dumping, ignoring invalid packets and allowing to find wrong packet easier. -* Improved logging of errored keys/subkeys information for easier debugging. -* Fixed support for old RSA sign-only/encrypt-only and ElGamal encrypt-and-sign keys. -* Fixed support for ElGamal keys larger then 3072 bits. -* Fixed symbol visibility so only FFI functions are exposed outside of the library. -* Added support for unwrapping of raw literal packets. -* Fixed crash with non-detached signature input, fed into the `rnp_op_verify_detached_create()`. -* Significantly reduced memory usage for the keys large number of signatures. -* Fixed long armor header lines processing. -* Added basic support for GnuPG's offline primary keys (`gnupg --export-secret-subkeys`) and secret keys, stored on card. -* Fixed primary key binding signature validation when hash algorithm differs from the one used in the subkey binding signature. +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 link:https://visualstudio.microsoft.com/[MSVC] and +link:https://www.msys2.org/[MinGW/MSYS2] build systems. Additionally, it +introduces substantial improvements to key validation, memory management, and +compatibility with other OpenPGP implementations. + +Key highlights: + +* <> via MSVC and MinGW/MSYS2 +* <> with stricter requirements +* <> 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 + + +[[windows-support]] +== 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-validation]] +== 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]] +== 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 possible crashes during processing of malformed armored input. -* Limited allowed nesting levels for OpenPGP packets. -* Fixed support for text-mode signatures. -* Replaced strcpy calls with std::string and memcpy where applicable. -* Removed usage of mktemp, replacing it with mkstemp. -* Replaced usage of deprecated `botan_pbkdf()` with `botan_pwdhash()`. -* Added support for the marker packet, issued by some implementations. -* Added support for unknown experimental s2ks. -* Fixed armored message contents detection (so armored revocation signature is not more reported as the public key). -* Changed behaviour to use latest encryption subkey by default. -* Fixed support for widechar parameters/file names on Windows. -* Implemented userid validity checks so only certified/non-expired/non-revoked userid may be searched. -* Fixed GnuPG compatibility issues with CR (`\r`) characters in text-mode and cleartext-signed documents. -* Improved performance of the key/uid signatures access. -* Migrated tests to the Python 3. -* Migrated most of the internal code to C++. - -== CLI - -* 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: Added `--import-sigs` and changed behavior of `--import` to check whether input is key or signature. -* rnpkeys: Added `--export-rev` command to export key's revocation, parameters `--rev-type`, `--rev-reason`. -* rnpkeys: Added `--revoke-key` command. -* rnpkeys: Added `--permissive` parameter to `--import-keys` command. -* rnpkeys: Added `--password` options, allowing to specify password and/or generate unprotected key. - -== FFI - -* Added keystore type constants `RNP_KEYSTORE_*`. -* Added `rnp_import_signatures`. -* Added `rnp_key_export_revocation`. -* Added `rnp_key_revoke`. -* Added `rnp_request_password`. -* Added `rnp_key_set_expiration` to update key's/subkey's expiration time. -* Added flag `RNP_LOAD_SAVE_PERMISSIVE` to `rnp_import_keys`, allowing to skip erroneous packets. -* Added flag `RNP_LOAD_SAVE_SINGLE`, allowing to import keys one-by-one. -* Added `rnp_op_verify_get_protection_info` to check mode and cipher used to encrypt message. -* Added functions to retrieve recipients information (`rnp_op_verify_get_recipient_count`, `rnp_op_verify_get_symenc_count`, etc.). -* Added flag `RNP_KEY_REMOVE_SUBKEYS` to `rnp_key_remove` function. -* Added function `rnp_output_pipe` allowing to write data from input to the output. -* Added function `rnp_output_armor_set_line_length` allowing to change base64 encoding line length. -* Added function `rnp_key_export_autocrypt` to export public key in autocrypt-compatible format. -* Added functions to retrieve information about the secret key's protection (`rnp_key_get_protection_type`, etc.). -* Added functions `rnp_uid_get_type`, `rnp_uid_get_data`, `rnp_uid_is_primary`. -* Added function `rnp_uid_is_valid`. -* Added functions `rnp_key_get_revocation_signature` and `rnp_uid_get_revocation_signature`. -* Added function `rnp_signature_get_type`. -* Added function `rnp_signature_is_valid`. -* Added functions `rnp_key_is_valid` and `rnp_key_valid_till`. -* Added exception guard to FFI boundary. +* 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. -== Security -* Removed version header from armored messages (see footnote:[https://mailarchive.ietf.org/arch/msg/openpgp/KikdJaxvdulxIRX_yxU2_i3lQ7A/] ). -* Enabled fuzzing via oss-fuzz and fixed reported issues. -* Fixed a bunch of issues reported by static analyzer. -* Require at least Botan 2.14.0. +=== 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 https://github.com/rnpgp/rnp/releases/tag/v0.14.0[release page]. diff --git a/_posts/2021-04-05-rnp-release-0-15.adoc b/_posts/2021-04-05-rnp-release-0-15.adoc index 781352b..0efeb3e 100644 --- a/_posts/2021-04-05-rnp-release-0-15.adoc +++ b/_posts/2021-04-05-rnp-release-0-15.adoc @@ -8,30 +8,161 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - API, CLI and FFI enhancements + Enhances build system flexibility and improves message format handling for better OpenPGP compatibility --- -RNP v0.15 has been released on 2021-04-04, providing API, CLI and FFI improvements. +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. -== General +This release focuses on making RNP more accessible to developers while improving +compatibility and usability. -* Added CMake options to allow offline builds, i.e. without `Googletest`/`ruby-rnp` downloads. -* Removed major library version from the library name (`librnp-0.{so,dll}` -> `librnp.{so,dll}`). -* Improved handling of cleartext signatures, when empty line between headers and contents contains some whitespace characters. -* Relaxed requirements for the armored messages CRC (allow absence of the CRC, and issue warning instead of complete failure). -* Updated build instructions for MSVC. -* Improved support of 32-bit platforms (year 2038 problem). +== Introduction -== CLI +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. -* Added up-to-date manual pages for `rnp` and `rnpkeys`. -* rnpkeys: added `--remove-key` command. +Key highlights: +* <> for secure environments +* <> for better compatibility +* <> for easier integration -== FFI +Other highlights: -* Added up-to-date manual page for `librnp`. -* Added function `rnp_signature_remove` -* Added function `rnp_uid_remove` -* Added function `rnp_key_remove_signatures` for batch signature removal and filtering. +* 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 + +[[offline-builds]] +== Build system improvements + +=== Offline build support + +A major enhancement to the build system enables offline builds: + +* New https://cmake.org[CMake] options for building without external downloads: +** https://github.com/google/googletest[Googletest] can be skipped during build +** https://github.com/rnpgp/ruby-rnp[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]] +=== 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]] +== 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 https://en.wikipedia.org/wiki/Year_2038_problem[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 https://github.com/rnpgp/rnp/releases/tag/v0.15.0[release page]. diff --git a/_posts/2021-05-31-rnp-release-0-15-1.adoc b/_posts/2021-05-31-rnp-release-0-15-1.adoc index a3b3b38..420431f 100644 --- a/_posts/2021-05-31-rnp-release-0-15-1.adoc +++ b/_posts/2021-05-31-rnp-release-0-15-1.adoc @@ -8,26 +8,147 @@ authors: social_links: - https://github.com/ronaldtse excerpt: >- - API and security enhancements + Addresses key protection vulnerability and implements Year 2038 compatibility + for cryptographic operations --- -The latest release of RNP v0.15.1 on 2021-05-28 provides API and security enhancements. +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. -== General +This release also enhances build system flexibility and API robustness. -* Make man pages building optional. -* Fixed updating of expiration time for a key with multiple user ids. -* Fixed key expiry check for keys valid after the year 2038. -* Pick up key expiration time from direct-key signature or primary userid certification if available. +== Introduction -== FFI +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. -* Added function `rnp_key_valid_till64()` to correctly handle keys which expire after the year 2038. -* Added `RNP_FEATURE_*` defines to be used instead of raw strings. +Key highlights: -== Security +* <> (CVE-2021-33589) +* <> for long-term key validity +* <> for complex PKI deployments -* Fixed issue with cleartext key data after `rnp_key_unprotect()`/`rnp_key_protect()` calls -(link:/advisories/ri-2021-001[RI 2021-001/CVE-2021-33589 advisory]). +Other highlights: +* link:https://en.wikipedia.org/wiki/Man_page[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-fix]] +== 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 +link:/advisories/ri-2021-001[RI 2021-001/CVE-2021-33589 advisory]. + +[[y2038-support]] +== Year 2038 compatibility improvements + +=== Long-term cryptographic operations + +The link:https://en.wikipedia.org/wiki/Year_2038_problem[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-expiration]] +== 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 link:https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1[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 link:https://en.wikipedia.org/wiki/Man_page[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 https://github.com/rnpgp/rnp/releases/tag/v0.15.1[release page]. diff --git a/_posts/2021-08-06-rnp-release-0-15-2.adoc b/_posts/2021-08-06-rnp-release-0-15-2.adoc index 2c3ac37..a3237bf 100644 --- a/_posts/2021-08-06-rnp-release-0-15-2.adoc +++ b/_posts/2021-08-06-rnp-release-0-15-2.adoc @@ -8,25 +8,132 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - Compatibility and security improvements + Enhances key validation mechanisms and improves compatibility with other + OpenPGP implementations --- -The latest release of RNP v0.15.2 on 2021-08-05 provides compatibility and security improvements. +Version: RNP 0.15.2 +Release date: 2021-08-05 -== General +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. -* Be less strict in userid validation: allow to use userids with self-signature, which has key expiration in the past. -* Do not mark signature as invalid if key which produced it is expired now, but was valid during signing. -* Fix incorrect key expiration calculation in some cases. -* Fix incorrect version number in the `version.txt`. +== Introduction -== FFI +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. -* Add function `rnp_key_get_default_key()` to pick the default key/subkey for the specific operation. -* Allow to pass NULL hash parameter to `rnp_key_add_uid()` to pick the default one. -* Use the same approach as in `rnp_op_encrypt_add_recipient()` for encryption subkey selection in `rnp_key_export_autocrypt()`. +Key highlights: -== CLI +* <> for expired self-signatures +* <> based on historical key status +* <> for better key lifecycle management -* `rnp`: Show error message if encryption failed. -* `rnpkeys` : Add `--expiration` option to specify expiration time during key generation. +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 + +[[user-id-validation]] +== 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]] +=== 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-handling]] +=== 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 +https://github.com/rnpgp/rnp/releases/tag/v0.15.2[release page]. diff --git a/_posts/2022-01-20-rnp-release-0-16-0.adoc b/_posts/2022-01-20-rnp-release-0-16-0.adoc index ef10aef..be7a48c 100644 --- a/_posts/2022-01-20-rnp-release-0-16-0.adoc +++ b/_posts/2022-01-20-rnp-release-0-16-0.adoc @@ -8,20 +8,154 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - OpenSSL backend and security profiles support + Introduces OpenSSL backend support, and customizable security profiles for + enhanced cryptographic policy control --- -The latest release of RNP v0.16.0 adds support for OpenSSL backend and security profiles, as well as improved security and compatibility with other implementations. +RNP 0.16.0 represents a major milestone in the project's evolution, introducing +OpenSSL backend support and customizable security profiles. -== Other fixes and improvements: +This release significantly enhances RNP's flexibility, security, and +compatibility with other OpenPGP implementations. -* Ability to disable certain features via compile-time switches (`ENABLE_AEAD`, `ENABLE_SM2`, etc.) -* Mark signatures with SHA1/MD5 hash, produced after the specific date (2019-01-19 and 2012-01-01) as invalid -* Fixed possible incompatibility with GnuPG on x25519 secret key export -* Fixed export of non-FFI symbols from rnp.so/rnp.dylib -* Fixed key expiration time calculation in some edge cases -* Added security profile manipulation functions to the FFI -* Improved CLI tools help messages -* Improved CLI: stdin/stdout/env input/output specifiers, `--notty` for batch processing, etc. +== Introduction -Full changelog is available at the https://github.com/rnpgp/rnp/releases/tag/v0.16.0[RNP v0.16.0 release page] \ No newline at end of file +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: + +* <> for flexible deployment options +* <> for granular cryptographic control +* <> 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 + +[[openssl-backend]] +== Major feature improvements + +=== OpenSSL backend support + +The introduction of https://www.openssl.org[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 https://botan.randombit.net[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-profiles]] +=== 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-policies]] +=== 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 https://github.com/rnpgp/rnp/releases/tag/v0.16.0[RNP v0.16.0 release page]. diff --git a/_posts/2022-09-06-rnp-release-0-16-1.adoc b/_posts/2022-09-06-rnp-release-0-16-1.adoc index 90eb8bd..81e7979 100644 --- a/_posts/2022-09-06-rnp-release-0-16-1.adoc +++ b/_posts/2022-09-06-rnp-release-0-16-1.adoc @@ -8,19 +8,142 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - Support for OpenSSL 3.0 backend and RHEL 9/Fedora 36 + Implements support for OpenSSL 3.0, flexible SHA1 signature handling, and RHEL + 9/Fedora 36 --- -Major new feature of RNP v0.16.1 is support for OpenSSL 3.0, allowing to build and use it on RHEL 9/Fedora 36 out of the box. +RNP 0.16.1 brings significant improvements in security policies, operational +flexibility, and platform support. -== Other fixes and improvements: +== Introduction -* More flexible SHA1 signature handling, allowing to distinguish between key and data signatures. By default support for SHA1 key signatures is extended till 2024-01-19. -* Optional raw encryption, allowing to encrypt already signed data -* Option to override current timestamp -* Do not fail completely on packets with unknown versions -* Automatic backend's feature detection during the build -* Optional import/export of base64-encoded keys (for Autocrypt headers) -* Default 2-year key expiration time +The release marks a major milestone in RNP's evolution with comprehensive +support for +https://openssl-library.org/news/openssl-3.0-notes/[OpenSSL 3.0], enabling +seamless integration with the latest enterprise Linux distributions. -Full changelog is available at the https://github.com/rnpgp/rnp/releases/tag/v0.16.1[RNP v0.16.1 release page] \ No newline at end of file +Additionally, it introduces more nuanced security policies and several +user-requested features that improve flexibility and ease of use. + +Key highlights: + +* <> for RHEL 9 and Fedora 36 compatibility +* <> for key and data signatures +* <> for flexible data processing + +Other highlights: + +* Configurable timestamp override functionality +* Improved handling of unknown packet versions +* <> during build +* Base64-encoded key import/export for Autocrypt +* Two-year default key expiration time + +[[openssl-support]] +== Platform support improvements + +=== OpenSSL 3.0 compatibility + +https://openssl-library.org/news/openssl-3.0-notes/[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 +https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9[RHEL 9], +https://www.centos.org/centos-stream/[CentOS Stream 9], and +https://getfedora.org/[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-handling]] +=== 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]] +=== 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 + +[[feature-detection]] +=== 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 https://github.com/rnpgp/rnp/releases/tag/v0.16.1[RNP v0.16.1 release page]. diff --git a/_posts/2022-09-07-new-verify-behavior.adoc b/_posts/2022-09-07-new-verify-behavior.adoc index 7c56839..b855f67 100644 --- a/_posts/2022-09-07-new-verify-behavior.adoc +++ b/_posts/2022-09-07-new-verify-behavior.adoc @@ -1,6 +1,6 @@ --- layout: post -title: "New signature verification behaviour" +title: "RNP now with updated approach to OpenPGP signature verification" categories: information authors: - name: Nickolay Olshevsky @@ -8,11 +8,337 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - Require only single valid signature for successfull verification. + A comprehensive look at RNP's new signature verification approach: simplifying + security without compromising integrity. --- -Within v0.16.1 release we decided to update signature verification behaviour (via the FFI API `rnp_op_verify_execute()` call) to better match user expectations. -Since the release by default it would require one valid signature to succeed (or zero, if data was just encrypted). Previously it required all signature to be valid. -In case you need to change the default behaviour the new function `rnp_op_verify_set_flags()` may be used. +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. -For more details please see the documentation for function `rnp_op_verify_execute()`. \ No newline at end of file +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 +https://datatracker.ietf.org/doc/html/rfc4880[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 +https://github.com/rnpgp/rnp/[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 https://www.gnupg.org/[GnuPG]. + +This approach prioritized maximum security through rigid verification +requirements, reflecting early cryptographic practices in the +https://datatracker.ietf.org/doc/html/rfc4880[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 +https://en.wikipedia.org/wiki/Hardware_security_module[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 +https://www.gnupg.org/[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 +https://github.com/rnpgp/rnp/[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 https://www.nist.gov/[NIST] or https://www.ietf.org/[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 +https://github.com/rnpgp/rnp/[RNP documentation]. diff --git a/_posts/2022-09-22-rnp-release-0-16-2.adoc b/_posts/2022-09-22-rnp-release-0-16-2.adoc index e2c61e6..bb8bac0 100644 --- a/_posts/2022-09-22-rnp-release-0-16-2.adoc +++ b/_posts/2022-09-22-rnp-release-0-16-2.adoc @@ -8,9 +8,125 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - Fix for CMake issues introduced in v0.16.2 + Resolves CMake build issues introduced in v0.16.2 affecting cryptographic + algorithm support customization --- -This update fixes CMake configuration issues, causing incorrect behaviour of `ENABLE_IDEA` and `ENABLE_BRAINPOOL` options. +RNP 0.16.2 addresses important build system configuration issues that affected +the customization of cryptographic algorithm support. -Release is available at the https://github.com/rnpgp/rnp/releases/tag/v0.16.2[RNP v0.16.2 release page] +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: + +* <> for IDEA cipher and Brainpool curves support +* <> for compliance requirements + +Other highlights: + +* Enhanced build configuration verification +* Improved documentation for build options +* Better support for regulated environments +* Streamlined build customization process + +[[cmake-fixes]] +== 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]] +=== Algorithm support improvements + +==== IDEA cipher implementation + +The https://en.wikipedia.org/wiki/International_Data_Encryption_Algorithm[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 https://datatracker.ietf.org/doc/html/rfc4880[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 https://github.com/rnpgp/rnp/releases/tag/v0.16.2[RNP v0.16.2 release +page]. diff --git a/_posts/2023-04-13-rnp-release-0-16-3.adoc b/_posts/2023-04-13-rnp-release-0-16-3.adoc index 8239423..e9a751b 100644 --- a/_posts/2023-04-13-rnp-release-0-16-3.adoc +++ b/_posts/2023-04-13-rnp-release-0-16-3.adoc @@ -8,13 +8,122 @@ authors: social_links: - https://github.com/ribose-jeffreylau excerpt: >- - Security fixes (CVE-2023-29479, CVE-2023-29480) + Addresses critical security vulnerabilities affecting input validation and + secret key handling --- -This update fixes the following security issues: +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. -- Possible hang on malformed inputs (CVE-2023-29479) -- In some cases, secret keys remain unlocked after use (CVE-2023-29480) +== 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. -The release is available at the https://github.com/rnpgp/rnp/releases/tag/v0.16.3[release page]. +Key highlights: + +* <> (CVE-2023-29479) preventing denial of service +* <> (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 + +[[input-validation]] +== 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. + +[[key-handling]] +=== 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 https://github.com/rnpgp/rnp/releases/tag/v0.16.3[release page]. diff --git a/_posts/2023-05-01-rnp-release-0-17-0.adoc b/_posts/2023-05-01-rnp-release-0-17-0.adoc index 51f1249..ff308d6 100644 --- a/_posts/2023-05-01-rnp-release-0-17-0.adoc +++ b/_posts/2023-05-01-rnp-release-0-17-0.adoc @@ -8,20 +8,235 @@ authors: social_links: - https://github.com/ni4 excerpt: >- - AEAD-OCB support for OpenSSL backend and other features + Implements AEAD-OCB encryption for OpenSSL backend and enhances key management + capabilities with GnuPG 2.3+ compatibility --- -This release adds support for AEAD OCB encryption mode for OpenSSL backend. +RNP 0.17.0 brings significant enhancements to encryption capabilities, key +management, and overall functionality. -== Other fixes and improvements: +This release introduces AEAD-OCB support for the OpenSSL backend, improves +hidden recipient handling, and adds compatibility with newer GnuPG key storage +formats. -* support for hidden recipients -* support for GnuPG 2.3+ key storage format -* FFI function to export key's signature -* improvements in key-related checks -* compile-time options to disable support of Blowfish, CAST5 and RIPEMD160 -* CLI improvements +== Introduction -Since this release, SExp parsing code (required for GnuPG key storage parsing) has been moved to the separate https://github.com/rnpgp/sexp[SExp] library. +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. -The release and full changelog are available at the https://github.com/rnpgp/rnp/releases/tag/v0.17.0[release page]. +Key highlights: + +* <> for improved performance and security +* <