RECENT BLOG NEWS

When looking to store your cryptographic secrets, it is important to have a good platform to store them on. Even more important is the ease of accessing and using those secrets.

With wolfTPM, we have support for all TPM 2.0 APIs. Additionally, we provide the following wrappers:

• Key Generation/Loading
• RSA encrypt/decrypt
• ECC sign/verify
• ECDH
• NV storage
• Hashing/HACM
• AES
• Sealing/Unsealing
• Attestation
• PCR Extend/Quote
• Secure Root of Trust

In wolfTPM we already added support for the following platforms:

• Raspberry Pi (Linux)
• MMIO (Memory mapped IO)
• STM32 with CubeMX
• Atmel ASF
• Xilinx (Ultrascale+ / Microblaze)
• QNX
• Infineon TriCore (TC2xx/TC3xx)
• Barebox

These TPM (Trusted Platform Module) 2.0 modules are tested and running in the field:

• STM ST33TP* SPI/I2C
• Infineon OPTIGA SLB9670/SLB9672
• Microchip ATTPM20
• Nations Tech Z32H330TC
• Nuvoton NPCT650/NPCT750

We have our own wolfPKCS11 with support for TPM 2.0 using wolfTPM. We also offer support for PKCS11 to interface to various HSMs like:

• Infineon TriCore Aurix
• Renesas RH850
• ST SPC58

For direct Secure Element access, we have ports in wolfSSL for:

• ST-SAFE
• Microchip ATECC508/608
• Microchip TA100
• NXP SE050

Wolfcrypt has support for the following:

• NXP CAAM (Cryptographic Acceleration and Assurance Module) on i.MX6 (QNX), i.MX8 (QNX/Linux), RT1170 FreeRTOS
• Intel SGX
• ARM TrustZone CryptoCell 310
• MAXQ1065/1080 RNG
• MAX32665 and MAX32666 TPU (Trust Protection Unit)

For more detailed information on our supported hardware take a look at our Hardware Support list.

Wolfcrypt also can make use of PSA (Platform Security Architecture). This includes the following algorithms:

• hashes: SHA-1, SHA-224, SHA-256
• AES: AES-ECB, AES-CBC, AES-CTR, AES-GCM, AES-CCM
• ECDH PK callbacks (P-256)
• ECDSA PK callbacks (P-256)
• RNG

Another product of interest could be wolfBoot, which – as the name suggests – is a bootloader that can use an HSM (Hardware Security Module) for validation and verification. It also provides secure vaults accessible via PKCS#11 API and secured through the ARM TrustZone technology. WolfBoot also supports all of the TPMs and secure elements listed above, as it inherits all of wolfCrypt’s capabilities. WolfBoot can also be combined with wolfTPM to implement measured boot.

If you have questions, please feel free to contact us at facts@wolfSSL.com or +1 425 245 8247, or view our FAQ page.

Download wolfSSL Now

Our very own Tim Pickering was in attendance today when White House officials announced that the standards for post-quantum algorithms were no longer in draft mode. They are now fully empowered as standard algorithms and endorsed by the US Federal Government.

What was standardized today?

• FIPS-203 ML-KEM
• FIPS-204 ML-DSA
• FIPS-205 SLH-DSA

Here at wolfSSL we’ve been anticipating this moment for a very long time. We already have our own implementations of ML-KEM and ML-DSA and have them integrated with several protocols such as TLS 1.3, DTLS 1.3, SSH and MQTT. We have demoed these new algorithms with many open source projects such as cURL, Apache-httpd, nginx, lighttpd, and stunnel.

Read the newly minted standards documents that are linked above for more details. Reach out to us if you’d like more information about our implementations of these new standards!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 424 245 8247.

Download wolfSSL Now

There are many different metrics that can be used when benchmarking cryptography. The common metrics are; average time per operation, average amount of data processed per unit of time, and number of clock cycles taken per data processed.

The first metric of average time per operation, is used with asymmetric key algorithms. These are algorithms that have a public and a private key pair and are doing operations such as signing, verifying, or creating a shared secret key where the input and output data of the operation is a constant size. In wolfSSL, the signature creation and verification operations for RSA and ECC can be benchmarked with the bundled benchmark application using the following command:

`./wolfcrypt/benchmark/benchmark -rsa -ecc`

The last two metrics of average amount of data processed per unit of time (often MB/s, megabytes per second) and number of clock cycles per byte processed are used with symmetric key algorithms. These are algorithms such as AES or ChaCha20 where the key used for encryption should be the same as decryption and the input / output sizes are dependent on the amount of data passed in by the user. When using hardware acceleration created specifically for crypto operations the cycles per byte can even dip below 1. That is – more than one byte of input data processed (encrypted or decrypted) in the time it took for one clock cycle with the CPU! An example of benchmarking AES and ChaCha20 would be the following command:

