1631583 - (CVE-2020-6829) Side channel attack on ECDSA signature generation

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Daniel Veditz [:dveditz]]

Attachment: wnaf_trace.jpg

[filed from mail to security@ from Sohaib ul Hassan]
Hey Folks!

We are a team of security researchers from Tampere University, Finland.
We have discovered a vulnerability in ECDSA signature generation that
enables us to exfiltrate information from various side channels and
recover the private key.

Vulnerable function

The vulnerability is found in the non-constant time ECC scalar
multiplication function ec_GFp_pt_mul_jm_wNAF @
lib/freebl/ecl/ecp_jm.cecp_jm.c. This code path is executed when
either NIST_P384 or NIST_P521 EC curve is selected. The wNAF scalar
multiplication computes EC point doubling (ec_GFp_pt_dbl_jm) at each
iteration, with a conditional branch depending on non-zero scalar
digits, which computes an EC point addition (ec_GFp_pt_add_jm_aff).

In general, wNAF point multiplication algorithm is known to be
vulnerable, and successfully targeted in the past e.g. in OpenSSL
ECDSA with L1 cache timings [4], LLC cache timings [3],
ElectroMagnetic emanations (EM) [2], and port contention [1].

Using the EM side-channel, we successfully extracted the position of
zero and non-zero wNAF digits while nss-certutil tool performed scalar
multiplication during the ECDSA signature generation, leaking partial
information about the ECDSA nonce. Given a small number of ECDSA
signatures, this information can be used to steal the private key.
Attached with this report, an EM trace which clearly reveals the
position of point doubling and additions.

We used the EM channel for simplicity, but also achieved success with
various other SW-based channels, including but not limited to timing.

Additionally and related to ECDSA signature generation, we also
exploited using a software controlled side-channel attack the wNAF
encoding function ec_compute_wNAF @ lib/freebl/ecl/ec_naf.c. We were
able to recover the wNAF encoding of the scalar using a single trace.

Fix

Replace the non-constant time wNAF calls with a constant time
implementation. Our team is willing to help with the fix.

Disclosure

We are planning for a public disclosure on May 18. But this embargo
date is also up for discussion.

Links

[1]:

https://www.thomas-krenn.com/en/wiki/PortSmash_Side-Channel_Vulnerability_CVE-2018-5407
[2]: https://eprint.iacr.org/2016/230.pdf
[3]: https://eprint.iacr.org/2014/161.pdf
[4]: https://www.iacr.org/archive/asiacrypt2009/59120664/59120664.pdf

We appreciate if you could take a look at this issue at your earliest
convenience. Thanks.

Best Regards,

Sohaib ul Hassan
Doctoral Researcher
Network and Information Security Group
Tampere University
Finland

Comment 1

[Daniel Veditz [:dveditz]]

RedHat identifies this issue as INC1266630 in case we need to talk to them about it.

Comment 2

[J.C. Jones [:jcj] (he/they)]

Thank you and your whole research group for this collection of reports. This comment is being added to each.

I’m assigning each of these to a team member for more detailed analysis beyond our initial triage. As all of these affect RHEL, I am also requesting impact analysis from our RedHat peers as well, as even if a side-channel is local, that might indicate higher-severity for server software than for Firefox. The analysis will also determine how to allocate CVE numbers, as needed.

I would like to advise that the embargo period your team has initially indicated is quite short, and in this case conflicts with both RedHat and Firefox release cycles. For a bug being actively exploited, we can do what is necessary; in the general case, our Release Calendar [0] indicates that to meet a 18 May disclosure date, we would need to make and uplift a point release of NSS from Nightly to Firefox Beta 76 within 8 days, which, given the complexity involved, seems unrealistic - and moreso for all four bugs at once. We’ll have a better idea as we complete our analysis of each bug.

Again, thank you for bringing these issues to our attention. Research such as yours makes the whole world safer!

[0] https://wiki.mozilla.org/Release_Management/Calendar

Comment 3

[J.C. Jones [:jcj] (he/they)]

Sohaib and team,

We’ve been alerted to the existence of https://eprint.iacr.org/2020/432.pdf, so it appears the issue is already publicly disclosed. Luckily, < 0.1% of Firefox beta telemetry are p384 and p521 [0]. Unfortunately, this is likely a serious issue for RedHat, as I expect they are more likely to have customers using the larger curves.

Sohaib: Are there plans for imminent disclosure for any of the other issues?

