1. 17 Mar, 2021 1 commit
  2. 15 Mar, 2021 1 commit
    • Martin Thomson's avatar
      Bug 1692930 - Update HPKE to final version, r=bbeurdouche · a4413156
      Martin Thomson authored
      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
      
      --HG--
      extra : rebase_source : b0717403cf5136efc14f85499182763aa551efc3
      a4413156
  3. 25 Jan, 2021 1 commit
    • Kevin Jacobs's avatar
      Bug 1678398 - Update HPKE to draft-07. r=mt · e2528512
      Kevin Jacobs authored
      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
      
      --HG--
      extra : moz-landing-system : lando
      e2528512
  4. 18 Dec, 2020 2 commits
    • Robert Relyea's avatar
      Bug 1651411 New tlsfuzzer code can still detect timing issues in RSA operations. · 3a48c7de
      Robert Relyea authored
      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
      3a48c7de
    • Robert Relyea's avatar
      Bug 1682071 IKE Quick mode IPSEC give you incorrect keys if you are asking for... · a080484f
      Robert Relyea authored
      Bug 1682071 IKE Quick mode IPSEC give you incorrect keys if you are asking 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
      a080484f
  5. 03 Nov, 2020 3 commits
  6. 12 Oct, 2020 1 commit
    • Kevin Jacobs's avatar
      Bug 1631890 - Add support for Hybrid Public Key Encryption (draft-irtf-cfrg-hpke-05). r=mt · bd4ef1c9
      Kevin Jacobs authored
      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
      
      --HG--
      extra : moz-landing-system : lando
      bd4ef1c9
  7. 29 Jun, 2020 1 commit
  8. 05 May, 2020 2 commits
    • Jan-Marek Glogowski's avatar
      Bug 1629553 Rework the LIBRARY_NAME ruleset r=rrelyea · 147d3feb
      Jan-Marek Glogowski authored
      * Drop the WIN% "32" default DLL suffix
      * Add default resource file handling => drop default RES
      * Generate IMPORT_LIBRARY based on IMPORT_LIB_SUFFIX and
        SHARED_LIBRARY, so we can drop all the explicit empty
        IMPORT_LIBRARY lines
      
      Originally this patch also tried to add a default MAPFILE rule,
      but this fails, because the ARCH makefiles set linker flags
      based on an existing MAPFILE variable.
      
      Differential Revision: https://phabricator.services.mozilla.com/D70369
      
      --HG--
      extra : moz-landing-system : lando
      147d3feb
    • Jan-Marek Glogowski's avatar
      Bug 290526 Fix gtests build for WIN% targets r=rrelyea · ea9bf78d
      Jan-Marek Glogowski authored
      The google_test gtest build doesn't provide any exports for the
      shared library on Windows and the gyp build also builds just a
      static library. So build gtest and gtestutil libraries as static.
      
      For whatever reason, the Windows linker doesn't find the main
      function inside the gtestutil library, if we don't tell it to
      build a console executable. But linking works fine, if the object
      file is used directly. But since we can have different main()
      objects based on build flags, we enforce building console
      applications binaries.
      
      Differential Revision: https://phabricator.services.mozilla.com/D70665
      
      --HG--
      extra : moz-landing-system : lando
      ea9bf78d
  9. 16 Apr, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1630721 Softoken Functions for FIPS missing r=mt · 60de8da9
      Robert Relyea authored
      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
      60de8da9
  10. 06 Apr, 2020 1 commit
  11. 24 Feb, 2020 1 commit
  12. 16 Jan, 2020 1 commit
  13. 13 Jan, 2020 1 commit
  14. 30 Sep, 2019 1 commit
  15. 27 Sep, 2019 1 commit
  16. 06 Aug, 2019 1 commit
  17. 03 Jun, 2019 1 commit
  18. 31 May, 2019 2 commits
  19. 16 May, 2019 1 commit
  20. 13 May, 2019 1 commit
  21. 08 Nov, 2018 1 commit
  22. 19 Dec, 2018 1 commit
    • Jonas Allmann's avatar
      Bug 1514999 - Add wycheproof Curve25519 testcases to nss, r=franziskus · 69203eee
      Jonas Allmann authored
      Differential Revision: https://phabricator.services.mozilla.com/D14843
      
      --HG--
      rename : gtests/common/chachapoly-vectors.h => gtests/common/testvectors/chachapoly-vectors.h
      rename : gtests/common/gcm-vectors.h => gtests/common/testvectors/gcm-vectors.h
      rename : gtests/common/wycheproof/header_bases/chachapoly-vectors.h => gtests/common/testvectors_base/chachapoly-vectors_base.h
      rename : gtests/common/wycheproof/header_bases/gcm-vectors.h => gtests/common/testvectors_base/gcm-vectors_base.h
      rename : gtests/common/wycheproof/testvectors/aes_gcm_test.json => gtests/common/wycheproof/source_vectors/aes_gcm_test.json
      rename : gtests/common/wycheproof/testvectors/chacha20_poly1305_test.json => gtests/common/wycheproof/source_vectors/chacha20_poly1305_test.json
      extra : amend_source : c6a4e9bc385e669347b13bbe1703eed65e385d6c
      69203eee
  23. 13 Dec, 2018 1 commit
  24. 11 Dec, 2018 1 commit
  25. 01 Nov, 2017 1 commit
  26. 20 Oct, 2017 2 commits
  27. 09 Jun, 2017 1 commit
  28. 01 Jun, 2017 1 commit
  29. 22 Mar, 2017 1 commit
  30. 28 Feb, 2017 1 commit
  31. 10 Feb, 2017 1 commit
  32. 06 Feb, 2017 1 commit
  33. 02 Feb, 2017 1 commit
  34. 20 Jan, 2017 1 commit