`./wolfcrypt/benchmark/benchmark -aes-gcm -chacha20`

There are many options available with the wolfSSL benchmark application. All of the options can be seen by using the flag -h `./wolfcrypt/benchmark/benchmark -h`. A couple of the flags that are of note are -base10 and -csv. The flag -base10 uses 1000 bytes as a kilobyte (instead of 1024 which is the default with wolfSSL, aka KiB) and can be used when comparing performance with OpenSSL which defaults to treating 1000 bytes as a kilobyte. Benchmark performance also is very dependent on the hardware that it is run on. The wolfSSL benchmarks page has performance of wolfSSL crypto operations on various hardware platforms.

For questions about setting up wolfSSL to be as fast as possible on your platform, or for inquiries about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

Join us for an insightful live webinar with Daniel Stenberg, the founder and lead developer of curl and libcurl, on August 15th at 10 am PT. Daniel will present “Getting Started with libcurl” for all skill levels.

In this session, Daniel will delve into the core concepts and best practices of libcurl, the widely known client-side URL transfer library. libcurl is recognized for its user-friendliness and support for numerous protocols, including HTTP/3, cookies, DICT, FILE, FTP, and FTPS, ensuring compatibility across almost all platforms.

Register today: Getting Started with libcurl

Here’s a sneak peek of what the webinar will cover:

• Basic knowledge of libcurl
• Best practices for Synchronous Transfer
• Extracting information from transfers, properly receiving and uploading data
• Concurrent transfer methods
• URL parser

Don’t miss this chance to refresh your knowledge or learn new skills directly from the creator of libcurl. Enhance your expertise and strengthen your toolkit with libcurl training! Embark on a rewarding journey with libcurl. Register now!

Duration: 60minutes

As always, our webinars include Q&A sessions. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

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 fifth and final in a series of postings about the questions and answers that we feel are most interesting and our reactions to them.

Q: Can I mitigate the quantum threat by using a pre-shared key?
A: Many commercial protocols allow a pre-shared key option that may mitigate the quantum threat, and some allow the combination of pre-shared and asymmetric keys in the same negotiation. However, this issue can be complex. Customers who wish to explore this option should contact NSA or follow guidance the CSfC program provides.

This is great news for our customers as this means they can enable our PSK (pre-shared key) support in wolfSSL and start their post-quantum journey today! If you’re using Sneakernet (avoiding network transmission) then you’re golden! The knowledge of the pre-shared key takes care of both authentication and key establishment so there is no need for public key cryptography and therefore thwarts Shor’s algorithm.

That said, the NSA is correct, this issue is complicated. Here are just a few points to think about:

• How is the key shared? If it was sent over a data connection that was negotiated with non-quantum-safe algorithms, then this is not considered mitigating the quantum threat.
• How is the key generated? If it was done using an entropy source and/or PRNG (Pseudo-Random Number Generator) that is not approved then you are going to run into problems.
• Do you require PFS (Perfect Forward Secrecy)? Then you might have to think about how you’re going to achieve that very carefully.
• How are you storing and protecting the pre-shared keys? If your efforts to protect it are insufficient then you leave yourself vulnerable to other attack vectors.

Most people are not aware that this can even apply to our wolfBoot product. The signing tool in wolfBoot has a –encrypt SHAREDKEY.BIN flag that allows you to use a pre-shared key to encrypt the firmware image. On the device at boot time, as long as the shared key is stored in a secure manner (ie TPM, secure element) then it can be used to decrypt the firmware image.

Let our experts help you sort out these details. Get started on your journey into a world with quantum computers by downloading wolfSSL now.

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 our CNSA 2.0 Update Blog Series!

• CNSA 2.0 Update Part 1: Today!
• CNSA 2.0 Update Part 2: NIAP
• CNSA 2.0 Update Part 3: LMS and XMSS
• CNSA 2.0 Update Part 4: Deployment

Download wolfSSL Now

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 fourth in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.

Q: When should deployment of CNSA 2.0 algorithms in mission systems begin?
A: When validated products become available they should be deployed in mission systems. Meanwhile, NSA encourages responsible testing in vendor and government research environments now to understand the effects of deployment of the new algorithms on particular systems given the increased sizes used in these algorithms.

Translation: time to “get cracking” and build post-quantum cryptographic implementations you plan to use. You need to understand that while performance for Kyber/ML-KEM won’t be an issue, (see our benchmarks) artifact sizes are increasing!