Dan: Since there’s now a spotlight pointed at this, we’re definitely going to need a CVE for RedHat’s management.

Bob, RedHat: Heads-up.

[0] https://mzl.la/3eUrSkW

Comment 4

[Billy Brumley]

For clarification, you might be misreading Table 1 in eprint:2020:432. It is saying NSS is threatened to do the use of BEEA during projective to affine point conversion. The paper is (mostly) unrelated to the "Scalar Multiplication" column, and does not mention wNAF elsewhere in the paper. (Or even define what it is.)

Comment 5

[Billy Brumley]

In terms of "imminent disclosure", you're seeing everything we have at the moment :)

And Re: eprint:2020:432 -- for the record, Alejandro reported our research results to [e-mail] on 17 March.

Thanks for the discourse!

Comment 6

[Billy Brumley]

Our proposed fix for this is, similar to the P-256 code in NSS, a custom ECGroupStr for P-384 and P-521 with formally verified and constant time code. My team is happy to assist with that, especially since it is a non-trivial change. (Patching wNAF is a waste of time and effort.)

Comment 7

[Kevin Jacobs [:kjacobs]]

Thanks. We agree that moving to a non-wNAF and constant-time algorithm is the best direction here. That algorithm could be either generic or specific for these two curves.

We would be happy to review and accept a patch (as well as lend assistance with any NSS-specific questions that come up), but if you already have a CT/FV implementation in mind, we can also take on the work of incorporating it into NSS. Let us know how you’d like to proceed.

Comment 8

[Billy Brumley]

Public tooling can give us the CT/FV for the GFp layer, but the EC layer and rigging is missing.

I have a pair of researchers working on automating all of this -- the focus there is for OpenSSL but since the EC bits of NSS and OpenSSL were forked from the same source 20 years ago I'm guessing it's not that hard to tweak our tooling output.

And it is somehow easier for NSS since we're only talking about 2 curves here. (cf. like 50 in OpenSSL.) NSS has done a good job of narrowing their attack surface in that sense.

So give us some time and we'll come to you when we have a working implementation. This will take several weeks but we will keep you posted.

I mentioned on another thread (likely buried somewhere) we can push the embargo date on all my team's work (#1631576 #1631573 #1631583 #1631597) to at least 02 June.

Let's take the time to get the fixes in right. I've been fixing and re-fixing OpenSSL now for over a decade, so I feel like I know exactly what not to do. (e.g. push out half baked patches and one-liner crutch fixes, punting the problem to other parts of the library.)

Comment 9

[Kevin Jacobs [:kjacobs]]

Excellent - we're glad to have your (collective) eyes on this!

I'm going to needinfo myself to make sure this doesn't fall off the radar. Let me know if any questions come up, or once you're ready for review and testing on the patch.

Comment 10

[J.C. Jones [:jcj] (he/they)]

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1631583#c8, updating disclosure date. Thanks, bbrumley and team!

Comment 11

[Robert Relyea]

Huzaifas is probably the best person to handle any Red Hat CVE's. If you need me to review anything, let me know.

bob

Comment 12

[Huzaifa Sidhpurwala]

