summaryrefslogtreecommitdiff
path: root/gtests/pk11_gtest
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1767883 - Need to add policy control to keys lengths for signatures. ↵Robert Relyea2023-03-031-1/+8
| | | | | | | | | | | | | | | | | r=nss-reviewers There are three changes in the patch which are related to key length processing: Change RSA_MIN_MODULUS_BITS in blalpit.h from 128 to 1023. This necessitated changes to the following tests: testcrmf.c: up the generated key for the test from 512 to 1024. pk11_rsapkcs1_unittest.cc (in pk11_gtest): skip the min padding test if the MIN_RSA_MODULUS_BITS is more than 736 (The largest hash we support is 512, which fits in an RSA key less then 736. If we can't generate a key less than 736, we can't test minimum padding, but we can never get into that situation anyway now). tls_subcerts_unittest.cc: set our key size to at least RSA_MIN_MODULUS_BITS, and then make sure the policy had a higher minimum key length so we still trigger the 'weakKey' event. pk11kea.c: use 1024 bits for the transfer key now that smaller keysizes aren't supported by softoken. Expand the add a new flag to meaning of NSS_XXX_MIN_KEY_SIZE beyond it's use in SSL (add the ability to limit signing and verification to this as well). This allows us to set strict FIPS 140-3 policies, where we can only sign with 2048, but can still verify 1024. This part includes: New utility functions in seckey.c: SECKEY_PrivateKeyStrengthInBits(): The private key equivalent to SECKEY_PublicKeyStrengthInBits(). This function could be exported globally, but isn't in this patch. seckey_EnforceKeySize(). Takes a key type and a length and makes sure that length falls into the range set by policy. secsign.c and secvfy.c: add policy length check where we check the other policy flags. nss.h, nssoptions.c: add NSS_KEY_SIZE_POLICY_FLAGS and define flags for SSL, VERIFY, and SIGN. SSL is set by default (to maintain the current behavior). pk11parse.c: add keywords for the new NSS_KEY_SIZE_POLICY_FLAGS. ssl3con.c: use the flags to decide if the policy lengths are active for SSL. policy.txt: Test that the new policy flags are parsed correctly sslpolicy.txt: Add tests to make sure the policy flags are functioning. Update fips_algorithms.h to make sure the FIPS indicators are exactly compliant with FIPS 140-3 current guidance (RSA 2028 and above, any key size, Legacy verification allowed for 1024, 1280, 1536, and 1792 [1024-1792, step 256]). The previous attempt to push failed because the pk11_rsapkcs1_unittest.cc change was eaten in the merge. Differential Revision: https://phabricator.services.mozilla.com/D146341
* Bug 1747957 - RSA OAEP Wycheproof JSON, r=jschanckMartin Thomson2023-01-122-69/+138
| | | | | | Depends on D134922 Differential Revision: https://phabricator.services.mozilla.com/D134923
* Bug 1747957 - RSA decrypt Wycheproof JSON, r=jschanckMartin Thomson2023-01-121-20/+94
| | | | | | Depends on D134921 Differential Revision: https://phabricator.services.mozilla.com/D134922
* Bug 1747957 - ECDSA Wycheproof JSON, r=jschanckMartin Thomson2023-01-121-19/+73
| | | | | | Depends on D134920 Differential Revision: https://phabricator.services.mozilla.com/D134921
* Bug 1747957 - ECDH Wycheproof JSON, r=jschanckMartin Thomson2023-01-121-43/+194
| | | | | | Depends on D134886 Differential Revision: https://phabricator.services.mozilla.com/D134920
* Bug 1747957 - PKCS#1v1.5 wycheproof json, r=nss-reviewers,nkulatovaMartin Thomson2023-01-121-86/+108
| | | | | | Depends on D134853 Differential Revision: https://phabricator.services.mozilla.com/D134886
* Bug 1747957 - Use X25519 wycheproof json, r=nss-reviewers,jschanckMartin Thomson2023-01-128-255/+507
| | | | | | Depends on D134846 Differential Revision: https://phabricator.services.mozilla.com/D134853
* Bug 1792821 - Updating the clang-format version to 10. r=jschanckAnna Weine2022-10-0710-42/+47
| | | | Differential Revision: https://phabricator.services.mozilla.com/D158323
* Bug 1681099, pk11wrap: Tighten certificate lookup based on PKCS #11 URI, ↵Daiki Ueno2022-07-261-1/+34
| | | | | | | | | | r=kjacobs,rrelyea Previously we only used the "object" attribute (mapped to CKA_LABEL) to find certificates by PKCS #11 URI. This updates the logic to match also with "id" (mapped to CKA_ID) and reject the request if a "type" attribute is present with the value other than "cert". Note: as "id" may not be null-terminated, the PKCS #11 URI API had to be revamped to allow binary blobs. This is still not perfect because PK11URIAttribute doesn't have a length field of value. Differential Revision: https://phabricator.services.mozilla.com/D98940
* Bug 1757279 - Support UTF-8 library path in the module spec string. ↵Masatoshi Kimura2022-03-221-0/+41
| | | | | | r=nss-reviewers,jschanck Differential Revision: https://phabricator.services.mozilla.com/D139785
* Bug 1747957 - Use Wycheproof JSON for RSASSA-PSS, r=nss-reviewers,bbeurdoucheMartin Thomson2022-02-143-195/+369
| | | | Differential Revision: https://phabricator.services.mozilla.com/D134846
* Bug 1748386 - Enable CKM_CHACHA20, r=rrelyeaMartin Thomson2022-01-112-154/+272
| | | | | | | | | | This change makes a few tiny changes to the code to re-enable the use of Chacha20 ciphers and align their key type. There are a lot more changes in tests, mostly just to factor existing tests and determine that the legacy and final PKCS#11 mechanisms work as expected. Differential Revision: https://phabricator.services.mozilla.com/D135007
* Bug 1747316 - Use ASSERT_ macros to end failed tests early, ↵Martin Thomson2021-12-281-4/+4
| | | | | | r=nss-reviewers,jschanck Differential Revision: https://phabricator.services.mozilla.com/D134557
* Formatting for gtests/pk11_gtest/pk11_hpke_unittest.cc r=jschanckBenjamin Beurdouche2021-08-241-1/+1
| | | | | | | The clang-format target was failing. https://treeherder.mozilla.org/logviewer?job_id=348100377&repo=nss-try Differential Revision: https://phabricator.services.mozilla.com/D122369
* Bug 1709750 - Read HPKE vectors from official JSON, r=djacksonMartin Thomson2021-08-102-145/+461
| | | | | | Added check for required fields Differential Revision: https://phabricator.services.mozilla.com/D119046
* Bug 1693206 - Implement PKCS8 export of ECDSA keysRobert Relyea2021-06-306-13/+89
| | | | | patch by Christoph Walcher r=rrelyea, bbeurdouche
* fix clang format error from patch for bug 1709750NSS_3_65_BETA1Robert Relyea2021-05-111-1/+1
|
* Bug 1709750 - Disable HPKE test when fuzzing, r=bbeurdoucheMartin Thomson2021-05-061-0/+4
| | | | Differential Revision: https://phabricator.services.mozilla.com/D114443
* Bug 1692930 - Update HPKE to final version, r=bbeurdoucheMartin Thomson2021-03-161-10/+0
| | | | | | | | | | | | | | | | | | | | | This adds the final HPKE version string. This removes the draft version markers from the implementation and stops tracking the draft version with the exported syntax. I've added the script that I used to convert the JSON test vectors from the specification; that should allow us to pick up new tests relatively easily, especially if we need to add new algorithms. This change breaks several ECH test cases. As fixing those tests is extraordinarily fiddly, I'm going to defer making those changes until we need to update ECH. As we can't land this code until ECH is updated to depend on the final HPKE and until we have coordinated with servers on when the ECH update can be deployed, it should be OK to defer. In short, don't land this without the matching ECH changes. Differential Revision: https://phabricator.services.mozilla.com/D105256
* Bug 1702663 Need to support RSA PSS with Hashing PKCS #11 Mechanisms.Robert Relyea2021-04-018-201/+380
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FIPS requires that we supply a hash and sign interface for our supported signing algorithms to be validated. We already have those interfaces in softoken for RSA PKCS1, DSA, and ECDSA. However, we don't test those interfaces, now do we supply a way for an application to access those interfaces (usually applications use the VFY_ and SGN_ interfaces which handles the hashing an verify/sign operations). We also have a generic pk11_signature_tests class in pk11_gtest, but only ecdsa and some rsa pss tests uses it. This patch rectifies all of these deficiencies: lib/softokn 1) Hash and sign/verify mechanisms have been added to softoken to support PSS hash and sign. 2) The rsa, dsa, and ecdsa hash and sign algorithms were also cleaned up by creating a fake CKM_SHA1 which matches CKM_SHA_1 so that we can fully use the same macros for all the hash types. 1&2 was sufficient to provide the goals of this task, however we wanted to be able to add tests for this functionality.. lib/pk11wrap 3) Two new functions were added: PK11_CreateContextByPubKey and PK11_CreateContextByPrivKey. These allow you to create multipart contexts with Public and Private keys. This is a requirement to support hash and sign, as they are multi-part operations (rather then just signing a hash, which is a single part operation). With these functions, you can now use the PK11_DigestOp and PK11_DigestFinal to complete a signature or verify optiation. gtests/pk11_gtest 4) Add hash and sign/hash and verify support to the generic pk11_signature_tests.h. 5) pk11_dsa_unittest.cc, pk11_rsa_unittest.cc, and the remainder of pk11_rsapss_unittest.cc (Wycheproof tests) were moved to use the pk11_signature_tests common implementation rather then their own. 6) pk11_ecdsa_unittest.cc was updated to support the hash&sign/verify combo mechanism. 7) With multiple functions using pk11_signature_tests.h, The large functions are moved to pk11_signature_tests.cpp. 8) The test vectors themselves were not changes, now just test against the traditional hash first then verify interfaces and the hash and verify interfaces. Differential Revision: https://phabricator.services.mozilla.com/D110641
* Bug 1678398 - Add Export/Import functions for HPKE context. r=mtKevin Jacobs2021-01-251-0/+125
| | | | | | | | | | | | | | | | This patch adds and exports two new HPKE functions: `PK11_HPKE_ExportContext` and `PK11_HPKE_ImportContext`, which are used to export a serialized HPKE context, then later reimport that context and resume Open and Export operations. Only receiver contexts are currently supported for export (see the rationale in pk11pub.h). One other change introduced here is that `PK11_HPKE_GetEncapPubKey` now works as expected on the receiver side. If the `wrapKey` argument is provided to the Export/Import functions, then the symmetric keys are wrapped with AES Key Wrap with Padding (SP800-38F, 6.3) prior to serialization. Differential Revision: https://phabricator.services.mozilla.com/D99277
* Bug 1678398 - Update HPKE to draft-07. r=mtKevin Jacobs2021-01-251-234/+257
| | | | | | | | | | | | This patch updates HPKE to draft-07. A few other minor changes are included: - Refactor HPKE gtests for increased parameterized testing. - Replace memcpy calls with PORT_Memcpy - Serialization tweaks to make way for context Export/Import (D99277). This should not be landed without an ECH update, as fixed ECH test vectors will otherwise fail to decrypt. Differential Revision: https://phabricator.services.mozilla.com/D99276
* Restore lost portion of the bleichenbacher timing batch that addressedRobert Relyea2020-12-221-3/+3
| | | | | review comments. All the review comments pertained to actual code comments, so this patch only affects the comments.
* Bug 1651411 New tlsfuzzer code can still detect timing issues in RSA operations.Robert Relyea2020-12-182-11/+30
| | | | | | | | | | | | | | | | | | | | | | | | This patch defeats Bleichenbacher by not trying to hide the size of the decrypted text, but to hide if the text succeeded for failed. This is done by generating a fake returned text that's based on the key and the cipher text, so the fake data is always the same for the same key and cipher text. Both the length and the plain text are generated with a prf. Here's the proposed spec the patch codes to: 1. Use SHA-256 to hash the private exponent encoded as a big-endian integer to a string the same length as the public modulus. Keep this value secret. (this is just an optimisation so that the implementation doesn't have to serialise the key over and over again) 2. Check the length of input according to step one of https://tools.ietf.org/html/rfc8017#section-7.2.2 3. When provided with a ciphertext, use SHA-256 HMAC(key=hash_from_step1, text=ciphertext) to generate the key derivation key 4. Use SHA-256 HMAC with key derivation key as the key and a two-byte big-endian iterator concatenated with byte string "length" with the big-endian representation of 2048 (0x0800) as the bit length of the generated string. - Iterate this PRF 8 times to generate a 256 byte string 5. initialise the length of synthetic message to 0 6. split the PRF output into 2 byte strings, convert into big-endian integers, zero-out high-order bits so that they have the same bit length as the octet length of the maximum acceptable message size (k-11), select the last integer that is no larger than (k-11) or remain at 0 if no integer is smaller than (k-11); this selection needs to be performed using a side-channel free operators 7. Use SHA-256 HMAC with key derivation key as the key and a two-byte big-endian iterator concatenated with byte string "message" with the big-endian representation of k*8 - use this PRF to generate k bytes of output (right-truncate last HMAC call if the number of generated bytes is not a multiple of SHA-256 output size) 8. perform the RSA decryption as described in step 2 of section 7.2.2 of rfc8017 9. Verify the EM message padding as described in step 3 of section 7.2.2 of rfc8017, but instead of outputting "decryption error", return the last l bytes of the "message" PRF, when l is the selected synthetic message length using the "length" PRF, make this decision and copy using side-channel free operation Differential Revision: https://phabricator.services.mozilla.com/D99843
* Bug 1682071 IKE Quick mode IPSEC give you incorrect keys if you are asking ↵Robert Relyea2020-12-173-0/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | for keys smaller than the hash size. IKE Appendix B fixes. This patch fixes 2 problems. If you run either ike v1 App B or quick mode asking for a key with length mod macsize = 0, you will generate an extra block that's not used and overwrites the end of the buffer. If you use quick mode, the function incorrectly subsets the existing key rather than generating a new key. This is correct behavior for Appendix B, where appendix B is trying to take a generated key and create a new longer key (with no diversification, just transform the key into something that's longer), so if you ask for a key less than or equal to, then you want to just subset the original key. In quick mode you are taking a base key and creating a set of new keys based on additional data, so you want to subset the generated data. This patch only subsets the original key if you aren't doing quickmode. Full test vectors have now been added for all ike modes in this patch as well (previously we depended on the FIPS CAVS tests to test ike, which covers basic IKEv1, IKEv1_psk, and IKEv2 but not IKEv1 App B and IKE v1 Quick mode). Differential Revision: https://phabricator.services.mozilla.com/D99569
* Bug 1677207 - Replace references to TestCase, which is deprecated, with ↵Kevin Jacobs2020-12-1120-104/+105
| | | | | | | | | TestSuite r=bbeurdouche grep -rl --exclude-dir=google_test INSTANTIATE_TEST_CASE_P gtests | xargs sed -i '' s/INSTANTIATE_TEST_CASE_P/INSTANTIATE_TEST_SUITE_P/g grep -rl --exclude-dir=google_test SetUpTestCase gtests | xargs sed -i '' s/SetUpTestCase/SetUpTestSuite/g Differential Revision: https://phabricator.services.mozilla.com/D98818
* Bug 1680400 - Fix memory leak in PK11_UnwrapPrivKey. r=bbeurdoucheNSS_3_60_BETA1Kevin Jacobs2020-12-041-0/+8
| | | | Differential Revision: https://phabricator.services.mozilla.com/D98772
* Bug 1672823 - Add Wycheproof HMAC test cases. r=jcjKevin Jacobs2020-11-033-0/+76
| | | | Differential Revision: https://phabricator.services.mozilla.com/D94497
* Bug 1672823 - Add Wycheproof HKDF test cases. r=bbeurdoucheKevin Jacobs2020-11-032-195/+145
| | | | Differential Revision: https://phabricator.services.mozilla.com/D94496
* Bug 1672823 - Add Wycheproof DSA test cases. r=jcjKevin Jacobs2020-11-033-0/+81
| | | | Differential Revision: https://phabricator.services.mozilla.com/D94495
* Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism r=mt,rrelyeaRobert Relyea2020-10-231-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary This is useful for RSA-OAEP support. The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS be present for PKCS#11 calls. This provides required context for OAEP. However, PK11_PubWrapSymKey lacks a way of providing this context and historically silently converted CKM_RSA_PKCS_OAEP to CKM_RSA_PKCS when a RSA key is provided. Introducing a new call will let us indicate parameters and potentially support other mechanisms in the future. This call mirrors the earlier calls introduced for RSA-PSS: PK11_SignWithMechanism and PK11_VerifyWithMechanism. The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS be present for PKCS#11 calls. This provides required context for OAEP. However, PK11_PubUnwrapSymKey lacks a way of providing this context, and additionally lacked a way of indicating which mechanism type to use for the unwrap operation (instead detecting it by key type). Introducing a new call will let us indicate parameters and potentially support other mechanisms in the future. Signed-off-by: Alexander Scheel <ascheel@redhat.com> Differential Revision: https://phabricator.services.mozilla.com/D93424
* Bug 1668123 - Export CERT_AddCertToListHeadWithData and ↵Kevin Jacobs2020-10-231-0/+35
| | | | | | CERT_AddCertToListTailWithData. r=jcj Differential Revision: https://phabricator.services.mozilla.com/D94524
* Bug 1631890 - Add support for Hybrid Public Key Encryption ↵Kevin Jacobs2020-10-123-0/+549
| | | | | | | | | | | | (draft-irtf-cfrg-hpke-05). r=mt This patch adds support for Hybrid Public Key Encryption (draft-irtf-cfrg-hpke-05). Because the draft number (and the eventual RFC number) is an input to the key schedule, future updates will *not* be backwards compatible in terms of key material or encryption/decryption. For this reason, a default compilation will produce stubs that simply return an "Invalid Algorithm" error. To opt into using the HPKE functionality , compile with `NSS_ENABLE_DRAFT_HPKE` defined. Once finalized, this flag will not be required to access the functions. Lastly, the `DeriveKeyPair` API is not implemented as it adds complextiy around PKCS #11 and is unnecessary for ECH. Differential Revision: https://phabricator.services.mozilla.com/D73947
* Bug 1667153 - Add PK11_ImportDataKey API. r=rrelyeaKevin Jacobs2020-09-241-40/+48
| | | | | | This patch adds and exports `PK11_ImportDataKey`, and refactors the null PSK TLS 1.3 code to use it. Differential Revision: https://phabricator.services.mozilla.com/D91316
* Bug 1636771 - Disable PKCS11 incremental mode for ChaCha20. r=kjacobs,rrelyeaBenjamin Beurdouche2020-07-181-0/+49
| | | | | | Depends on D74801 Differential Revision: https://phabricator.services.mozilla.com/D83994
* Bug 1636771 - Fix incorrect call to Chacha20Poly1305 by PKCS11. ↵Benjamin Beurdouche2020-07-181-2/+9
| | | | | | r=jcj,kjacobs,rrelyea Differential Revision: https://phabricator.services.mozilla.com/D74801
* Bug 1649648 - Fix null pointers passed as argument in pk11wrap/pk11pbe.c:886 ↵Benjamin Beurdouche2020-07-091-7/+41
| | | | | | r=kjacobs Differential Revision: https://phabricator.services.mozilla.com/D81824
* Bug 1067214 - Check minimum padding in RSA_CheckSignRecover. r=rrelyeaKevin Jacobs2020-07-071-0/+114
| | | | | | This patch adds a check to `RSA_CheckSignRecover` enforcing a minimum padding length of 8 bytes for PKCS #1 v1.5-formatted signatures. In practice, RSA key size requirements already ensure this requirement is met, but smaller (read: broken) key sizes can be used via configuration overrides, and NSS should just follow the spec. Differential Revision: https://phabricator.services.mozilla.com/D82462
* Bug 1649633 - follow-up to make test comparisons in ↵Dana Keeler2020-07-061-94/+89
| | | | | | pk11_find_certs_unittest.cc yoda comparisons r=kjacobs Differential Revision: https://phabricator.services.mozilla.com/D82460
* Bug 1649633 - add PK11_FindEncodedCertInSlot r=kjacobs,jcjDana Keeler2020-07-061-0/+49
| | | | | | | | PK11_FindEncodedCertInSlot can be used to determine the PKCS#11 object handle of an encoded certificate in a given slot. If the given certificate does not exist in that slot, CK_INVALID_HANDLE is returned. Differential Revision: https://phabricator.services.mozilla.com/D81924
* Bug 1649226 - Add Wycheproof ECDSA tests. r=bbeurdoucheKevin Jacobs2020-06-291-0/+48
| | | | Differential Revision: https://phabricator.services.mozilla.com/D81589
* Bug 1622033 - Disable flag for SEED deprecation. r=kjacobs,rrelyeaBenjamin Beurdouche2020-05-052-3/+20
| | | | Differential Revision: https://phabricator.services.mozilla.com/D70672
* Bug 1619959 - Properly handle multi-block SEED ECB inputs. r=bbeurdouche,jcjKevin Jacobs2020-04-301-28/+37
| | | | Differential Revision: https://phabricator.services.mozilla.com/D71648
* Bug 1630721 Softoken Functions for FIPS missing r=mtRobert Relyea2020-04-163-0/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For FIPS we need the following: 1. NIST official Key padding for AES Key Wrap. 2. Combined Hash/Sign mechanisms for DSA and ECDSA. In the first case our AES_KEY_WRAP_PAD function addes pkcs8 padding to the normal AES_KEY_WRAP, which is a different algorithm then the padded key wrap specified by NIST. PKCS #11 recognized this and created a special mechanism to handle NIST padding. That is why we don't have industry test vectors for CKM_NSS_AES_KEY_WRAP_PAD. This patch implements that NIST version (while maintaining our own). Also PKCS #11 v3.0 specified PKCS #11 mechanism for AES_KEY_WRAP which are compatible (semantically) with the NSS vendor specific versions, but with non-vendor specific numbers. Softoken now accepts both numbers. This patch also updates softoken to handle DSA and ECDSA combined hash algorithms other than just SHA1 (which is no longer validated). Finally this patch uses the NIST KWP test vectors in new gtests for the AES_KEY_WRAP_KWP wrapping algorithm. As part of the AES_KEY_WRAP_KWP code, the Constant time macros have been generalized and moved to secport. Old macros scattered throughout the code have been deleted and existing contant time code has been updated to use the new macros. Differential Revision: https://phabricator.services.mozilla.com/D71225
* Bug 1612260 - Add Wycheproof vectors for RSA PKCS1 and PSS signing, PKCS1 ↵Kevin Jacobs2020-04-066-92/+388
| | | | | | | | and OEAP decryption. r=bbeurdouche This patch updates the Wycheproof script to build RSA test vectors (covering PKCS1 decryption/verification, as well as PSS and OAEP) and adds the appropriate test drivers. Differential Revision: https://phabricator.services.mozilla.com/D69847
* Bug 1561637 TLS 1.3 does not work in FIPS modeRobert Relyea2020-03-301-12/+129
| | | | | | | | | | | | | | | | | | | | | | | | | Patch 1 of 2. This patch updates softoken and helper functions with the new PKCS #11 v3 HKDF, which handles all the correct key management so that we can work in FIPS mode 1) Salts can be passed in as data, as and explicit NULL (which per spec means a zero filled buffer of length of the underlying HMAC), or through a key handle 2) A Data object can be used as a key (explicitly allowed for this mechanism by the spec). 3) A special mechansism produces a data object rather than a key, the latter which can be exported. Softoken does not do the optional validation on the pInfo to verify that the requested values are supposed to be data rather than keys. Some other tokens may. The old hkdf mechanism has been retained for compatibility (well namely until patch 2 is created, tls is still using it). The hkdf function has been broken off into it's own function rather than inline in the derive function. Note: because the base key and/or the export key could really be a data object, our explicit handling of sensitive and extractable are adjusted to take into account that those flags do not exist in data objects. Differential Revision: https://phabricator.services.mozilla.com/D68940
* Bug 1623374 Need to support the new PKCS #11 Message interface for AES GCM ↵Robert Relyea2020-03-192-0/+435
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and ChaCha Poly PKCS #11 defines a new interface for handling AEAD type ciphers that allow multiple AEAD operations without repeating the key schedule. It also allows tokens to keep track of the number of operations, and generate IVs (depending on the cipher). This patch: 1. implement those new functions in softoken. With the addition of CKF_MESSAGE_* flags to various mechanism, we need to strip them when using the version 2 API of softoken (since there are no C_Message* function in version 2). For that we need a separate C_GetMechanismInfo function. We use the same trick we used to have a separate version function for the V2 interface. Also now that the new message functions are in their own file, they still need access to the common Session state processing functions. those have gone from static to exported within softoken to accomidate that. Same with sftk_MapDecryptError() (sftk_MapVerifyError() was also made global, though nothing else is yet using it). Only C_MessageEncrptInit(), C_EncryptMessage(), C_MessageEncryptFinal, C_MessageDecryptInit(), C_DecryptMessage(), and C_MessageDecryptFinal are implemented. C_EncryptMessageBegin(), C_EncryptMessageNext(), C_DecryptMessageBegin(), and C_DecryptMessageNext() are all part of the multi-part withing a multi-part operation and are only necessary for things like S/MIME (potentially). If we wanted to implement them, we would need more functions exported from freebl (and initaead, updateaead, finalaead for each mechanism type). 2. make those interfaces call aes_gcm and chacha20_poly1503 (and make adjustments for those ciphers). For AES, I added a new function AES_AEAD, which handles both encrypt and decrypt. Internally, the gcm functions (both the generic gcm and the intel gcm wrapper) had their init functions split into key scheduling and counter mode/tag initialization. The latter is still called from init, but the former is now for each update call. IV generation is handled by a single function in gcm.c, and shared with intel_gcm_wrapper.c Since the AES functions already know about the underlying PKCS #11 mechanism parameters, the new AEAD functions also parse the PKCS #11 GCM parameters. For Chacha/Poly new aead update functions were created called ChaChaPoly1305_Encrypt and ChaChaChaPoly1305_Decrypt. There was no Message specific initialization in the existing chacha_init, so no changes were needed there. The primary difference between _Encrypt/_Decrypt and _Seal/_Open is the fact that the tag is put at the end of the encrypted data buffer in the latter, and in a generic buffer in the former. 3. create new pk11wrap interfaces that also squash the api differences between the various mechanisms for aead (similiar to the way we do it for CBC and ECB crypto today). To accomplish this I added PK11_AEADOp() and PK11_AEADRawOp(). Both functions handle the case where the token only supports the single shot interface, by using the single short interface to simulate the Message interface. The PK11_AEADOp() also smooths out the differences in the parameters and symantics of the various mechanism so the application does not need to worry about the PKCS #11 differences in the mechanism. Both use contexts from the standard PK11_CreateContext(), so key schedules are done once for each key rather than once for each message. MESSAGE/AEAD operations are selected by adding the psuedo attribute flag CKA_NSS_MESSAGE to the requested operation (CKA_ENCRYPT, CKA_DECRYPT, CKA_SIGN, CKA_VERIFY). 4. write tests for the new interfaces Tests were added to make sure the PK11_AEADRawOp interface works, The single shot interface is used to test output of the message interface we also use two test only functions to force the connection to use the simulation interface, which is also compared to the non-simulate inteface. The AES_GCM also tests various IV generators. Differential Revision: https://phabricator.services.mozilla.com/D67552
* Bug 1603628 Update NSS to handle PKCS #11 v3.0 r=daiki r=mhoyeRobert Relyea2020-02-182-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://phabricator.services.mozilla.com/D63241 This patch implements the first phase: updating the headers. lib/util/pkcs11.h lib/util/pkcs11f.h lib/util/pkcs11t.h Were updated using the released OASIS PKCS #11 v3.0 header files. lib/util/pkcs11n.h was updated to finally deprecate all uses of CK?_NETSCAPE_?. A new define as added: NSS_PKCS11_2_0_COMPAT. If it's defined, the small semantic changes (including the removal of deprecated defines) between the NSS PKCS #11 v2 header file and the new PKCS #11 v3 are reverted in favor of the PKCS #11 v2 definitions. This include the removal of CK?_NETSCAPE_? in favor of CK?_NSS_?. One notable change was caused by an inconsistancy between the spec and the released headers in PKCS #11 v2.40. CK_GCM_PARAMS had an extra field in the header that was not in the spec. OASIS considers the header file to be normative, so PKCS #11 v3.0 resolved the issue in favor of the header file definition. NSS had the spec definition, so now there are 2 defines for this structure: CK_NSS_GCM_PARAMS - the old nss define. Still used internally in freebl. CK_GCM_PARAMS_V3 - the new define. CK_GCM_PARAMS - no longer referenced in NSS itself. It's defined as CK_GCM_PARAMS_V3 if NSS_PKCS11_2_0_COMPAT is *not* defined, and it's defined as CKM_NSS_GCM_PARAMS if NSS_PKCS11_2_0_COMPAT is defined. Softoken has been updated to accept either CK_NSS_GCM_PARAMS or CK_GCM_PARAMS_V3. In a future patch NSS will be updated to use CK_GCM_PARAMS_V3 and fall back to CK_NSS_GMC_PARAMS. One other semantic difference between the 3.0 version of pkcs11f.h and the version here: In the oasis version of the header, you must define CK_PKCS11_2_0_ONLY to get just the PKCS #11 v2 defines. In our version you must define CK_PKCS11_3 to get the PCKS #11 v3 defines. Most of this patch is to handle changing the deprecated defines that have been removed in PCKS #11 v3 from NSS. Differential Revision: https://phabricator.services.mozilla.com/D63241
* Bug 1612259 - Add Wycheproof vectors for P384 and P521 ECDH. r=bbeurdoucheKevin Jacobs2020-02-241-3/+9
| | | | Differential Revision: https://phabricator.services.mozilla.com/D63688
* Bug 1604596 - Update Wycheproof vectors and add support for CBC, P256-ECDH, ↵Kevin Jacobs2020-01-168-26/+195
| | | | | | | | | | | | | | | and CMAC tests r=franziskus This patch updates to the latest Wycheproof vectors and adds Wycheproof support for CBC, CMAC, and P256-ECDH: ChaCha20: +141 tests Curve25519: +431 tests GCM: +39 tests CBC (new): +183 tests CMAC (new): +308 tests P256 ECDH (new): +460 tests Differential Revision: https://phabricator.services.mozilla.com/D57477
View Lorry Controller Status