[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

For the record, I have reviewed Adam's versions of the code before these were posted here, and Adam has resolved the problems that I pointed out. As of the latest patch, I think the code is suitable for inclusion in OpenSSL. The final missing part is support that makes it easy to build with or with

RE: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

openssl-dev@openssl.org Subject: Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms > Here is an updated version of the patch. > > Addressing a) "pointer to the function" (to select ADCX/ADOX) an

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

Not sent to RT, to only. Alternatives would be (a) using a new lock for safe static initialization, or (b) more code duplication to avoid the need for an explicit pointer (there could be two separate implementations for the higher-level routines). However, given the 1% performance penalty, tha

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

>> Do you have any comment from Intel on the concerns regarding the scattering >> technique (http://cryptojedi.org/peter/data/chesrump-20130822.pdf)? > > As discussed off-list in this case the discrepancy is because so called > memory disambiguation logic attempting to move loads ahead of stores,

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

> While if (functiona==NULL || functionb==NULL) { asssign functiona, > functionb } can be unsafe, I'd argue that if (functiona==NULL) { assign > functiona } followed by if (functionb) { assign functionb } is. > We're implicitly assuming here that (thanks to alignment, etc.) each pointer can be acc

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

On Fri, Nov 8, 2013 at 2:43 PM, Andy Polyakov via RT wrote: >> Alternatives would be (a) using a new lock for safe static initialization, >> or (b) more code duplication to avoid the need for an explicit pointer >> (there could be two separate implementations for the higher-level >> routines). Ho

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

>> Here is an updated version of the patch. >> >> Addressing a) "pointer to the function" (to select ADCX/ADOX) and b) >> multiple points addition >> >> There is (only) ~1% performance deterioration in due to the pointer being >> passed now, instead of (originally) being static. You can choose whic

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

On Fri, Nov 8, 2013 at 4:08 AM, Bodo Moeller via RT wrote: > Alternatives would be (a) using a new lock for safe static initialization, Maybe you could try my patches on my thread_safety branch of my github clone of OpenSSL? (https://github.com/nicowilliams/openssl) Nico --

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

> Here is an updated version of the patch. > > Addressing a) "pointer to the function" (to select ADCX/ADOX) and b) > multiple points addition > > There is (only) ~1% performance deterioration in due to the pointer being > passed now, instead of (originally) being static. You can choose which > sty

RE: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

, 2013 19:18 To: Gueron, Shay Cc: openssl-dev@openssl.org Subject: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms Thanks for the submission! It seems that the BN_MONT_CTX-related code (used in crypto/ecdsa for c

[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

> This initialization is used for selecting a code path that would use ADCX/ADOX > instructions when the processor supports them. The outcome depends only on > the appropriate CPUID bits. Therefore, there is no “thread-safe” issue (because > any thread would select the same path). I understand tha

RE: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

, 2013 19:18 To: Gueron, Shay Cc: openssl-dev@openssl.org Subject: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms Thanks for the submission! It seems that the BN_MONT_CTX-related code (used in crypto/ecdsa for c

[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

Thanks for the submission! It seems that the BN_MONT_CTX-related code (used in crypto/ecdsa for constant-time signing) is entirely independent of the remainder of the patch, and should be considered separately. Regarding your reference 'S.Gueron and V.Krasnov, "Fast Prime Field Elliptic Curve Cr

[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

Hello all, This patch is a contribution to OpenSSL. It offers an efficient and constant-time implementation of EC multiplication for NIST P256 curve. It accelerated ECDSA (sign and verify) as well as ECDH (compute and generate key), for the P256 curve. The implementation is based on Montgomery