diff --git a/.github/workflows/code-spell.yml b/.github/workflows/code-spell.yml new file mode 100644 index 00000000..d383ee21 --- /dev/null +++ b/.github/workflows/code-spell.yml @@ -0,0 +1,39 @@ +name: Codespell + +on: + push: + branches: [ 'master' ] + pull_request: + branches: [ '*' ] + workflow_dispatch: + +concurrency: + group: ${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: true + +jobs: + codespell: + name: Check for spelling errors + runs-on: ubuntu-22.04 + timeout-minutes: 5 + steps: + - uses: actions/checkout@v4 + + - name: Run codespell + uses: codespell-project/actions-codespell@v2.1 + with: + check_filenames: true + check_hidden: true + # Words below are false positives, not typos: + # TE - FIPS test requirement IDs, e.g. "TE.09.09.02" + # Thi - from the example password "Thi$i$myPa$$w0rd" + # regist - parameter name in wolfMQTT (SN_Register *regist) + # Writen - Writen() wrapper from "Unix Network Programming" + # Challener - author name (Challener D., A Practical Guide to TPM 2.0) + # cant - verbatim wolfSSL error string "cant decode peer key" + # mot - Renesas skmt.exe -filetype "mot" (Motorola S-record) + # callin - verbatim wolfSentry example output + # Incomming - verbatim lwIP echoserver example output + # psuedo - verbatim wolfSSH client --help output + ignore_words_list: TE,Thi,inter-operability,regist,Writen,Challener,cant,mot,callin,Incomming,psuedo + skip: '.git' diff --git a/wolfBoot/src-ja/appendix12.md b/wolfBoot/src-ja/appendix12.md index 4b44754a..6b066c3b 100644 --- a/wolfBoot/src-ja/appendix12.md +++ b/wolfBoot/src-ja/appendix12.md @@ -42,7 +42,7 @@ OPTION BYTES BANK: 0 nRST_STOP : 0x1 (No reset generated when entering Stop mode) nRST_STDBY : 0x1 (No reset generated when entering Standby mode) nRST_SHDW : 0x1 (No reset generated when entering the Shutdown mode) - IWDG_SW : 0x1 (Software independant watchdog) + IWDG_SW : 0x1 (Software independent watchdog) IWDG_STOP : 0x1 (IWDG counter active in stop mode) IWDG_STDBY : 0x1 (IWDG counter active in standby mode) WWDG_SW : 0x1 (Software window watchdog) diff --git a/wolfBoot/src/appendix12.md b/wolfBoot/src/appendix12.md index d3575395..9d6924b1 100644 --- a/wolfBoot/src/appendix12.md +++ b/wolfBoot/src/appendix12.md @@ -53,7 +53,7 @@ OPTION BYTES BANK: 0 nRST_STOP : 0x1 (No reset generated when entering Stop mode) nRST_STDBY : 0x1 (No reset generated when entering Standby mode) nRST_SHDW : 0x1 (No reset generated when entering the Shutdown mode) - IWDG_SW : 0x1 (Software independant watchdog) + IWDG_SW : 0x1 (Software independent watchdog) IWDG_STOP : 0x1 (IWDG counter active in stop mode) IWDG_STDBY : 0x1 (IWDG counter active in standby mode) WWDG_SW : 0x1 (Software window watchdog) diff --git a/wolfBoot/src/chapter02.md b/wolfBoot/src/chapter02.md index 3f3557f6..ad3292aa 100644 --- a/wolfBoot/src/chapter02.md +++ b/wolfBoot/src/chapter02.md @@ -54,7 +54,7 @@ This is the start address of the update partition. If an external memory is used - `WOLFBOOT_PARTITION_SWAP_ADDRESS` -The address for the swap spaced used by wolfBoot to swap the two firmware images in place, in order to perform a reversable update. The size of the SWAP partition is exactly one sector on the flash. If an external memory is used, the variable contains the offset of the SWAP area from the beginning of its addressable space. +The address for the swap spaced used by wolfBoot to swap the two firmware images in place, in order to perform a reversible update. The size of the SWAP partition is exactly one sector on the flash. If an external memory is used, the variable contains the offset of the SWAP area from the beginning of its addressable space. - `WOLFBOOT_PARTITION_SIZE` diff --git a/wolfBoot/src/chapter03.md b/wolfBoot/src/chapter03.md index 1e8a4455..0859c9c8 100644 --- a/wolfBoot/src/chapter03.md +++ b/wolfBoot/src/chapter03.md @@ -1507,7 +1507,7 @@ c Supports K64 and K82 with crypto hardware acceleration. -### Buld options +### Build options See `/config/examples/kinetis-k82f.config` for example configuration. @@ -2133,7 +2133,7 @@ Default Onboard Flash Memory Layout (2MB) (32KB sector): | wolfBoot | 0xFFFF0000 | 0x00010000 ( 64 KB) | -### Renesas Data Endianess +### Renesas Data Endianness To switch RX parts to big endian data use: @@ -2184,7 +2184,7 @@ rfp-cli -if fine -t e2l -device RX65x -auto -auth id FFFFFFFFFFFFFFFFFFFFFFFFFFF -run ``` -Note: Endianess: if using big endian add `-endian big` +Note: Endianness: if using big endian add `-endian big` Note: Linux Install E2 Lite USB Driver: @@ -2195,7 +2195,7 @@ sudo udevadm control --reload-rules ### Debugging Renesas RX65N -Create a new "Renesas Debug" project. Choose the "E2 Lite" emulator and the built `wolfboot.elf`. After project is created open the "Debug Configuration" and change the debugger interface from "JTAG" to "FINE". Run debug and it will stop in the "reset" code in `boot_renesas_start.S`. If using Big Endian change endianess mode in "Debugger -> Debug Tool Settings -> Memory Endian -> Big Endian". +Create a new "Renesas Debug" project. Choose the "E2 Lite" emulator and the built `wolfboot.elf`. After project is created open the "Debug Configuration" and change the debugger interface from "JTAG" to "FINE". Run debug and it will stop in the "reset" code in `boot_renesas_start.S`. If using Big Endian change endianness mode in "Debugger -> Debug Tool Settings -> Memory Endian -> Big Endian". ## Renesas RX72N @@ -2298,7 +2298,7 @@ rfp-cli -if fine -t e2l -device RX72x -auto -auth id FFFFFFFFFFFFFFFFFFFFFFFFFFF -run ``` -Note: Endianess: if using big endian add `-endian big` +Note: Endianness: if using big endian add `-endian big` Note: Linux Install E2 Lite USB Driver: diff --git a/wolfBoot/src/chapter06.md b/wolfBoot/src/chapter06.md index 85baf871..488ddb44 100644 --- a/wolfBoot/src/chapter06.md +++ b/wolfBoot/src/chapter06.md @@ -319,9 +319,9 @@ wolfBoot can interact with TPM2.0 chips thanks to its integration with wolfTPM. ### Concept -Typically, systems use Secure Boot to guarantee that the correct and geniune firmware is booted by verifying its signature. Afterwards, this knowledge is unknown to the sytem. The application does not know if the system started in a good known state. Sometimes, this guarantee is needed by the firmware itself. To provide such mechanism the concept of Measured Boot exist. +Typically, systems use Secure Boot to guarantee that the correct and genuine firmware is booted by verifying its signature. Afterwards, this knowledge is unknown to the system. The application does not know if the system started in a good known state. Sometimes, this guarantee is needed by the firmware itself. To provide such mechanism the concept of Measured Boot exist. -Measured Boot can be used to check every start-up component, including settings and user information(user partition). The result of the checks is then stored into special registers called PCR. This process is called PCR Extend and is refered to as a TPM measurement. PCR registers can be reset only on TPM power-on. +Measured Boot can be used to check every start-up component, including settings and user information(user partition). The result of the checks is then stored into special registers called PCR. This process is called PCR Extend and is referred to as a TPM measurement. PCR registers can be reset only on TPM power-on. Having TPM measurements provide a way for the firmware or Operating System(OS), like Windows or Linux, to know that the software loaded before it gained control over system, is trustworthy and not modified. @@ -356,7 +356,7 @@ Any TPM has a minimum of 24 PCR registers. Their typical use is as follows: Recommendations for choosing a PCR index: -- During development it is recommended to use PCR16 that is intented for testing. +- During development it is recommended to use PCR16 that is intended for testing. - In production, if you are running a bare-metal firmware or RTOS, you could use almost all PCRs(PCR0-15), except the one for DRTM and Trusted OS(PCR17-23). - If you are running Linux or Windows, PCR12-15 can be chosen for production ready firmware, in order to avoid conflict with other software that might be using PCRs from within Linux, like the Linux IMA or Microsoft Bitlocker. @@ -538,7 +538,7 @@ The tool also adds all the required Tags to the image header, containing the sig wolfBoot can update itself if `RAM_CODE` is set. This procedure operates almost the same as firmware update with a few key differences. The header of the update is marked as a bootloader update (use `--wolfboot-update` for the sign tools). -The new signed wolfBoot image is loaded into the UPDATE parition and triggered the same as a firmware update. Instead of performing a swap, after the image is validated and signature verified, the bootloader is erased and the new image is written to flash. This operation is _not_ safe from interruption. Interruption will prevent the device from rebooting. +The new signed wolfBoot image is loaded into the UPDATE partition and triggered the same as a firmware update. Instead of performing a swap, after the image is validated and signature verified, the bootloader is erased and the new image is written to flash. This operation is _not_ safe from interruption. Interruption will prevent the device from rebooting. wolfBoot can be used to deploy new bootloader versions as well as update keys. @@ -657,7 +657,7 @@ Encryption of external partition works at the level of the external flash interf All write calls to external partitions from the bootloader perform an additional encryption step to hide the actual content of the external non-volatile memory. -Viceversa, all read operations will decrypt the data stored when the feature is enabled. +Vice versa, all read operations will decrypt the data stored when the feature is enabled. An extra option is provided to the `sign` tool to encrypt the firmware update after signing it, so that it can be stored as is in the external memory by the application, and will be decrypted by the bootloader diff --git a/wolfCLU/src/build.md b/wolfCLU/src/build.md index c90bfd4c..d9ed26d7 100644 --- a/wolfCLU/src/build.md +++ b/wolfCLU/src/build.md @@ -14,7 +14,7 @@ sudo make install Note that if parsing PKCS12 files with RC2 or if using CRL the flags --enable-rc2 and --enable-crl would also need to be used when building wolfSSL. -Then build wolfCLU linking agianst the wolfSSL library created. +Then build wolfCLU linking against the wolfSSL library created. ``` cd wolfclu diff --git a/wolfEngine/mkdocs.yml b/wolfEngine/mkdocs.yml index 0ecc3bd6..3940e9c7 100644 --- a/wolfEngine/mkdocs.yml +++ b/wolfEngine/mkdocs.yml @@ -5,7 +5,7 @@ site_dir: html/ copyright: Copyright © 2022 wolfSSL Inc. nav: - "1. Introduction": index.md - - "2. OpenSSL Version Compatability": chapter02.md + - "2. OpenSSL Version Compatibility": chapter02.md - "3. Building wolfEngine": chapter03.md - "4. FIPS 140-2 Support": chapter04.md - "5. Engine Control Commands": chapter05.md diff --git a/wolfEngine/src/chapter02.md b/wolfEngine/src/chapter02.md index b04fbcfb..ccedc368 100644 --- a/wolfEngine/src/chapter02.md +++ b/wolfEngine/src/chapter02.md @@ -1,4 +1,4 @@ -# OpenSSL Version Compatability +# OpenSSL Version Compatibility wolfEngine has been tested against the following versions of OpenSSL. wolfEngine may work with other versions, but may require some modification or adjustment: diff --git a/wolfHSM/Doxyfile b/wolfHSM/Doxyfile index 8fbb5889..1b4a100a 100644 --- a/wolfHSM/Doxyfile +++ b/wolfHSM/Doxyfile @@ -794,7 +794,7 @@ CITE_BIB_FILES = # messages are off. # The default value is: NO. -# TODO set to YES for upsteaming +# TODO set to YES for upstreaming QUIET = NO # The WARNINGS tag can be used to turn on/off the warning messages that are diff --git a/wolfMQTT/Doxyfile b/wolfMQTT/Doxyfile index a74bd285..f198e499 100644 --- a/wolfMQTT/Doxyfile +++ b/wolfMQTT/Doxyfile @@ -794,7 +794,7 @@ CITE_BIB_FILES = # messages are off. # The default value is: NO. -# TODO set to YES for upsteaming +# TODO set to YES for upstreaming QUIET = NO # The WARNINGS tag can be used to turn on/off the warning messages that are diff --git a/wolfMQTT/Doxyfile-ja b/wolfMQTT/Doxyfile-ja index 57a080d7..15fc40b1 100644 --- a/wolfMQTT/Doxyfile-ja +++ b/wolfMQTT/Doxyfile-ja @@ -794,7 +794,7 @@ CITE_BIB_FILES = # messages are off. # The default value is: NO. -# TODO set to YES for upsteaming +# TODO set to YES for upstreaming QUIET = NO # The WARNINGS tag can be used to turn on/off the warning messages that are diff --git a/wolfProvider/mkdocs.yml b/wolfProvider/mkdocs.yml index b2813886..340dff62 100644 --- a/wolfProvider/mkdocs.yml +++ b/wolfProvider/mkdocs.yml @@ -5,7 +5,7 @@ site_dir: html/ copyright: Copyright © 2024 wolfSSL Inc. nav: - "1. Introduction": index.md - - "2. OpenSSL Version Compatability": chapter02.md + - "2. OpenSSL Version Compatibility": chapter02.md - "3. Building wolfProvider": chapter03.md - "4. FIPS 140-3 Support": chapter04.md - "5. Logging": chapter05.md diff --git a/wolfProvider/src/chapter02.md b/wolfProvider/src/chapter02.md index 1ccf8355..57694745 100644 --- a/wolfProvider/src/chapter02.md +++ b/wolfProvider/src/chapter02.md @@ -1,4 +1,4 @@ -# OpenSSL Version Compatability +# OpenSSL Version Compatibility wolfProvider has been tested against the following versions of OpenSSL. wolfProvider may work with other versions, but may require some modification or adjustment: diff --git a/wolfSSH/src/chapter06.md b/wolfSSH/src/chapter06.md index 60015cb9..67598fbe 100644 --- a/wolfSSH/src/chapter06.md +++ b/wolfSSH/src/chapter06.md @@ -40,7 +40,7 @@ The example echo server implements the authentication callback with sample users ``` wolfSSH_SetUserAuth(ctx, wsUserAuth); ``` -The example password file (passwd.txt) is a simple list of usernames and passwords seperated with a colon respectively. The defaults that exist within this file are as follows. +The example password file (passwd.txt) is a simple list of usernames and passwords separated with a colon respectively. The defaults that exist within this file are as follows. ``` jill:upthehill diff --git a/wolfSSH/src/chapter14.md b/wolfSSH/src/chapter14.md index 0b0794d9..7050e5be 100644 --- a/wolfSSH/src/chapter14.md +++ b/wolfSSH/src/chapter14.md @@ -81,7 +81,7 @@ int wolfSSH_SFTP_connect(WOLFSSH* ssh ); WOLFSSH* ssh; ``` ``` -//after creating a new WOLFSSH structrue +//after creating a new WOLFSSH structure ``` ``` wolfSSH_SFTP_connect(ssh); diff --git a/wolfSSL-FIPS-FAQ/src/section01.md b/wolfSSL-FIPS-FAQ/src/section01.md index d7bf4ba2..4053dd4e 100644 --- a/wolfSSL-FIPS-FAQ/src/section01.md +++ b/wolfSSL-FIPS-FAQ/src/section01.md @@ -1,6 +1,6 @@ # Introduction -This page lists some of the most common issues and questions that are recieved by our wolfSSL security experts, along with their responses. This FAQ is useful for solving general questions that pertain to building/implementing wolfSSL FIPS. If this page does not provide an answer to your question, please feel free to check the wolfSSL Manual, or contact us at support@wolfssl.com. +This page lists some of the most common issues and questions that are received by our wolfSSL security experts, along with their responses. This FAQ is useful for solving general questions that pertain to building/implementing wolfSSL FIPS. If this page does not provide an answer to your question, please feel free to check the wolfSSL Manual, or contact us at support@wolfssl.com. Last Updated: 30 Mar 2026 @@ -15,7 +15,7 @@ Last Updated: 30 Mar 2026 4. [Followup Post Q: What about with fips-ready, can I use NO_ATTRIBUTE_CONSTRUCTOR with fips-ready?](./section02.md#does-the-power-on-self-test-post-really-have-to-run-every-time) 4. [What can go wrong for the end user after basic testing?](./section02.md#what-can-go-wrong-for-the-end-user-after-basic-testing) 5. [Moving from 140-2 to 140-3, what's new?](./section02.md#moving-from-140-2-to-140-3-whats-new) - 1. [Will my applications that are linked agaist the 140-2 module still work with the 140-3 module?](./section02.md#will-my-app-for-1402-still-work-with-1403) + 1. [Will my applications that are linked against the 140-2 module still work with the 140-3 module?](./section02.md#will-my-app-for-1402-still-work-with-1403) 2. [The wc_SetSeed_Cb() callback and the TLS Layer:](./section02.md#wc-setseed-and-tls) 3. [The wc_SetSeed_Cb() callback and a custom seed generation function:](./section02.md#wc-setseed-and-custom-genseed) 4. [The POST](./section02.md#the-post) diff --git a/wolfSSL-FIPS-FAQ/src/section02.md b/wolfSSL-FIPS-FAQ/src/section02.md index 75def2f3..8655a06a 100644 --- a/wolfSSL-FIPS-FAQ/src/section02.md +++ b/wolfSSL-FIPS-FAQ/src/section02.md @@ -4,7 +4,7 @@ Example: I received wolfssl-4.8.1-commercial-fips-ARMv8-A-v2 but the validation was for version 4.5.4, why did I receive a 4.8.1 release? -A: The version validated (IE 4.5.4 from the exmaple) applies to the wolfCrypt module ONLY. It was loosely based off the wolfSSL library version at the time of validattion however the wolfSSL version will continue to update as enhancements and fixes are applied in subsequent releases. You will alwasy receive the latest release with the proper wolfCrypt module (v4.5.4 in the exam-ple) inside even though the wolfSSL version (4.8.1 in the example_ continues to update over time! If you have any questions on this, contact us at fips@wolfssl.com or support@wolfssl.com +A: The version validated (IE 4.5.4 from the example) applies to the wolfCrypt module ONLY. It was loosely based off the wolfSSL library version at the time of validattion however the wolfSSL version will continue to update as enhancements and fixes are applied in subsequent releases. You will always receive the latest release with the proper wolfCrypt module (v4.5.4 in the exam-ple) inside even though the wolfSSL version (4.8.1 in the example_ continues to update over time! If you have any questions on this, contact us at fips@wolfssl.com or support@wolfssl.com ## How do I know if I am using the FIPS module? @@ -46,7 +46,7 @@ from [https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Module-Validation- A: It exists for two select exception cases: -1. The first exception is when an operating system would perform a memory zero during an application start that would erase the POST result (pass/fail) and therefore the POST must be called AFTER the memory zero. To remain FIPS compliant the call must be proven to the CMVP to be not optional and not require operator intervention to trigger (has to be called by the OS before control is returnd to the user-space app or kernel module). +1. The first exception is when an operating system would perform a memory zero during an application start that would erase the POST result (pass/fail) and therefore the POST must be called AFTER the memory zero. To remain FIPS compliant the call must be proven to the CMVP to be not optional and not require operator intervention to trigger (has to be called by the OS before control is returned to the user-space app or kernel module). 2. The second exception is when an entropy source can not be made available to the attribute constructor. In this case the RNG has to be initialized first and then the call to fipsEntry() made. Again the call must be proven to the CMVP to be not optional requiring no operator intervention to trigger (has to be called by the OS before control is returned to the user-space app or kernel module). @@ -54,7 +54,7 @@ A: It exists for two select exception cases: A: Only wolfSSL staff in collaboration with an NVLAP accredited FIPS lab during an OE operational testing effort can determine the viability of the feature NO_ATTRIBUTE_CONSTRUCTOR. If the feature is warranted for a specific operating environment: -1. It will be noted in the FIPS user guide section for that operating environement +1. It will be noted in the FIPS user guide section for that operating environment 2. The bundle releases the customer receives from wolfSSL will build cleanly with the feature enabled (no compile time error) @@ -62,7 +62,7 @@ A: Only wolfSSL staff in collaboration with an NVLAP accredited FIPS lab during ### Followup Post Q: What about with fips-ready, can I use NO_ATTRIBUTE_CONSTRUCTOR with fips-ready? -A: The term "fips-ready' implies a module is abiding by ALL the FIPS requirements such that it could be submitted to the CMVP without any changes and achieve FIPS certification. Using the feature NO_ATTRIBUTE_CONSTRUCTOR without wolfSSL staff and an NVLAP accredited FIPS lab approving it for that operating environement would imply the fips-ready solution is no longer a fips-ready release, that release would no longer be considered "fips-ready" until reviewed by wolfSSL staff in collaboration with an NVLAP accredited FIPS lab. +A: The term "fips-ready' implies a module is abiding by ALL the FIPS requirements such that it could be submitted to the CMVP without any changes and achieve FIPS certification. Using the feature NO_ATTRIBUTE_CONSTRUCTOR without wolfSSL staff and an NVLAP accredited FIPS lab approving it for that operating environment would imply the fips-ready solution is no longer a fips-ready release, that release would no longer be considered "fips-ready" until reviewed by wolfSSL staff in collaboration with an NVLAP accredited FIPS lab. ## What can go wrong for the end user after basic testing? @@ -82,7 +82,7 @@ A: (Multi-part) 5. Windows: Randomized base addressing in Windows OS. Because the function addresses are included in the integrity check, the module needs to load at the same location in memory each time. There are 2 factors to this one: - 1. Must diable Random base address at the project level. Example: [https://github.com/wolfSSL/wolfssl/blob/master/IDE/WIN10/wolfssl-fips.vcxproj#L159](https://github.com/wolfSSL/wolfssl/blob/master/IDE/WIN10/wolfssl-fips.vcxproj#L159) + 1. Must disable Random base address at the project level. Example: [https://github.com/wolfSSL/wolfssl/blob/master/IDE/WIN10/wolfssl-fips.vcxproj#L159](https://github.com/wolfSSL/wolfssl/blob/master/IDE/WIN10/wolfssl-fips.vcxproj#L159) 2. Must assign a physical fixed address (and this is KEY!!) that is NOT in contention with any other DLL on the system. Example: [https://github.com/wolfSSL/wolfssl/blob/master/IDE/WIN10/wolfssl-fips.vcxproj#L158](https://github.com/wolfSSL/wolfssl/blob/master/IDE/WIN10/wolfssl-fips.vcxproj#L158) @@ -119,7 +119,7 @@ wolfCrypt_SetCb_fips(myFipsCb); 2. wolfSSL Inc also wanted an option available should one wish to call one of the ESV validated entropy sources so a callback option made sense. -## Will my applications that are linked agaist the 140-2 module still work with the 140-3 module? +## Will my applications that are linked against the 140-2 module still work with the 140-3 module? A: Absolutely! wolfCrypt FIPS modules v2.x (cert #3389, 140-2 module) has 100% API compatibility minus the 3DES services with wolfCrypt FIPS module v5.2.1 (cert #4718, 140-3 module). In addition to the 140-2 APIs, there are new services (TLS KDFs, AES-OFB, etc) and newer extended APIs. For a full list of new services and new API definitions supported by the 140-3 module please refer to the FIPS 140-3 User Guide [UG] which includes an exhaustive list of every FIPS service and correlated API + description(s). If you need a copy of the [UG] please let the wolfSSL team know by emailing support@wolfssl.com requesting a copy of the FIPS [UG]. @@ -312,7 +312,7 @@ PRIVATE_KEY_LOCK() ; ``` The key access can optionally be unlocked\* only once on startup and locked again prior to shutdown\*\* or... If the application wishes to be very strict, these can be called immediately before and after each call that involves a private key load or use. -\*Be aware that LOCK and UNLOCK are **thread-local**. Aas this is a semaphore, each UNLOCK must be paired with a corresponding LOCK at the same scope to properly decrement the lock count. Alternatively doing a "true lock" (example provided below) may be the best approach for proper lock management. +\*Be aware that LOCK and UNLOCK are **thread-local**. As this is a semaphore, each UNLOCK must be paired with a corresponding LOCK at the same scope to properly decrement the lock count. Alternatively doing a "true lock" (example provided below) may be the best approach for proper lock management. \*\* "application ***shall*** lock again before terminating" - This is a documentation requirement, this is not enforced at run-time by any error or prevention from exiting. Failing to re-lock key access before exiting makes the application "not FIPS compliant" however. diff --git a/wolfSSL-FIPS-Ready/src-ja/section01.md b/wolfSSL-FIPS-Ready/src-ja/section01.md index fcda053b..8fe3c783 100644 --- a/wolfSSL-FIPS-Ready/src-ja/section01.md +++ b/wolfSSL-FIPS-Ready/src-ja/section01.md @@ -10,7 +10,7 @@ FIPSは複雑なトピックです。このドキュメントをご覧いただ wolfCrypt FIPS APIは、FIPS環境内に存在するすべてのアルゴリズム関数のラッパーを提供します。FIPS APIをご利用にならず、非FIPS版にも存在するAPIを用いてコードを記述いただくことも可能です。いずれの場合でも、コンパイル時に自動的にwolfCrypt FIPS APIに置換します。FIPS APIは、実際の関数を呼び出す前に内部ステータスのセルフテストを行います。そして各アルゴリズムの初回実行時にCASTが実行します。このようなタイミングでの実行を避けたい場合は、起動時に予め各テストを実行することも可能です。 -wolfCrypt FIPS 140-3 Ready版のコードには、メモリ内の実行可能ファイルの整合性を自動的にチェックする必須の電源投入時自己テスト (POST) が含まれています。これにはアルゴリズムのKnown Answere Tests (KAT) が含まれており、140-2 以降変更しておりません。 POST で使用しないものは、使用が条件付きになりました。実行可能ファイルは、FIPS環境内のコードがメモリ内で隣接するように設計しています。FIPSコードを使用するアプリケーションが起動するか、共有ライブラリがロードされると、ライブラリのデフォルトエントリーポイントを呼び出し、POSTを自動的に実行します。これには、コア内のメモリチェックとPOSTで使用するアルゴリズム(HMAC-SHA256)のためのKATの2つが含まれます。 +wolfCrypt FIPS 140-3 Ready版のコードには、メモリ内の実行可能ファイルの整合性を自動的にチェックする必須の電源投入時自己テスト (POST) が含まれています。これにはアルゴリズムのKnown Answer Tests (KAT) が含まれており、140-2 以降変更しておりません。 POST で使用しないものは、使用が条件付きになりました。実行可能ファイルは、FIPS環境内のコードがメモリ内で隣接するように設計しています。FIPSコードを使用するアプリケーションが起動するか、共有ライブラリがロードされると、ライブラリのデフォルトエントリーポイントを呼び出し、POSTを自動的に実行します。これには、コア内のメモリチェックとPOSTで使用するアルゴリズム(HMAC-SHA256)のためのKATの2つが含まれます。 まずHMAC-SHA256のPOSTを実行し、次いでコア内メモリテストを実行します。メモリ内のコードはHMAC-SHA256でハッシュを取り、一致した場合のみテストを続行します。一致しなければFIPSモジュールはエラー状態となり、整合性が取れるまですべての呼び出しは成功しません。 diff --git a/wolfSSL-FIPS-Ready/src/section01.md b/wolfSSL-FIPS-Ready/src/section01.md index bf27baf2..83fd7e1c 100644 --- a/wolfSSL-FIPS-Ready/src/section01.md +++ b/wolfSSL-FIPS-Ready/src/section01.md @@ -32,7 +32,7 @@ is swapped by the headers so that the FIPS wrappers will be called either way. The FIPS wrapper functions check the status of the internal self-testing before calling the actual function. If the CAST for that specific algorithm has not been run at least one time previously it will run the first time the algorithm -is used. Users now have the option to either pre-emptively test algorithms at +is used. Users now have the option to either preemptively test algorithms at start up if they wish to avoid the test running at a later time or they can just let the test run when the algorithm is used. diff --git a/wolfSSL-JNI/src/chapter03.md b/wolfSSL-JNI/src/chapter03.md index 5013bf15..d061c297 100644 --- a/wolfSSL-JNI/src/chapter03.md +++ b/wolfSSL-JNI/src/chapter03.md @@ -192,7 +192,7 @@ The project looks for the directory This can added in multiple ways: - OPTION A: Download the latest wolfSSL library release from www.wolfssl.com, -unzip it, rename it to `wolfssl`, and place it in the direcotry +unzip it, rename it to `wolfssl`, and place it in the directory `wolfssljni/IDE/Android/app/src/main/cpp/`. ``` @@ -251,7 +251,7 @@ cd examples/provider ./convert-to-bks.sh ``` -For exmaple, when using bcprov-ext-jdk15on-169.jar: +For example, when using bcprov-ext-jdk15on-169.jar: ``` cd examples/provider diff --git a/wolfSSL/src/appendix05.md b/wolfSSL/src/appendix05.md index ea026672..741f25bb 100644 --- a/wolfSSL/src/appendix05.md +++ b/wolfSSL/src/appendix05.md @@ -21,7 +21,7 @@ * Block Cipher Information - [Wikipedia](https://en.wikipedia.org/wiki/Block_cipher) * AES - [NIST Publication](https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf) [Wikipedia](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) * AES-GCM - [NIST Specification](https://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf) -* AES-NI - [Intel Sofware Network](https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/) +* AES-NI - [Intel Software Network](https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/) * DES/3DES - [NIST Publication](https://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf) [Wikipedia](https://en.wikipedia.org/wiki/Data_Encryption_Standard) ## Hashing Functions diff --git a/wolfSSL/src/appendix09.md b/wolfSSL/src/appendix09.md index 3f510fde..3b68ac43 100644 --- a/wolfSSL/src/appendix09.md +++ b/wolfSSL/src/appendix09.md @@ -1,6 +1,6 @@ # Experimenting with Post-Quantum Cryptography -A while back, the wolfSSL team integrated experimental post-quantum cryptographic algorithms into the wolfSSL library. This was done by integrating with the Open Quantum Safe team's liboqs. Currently, wolfCrypt implements LMS, XMSS, ML-DSA and ML-KEM. So, for the purpose of code size reduction and ease of maintence, the wolfSSL team removed the integration with liboqs. +A while back, the wolfSSL team integrated experimental post-quantum cryptographic algorithms into the wolfSSL library. This was done by integrating with the Open Quantum Safe team's liboqs. Currently, wolfCrypt implements LMS, XMSS, ML-DSA and ML-KEM. So, for the purpose of code size reduction and ease of maintenance, the wolfSSL team removed the integration with liboqs. This appendix is intended for anyone that wants to start learning about post-quantum cryptography in the context of (D)TLS 1.3. It explains why post-quantum algorithms are important, what we have done in response to the quantum threat and how you can start experimenting with these new algorithms. @@ -47,7 +47,7 @@ These use different kinds of math from the conventional algorithms. They are des as NIST is not considering them for standardization. **Note**: When the liboqs integration was removed, we also removed the FALCON - and SPHINCS+ signature schemes. We will have our own implmentations + and SPHINCS+ signature schemes. We will have our own implementations in the future. An explanation of lattice-based cryptography would fall outside the scope of this document but more information about these algorithms can be found in their NIST submissions at . diff --git a/wolfSSL/src/chapter02.md b/wolfSSL/src/chapter02.md index 95376388..7923438a 100644 --- a/wolfSSL/src/chapter02.md +++ b/wolfSSL/src/chapter02.md @@ -61,7 +61,7 @@ Alternatively you can use autoconf to run the testsuite as well as the standard make test ``` -Further details about expected output of the testsuite program can be found in the [Testsuite section](chapter03.md#testsuite). If you want to build only the wolfSSL library and not the additional items (examples, testsuite, benchmark app, etc.), you can run the following command fromthe wolfSSL root directory: +Further details about expected output of the testsuite program can be found in the [Testsuite section](chapter03.md#testsuite). If you want to build only the wolfSSL library and not the additional items (examples, testsuite, benchmark app, etc.), you can run the following command from the wolfSSL root directory: ```sh make src/libwolfssl.la @@ -630,7 +630,7 @@ Used for AES key size selection at compile time. #### NO_AESGCM_AEAD -Used for disabliing TLS cipher suites thst use AES GCM. It is used internally when no AES GCM cipher suites are enabled, but can also be used to limit cipher suites. +Used for disabliing TLS cipher suites that use AES GCM. It is used internally when no AES GCM cipher suites are enabled, but can also be used to limit cipher suites. #### NO_ASN_TIME @@ -928,7 +928,7 @@ Disables TLS client authentication support for ED25519. It is used to reduce mem #### NO_ED448_CLIENT_AUTH -Disables client authentification for ED448. +Disables client authentication for ED448. #### NO_FORCE_SCR_SAME_SUITE @@ -980,7 +980,7 @@ This applies to TLS 1.3 only. It allows SHA2-256 to be enabled and usable from w #### WOLFSSL_BLIND_PRIVATE_KEY -Used as a mask to blind the private key. The blinding is used to proctect aginst Rowhammer attacks. +Used as a mask to blind the private key. The blinding is used to protect against Rowhammer attacks. #### WOLFSSL_DTLS13_NO_HRR_ON_RESUME @@ -1029,7 +1029,7 @@ Disables session ticket expiration checking. Session tickets will be accepted re #### WOLFSSL_NO_TLS12 -Define to exlude TLS 1.2. +Define to exclude TLS 1.2. #### WOLFSSL_PEM_TO_DER @@ -1591,7 +1591,7 @@ Define for internal testing to induce random malloc failures. #### WOLFSSL_POST_HANDSHAKE_AUTH -TLS extension, Used for post-handshake authentification. +TLS extension, Used for post-handshake authentication. #### WOLFSSL_PSK_MULTI_ID_PER_CS @@ -3204,7 +3204,7 @@ Compiles in a faster mod_exp implementation at the expense of code size. #### WC_DISABLE_RADIX_ZERO_PAD -Disable printing of leading zero in hexidecimal string output. For example, if this macro is defined, the value 8 will be printed as the string "0x8" but if it is not defined it will be printed as "0x08". Defining this macro can reduce code size. +Disable printing of leading zero in hexadecimal string output. For example, if this macro is defined, the value 8 will be printed as the string "0x8" but if it is not defined it will be printed as "0x08". Defining this macro can reduce code size. #### WC_ASN_NAME_MAX @@ -3569,7 +3569,7 @@ Enables "non blocking" mode for Single Precision math, which will return FP_WOUL ##### WOLFSSL_SP_FAST_NCT_EXPTMOD -Enables the faster non-constant time modular exponentation implementation. Will only be used for public key operations; not private key operations. +Enables the faster non-constant time modular exponentiation implementation. Will only be used for public key operations; not private key operations. ##### WOLFSSL_SP_INT_NEGATIVE @@ -4816,7 +4816,7 @@ Enables Apache httpd support ### `--enable-afalg` -Enables use of Linux module AF\_ALG for hardware accleration. Additional Xilinx use with `=xilinx`, `=xilinx-rsa`, `=xilinx-aes`, `=xilinx-sha3` +Enables use of Linux module AF\_ALG for hardware acceleration. Additional Xilinx use with `=xilinx`, `=xilinx-rsa`, `=xilinx-aes`, `=xilinx-sha3` Is similar to [`--enable-devcrypto`](#--enable-devcrypto) in that it leverages a Linux kernel module (AF\_ALG) for offloading crypto operations. On some hardware the module has performance accelerations available through the Linux crypto drivers. In the case of Petalinux with Xilinx the flag `--enable-afalg=xilinx` can be used to tell wolfSSL to use the Xilinx interface for AF\_ALG. @@ -4846,7 +4846,7 @@ Enables support for single PSK ID with TLS 1.3 Enable crypto callbacks. Register a crypto callback using wc_CryptoCb_RegisterDevice and set the associated devId using wolfSSL_CTX_SetDevId. -The following two defines can be used with `--enable-cryptocb` to complie out RSA or ECC software fallback to optimize for footprint reduction when software RSA/ECC is not required. +The following two defines can be used with `--enable-cryptocb` to compile out RSA or ECC software fallback to optimize for footprint reduction when software RSA/ECC is not required. * WOLF_CRYPTO_CB_ONLY_RSA - compiles out RSA software crypto fallback * WOLF_CRYPTO_CB_ONLY_ECC - compiles out ECC software crypto fallback diff --git a/wolfSSL/src/chapter07.md b/wolfSSL/src/chapter07.md index 579de75a..b592d983 100644 --- a/wolfSSL/src/chapter07.md +++ b/wolfSSL/src/chapter07.md @@ -492,7 +492,7 @@ ret = wc_SignCert(request.bodySz, request.sigType, der, sizeof(der), NULL, &key, /* check ret value for error handling, <= 0 indicates a failure */ ``` -Lastly it is time to convert the CSR to PEM format for sending to a CA authority to use in issueing a certificate: +Lastly it is time to convert the CSR to PEM format for sending to a CA authority to use in issuing a certificate: ```c ret = wc_DerToPem(der, derSz, pem, sizeof(pem), CERTREQ_TYPE); diff --git a/wolfSentry/src-ja/chapter02.md b/wolfSentry/src-ja/chapter02.md index 6bbea1f6..309dc339 100644 --- a/wolfSentry/src-ja/chapter02.md +++ b/wolfSentry/src-ja/chapter02.md @@ -94,7 +94,7 @@ make SINGLETHREADED=1 EXTRA_CFLAGS='-DWOLFSENTRY_NO_CLOCK_BUILTIN' |`WOLFSENTRY_NO_ERROR_STRINGS` | エラー文字列関数へのエラー コードを無効にする | |`WOLFSENTRY_NO_MALLOC_BUILTINS` | 組み込みの malloc 関数を無効にする | |`WOLFSENTRY_HAVE_NONGNU_ATOMICS` | アトミックは非 GNU です (`SINGLETHREADED` が設定されている場合は無視されます) | -|`WOLFSENTRY_NO_CLOCK_BUILTIN` | Bulitin 時間関数を使用しないでください | +|`WOLFSENTRY_NO_CLOCK_BUILTIN` | Built-in 時間関数を使用しないでください | |`WOLFSENTRY_LWIP` | wolfSentry は BSD ソケットではなく LWIP に対して構築されています | |`FREERTOS` | FreeRTOS サポートでビルド | diff --git a/wolfSentry/src/ChangeLog.md b/wolfSentry/src/ChangeLog.md index 8860fa91..f2a0b98b 100644 --- a/wolfSentry/src/ChangeLog.md +++ b/wolfSentry/src/ChangeLog.md @@ -537,7 +537,7 @@ Fixed copying of route table header fields (table config) when cloning or rebuil Implemented proper locking in `wolfsentry_route_get_reference()`, and corresponding lock assertion in `wolfsentry_table_cursor_init()`. -Fixed logic in address matching to properly match zero-length addresses when peforming subnet matching, even if the corresponding `_ADDR_WILDCARD` flag bit is clear. +Fixed logic in address matching to properly match zero-length addresses when performing subnet matching, even if the corresponding `_ADDR_WILDCARD` flag bit is clear. ## Self-Test Enhancements diff --git a/wolfSentry/src/chapter01.md b/wolfSentry/src/chapter01.md index 5775ce3c..8cd8ff82 100644 --- a/wolfSentry/src/chapter01.md +++ b/wolfSentry/src/chapter01.md @@ -1,6 +1,6 @@ # Introduction -This manual is writen as a technical guide to the wolfSentry embedded Intrusion Detection Protection System (IDPS). It will explain how to build and get started with wolfSentry, provide an overview of build options, features, portability enhancements, support, and much more. +This manual is written as a technical guide to the wolfSentry embedded Intrusion Detection Protection System (IDPS). It will explain how to build and get started with wolfSentry, provide an overview of build options, features, portability enhancements, support, and much more. ## Why Choose wolfSentry? diff --git a/wolfSentry/src/chapter02.md b/wolfSentry/src/chapter02.md index 6bd67b7f..bed20146 100644 --- a/wolfSentry/src/chapter02.md +++ b/wolfSentry/src/chapter02.md @@ -20,7 +20,7 @@ described: ## Dependencies -In its default build, wolfSentry depends on a POSIX runtime, specifically the heap allocator, clock_gettime, stdio, semaphore, and string APIs. However, these dependencies can be avoided with various build-time options. In paticular, the recipe +In its default build, wolfSentry depends on a POSIX runtime, specifically the heap allocator, clock_gettime, stdio, semaphore, and string APIs. However, these dependencies can be avoided with various build-time options. In particular, the recipe ```sh make STATIC=1 SINGLETHREADED=1 NO_STDIO=1 EXTRA_CFLAGS='-DWOLFSENTRY_NO_CLOCK_BUILTIN -DWOLFSENTRY_NO_MALLOC_BUILTIN' @@ -95,7 +95,7 @@ The following table lists the possible options: | `WOLFSENTRY_NO_ERROR_STRINGS` | Disable error code to error string functions | | `WOLFSENTRY_NO_MALLOC_BUILTINS` | Disable builtin malloc functions | | `WOLFSENTRY_HAVE_NONGNU_ATOMICS` | Atomics are non-GNU (ignored if `SINGLETHREADED` is set) | -| `WOLFSENTRY_NO_CLOCK_BUILTIN` | Do not use bulitin time functions | +| `WOLFSENTRY_NO_CLOCK_BUILTIN` | Do not use built-in time functions | | `WOLFSENTRY_LWIP` | wolfSentry is being built against LWIP instead of BSD sockets | | `FREERTOS` | Build with FreeRTOS support | diff --git a/wolfSentry/src/chapter04.md b/wolfSentry/src/chapter04.md index 4f0f20d7..ef2574d5 100644 --- a/wolfSentry/src/chapter04.md +++ b/wolfSentry/src/chapter04.md @@ -30,7 +30,7 @@ I hear you fa shizzle! ## wolfSentry Examples -Examples are loacated in wolfSentry rero, `/examples` +Examples are located in wolfSentry rero, `/examples` ### wolfSentry lwIP Echo Test diff --git a/wolfTPM/src/chapter02.md b/wolfTPM/src/chapter02.md index e339a8bd..fb5cc79b 100644 --- a/wolfTPM/src/chapter02.md +++ b/wolfTPM/src/chapter02.md @@ -720,7 +720,7 @@ This separation ensures that cryptographic keys are protected even if the main p 1. Verify SPI clock polarity and phase (typically CPOL=0, CPHA=0 for TPM) 2. Check SPI clock speed - start with a slower speed (1-10 MHz) and increase -3. Verify chip select is asserted low during entire send/recieve +3. Verify chip select is asserted low during entire send/receive 4. Some TPMs require wait states during SPI operations which requires extra bytes until the MSB is set to signal response readiness (enabled with `WOLFTPM_CHECK_WAIT_STATE`) 5. Enable debug output with `#define DEBUG_WOLFTPM` (general), `WOLFTPM_DEBUG_VERBOSE` (detailed), or `WOLFTPM_DEBUG_IO` (SPI/I2C transactions)