CNSA 2.0 Update Part 2: NIAP
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the second in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
But first, some clarifications on terms and acronyms:
- NIST SP 800-208 National Institute of Standard and Technology Special Publication 800-208 titled: Recommendation for Stateful Hash-Based Signature Schemes
- NIAP: National Information Assurance Partnership: A United States government organization that oversees evaluations of commercial information technology products for use in national security systems
- LMS: Leighton-Micali Signatures; a stateful hash-based signature scheme
- XMSS: eXtended Merkle Signature Scheme; a stateful hash-based signature scheme
- CAVP: The Cryptographic Algorithm Validation Program; provides guidelines for validation testing which is a pre-requisite for CMVP testing
- CMVP: Cryptographic Module Validation Program; security accreditation program for cryptographic modules.
Q: As a commercial vendor, how do I know if my NIST SP 800-208 implementation meets CNSA 2.0?
A: NIAP validates products against its published Protection Profiles, which will start including quantum-resistant signatures in line with our published transition timelines. For commercial vendors, we do not anticipate NIAP Protection Profiles will perform signature generation within the Target of Evaluation (TOE) boundary, only signature verification. As signature generation is the component of LMS/XMSS that requires state management, if only signature verification is being performed, only CAVP validation (not CMVP) will be expected for such products.
Anyone who has been following wolfSSL’s progress with post-quantum algorithms knows we have our own implementations of LMS/HSS and XMSS/XMSS^MT and they are integrated into the wolfBoot product! wolfBoot only uses them to verify the signature of the firmware, therefore one only needs to build these algorithms with verification functionalities. Check out sections 17 and 20 of our wolfSSL INSTALL file.
Requiring only CAVP validation is an excellent bonus for our customers. It means that validation will be a simpler and easier process for our team to help you achieve. You can count on fast turnaround times and little if any paperwork.
Preparing for NIAP and need the best cryptography? If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Check out CNSA 2.0 Update Part 3: LMS and XMSS.
Download wolfSSL Now
CNSA 2.0 Update Part 1: Today
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory. They did it in the form of an FAQ document (list of Frequently Asked Questions with answers). The FAQ document was sent to the PQC Forum. This will be the first in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: Is there a quantum-resistant public-key algorithm that commercial vendors should adopt today?
A: NSA encourages vendors to use CNSA 2.0 approved hash-based signatures for software- and firmware-signing. NSA does not approve using pre-standardized or non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes) for NSS missions. However, NSA does recommend limited use of pre-standardized or non-FIPS-validated CNSA 2.0 algorithms and modules in research settings to prepare for the transition. NSA requests vendors begin preparing to implement CNSA 2.0 algorithms so they are primed to provide products soon after NIST completes standardization.
The NSA has spoken and they expect the industries from which they purchase to provide products that support the CNSA 2.0 Algorithm Suite upon standardization. That means DO NOT start when standardization is complete; start now.
You need to be prepared with these algorithms already integrated into your products. Here at wolfSSL we have been saying the same message for years. You need to prepare for and understand the impacts that the larger keys, cipher text and signatures are going to have on your systems. Will these larger cryptographic artifacts require more memory resources? Will they slow down your transmissions? Will the answer to those questions cascade into new requirements and trade-offs? Now is the time to find those answers. Contact us at support@wolfssl.com for benchmarking details.
If you haven’t already, go ahead and get started today. See Appendix G of our wolfSSL manual. Have further questions about getting started with CNSA 2.0 using wolfSSL, contact us at support@wolfSSL.com.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Check out CNSA 2.0 Update Part 2: NIAP.
Download wolfSSL Now
wolfEngines for OpenSSL in Yocto
What Is wolfEngine?
Recently added to meta-wolfssl, wolfEngine bridges the gap between OpenSSL 1.x and wolfCrypt’s robust cryptographic functionality. This integration allows OpenSSL 1.x consumers to leverage wolfSSL’s FIPS 140-3 algorithms.
Why Choose wolfEngine?
- Seamless Integration: Easily combine OpenSSL 1.x with the cryptographic algorithms of wolfCrypt.
- Enhanced Security: Benefit from advanced, high-performance cryptographic capabilities.
- FIPS-Ready: Smooth path to FIPS 140-3 compliance, making your project future-proof.
Leveraging wolfEngine
wolfEngine allows wolfCrypts FIPS 140-3 cryptography to be seamlessly integrated in your OpenSSL 1.x projects. Take the steps to prepare for FIPS 140-3 certification by using FIPS-Ready wolfSSL with wolfEngine.
Questions?
For further insights into our Standard and Commercial Bundles or if you have any inquiries, feel free to contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Elevate OpenSSL in Yocto with wolfProvider
What Is wolfProvider?
New to meta-wolfssl, wolfProvider marries OpenSSL 3.x with wolfCrypt’s cutting-edge cryptography, empowering Yocto projects to utilize wolfCrypt’s FIPS 140-3 algorithms seamlessly.
Why Choose wolfProvider?
- Effortless Integration: Fuse OpenSSL 3.x with wolfSSL’s algorithms swiftly.
- Superior Security: Access wolfSSL’s lightweight, high-performance cryptography and wide range of supported operating environments.
- FIPS-Ready: Smooth path to FIPS 140-3 compliance, making your project future-proof.
Leveraging wolfProvider
wolfProvider unlocks the potential to incorporate wolfCrypt’s FIPS 140-3 cryptography within your OpenSSL 3.x applications. Kickstart your project now with wolfProvider and our FIPS-Ready bundle, setting the foundation for FIPS 140-3 compliance in your project.
Questions?
If you have questions about any of the above or wish to explore more about FIPS and commercial bundles, contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Join Our Live Webinar: Enhanced Security: SM Ciphers Integrated with wolfSSL
Please join us for our informative webinar titled “Enhanced Security: SM Ciphers Integration with wolfSSL,” scheduled for May 23rd at 2 pm PT. This session, led by wolfSSL Senior Software Engineer Sean Parkinson, will explore the integration of SM Ciphers and their effective employment within the wolfSSL framework. Sean will provide in-depth insights into the ShangMi algorithms, highlighting their benefits and applications in various critical systems.
Watch the webinar here: Enhanced Security: SM Ciphers Integration with wolfSSL
As mandated by Chinese government regulations, the use of SM2, SM3, and SM4 is now required in critical systems such as automobiles, avionics, power systems, and communication networks. In response to these requirements and the needs of our multinational clients operating in China, we have integrated these algorithms into our wolfSSL products. Our latest release supports SM2, SM3, and SM4, and we plan to introduce the ZUC stream cipher later this year to fully comply with SM9 standards. We are also working towards achieving OSCCA certification, enhancing our appeal in the Chinese market.
For those considering wolfSSL for your security needs, here are 6 benefits of our ShangMi ciphers implementation:
- The SM Ciphers are fully supported in wolfSSL’s TLS 1.3 and DTLS 1.3 implementations.
- wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
- ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance
- We support bare metal for SM2, SM3, and SM4.
- We have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
- Our GPLv2 versions of the SM ciphers are available on GitHub and for download.
Commercial licenses are also available.
Don’t miss this opportunity to discover comprehensive security solutions and compliance strategies during our webinar on SM cipher implementations from wolfSSL. Watch now!
As always, the webinar will feature interactive Q&A sessions. If you have any questions about the ShangMi ciphers and algorithms, please contact us at facts@wolfSSL.com, or call us at +1 425 245 8247.
Download wolfSSL Now
Participate Now | curl User Survey 2024
We are excited to announce the opening of the 11th annual curl user survey 2024. As part of our ongoing commitment to enhance your experience and adapt to community needs, we invite all curl and libcurl users to share their invaluable feedback.
This survey serves as the primary channel to connect with url and libcurl users, understanding their views and preferences without any tracking, cookies, or advertisements on our website. Your participation helps us maintain our privacy-focused user feedback tools, ensuring that we respect your digital space while gathering essential insights.
Why Your Feedback Matters
Your feedback is crucial. By dedicating a few minutes of your time to our survey, you not only contribute to our knowledge but directly influence the future development of curl and libcurl. The insight from the curl user survey help us identify trends and understand the broader impact of curl on developers.
Community Insights and Trends
By asking similar questions as in previous years, such as those features in the curl user survey 2023 analysis, we aim to track changes and emerging trends within our community. This consistency allows us to compare data year-over-year and better understand how our tools are being used.
This survey will be available from May14th until the end of May 27th, 2024. We aspire to surpass last year’s participation, where 606 people shared their thoughts. If you know friends or colleagues who use curl or libcurl, encourage them to participate as well. Every response adds value and enhances our community-driven project.
Participate in curl User Survey 2024
We appreciate your continued support and honest opinions. Your feedback not only guides us but is integral to the ongoing success and improvement of curl.
See also:
- Curl user Survey 2023: Discover what we learned from last year and how it’s shaping our plans.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
MQTT v5.0 versus v3.1.1
wolfMQTT was updated to support the draft MQTT v5.0 version of the specification in 2018. The specification was finalized in 2019, and wolfSSL has been a proponent of the new version ever since!
- Enhanced Session Management:
- MQTT v5.0 introduces improved session management, allowing clients to resume sessions seamlessly. This feature ensures continuity and reliability, especially in scenarios where connections may be unstable or intermittent.
- Extended Message Properties:
- Version 5.0 introduces extended message properties. These properties offer richer metadata for messages, enabling more sophisticated message routing, filtering, and processing.
- Payload Format Indicators:
- With MQTT v5.0, publishers can indicate the format of the message payload, providing valuable information to subscribers. This feature enhances interoperability and simplifies message handling, especially in heterogeneous IoT environments.
- Message Expiry Interval:
- MQTT v5.0 allows publishers to specify a message expiry interval, ensuring that messages are delivered within a defined timeframe or discarded if they expire. This capability enhances message reliability and resource efficiency, particularly in constrained IoT networks.
- Request/Response Model:
- Version 5.0 introduces a request/response messaging pattern, enabling clients to make requests and receive responses over MQTT. This feature simplifies communication in IoT applications, facilitating interactions between devices and servers.
- Flow Control Enhancements:
- MQTT v5.0 provides improved flow control mechanisms, including the ability to specify maximum packet size and rate limits. These enhancements help prevent network congestion and improve overall system stability and performance.
- Topic Alias:
- In MQTT v5.0, topic aliasing allows clients to use shorter topic identifiers, reducing bandwidth usage and improving efficiency, especially in scenarios with long or complex topic names.
- Shared Subscriptions:
- Shared subscriptions enable multiple clients to share the processing of messages from a single subscription, distributing the workload efficiently across subscribers. This feature enhances scalability and resource utilization in MQTT v5.0 compared to v3.1.1.
- Support for Binary Data:
- MQTT v5.0 introduces native support for binary data transmission, eliminating the need for encoding and decoding payloads, which simplifies application development and improves performance.
- Authentication Enhancements:
- Version 5.0 offers enhanced authentication mechanisms, including support for more robust authentication methods such as OAuth 2.0. These enhancements bolster security and authentication capabilities, addressing evolving IoT security requirements.
wolfMQTT has excellent examples that demonstrate the capabilities of MQTT v5.0: Property handling callback for incoming messages
During connect:
LWT delay
Request problem info
Max packet size
During subscribe:
During publish:
Payload format indicator
Topic alias
As the MQTT specification continues to evolve, wolfSSL will stay on top of the latest improvements. Want to try out MQTT v5.0? You’ll need a broker that supports MQTT v5.0. You can find a list of brokers that we tested.
You can run the wolfMQTT client examples after building the code from here.
While you’re there, show us some love and give the wolfMQTT project a Star!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL now supported on PlatformIO
The best encryption libraries are now available on the PlatformIO environment!
At wolfSSL, we continue to embrace rapid prototyping environments, including Arduino, Visual Studio, and now PlatformIO for VS Code, among other IDE applications.
There are hundreds of boards supported by PlatformIO on numerous frameworks and platforms.
We are providing two different Official wolfSSL libraries: standard and another specifically for Arduino:
There are also two different versions: the stable release versions (above) and these staging updates, with the latest post-release changes.
The stable release versions will generally follow our standard release cycle. The initial 5.7.0 versions include post stable-release updates needed for the Initial PlatformIO support.
See the PlatformIO documentation for Getting Started with PlatformIO.
For Windows users using pio from command line:
set PATH=%PATH%;C:\Users\%USERNAME%\.platformio\penv\Scripts\ pio --help pio account show
Our initial release has full support for Espressif ESP32 boards, but other boards should work with just a few modifications to the wolfSSL user_settings.h file. See the example configs:
https://github.com/wolfSSL/wolfssl/tree/master/examples/configs
Here’s an example platformio.ini file for the ESP32:
[env:esp32dev] platform = espressif32 board = esp32dev framework = espidf upload_port = COM82 monitor_port = COM82 monitor_speed = 115200 build_flags = -DWOLFSSL_USER_SETTINGS, -DWOLFSSL_ESP32 monitor_filters = direct lib_deps = wolfssl/wolfSSL@^5.7.0-rev.3b
See also: Espressif Systems Leverages PlatformIO Labs Next-Gen Technology for its Software Products.
Is your device working on the PlatformIO environment with wolfSSL? Send us a message and let us help you get started: support@wolfSSL.com or open an issue on GitHub.
Get Started with wolfSSL
Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:
There’s also a must-see 2024 Roadmap to review all the exciting new features:
Find out more
If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub.
Download wolfSSL Now
What is the difference between AES and ECC?
AES (Advanced Encryption Standard) and ECC (Elliptic Curve Cryptography) are both cryptographic algorithms used for securing data, but they operate in different ways and serve different purposes:
AES (Advanced Encryption Standard)
- AES is a symmetric encryption algorithm, meaning the same key is used for both encryption and decryption.
- It operates on blocks of data and is commonly used for encrypting large amounts of data, such as files or entire hard drives.
- AES is widely adopted and considered secure when used with sufficiently long keys (128, 192, or 256 bits).
- Code Size: The code size for implementing AES depends on factors such as the programming language, optimization techniques used, and the desired features (e.g., support for different key lengths).
- In optimized implementations, the core AES algorithm (encryption and decryption) can be relatively compact. Implementations in low-level languages like C or assembly language are often more efficient in terms of code size.
- Additional features such as key expansion, mode of operation (e.g., CBC, ECB), and padding schemes can increase the overall code size.
- Memory Footprint: The memory footprint of AES implementations can vary depending on factors such as the key length, block size, and the specific operations being performed.
- Memory requirements typically include space for storing the encryption/decryption keys, the input plaintext/ciphertext blocks, and intermediate values during computation.
- For embedded systems or devices with limited resources, memory optimization techniques such as minimizing the number of lookup tables or precomputing values can be employed to reduce memory usage
ECC (Elliptic Curve Cryptography)
- ECC is an asymmetric encryption algorithm, meaning it uses a pair of keys: a public key used on one end and a private key used on the other. For example, in signing, the encryption is done with the private key and verification is done with the public key.
- It is based on the mathematics of elliptic curves over finite fields.
- ECC is particularly well-suited for scenarios where computational resources are limited, such as mobile devices or IoT devices, as it offers equivalent security to RSA but with shorter key lengths, resulting in faster computations and less memory usage. That being said, ECC requires larger keys than AES to provide equivalent encryption strength.
- ECC is often used for key exchange protocols like Diffie-Hellman key exchange and in digital signatures.
- Code Size: Implementing ECC requires additional mathematical operations compared to AES, particularly involving elliptic curve arithmetic. However, optimized libraries are available that provide efficient ECC implementations.
- Code size can vary depending on factors such as the choice of elliptic curve parameters, the underlying arithmetic field, and the desired level of optimization.
- Libraries such as WolfSSL or OpenSSL provide ECC functionality and can be integrated into applications with relatively modest code size overhead.
- Memory Footprint: ECC implementations typically require memory for storing various parameters, including public/private keys, intermediate values during computation, and precomputed tables for performance optimization.
- Memory usage depends on factors such as the key size, the chosen elliptic curve, and the specific operations being performed (e.g., key generation, point multiplication).
- ECC implementations optimized for memory-constrained environments often utilize techniques such as point compression to reduce memory usage.
In summary, AES is used for symmetric encryption of large amounts of data, while ECC is used for signing/verification and key exchange, particularly in resource constrained environments.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfCrypt JCE Provider and JNI Wrapper 1.6.0 Now Available
wolfCrypt JNI/JCE 1.6.0 is now available for download!
wolfCrypt JNI/JCE provides Java-based applications with an easy way to use the native wolfCrypt cryptography library. The thin JNI wrapper can be used for direct JNI calls into native wolfCrypt, or the JCE provider (wolfJCE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfCrypt JNI/JCE also supports running on top of wolfCrypt FIPS 140-2 and the upcoming wolfCrypt 140-3 modules for easy conformance to FIPS cryptography requirements in your Java-based application or service.
Release 1.6.0 contains a significant number of bug fixes, changes, and new features to help better support application usage of the Java Security APIs as well as 3rd party Java frameworks that consume JCE providers internally. This release adds new JCE class implementations, new algorithm modes, Windows support, and improves automated testing with GitHub Actions across several Java JDK implementations and versions.
New functionality added in this release is summarized below, but please see ChangeLog.md for a full list that includes all changes and fixes.
New Functionality
New JCE Functionality:
- Add RSA support to KeyPairGenerator class (PR 49)
- Add AES/CBC/PKCS5Padding support to Cipher class (PR 51)
- Add RSA support to Cipher class (PR 51)
- Add PKIX implementation of CertPathValidator class (PR 60, 66)
- Add SHA1 alias for MessageDigest SHA-1 for interop compatibility (PR 61)
- Add AES/GCM/NoPadding support to Cipher class (PR 62)
- Add SecretKeyFactory implementation supporting PBKDF2 (PR 70)
- Add DEFAULT support to SecureRandom class (PR 72)
New JNI Wrapped APIs and Functionality:
- Add AES-GCM support to com.wolfssl.wolfcrypt.AesGcm class (PR 62)
New Platform Support:
- Add Windows support with Visual Studio, see IDE/WIN/README.md (PR 46)
Build System Changes:
- Support custom wolfSSL library prefix and name in makefile.linux (PR 45)
- Standardize JNI library name on OSX to .dylib (PR 54)
- Update Maven build support (PR 55)
Testing Changes:
- Add extended threading test for WolfCryptRandom class (PR 44)
- Add Facebook Infer test script, make fixes (PR 48, 63)
- Add GitHub Actions tests for Oracle/Zulu/Coretto/Temurin/Microsoft JDKs on Linux and OS X (PR 65)
wolfCrypt JNI/JCE 1.6.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. For any questions, or to get help using wolfSSL in your product or projects, contact us at support@wolfSSL.com.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now