If you are used to the tiny artifacts in ECDHE then this should be a real eye opener. We’re talking kilobytes going over the wire and taking up memory.

How will this affect you? First of all, if your transmission medium is slow then more bytes going over the wire during the protocol handshake will naturally increase the time to your first application data being sent. Secondly, if your current application is already memory constrained, you might need to re-evaluate how you use your memory or even increase the amount of memory available to your application.

What about your boot loaders that do firmware verification? The best options for quantum-readiness are the stateful hash-based signature schemes LMS and XMSS. Due to the state management requirement, all signing must be done in an HSM to be compliant. Do you already have that infrastructure in place? If not, now is the time to get started thinking about how this requirement is going to affect your processes. For the verification side, have a look at our wolfBoot product!

Considering these things takes time and planning, now is the time to start! Download now.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Catch up on CNSA 2.0 Update Part 1, Part 2 and Part 3! Stay tuned for the final part of the series.

Download wolfSSL Now

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

• NSS: National Security System
• NIST SP 800-208 National Institute of Standard and Technology Special Publication 800-208 titled: Recommendation for Stateful Hash-Based Signature Schemes
• LMS: Leighton-Micali Signatures; a stateful hash-based signature scheme
• HSS: Hierarchical Signature Scheme; the hyper-tree algorithm that is on top of LMS
• XMSS: eXtended Merkle Signature Scheme; a stateful hash-based signature scheme
• XMSS^MT: eXtended Merkle Signature Scheme – Multi-Tree; the hyper-tree algorithm that is on top of XMSS

Q: Can I use HSS or XMSSMT from NIST SP 800-208?
A: From NIST SP 800-208, NSA has only approved LMS and XMSS for use in NSS. The multitree algorithms HSS and XMSSMT are not allowed.

Essentially what this means is that only the actual stateful hash-based signature schemes are approved for usage in NSS. The hyper-tree (colloquially known as “tree of trees”) components specified in NIST SP 800-208 are not approved.

Our implementation supports the hyper-tree components with the actual stateful hash-based signature schemes. More specifically, HSS/LMS and XMSS/XMSS^MT.

It is quite simple to transform an LMS public key into an HSS/LMS public key by putting 4 bytes of zeros in front of the LMS public key. The same is true of the signature.

In addition to the hyper-tree components, we allow for XMSS by supporting the following specifications in our API:

• XMSS-SHA2_10_256
• XMSS-SHA2_16_256
• XMSS-SHA2_20_256

Note the lack of MT.

These algorithms are used in our wolfBoot product for firmware verification and are ready for use today and that’s a good thing as the CNSA 2.0 timeline says you need to be ready now.

Here at wolfSSL we are looking forward to the future of post-quantum algorithms. If you need LMS or XMSS that is performant, capable of running in bare metal or resource constrained environments, have a look at our wolfBoot product.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Check out CNSA 2.0 Update Part 1 and Part 2, and stay tuned for more insights in our upcoming blogs!

Download wolfSSL Now

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? Contact us at support@wolfSSL.com or reach out with any questions at facts@wolfSSL.com or +1 425 245 8247.

Catch up on ‘CNSA 2.0 Updated Part 1: Today!‘ and stay tuned for more insights in our upcoming blogs!

Download wolfSSL Now

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 a multi-part 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.

Note that for software/firmware signing it says you should already have it added and tested in your system! By next year, it should be the default and preferred. This means if you are not using LMS or XMSS in your boot loader then you are out of compliance with the CNSA 2.0 guidance. Checkout wolfBoot where we have already added support for the stateful hash-based signature schemes.

The NSA is also saying 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 the answers to those questions. 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 +1 425 245 8247.

Download wolfSSL Now

In today’s security-conscious world, ensuring that your technology solutions meet stringent compliance standards is more crucial than ever, especially for government buyers. One key compliance standard is FIPS (Federal Information Processing Standards). Join us for an informative webinar where Kaleb Himes, Senior Software Engineer at wolfSSL, will guide you through the essential aspects of determining FIPS compliance.

Watch Today: How to Determine FIPS Compliance for Government Buyers

This webinar will cover:

• Why is FIPS important?
• Why is having a specific OE on the cert important?
• How to lookup a cert and determine if that cert fits your program requirements
• How to detect fake FIPS claims & Red Flags to lookout for
  And more

This webinar is designed for government buyers who need to ensure that their systems meet the rigorous standards of FIPS. Kaleb will provide valuable insights and practical tips to help you navigate the complexities of FIPS compliance, avoid potential pitfalls, and make informed decisions.

Don’t miss this opportunity to enhance your understanding of FIPS compliance and safeguard your systems. Check it out for this exclusive webinar!

As always, our webinar includes Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now