(In reply to J.C. Jones [:jcj] (he/him) [increased latency due to COVID-19] from comment #3)

Sohaib and team,

We’ve been alerted to the existence of https://eprint.iacr.org/2020/432.pdf, so it appears the issue is already publicly disclosed. Luckily, < 0.1% of Firefox beta telemetry are p384 and p521 [0]. Unfortunately, this is likely a serious issue for RedHat, as I expect they are more likely to have customers using the larger curves.

Sohaib: Are there plans for imminent disclosure for any of the other issues?

Dan: Since there’s now a spotlight pointed at this, we’re definitely going to need a CVE for RedHat’s management.

Bob, RedHat: Heads-up.

[0] https://mzl.la/3eUrSkW

Seems like a CVE has already been assigned to this issue, i can assign CVEs if you want, but isnt Mozilla already a CNA?
Also since the paper is already published, should'nt we consider this issue as already public?

Comment 13

[Billy Brumley]

Quick update. We are making progress. We have the formally verified GF layer, and at least a first go at an EC layer. We are working essentially on lots of glue -- between the GF layer to the EC layer, and the EC layer to NSS rigging. I hope to have at least something initial to show within a week or so.

(This is for P-384 and P-521.)

BBB

Comment 14

[J.C. Jones [:jcj] (he/they)]

(In reply to Huzaifa Sidhpurwala from comment #12)

Seems like a CVE has already been assigned to this issue, i can assign CVEs if you want, but isnt Mozilla already a CNA?
Also since the paper is already published, should'nt we consider this issue as already public?

Huzaifa: Sorry for the delay in responding here. There's already a CVE assigned, as you see, but this issue is not public. The paper points to this function, but doesn't reference this particular vulnerability.

Comment 15

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

These are current, open bugs with a Severity of critical. The Severity of these bugs is being changed to S2 to be consistent with the May 4 2020 Severity definitions.

Please let Release Management know if these bugs are still S2.

Comment 16

[J.C. Jones [:jcj] (he/they)]

Retargeting to 30 June per https://bugzilla.mozilla.org/show_bug.cgi?id=1631597#c14 - thanks bbrumley and team!

Comment 17

[Billy Brumley]

Update: our internal unit tests for P-384 and P-521 are now passing. It means one side of the rigging is now done (our own EC layer to fiat's GF layer). So all that's left is

1. More performance optimization of the EC layer
2. NSS rigging

So when we understand the performance tradeoffs more, we'll come to you with a patch.

Right now the code is 64-bit only because it uses the __int128 type. (And possibly gcc/clang only? I don't know.)

FIAT has 32-bit flavors too that we can likely ifdef at compile time, but we don't have that rigged in yet.

Any hints / expectations here in terms of portability, architecture, and required compilers?

My team is a Linux-only shop so anything that isn't gcc or clang we can't sign up for. Cross-architecture is fine -- x64, x32, aarch64, armv7, even maybe mips32 we can test. But yea Linux-only. So we need your help there testing wise since I reckon you support lots of OSs.

Comment 18

[J.C. Jones [:jcj] (he/they)]

Tampere University team,

I realize I haven’t replied to your specific questions here, so let me do that as best I can:

Any hints / expectations here in terms of portability, architecture, and required compilers?

NSS is pretty cross-platform, but the way we’re approaching all of these patches so far is going to be pretty much the same. As we’re doing with the patch for CVE-2020-12402, we’ll test on all our tier-1 platforms and compilers as part of the review process, but basically that’s every line depicted here — particularly expand the Builds (+5) portions to see clang (4) and gcc versions (4.4+). But we’ll help adapt the patches and ensure support.

We can also help with the 32-bit compile-time work with the Fiat code, if you want to post a work-in-progress patch (moz-phab submit --wip).

(As something of a reminder to myself, when we do land fiat crypto code, I need to patch Firefox’s about:license to include its license)

Finally, I'm marking 68 ESR as wontfix, since this Firefox's perspective this is more of a sec-moderate and so not a typical ESR candidate.

Comment 19

[Billy Brumley]

Great thanks JC.

The code is pretty much ready. I'm confident I'll be able to submit a patch tomorrow. The performance looks very good. Just a small issue to solve on big endian platforms.

For P-384, you'll get both 64-bit and 32-bit portable versions.

Unfortunately for P-521, we can only deliver the 64-bit portable version. The reason is a combination of Fiat limitations and 521 being not on a word boundary.

What I can do is: promise to deliver the 32-bit version if and when Fiat supports that field. All the code is 100% machine generated so when that happens, it's less than a 5min job.

Comment 20

[Billy Brumley]

Attachment: Bug 1631583 - ECC: constant time P-384

Comment 21

[Billy Brumley]

So ... I did the submission with moz-phab (I think). Some notes:

• The ecp_secp384r1.c file is 100% computer generated.
• For review, try to ignore anything between /* BEGIN verbatim fiat code */ and /* END verbatim fiat code */
• Everything from static void fe_inv_secp384r1 up to static void precomp_rdx is also computer generated like everything else, but with high confidence because we did not hand write the ECC arith formulas or inversion -- they are auto generated from EFD format.
• So for review, try to focus on static void precomp_rdx up to and including mp_err ec_group_set_secp384r1. In particular, the NSS rigging starts at #include "mplogic.h".
• I need to add some kind of license notice

Here's the numbers for my super crappy laptop, clang-10 64-bit build.

Before

bbrumley@emerald:~/svnrepos/libnss/nss$ LD_LIBRARY_PATH=$HOME/svnrepos/libnss/dist/Release/lib ../dist/Release/bin/ecperf
Testing NIST-P256 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.11 op/sec: 938.89
    ECDSA_Sign      count: 100 sec: 0.02 op/sec: 5196.69
        ECDHE max rate = 1533.90
    ECDSA_Verify    count: 100 sec: 0.05 op/sec: 1937.38
... okay.
Testing NIST-P384 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.21 op/sec: 481.40
    ECDSA_Sign      count: 100 sec: 0.11 op/sec: 874.95
        ECDHE max rate = 339.09
    ECDSA_Verify    count: 100 sec: 0.19 op/sec: 521.73
... okay.
Testing NIST-P521 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.29 op/sec: 343.25
    ECDSA_Sign      count: 100 sec: 0.16 op/sec: 622.60
        ECDHE max rate = 241.46
    ECDSA_Verify    count: 100 sec: 0.25 op/sec: 404.48
... okay.
Testing Curve25519 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.01 op/sec: 18775.82
... okay.

After

bbrumley@emerald:~/svnrepos/libnss/nss$ LD_LIBRARY_PATH=$HOME/svnrepos/libnss/dist/Release/lib ../dist/Release/bin/ecperf
Testing NIST-P256 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.10 op/sec: 953.02
    ECDSA_Sign      count: 100 sec: 0.02 op/sec: 5488.47
        ECDHE max rate = 1610.37
    ECDSA_Verify    count: 100 sec: 0.05 op/sec: 1896.71
... okay.
Testing NIST-P384 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.16 op/sec: 630.42
    ECDSA_Sign      count: 100 sec: 0.03 op/sec: 3026.82
        ECDHE max rate = 914.31
    ECDSA_Verify    count: 100 sec: 0.10 op/sec: 1044.17
... okay.
Testing NIST-P521 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.29 op/sec: 350.78
    ECDSA_Sign      count: 100 sec: 0.16 op/sec: 633.75
        ECDHE max rate = 246.13
    ECDSA_Verify    count: 100 sec: 0.24 op/sec: 408.67
... okay.
Testing Curve25519 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.01 op/sec: 18730.10
... okay.

Comment 22

[Kevin Jacobs [:kjacobs]]

Thanks for the patch! The performance improvement is a nice bonus.

We've already started the review, which we plan to complete by the middle of next week (~24 June). For scheduling purposes, is there any ETA on the 64-bit P521 patch?

Comment 23

[Billy Brumley]

Attachment: Bug 1631583 - ECC: constant time P-521

Comment 24

[Billy Brumley]

(In reply to Kevin Jacobs [:kjacobs] from comment #22)

Thanks for the patch! The performance improvement is a nice bonus.

We've already started the review, which we plan to complete by the middle of next week (~24 June). For scheduling purposes, is there any ETA on the 64-bit P521 patch?

It's there now ;)

Comment 25

[Billy Brumley]

Attachment: Screenshot from 2020-06-17 18-06-20.png

Numbers from the paper attached. Bottom 2 rows are relevant for NSS. Numbers look pretty good.

You're derive is slower because you're doing explicit point validation:

1. Checking nP = inf
2. Finally calculating the shared kP

So two scalar multiplications. That made sense when NSS supported a bunch of random curves, but not anymore. Since these are prime-order curves, verifying points satisfy the curve equation is enough so you can do away with (1) above.

It is easy to add that logic to the templating, adding a fourth function pointer. But I haven't yet.

Comment 26

[Robert Relyea]

I think it's there as a FIPS requirement to prevent small sub-group attacks. I'd have to check with the lab to verify that it's redundant if y is on the curve and the curve is in a prime field.
RE: machine generated code. I'm OK with that as long as the tool which generated it (and the source input to that tool) is available. (We don't need to rerun it at build time, but we would want users to be able to regenerate their own .c files for the paranoid.

Comment 27

[Billy Brumley]

Hey Bob,

Absolutely it's a FIPS requirement. But if the point satisfies the curve equation, and the curve has prime-order, it's guaranteed to be order-n. That's a group theory constraint.

All of our tooling will be open sourced as soon as we clean up stuff, and we wanted to wait until embargoes expire.

If you want "early access", just give me a GitLab username and I'm happy to grant access.

PS I'm not sure the paper describing this code generation helps with review, but I'm also happy to share that if you want nitty gritty academic research details. NSS was only a very small part of the work here (on the mathematically "boring" end since these are extremely legacy curves), as you can see from the table. (Nevertheless, we are very happy to have it in scope.)

Comment 28

[Robert Relyea]

OK, I will check with the lab, but I think a check that the curve is prime-order (out of paranoia) and skipping the test in that case would be fine.

We don't need early access, if the tools are available "soon" after embargo, that is fine.

bob

Comment 29

[J.C. Jones [:jcj] (he/they)]

bbrumley, regarding this bug, Bug 1631573, and Bug 1623116:

Could we re-target the disclosure dates out one more release cycle, to 2020-07-28 (Firefox 79)? I know my team has started reviews of this bug's attached patches, and I apologize that we don't have further comments posted yet, but we'll be on that alongside getting this week's release of NSS 3.54 out.

Thanks!

Comment 30

[Billy Brumley]

Hey JC,

Could we re-target the disclosure dates out one more release cycle, to 2020-07-28 (Firefox 79)? I know my team has started reviews of this bug's attached patches, and I apologize that we don't have further comments posted yet, but we'll be on that alongside getting this week's release of NSS 3.54 out.

Yea let's re-target. It's a lot of code and we didn't exactly deliver in a timely fashion. Let's take the time to do the fix right.

In the meantime, we even have some performance improvements with our tooling. But I guess that's not the main point here, and when the tooling is public I hope we can provide improvements seamlessly from our upstream tooling.

BBB

Comment 31

[J.C. Jones [:jcj] (he/they)]

Thanks so much, bbrumley. It's a lot, and again we appreciate your team's interest, skill, and professionalism. Re-targetting to 2020-07-28.

Comment 32

[Billy Brumley]

Attachment: Bug 1631583 - ECC: constant time P-521

Depends on D80012

Comment 33

[Billy Brumley]

Attachment: Bug 1631583 ECC: constant time P-384

Depends on D79267

Comment 34

[Billy Brumley]

Slightly better numbers for P-384:

Testing NIST-P384 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.15 op/sec: 651.02
    ECDSA_Sign      count: 100 sec: 0.02 op/sec: 4013.16
        ECDHE max rate = 1166.05
    ECDSA_Verify    count: 100 sec: 0.09 op/sec: 1151.07
... okay.

I guess the P-521 numbers are pretty good too:

Before

Testing NIST-P521 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.29 op/sec: 345.72
    ECDSA_Sign      count: 100 sec: 0.16 op/sec: 623.53
        ECDHE max rate = 242.31
    ECDSA_Verify    count: 100 sec: 0.25 op/sec: 402.94
... okay.

After

Testing NIST-P521 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.17 op/sec: 605.66
    ECDSA_Sign      count: 100 sec: 0.05 op/sec: 1998.28
        ECDHE max rate = 650.99
    ECDSA_Verify    count: 100 sec: 0.11 op/sec: 927.28
... okay.

But more importantly: we were able to get the 32-bit Fiat code working for P-521! So this gives you complete coverage for the fix :)

I have no Idea if I'm doing this revision thing correctly. In the git universe this would be fixup commits pushed to the PR branch ... shrug pls advise if I'm mucking things up.

Comment 35

[Billy Brumley]

Attachment: Bug 1631583 - ECC: constant time P-256

Comment 36

[Billy Brumley]

I added P-256 for consistency, if you're interested.

Before

Testing NIST-P256 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.08 op/sec: 1210.81
    ECDSA_Sign      count: 100 sec: 0.03 op/sec: 3622.53
        ECDHE max rate = 1208.34
    ECDSA_Verify    count: 100 sec: 0.06 op/sec: 1603.03
... okay.

After

Testing NIST-P256 using freebl implementation...
    ECDH_Derive     count: 100 sec: 0.05 op/sec: 2137.03
    ECDSA_Sign      count: 100 sec: 0.02 op/sec: 5344.74
        ECDHE max rate = 1870.44
    ECDSA_Verify    count: 100 sec: 0.03 op/sec: 2925.52
... okay.

Comment 37

[J.C. Jones [:jcj] (he/they)]

Hey Bob,

I'm expecting you'll mostly have similar comments as with the 384, but could you take a look at the 521 patch too, please? https://phabricator.services.mozilla.com/D80012

Comment 38

[Billy Brumley]

We are getting failures on aarch64. I don't know why yet.

Comment 39

[Benjamin Beurdouche [:beurdouche]]

Random thought: endianness/signedness issues? : )

Comment 40

[Robert Relyea]

OK, I've looked at both and approved them (though see comment 38 which I just noticed).

Comment 41

[Robert Relyea]

re comment 38: I'm not seeing any potential endian issues. The code seems to treat everything as uint64's or uint128's. I wonder if arm is doing the right thing when multiplying a 128bit value(which is a 64 bit casted to 128 bit) by a 64 bit value and getting the correct 128 bit value

Comment 42

[Billy Brumley]

We are getting failures on aarch64. I don't know why yet.

I think we got it. char defaults to unsigned on arm but signed on x86/x64. Checking the fixes now.

Comment 43

[J.C. Jones [:jcj] (he/they)]

Comment on attachment 9155893 [details]
Bug 1631583 - ECC: constant time P-384

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Medium difficulty.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which older supported branches are affected by this flaw?: All
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?: It's not risky, but I'm not sure if we want to do this into an ESR this release, or maybe include in a future ESR update.
• How likely is this patch to cause regressions; how much testing does it need?: Moderate possibility, but we'd see the issues pretty rapidly when it gets into Beta.

Comment 44

[Tom Ritter [:tjr] (OOTO until mid-August)]

Comment on attachment 9155893 [details]
Bug 1631583 - ECC: constant time P-384

Approved to land

Comment 45

[Tom Ritter [:tjr] (OOTO until mid-August)]

Comment on attachment 9157321 [details]
Bug 1631583 - ECC: constant time P-521

Sorry, missed this one!

Comment 46

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Per JC, we're going to let these fixes ride the regular NSS trains without uplifting since the severity to Firefox is significantly lower.

Comment 47

[Kevin Jacobs [:kjacobs]]

try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1bd549658c61b15be26a64c9875e8d594a2bb40f
nss-try push: https://treeherder.mozilla.org/#/jobs?repo=nss-try&revision=16596e415bdf93fcc23d1327b24fe43e1036bf01

Comment 48

[Kevin Jacobs [:kjacobs]]

bbrumley: We are ready to land P384/P521, but I noticed that the summaries are all blank. Would you like to provide one, including any credit to you and your team? If not, that's fine too.

Thanks!

Comment 49

[Billy Brumley]

bbrumley: We are ready to land P384/P521

Great!

I noticed that the summaries are all blank. Would you like to provide one, including any credit to you and your team? If not, that's fine too.

Oh, right. Sure -- anything similar to below is fine :)

BBB

This portable code contributed by the Network and Information Security
Group (NISEC) at Tampere University comes from
[ECCKiila](https://gitlab.com/nisec/ecckiila) that uses
[Fiat](https://github.com/mit-plv/fiat-crypto) for the underlying field
arithmetic.

Co-authored-by: Luis Rivera-Zamarripa <[e-mail]>
Co-authored-by: Jesús-Javier Chi-Domínguez <[e-mail]>

Comment 50

[Kevin Jacobs [:kjacobs]]

P384 and P521 landed:
https://hg.mozilla.org/projects/nss/rev/d19a3cd451bbf9602672fdbba8d6a817a55bfc69
https://hg.mozilla.org/projects/nss/rev/ca068f5b5c176c503ddce969e78dd326cc5fd29a

Regarding the P256 patch, the 32-bit performance takes a ~30-50% hit over the existing implementation. We're still interested in taking it, but need to do some investigation into what kind of impact that would have on Firefox, particularly on mobile devices. Maybe some optimizations are possible. We have an in-progress patch to bring in 64-bit HACL* P256, but will certainly benchmark it against the 64-bit Fiat code.

I'm going to mark this bug resolved and for now, link it to bug 1653364 so that we can circle back on the last patch.

Thanks again for these contributions!

Comment 51

[J.C. Jones [:jcj] (he/they)]

I'm planning to uplift this bug's patches to the 3.53 branch for whenever we make our next build of NSS destined for ESR 78.

Comment 52

[BugBot [:suhaib / :marco/ :calixte]]

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.

Comment 53

[J.C. Jones [:jcj] (he/they)]

NSS_3_53_BRANCH
https://hg.mozilla.org/projects/nss/rev/e55ab3145546ae3cf1333b43956a974675d2d25c
https://hg.mozilla.org/projects/nss/rev/3f022d5eca5d3cd0e366a825a5681953d76299d0

Comment 54

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt

Advisory attached, LMK if any corrections are needed.

Comment 55

[Billy Brumley]

This one is also fine :)