Re: [openssl-dev] [openssl.org #3667] [PATCH] Faster GLV elliptic curves
Ported from 1.0 to 1.1 -- PR:
https://github.com/openssl/openssl/pull/776
On Tue, Jan 20, 2015 at 4:02 PM, Billy Brumley via RT <r...@openssl.org> wrote:
> This patch gives about 50% speed improvement for existing GLV elliptic
> curves in OpenSSL. Read about it here:
>
> http://eprint.iacr.org/2015/036
>
> It could use a review. Perhaps the best known use case for secp256k1
> right now is Bitcoin.
>
> BBB
>
> Before:
> op op/s
> 160 bit ecdh (secp160r1) 0.0001s 6730.6
> 192 bit ecdh (nistp192) 0.0002s 5714.8
> 224 bit ecdh (nistp224) 0.0002s 4153.6
> 256 bit ecdh (nistp256) 0.0003s 3573.1
> 160 bit ecdh (secp160k1) 0.0002s 6198.2
> 192 bit ecdh (secp192k1) 0.0002s 5191.9
> 224 bit ecdh (secp224k1) 0.0003s 3789.3
> 256 bit ecdh (secp256k1) 0.0003s 3281.2
>
> signverifysign/s verify/s
> 160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19289.6 5581.5
> 192 bit ecdsa (nistp192) 0.0001s 0.0002s 16011.7 4650.7
> 224 bit ecdsa (nistp224) 0.0001s 0.0003s 12987.1 3378.2
> 256 bit ecdsa (nistp256) 0.0001s 0.0003s 11061.8 2913.0
> 160 bit ecdsa (secp160k1) 0.0001s 0.0002s 18946.5 5290.5
> 192 bit ecdsa (secp192k1) 0.0001s 0.0002s 15605.9 4289.9
> 224 bit ecdsa (secp224k1) 0.0001s 0.0003s 12752.6 3145.9
> 256 bit ecdsa (secp256k1) 0.0001s 0.0004s 10803.0 2733.2
>
>
>
> After:
> op op/s
> 160 bit ecdh (secp160r1) 0.0001s 6798.4
> 192 bit ecdh (nistp192) 0.0002s 5667.2
> 224 bit ecdh (nistp224) 0.0002s 4081.5
> 256 bit ecdh (nistp256) 0.0003s 3578.9
> 160 bit ecdh (secp160k1) 0.0001s 9102.5
> 192 bit ecdh (secp192k1) 0.0001s 7784.3
> 224 bit ecdh (secp224k1) 0.0002s 5554.4
> 256 bit ecdh (secp256k1) 0.0002s 4890.4
>
> signverifysign/s verify/s
> 160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19264.6 5416.7
> 192 bit ecdsa (nistp192) 0.0001s 0.0002s 15956.0 4723.1
> 224 bit ecdsa (nistp224) 0.0001s 0.0003s 12855.8 3379.9
> 256 bit ecdsa (nistp256) 0.0001s 0.0003s 11017.8 2911.7
> 160 bit ecdsa (secp160k1) 0.0001s 0.0001s 18959.9 6705.4
> 192 bit ecdsa (secp192k1) 0.0001s 0.0002s 15624.0 5681.4
> 224 bit ecdsa (secp224k1) 0.0001s 0.0002s 12513.0 4189.3
> 256 bit ecdsa (secp256k1) 0.0001s 0.0003s 10621.2 3569.8
>
>
>
> $ cat /proc/cpuinfo
> processor: 0
> vendor_id: GenuineIntel
> cpu family: 6
> model: 60
> model name: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
> stepping: 3
> microcode: 26
> cpu MHz: 800.000
> cache size: 6144 KB
> physical id: 0
> siblings: 4
> core id: 0
> cpu cores: 4
> apicid: 0
> initial apicid: 0
> fpu: yes
> fpu_exception: yes
> cpuid level: 13
> wp: yes
> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor
> ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2
> x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
> lahf_lm abm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi
> flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid
> rtm
> bogomips: 6384.88
> clflush size: 64
> cache_alignment: 64
> address sizes: 39 bits physical, 48 bits virtual
> power management: SNIP
>
>
> diff -ru --new-file openssl-1.0.1l-orig/apps/speed.c
> openssl-1.0.1l/apps/speed.c
> --- openssl-1.0.1l-orig/apps/speed.c2015-01-15 16:43:49.0 +0200
> +++ openssl-1.0.1l/apps/speed.c 2015-01-19 13:44:38.232456333 +0200
> @@ -244,7 +244,7 @@
> #define RSA_NUM4
> #define DSA_NUM3
>
> -#define EC_NUM 16
> +#define EC_NUM 8
> #define MAX_ECDH_SIZE 256
>
> static const char *names[ALGOR_NUM]={
> @@ -512,18 +512,10 @@
> #define R_EC_P1921
> #define R_EC_P2242
> #define R_EC_P2563
> -#define R_EC_P3844
> -#define R_EC_P5215
> -#define R_EC_K1636
> -#define R_EC_K2337
> -#define R_EC_K2838
> -#define R_EC_K4099
> -#define R_EC_K57110
> -#define R_EC_B16311
> -#define R_EC_B23312
> -#define R_EC_B28313
> -#define R_EC_B40914
> -#define R_EC_B57115
> +#define R_EC_K1604
> +#define R_EC_K1925
> +#define R_EC_K2246
Re: [openssl-dev] [openssl.org #3667] [PATCH] Faster GLV elliptic curves
Ported from 1.0 to 1.1 -- PR:
https://github.com/openssl/openssl/pull/776
On Tue, Jan 20, 2015 at 4:02 PM, Billy Brumley via RT <r...@openssl.org> wrote:
> This patch gives about 50% speed improvement for existing GLV elliptic
> curves in OpenSSL. Read about it here:
>
> http://eprint.iacr.org/2015/036
>
> It could use a review. Perhaps the best known use case for secp256k1
> right now is Bitcoin.
>
> BBB
>
> Before:
> op op/s
> 160 bit ecdh (secp160r1) 0.0001s 6730.6
> 192 bit ecdh (nistp192) 0.0002s 5714.8
> 224 bit ecdh (nistp224) 0.0002s 4153.6
> 256 bit ecdh (nistp256) 0.0003s 3573.1
> 160 bit ecdh (secp160k1) 0.0002s 6198.2
> 192 bit ecdh (secp192k1) 0.0002s 5191.9
> 224 bit ecdh (secp224k1) 0.0003s 3789.3
> 256 bit ecdh (secp256k1) 0.0003s 3281.2
>
> signverifysign/s verify/s
> 160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19289.6 5581.5
> 192 bit ecdsa (nistp192) 0.0001s 0.0002s 16011.7 4650.7
> 224 bit ecdsa (nistp224) 0.0001s 0.0003s 12987.1 3378.2
> 256 bit ecdsa (nistp256) 0.0001s 0.0003s 11061.8 2913.0
> 160 bit ecdsa (secp160k1) 0.0001s 0.0002s 18946.5 5290.5
> 192 bit ecdsa (secp192k1) 0.0001s 0.0002s 15605.9 4289.9
> 224 bit ecdsa (secp224k1) 0.0001s 0.0003s 12752.6 3145.9
> 256 bit ecdsa (secp256k1) 0.0001s 0.0004s 10803.0 2733.2
>
>
>
> After:
> op op/s
> 160 bit ecdh (secp160r1) 0.0001s 6798.4
> 192 bit ecdh (nistp192) 0.0002s 5667.2
> 224 bit ecdh (nistp224) 0.0002s 4081.5
> 256 bit ecdh (nistp256) 0.0003s 3578.9
> 160 bit ecdh (secp160k1) 0.0001s 9102.5
> 192 bit ecdh (secp192k1) 0.0001s 7784.3
> 224 bit ecdh (secp224k1) 0.0002s 5554.4
> 256 bit ecdh (secp256k1) 0.0002s 4890.4
>
> signverifysign/s verify/s
> 160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19264.6 5416.7
> 192 bit ecdsa (nistp192) 0.0001s 0.0002s 15956.0 4723.1
> 224 bit ecdsa (nistp224) 0.0001s 0.0003s 12855.8 3379.9
> 256 bit ecdsa (nistp256) 0.0001s 0.0003s 11017.8 2911.7
> 160 bit ecdsa (secp160k1) 0.0001s 0.0001s 18959.9 6705.4
> 192 bit ecdsa (secp192k1) 0.0001s 0.0002s 15624.0 5681.4
> 224 bit ecdsa (secp224k1) 0.0001s 0.0002s 12513.0 4189.3
> 256 bit ecdsa (secp256k1) 0.0001s 0.0003s 10621.2 3569.8
>
>
>
> $ cat /proc/cpuinfo
> processor: 0
> vendor_id: GenuineIntel
> cpu family: 6
> model: 60
> model name: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
> stepping: 3
> microcode: 26
> cpu MHz: 800.000
> cache size: 6144 KB
> physical id: 0
> siblings: 4
> core id: 0
> cpu cores: 4
> apicid: 0
> initial apicid: 0
> fpu: yes
> fpu_exception: yes
> cpuid level: 13
> wp: yes
> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor
> ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2
> x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
> lahf_lm abm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi
> flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid
> rtm
> bogomips: 6384.88
> clflush size: 64
> cache_alignment: 64
> address sizes: 39 bits physical, 48 bits virtual
> power management: SNIP
>
>
> diff -ru --new-file openssl-1.0.1l-orig/apps/speed.c
> openssl-1.0.1l/apps/speed.c
> --- openssl-1.0.1l-orig/apps/speed.c2015-01-15 16:43:49.0 +0200
> +++ openssl-1.0.1l/apps/speed.c 2015-01-19 13:44:38.232456333 +0200
> @@ -244,7 +244,7 @@
> #define RSA_NUM4
> #define DSA_NUM3
>
> -#define EC_NUM 16
> +#define EC_NUM 8
> #define MAX_ECDH_SIZE 256
>
> static const char *names[ALGOR_NUM]={
> @@ -512,18 +512,10 @@
> #define R_EC_P1921
> #define R_EC_P2242
> #define R_EC_P2563
> -#define R_EC_P3844
> -#define R_EC_P5215
> -#define R_EC_K1636
> -#define R_EC_K2337
> -#define R_EC_K2838
> -#define R_EC_K4099
> -#define R_EC_K57110
> -#define R_EC_B16311
> -#define R_EC_B23312
> -#define R_EC_B28313
> -#define R_EC_B40914
> -#define R_EC_B57115
> +#define R_EC_K1604
> +#define R_EC_K1925
> +#define R_EC_K2246
[openssl-dev] [openssl.org #4357] NIST SP800-56A co-factor ECDH KATs
Didn't see any co-factor ECDH tests, so here's a PR: https://github.com/openssl/openssl/pull/763 KATs parsed from here: http://csrc.nist.gov/groups/STM/cavp/documents/components/ecccdhtestvectors.zip BBB -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4357 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.
> Thanks! Verify attached diff. Without looking too closely at the asm, at least the output now looks OK to me: Input point: P ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d 5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499 after ecp_nistz256_point_add(A, P, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b after ecp_nistz256_point_double(B, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b I will say that I don't understand how ecp_nistz256_point_add_affine does not have these conditions. Maybe that's a question for the original authors. BBB ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.
> Thanks! Verify attached diff. Without looking too closely at the asm, at least the output now looks OK to me: Input point: P ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d 5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499 after ecp_nistz256_point_add(A, P, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b after ecp_nistz256_point_double(B, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b I will say that I don't understand how ecp_nistz256_point_add_affine does not have these conditions. Maybe that's a question for the original authors. BBB ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] recent EC_PRE_COMP changes
>> Well I don't see an ex_data attached to EC_GROUP or EC_METHOD. > > No, do you need those? We can add them. > >> When I look at ec_lib.c, pre_comp_type is only being checked in switch >> statements in _free and _dup style wrappers. Seems out of place and oddly >> specific. Just one dude's opinion :) > > The precomp stuff is internal to openssl, so I think it's reasonable to put > there. So when I see original comments like this in the EC structures: /* The following members are handled by the method functions, even if they appear generic */ What I expect, and was the behavior at least into 2014, is that e.g. in ec_lib.c group->foo can happen for members "foo" above that comment, but not below that comment. Am I interpreting this wrong? BBB ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.
I verified this bug. At least, I think so.
Input point: P
88c38b77f62c7646 8761482ed66be7ec e29c7ff650f1ad3d a075da5d50ae8d0f
7aecc07d9b4b9a78 11c14dd2ab2cc516 e11dc6d90097e6b6 0ccfcffded344d8c
5723476edeccc439 0ad224b227c5b4e8 c2f7280137f60ac6 c97c65b4fe0fa310
after ecp_nistz256_point_add(A, P, P)
after ecp_nistz256_point_double(B, P)
5dc647edcf585e47 8a1234279b722778 d1fe20832426c68a 8854b03358f4812f
fe8c5c9008a694e5 5187b8b82213bc83 0c1da0ab8aced06c cc08ba7a7c7c7474
88cc2b97e5151f2f fe3275dcd154755a e98898ead6ffac57 282dd53b1eea1cf2
Basically the asm degenerates to
337 if (is_equal(U1, U2) && !in1infty && !in2infty) {
342 memset(r, 0, sizeof(*r));
343 return;
345 }
Since the subsequent (after jz branch taken) point_add arithmetic
causes everything to zero out, so you're left with the point at
infinity.
Note that ecp_nistz256_point_add adds two projective points, so it
doesn't get called for all EC_POINT_mul code paths.
BBB
On Mon, Feb 1, 2016 at 9:59 PM, Jun Sun via RT wrote:
> Hi openssl team,
>
> In function ecp_nistz256_point_add (in ecp_nistz256.c), in the case when U1
> == U2 and S1 == S2, in C reference code, the logic is call
> ecp_nistz256_point_double (line 339) to do a point double operation:
>
>
> 337 if (is_equal(U1, U2) && !in1infty && !in2infty) {
>
> 338 if (is_equal(S1, S2)) {
>
> 339 ecp_nistz256_point_double(r, a);
>
> 340 return;
>
> 341 } else {
>
> 342 memset(r, 0, sizeof(*r));
>
> 343 return;
>
> 344 }
>
> 345 }
>
>
>
>
> This is correct and follow what is described in S.Gueron and V.Krasnov's
> paper. But in x86_64 assembly code (ecp_nistz256-x86_64.pl), this logic is
> not implemented, it fall back to point adding code again:
>
>
> 2385 .byte 0x3e# predict taken
>
> 2386 jnz .Ladd_proceed$x # is_equal(U1,U2)?
>
> 2387 movq%xmm2, $acc0
>
> 2388 movq%xmm3, $acc1
>
> 2389 test$acc0, $acc0
>
> 2390 jnz .Ladd_proceed$x # (in1infty || in2infty)?
>
> 2391 test$acc1, $acc1
>
> 2392 jz .Ladd_proceed$x # is_equal(S1,S2)?
>
>
>
>
> The difference be seen in the latest ectest.c for the group order tests, even
> though both C code and assembly code does not generate any error, but they
> generate different values:
>
>
> 201 scalars[0] = n1;
>
> 202 points[0] = Q; /* => infinity */
>
> 203 scalars[1] = n2;
>
> 204 points[1] = P; /* => -P */
>
> 205 scalars[2] = n1;
>
> 206 points[2] = Q; /* => infinity */
>
> 207 scalars[3] = n2;
>
> 208 points[3] = Q; /* => infinity */
>
> 209 scalars[4] = n1;
>
> 210 points[4] = P; /* => P */
>
> 211 scalars[5] = n2;
>
> 212 points[5] = Q; /* => infinity */
>
> 213 if (!EC_POINTs_mul(group, P, NULL, 6, points, scalars, ctx))
>
> 214 ABORT;
>
> 215 if (!EC_POINT_is_at_infinity(group, P))
>
> 216 ABORT;
>
>
> P is holding different values between C reference C code and assembly code.
> This should not happen if the point doubling function is called in assembly
> code as well.
>
>
>
> Jun Sun
>
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged or confidential. Any distribution, printing
> or other use by anyone else is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete this
> email and attachments.
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.
I verified this bug. At least, I think so.
Input point: P
88c38b77f62c7646 8761482ed66be7ec e29c7ff650f1ad3d a075da5d50ae8d0f
7aecc07d9b4b9a78 11c14dd2ab2cc516 e11dc6d90097e6b6 0ccfcffded344d8c
5723476edeccc439 0ad224b227c5b4e8 c2f7280137f60ac6 c97c65b4fe0fa310
after ecp_nistz256_point_add(A, P, P)
after ecp_nistz256_point_double(B, P)
5dc647edcf585e47 8a1234279b722778 d1fe20832426c68a 8854b03358f4812f
fe8c5c9008a694e5 5187b8b82213bc83 0c1da0ab8aced06c cc08ba7a7c7c7474
88cc2b97e5151f2f fe3275dcd154755a e98898ead6ffac57 282dd53b1eea1cf2
Basically the asm degenerates to
337 if (is_equal(U1, U2) && !in1infty && !in2infty) {
342 memset(r, 0, sizeof(*r));
343 return;
345 }
Since the subsequent (after jz branch taken) point_add arithmetic
causes everything to zero out, so you're left with the point at
infinity.
Note that ecp_nistz256_point_add adds two projective points, so it
doesn't get called for all EC_POINT_mul code paths.
BBB
On Mon, Feb 1, 2016 at 9:59 PM, Jun Sun via RT wrote:
> Hi openssl team,
>
> In function ecp_nistz256_point_add (in ecp_nistz256.c), in the case when U1
> == U2 and S1 == S2, in C reference code, the logic is call
> ecp_nistz256_point_double (line 339) to do a point double operation:
>
>
> 337 if (is_equal(U1, U2) && !in1infty && !in2infty) {
>
> 338 if (is_equal(S1, S2)) {
>
> 339 ecp_nistz256_point_double(r, a);
>
> 340 return;
>
> 341 } else {
>
> 342 memset(r, 0, sizeof(*r));
>
> 343 return;
>
> 344 }
>
> 345 }
>
>
>
>
> This is correct and follow what is described in S.Gueron and V.Krasnov's
> paper. But in x86_64 assembly code (ecp_nistz256-x86_64.pl), this logic is
> not implemented, it fall back to point adding code again:
>
>
> 2385 .byte 0x3e# predict taken
>
> 2386 jnz .Ladd_proceed$x # is_equal(U1,U2)?
>
> 2387 movq%xmm2, $acc0
>
> 2388 movq%xmm3, $acc1
>
> 2389 test$acc0, $acc0
>
> 2390 jnz .Ladd_proceed$x # (in1infty || in2infty)?
>
> 2391 test$acc1, $acc1
>
> 2392 jz .Ladd_proceed$x # is_equal(S1,S2)?
>
>
>
>
> The difference be seen in the latest ectest.c for the group order tests, even
> though both C code and assembly code does not generate any error, but they
> generate different values:
>
>
> 201 scalars[0] = n1;
>
> 202 points[0] = Q; /* => infinity */
>
> 203 scalars[1] = n2;
>
> 204 points[1] = P; /* => -P */
>
> 205 scalars[2] = n1;
>
> 206 points[2] = Q; /* => infinity */
>
> 207 scalars[3] = n2;
>
> 208 points[3] = Q; /* => infinity */
>
> 209 scalars[4] = n1;
>
> 210 points[4] = P; /* => P */
>
> 211 scalars[5] = n2;
>
> 212 points[5] = Q; /* => infinity */
>
> 213 if (!EC_POINTs_mul(group, P, NULL, 6, points, scalars, ctx))
>
> 214 ABORT;
>
> 215 if (!EC_POINT_is_at_infinity(group, P))
>
> 216 ABORT;
>
>
> P is holding different values between C reference C code and assembly code.
> This should not happen if the point doubling function is called in assembly
> code as well.
>
>
>
> Jun Sun
>
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged or confidential. Any distribution, printing
> or other use by anyone else is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete this
> email and attachments.
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4275] Test all built-in curves and let the library choose the EC_METHOD
https://github.com/openssl/openssl/pull/592 Some of the other unit tests specify EC_METHOD. This additional test loop lets the library choose based on the default for the built-in curve's NID. BBB ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] recent EC_PRE_COMP changes
>> That commit caused EC_PRE_COMP to lose a lot of generality. Was a function >> pointer approach like below considered? I'm not trying to resurrect >> EC_EXTRA_DATA, but a *little* flexibility would be nice. > > What functionality was lost that isn't available in the public and standard > EX_DATA model? Well I don't see an ex_data attached to EC_GROUP or EC_METHOD. I must be missing something? I guess I can hijack one of the spare void pointers in EC_GROUP. I was somewhat familiar with the old point precomp flow for an EC_METHOD, so I'm having a bit of trouble wrapping my head around it. When I look at ec_lib.c, pre_comp_type is only being checked in switch statements in _free and _dup style wrappers. Seems out of place and oddly specific. Just one dude's opinion :) Thanks! BBB ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] recent EC_PRE_COMP changes
https://github.com/openssl/openssl/commit/3aef36ffef89849348049296892327e6fdf9d705
That commit caused EC_PRE_COMP to lose a lot of generality. Was a
function pointer approach like below considered? I'm not trying to
resurrect EC_EXTRA_DATA, but a *little* flexibility would be nice.
BBB
diff --git a/crypto/ec/ec_lcl.h b/crypto/ec/ec_lcl.h
index 2c5e1d9..9f5d4ec 100644
--- a/crypto/ec/ec_lcl.h
+++ b/crypto/ec/ec_lcl.h
@@ -256,24 +256,11 @@ struct ec_group_st {
BN_MONT_CTX *mont_data;
/* precomputed values for speed. */
-enum {
-pct_none,
-pct_nistp224, pct_nistp256, pct_nistp521, pct_nistz256,
-pct_ec } pre_comp_type;
-union {
-NISTP224_PRE_COMP *nistp224;
-NISTP256_PRE_COMP *nistp256;
-NISTP521_PRE_COMP *nistp521;
-NISTZ256_PRE_COMP *nistz256;
-EC_PRE_COMP *ec;
-} pre_comp;
+void (*pre_comp_free) (EC_PRE_COMP *);
+EC_PRE_COMP *(*pre_comp_dup) (EC_PRE_COMP *);
+EC_PRE_COMP *pre_comp;
} /* EC_GROUP */ ;
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4269] Extend ECDH tests to more curves. Add more ECDH KATs.
https://github.com/openssl/openssl/pull/587 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3863] [PATCH] ECC: Add missing NULL check. Set a flag.
https://github.com/openssl/openssl/pull/575 On Tue, May 26, 2015 at 9:06 PM, Billy Brumley via RT <r...@openssl.org> wrote: > Set point->Z_is_one flag after setting point->Z to one. Also check > BIGNUM for NULL before passing it to get_affine_coordinates. > > BBB > > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3863] [PATCH] ECC: Add missing NULL check. Set a flag.
https://github.com/openssl/openssl/pull/575 On Tue, May 26, 2015 at 9:06 PM, Billy Brumley via RT <r...@openssl.org> wrote: > Set point->Z_is_one flag after setting point->Z to one. Also check > BIGNUM for NULL before passing it to get_affine_coordinates. > > BBB > > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] ECDSA side-channel attack mitigation
Seems doubtful -- some patches hit the list a while back, but never got picked up. See RT 3741 and RT 3667. BBB On Tue, Aug 25, 2015 at 11:15 PM, John Foley fol...@cisco.com wrote: Is OpenSSL planning to implement side-channel resistance against the following attack: https://eprint.iacr.org/2014/161.pdf ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4013] [PATCH] Binary ECC: lambda projective coordinates
address sizes: 39 bits physical, 48 bits virtual
power management: SNIP
From e7d26ad981772aacfa0e5607c9c392c9786c0bff Mon Sep 17 00:00:00 2001
From: Billy Brumley bbrum...@gmail.com
Date: Thu, 20 Aug 2015 18:13:23 +0300
Subject: [PATCH] Binary ECC: lambda projective coordinates
---
crypto/ec/Makefile | 13 +-
crypto/ec/ec2_lambda.c | 438 +
crypto/ec/ec2_smpl.c | 1 +
crypto/ec/ec_cvt.c | 7 +-
crypto/ec/ec_key.c | 2 +
crypto/ec/ec_lcl.h | 15 ++
include/openssl/ec.h | 5 +
7 files changed, 478 insertions(+), 3 deletions(-)
create mode 100644 crypto/ec/ec2_lambda.c
diff --git a/crypto/ec/Makefile b/crypto/ec/Makefile
index a2c135a..242573d 100644
--- a/crypto/ec/Makefile
+++ b/crypto/ec/Makefile
@@ -19,13 +19,13 @@ GENERAL=Makefile
LIB=$(TOP)/libcrypto.a
LIBSRC= ec_lib.c ecp_smpl.c ecp_mont.c ecp_nist.c ec_cvt.c ec_mult.c\
ec_err.c ec_curve.c ec_check.c ec_print.c ec_asn1.c ec_key.c\
- ec2_smpl.c ec2_mult.c ec_ameth.c ec_pmeth.c eck_prn.c \
+ ec2_smpl.c ec2_lambda.c ec2_mult.c ec_ameth.c ec_pmeth.c eck_prn.c \
ecp_nistp224.c ecp_nistp256.c ecp_nistp521.c ecp_nistputil.c \
ecp_oct.c ec2_oct.c ec_oct.c
LIBOBJ= ec_lib.o ecp_smpl.o ecp_mont.o ecp_nist.o ec_cvt.o ec_mult.o\
ec_err.o ec_curve.o ec_check.o ec_print.o ec_asn1.o ec_key.o\
- ec2_smpl.o ec2_mult.o ec_ameth.o ec_pmeth.o eck_prn.o \
+ ec2_smpl.o ec2_lambda.o ec2_mult.o ec_ameth.o ec_pmeth.o eck_prn.o \
ecp_nistp224.o ecp_nistp256.o ecp_nistp521.o ecp_nistputil.o \
ecp_oct.o ec2_oct.o ec_oct.o $(EC_ASM)
@@ -113,6 +113,15 @@ ec2_smpl.o: ../../include/openssl/opensslv.h ../../include/openssl/ossl_typ.h
ec2_smpl.o: ../../include/openssl/safestack.h ../../include/openssl/stack.h
ec2_smpl.o: ../../include/openssl/symhacks.h ../include/internal/bn_int.h
ec2_smpl.o: ec2_smpl.c ec_lcl.h
+ec2_lambda.o: ../../include/openssl/asn1.h ../../include/openssl/bio.h
+ec2_lambda.o: ../../include/openssl/bn.h ../../include/openssl/crypto.h
+ec2_lambda.o: ../../include/openssl/e_os2.h ../../include/openssl/ec.h
+ec2_lambda.o: ../../include/openssl/err.h ../../include/openssl/lhash.h
+ec2_lambda.o: ../../include/openssl/obj_mac.h ../../include/openssl/opensslconf.h
+ec2_lambda.o: ../../include/openssl/opensslv.h ../../include/openssl/ossl_typ.h
+ec2_lambda.o: ../../include/openssl/safestack.h ../../include/openssl/stack.h
+ec2_lambda.o: ../../include/openssl/symhacks.h ../include/internal/bn_int.h
+ec2_lambda.o: ec2_lambda.c ec_lcl.h
ec_ameth.o: ../../e_os.h ../../include/openssl/asn1.h
ec_ameth.o: ../../include/openssl/asn1t.h ../../include/openssl/bio.h
ec_ameth.o: ../../include/openssl/bn.h ../../include/openssl/buffer.h
diff --git a/crypto/ec/ec2_lambda.c b/crypto/ec/ec2_lambda.c
new file mode 100644
index 000..36248a5
--- /dev/null
+++ b/crypto/ec/ec2_lambda.c
@@ -0,0 +1,438 @@
+/* crypto/ec/ec2_lambda.c */
+/**
+ * Binary curve arithmetic using lambda-projective coordinates.
+ * Only supports short binary curve coeffs a=0 and a=1.
+ * Essentially projective form of (x, y) - (x, lambda)
+ * where lambda = x XOR y/x.
+ *
+ * NB: Everything internally is lambda-affine/proj, relies
+ * on set/get_affine_coordinates function pointers for the
+ * external-facing interface to handle the conversion
+ * to/from the standard short form.
+ *
+ * See Faster Binary Curve Software: A Case Study,
+ * NordSec 2015, to appear.
+ *
+ * @author Billy Brumley billy.brumley AT tut DOT fi
+ */
+
+#include openssl/err.h
+
+#include internal/bn_int.h
+#include ec_lcl.h
+
+#ifndef OPENSSL_NO_EC2M
+
+const EC_METHOD *EC_GF2m_lambda_method(void)
+{
+static const EC_METHOD ret = {
+EC_FLAGS_DEFAULT_OCT,
+NID_X9_62_characteristic_two_field,
+ec_GF2m_simple_group_init,
+ec_GF2m_simple_group_finish,
+ec_GF2m_simple_group_clear_finish,
+ec_GF2m_simple_group_copy,
+ec_GF2m_simple_group_set_curve,
+ec_GF2m_simple_group_get_curve,
+ec_GF2m_simple_group_get_degree,
+ec_GF2m_simple_group_check_discriminant,
+ec_GF2m_simple_point_init,
+ec_GF2m_simple_point_finish,
+ec_GF2m_simple_point_clear_finish,
+ec_GF2m_simple_point_copy,
+ec_GF2m_simple_point_set_to_infinity,
+0 /* set_Jprojective_coordinates_GFp */ ,
+0 /* get_Jprojective_coordinates_GFp */ ,
+ec_GF2m_lambda_point_set_affine_coordinates,
+ec_GF2m_lambda_point_get_affine_coordinates,
+0, 0, 0,
+ec_GF2m_lambda_add,
+ec_GF2m_lambda_dbl,
+ec_GF2m_lambda_invert,
+ec_GF2m_simple_is_at_infinity,
+ec_GF2m_lambda_is_on_curve,
+ec_GF2m_simple_cmp,
+ec_GF2m_lambda_make_affine,
+ec_GF2m_simple_points_make_affine,
+0 /* mul defaults to ec_wNAF_mul */ ,
+/* next two functions defined in ec2_mult.c */
+ec_GF2m_precompute_mult,
+ec_GF2m_have_precompute_mult,
+ec_GF2m_simple_field_mul
[openssl-dev] [openssl.org #3863] [PATCH] ECC: Add missing NULL check. Set a flag.
Set point-Z_is_one flag after setting point-Z to one. Also check
BIGNUM for NULL before passing it to get_affine_coordinates.
BBB
From c9dc41fc0b91d7b3bf53871049881a68ed655bcf Mon Sep 17 00:00:00 2001
From: Billy Brumley bbrum...@gmail.com
Date: Tue, 26 May 2015 17:35:03 +0300
Subject: [PATCH] ECC: Add missing NULL check. Set a flag.
---
crypto/ec/ec2_smpl.c | 1 +
crypto/ec/ec_key.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/crypto/ec/ec2_smpl.c b/crypto/ec/ec2_smpl.c
index d6a41a4..eafe4ae 100644
--- a/crypto/ec/ec2_smpl.c
+++ b/crypto/ec/ec2_smpl.c
@@ -742,6 +742,7 @@ int ec_GF2m_simple_make_affine(const EC_GROUP *group, EC_POINT *point,
goto err;
if (!BN_one(point-Z))
goto err;
+point-Z_is_one = 1;
ret = 1;
diff --git a/crypto/ec/ec_key.c b/crypto/ec/ec_key.c
index 07c33fe..e6cd2dd 100644
--- a/crypto/ec/ec_key.c
+++ b/crypto/ec/ec_key.c
@@ -369,6 +369,8 @@ int EC_KEY_set_public_key_affine_coordinates(EC_KEY *key, BIGNUM *x,
tx = BN_CTX_get(ctx);
ty = BN_CTX_get(ctx);
+if (ty == NULL)
+goto err;
#ifndef OPENSSL_NO_EC2M
if (is_char_two) {
if (!EC_POINT_set_affine_coordinates_GF2m(key-group, point,
--
1.9.1
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3858] [PATCH] fix copy paste error in ec_GF2m function prototypes
Just removes some duplication in the header file. Patch attached. BBB From ad6f09994d0cb2dd49d7356cff1dcf294d908f3f Mon Sep 17 00:00:00 2001 From: Billy Brumley bbrum...@gmail.com Date: Fri, 22 May 2015 17:44:49 +0300 Subject: [PATCH] fix copy paste error in ec_GF2m function prototypes --- crypto/ec/ec_lcl.h | 8 1 file changed, 8 deletions(-) diff --git a/crypto/ec/ec_lcl.h b/crypto/ec/ec_lcl.h index 9db7106..3bf64c6 100644 --- a/crypto/ec/ec_lcl.h +++ b/crypto/ec/ec_lcl.h @@ -453,14 +453,6 @@ int ec_GF2m_simple_mul(const EC_GROUP *group, EC_POINT *r, int ec_GF2m_precompute_mult(EC_GROUP *group, BN_CTX *ctx); int ec_GF2m_have_precompute_mult(const EC_GROUP *group); -/* method functions in ec2_mult.c */ -int ec_GF2m_simple_mul(const EC_GROUP *group, EC_POINT *r, - const BIGNUM *scalar, size_t num, - const EC_POINT *points[], const BIGNUM *scalars[], - BN_CTX *); -int ec_GF2m_precompute_mult(EC_GROUP *group, BN_CTX *ctx); -int ec_GF2m_have_precompute_mult(const EC_GROUP *group); - #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128 /* method functions in ecp_nistp224.c */ int ec_GFp_nistp224_group_init(EC_GROUP *group); -- 1.9.1 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3741] [PATCH] Better side-channel security for ECC table lookups
This patch relates to RT 3667 and the paper here (to appear at COSADE 2015):
https://eprint.iacr.org/2015/036
Instead of a direct table lookup for precomputed points in the generic
ECC multi-scalar multiplication routine, it computes the point by
traversing the entire table. Motivation is better side-channel
security.
Benchmarking below (evidently code path is not executed for nistp256
anymore). Costs are 6-10% for ECDSA sign, 2-6% for ECDSA verify
(defense unnecessary, but AFAICT there is no way to authoritatively
distinguish at this depth whether to protect scalars or not), and 1-5%
for ECDH.
BBB
openssl speed ecdsa before:
signverifysign/s verify/s
160 bit ecdsa (secp160r1) 0.s 0.0002s 20818.1 5670.3
192 bit ecdsa (nistp192) 0.0001s 0.0002s 17844.1 4570.7
224 bit ecdsa (nistp224) 0.0001s 0.0003s 13452.7 3413.4
256 bit ecdsa (nistp256) 0.s 0.0001s 26485.2 10577.4
384 bit ecdsa (nistp384) 0.0002s 0.0007s 5961.0 1438.0
521 bit ecdsa (nistp521) 0.0004s 0.0015s 2837.1684.5
openssl speed ecdsa after:
signverifysign/s verify/s
160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19056.1 5369.1
192 bit ecdsa (nistp192) 0.0001s 0.0002s 16270.0 4490.4
224 bit ecdsa (nistp224) 0.0001s 0.0003s 12150.9 3354.7
256 bit ecdsa (nistp256) 0.s 0.0001s 26489.9 10554.9
384 bit ecdsa (nistp384) 0.0002s 0.0007s 5470.9 1355.5
521 bit ecdsa (nistp521) 0.0004s 0.0015s 2673.3667.4
openssl speed ecdh before:
op op/s
160 bit ecdh (secp160r1) 0.0001s 7025.0
192 bit ecdh (nistp192) 0.0002s 5786.0
224 bit ecdh (nistp224) 0.0002s 4158.1
256 bit ecdh (nistp256) 0.0001s 14899.7
384 bit ecdh (nistp384) 0.0006s 1732.1
521 bit ecdh (nistp521) 0.0012s820.4
openssl speed ecdh after:
op op/s
160 bit ecdh (secp160r1) 0.0001s 6750.8
192 bit ecdh (nistp192) 0.0002s 5477.6
224 bit ecdh (nistp224) 0.0002s 4060.2
256 bit ecdh (nistp256) 0.0001s 14886.2
384 bit ecdh (nistp384) 0.0006s 1709.7
521 bit ecdh (nistp521) 0.0012s802.1
(I do not have root on the benchmarking machine to peg the clock. Sorry.)
$ cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 60
model name: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
stepping: 3
microcode: 26
cpu MHz: 800.000
cache size: 6144 KB
physical id: 0
siblings: 4
core id: 0
cpu cores: 4
apicid: 0
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2
x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm abm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi
flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid
rtm
bogomips: 6385.38
clflush size: 64
cache_alignment: 64
address sizes: 39 bits physical, 48 bits virtual
power management: SNIP
diff -rupN openssl-1.0.2_orig/crypto/ec/ec_mult.c
openssl-1.0.2/crypto/ec/ec_mult.c
--- openssl-1.0.2_orig/crypto/ec/ec_mult.c 2015-01-22 16:58:32.0
+0200
+++ openssl-1.0.2/crypto/ec/ec_mult.c 2015-03-10 13:06:50.661644241 +0200
@@ -306,6 +306,66 @@ static signed char *compute_wNAF(const B
return r;
}
+/**
+ * Traverses t[i] for 0 = i 2**(w-1) and places t[digit 1] in r
+ * with bitwise operations as a side-channel defense.
+ * Assumes r has enough BIGNUM space so tops of BIGNUMs in t do not overflow.
+ * See https://eprint.iacr.org/2015/036
+ */
+void EC_POINT_select(EC_POINT *r, EC_POINT **t, int digit, int w, int top) {
+
+w = (1 w);
+
+int d, j;
+BN_ULONG mask;
+
+for(j=0; jtop; j++) {
+r-X.d[j] = 0;
+r-Y.d[j] = 0;
+r-Z.d[j] = 0;
+}
+r-X.top= 0;
+r-X.dmax = 0;
+r-X.neg= 0;
+r-X.flags = 0;
+r-Y.top= 0;
+r-Y.dmax = 0;
+r-Y.neg= 0;
+r-Y.flags = 0;
+r-Z.top= 0;
+r-Z.dmax = 0;
+r-Z.neg= 0;
+r-Z.flags = 0;
+r-Z_is_one = 0;
+
+for(d=1; dw; d+=2) {
+mask = (BN_ULONG)(((digit ^ d) - 1) 15);
+for(j=0; jt[d 1]-X.top; j++) {
+r-X.d[j] |= mask t[d 1]-X.d[j];
+}
+for(j=0; jt[d 1]-Y.top; j++) {
+r-Y.d[j] |= mask t[d 1]-Y.d[j];
+}
+for(j=0; jt[d 1]-Z.top; j++) {
+r-Z.d[j] |= mask t[d 1]-Z.d[j];
+}
+r-X.top|= mask (t[d 1]-X.top );
+r-X.dmax |= mask (t[d 1]-X.dmax );
+
[openssl-dev] [openssl.org #3667] [PATCH] Faster GLV elliptic curves
},
- { NID_secp224k1, _EC_SECG_PRIME_224K1.h, 0, SECG curve over a 224 bit
prime field },
+ { NID_secp192k1, _EC_SECG_PRIME_192K1.h, EC_GFp_glv_method, SECG
curve over a 192 bit prime field },
+ { NID_secp224k1, _EC_SECG_PRIME_224K1.h, EC_GFp_glv_method, SECG
curve over a 224 bit prime field },
#ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
{ NID_secp224r1, _EC_NIST_PRIME_224.h, EC_GFp_nistp224_method,
NIST/SECG curve over a 224 bit prime field },
#else
{ NID_secp224r1, _EC_NIST_PRIME_224.h, 0, NIST/SECG curve over a 224
bit prime field },
#endif
- { NID_secp256k1, _EC_SECG_PRIME_256K1.h, 0, SECG curve over a 256 bit
prime field },
+ { NID_secp256k1, _EC_SECG_PRIME_256K1.h, EC_GFp_glv_method, SECG
curve over a 256 bit prime field },
/* SECG secp256r1 is the same as X9.62 prime256v1 and hence omitted */
{ NID_secp384r1, _EC_NIST_PRIME_384.h, 0, NIST/SECG curve over a 384
bit prime field },
#ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/ec.h
openssl-1.0.1l/crypto/ec/ec.h
--- openssl-1.0.1l-orig/crypto/ec/ec.h 2015-01-15 16:43:49.0 +0200
+++ openssl-1.0.1l/crypto/ec/ec.h 2015-01-19 13:43:50.864153182 +0200
@@ -146,6 +146,11 @@
*/
const EC_METHOD *EC_GFp_mont_method(void);
+/** Returns GFp methods using optimized methods for GLV curves
+ * \return EC_METHOD object
+ */
+const EC_METHOD *EC_GFp_glv_method(void);
+
/** Returns GFp methods using optimized methods for NIST recommended curves
* \return EC_METHOD object
*/
diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/ec_lcl.h
openssl-1.0.1l/crypto/ec/ec_lcl.h
--- openssl-1.0.1l-orig/crypto/ec/ec_lcl.h 2015-01-15 16:43:49.0
+0200
+++ openssl-1.0.1l/crypto/ec/ec_lcl.h 2015-01-19 13:43:51.080045178 +0200
@@ -348,6 +348,13 @@
int ec_GFp_mont_field_set_to_one(const EC_GROUP *, BIGNUM *r, BN_CTX *);
+/* method functions in ecp_glv.c */
+int ec_GFp_glv_mul(const EC_GROUP *group, EC_POINT *r, const BIGNUM *scalar,
+ size_t num, const EC_POINT *points[], const BIGNUM *scalars[], BN_CTX
*ctx);
+int ec_GFp_glv_precompute_mult(EC_GROUP *group, BN_CTX *ctx);
+int ec_GFp_glv_have_precompute_mult(const EC_GROUP *group);
+
+
/* method functions in ecp_nist.c */
int ec_GFp_nist_group_copy(EC_GROUP *dest, const EC_GROUP *src);
int ec_GFp_nist_group_set_curve(EC_GROUP *, const BIGNUM *p, const BIGNUM *a,
const BIGNUM *b, BN_CTX *);
diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/ecp_glv.c
openssl-1.0.1l/crypto/ec/ecp_glv.c
--- openssl-1.0.1l-orig/crypto/ec/ecp_glv.c 1970-01-01 02:00:00.0
+0200
+++ openssl-1.0.1l/crypto/ec/ecp_glv.c 2015-01-20 11:30:44.442723943 +0200
@@ -0,0 +1,336 @@
+#include openssl/err.h
+
+#ifdef OPENSSL_FIPS
+#include openssl/fips.h
+#endif
+
+#include ec_lcl.h
+
+/**
+ * Faster scalar multiplication for GLV curves:
+ * http://eprint.iacr.org/2015/036
+ *
+ * @author Billy Brumley billy.brumley AT tut DOT fi
+ */
+
+const EC_METHOD *EC_GFp_glv_method(void)
+ {
+ static const EC_METHOD ret = {
+ EC_FLAGS_DEFAULT_OCT,
+ NID_X9_62_prime_field,
+ ec_GFp_mont_group_init,
+ ec_GFp_mont_group_finish,
+ ec_GFp_mont_group_clear_finish,
+ ec_GFp_mont_group_copy,
+ ec_GFp_mont_group_set_curve,
+ ec_GFp_simple_group_get_curve,
+ ec_GFp_simple_group_get_degree,
+ ec_GFp_simple_group_check_discriminant,
+ ec_GFp_simple_point_init,
+ ec_GFp_simple_point_finish,
+ ec_GFp_simple_point_clear_finish,
+ ec_GFp_simple_point_copy,
+ ec_GFp_simple_point_set_to_infinity,
+ ec_GFp_simple_set_Jprojective_coordinates_GFp,
+ ec_GFp_simple_get_Jprojective_coordinates_GFp,
+ ec_GFp_simple_point_set_affine_coordinates,
+ ec_GFp_simple_point_get_affine_coordinates,
+ 0,0,0,
+ ec_GFp_simple_add,
+ ec_GFp_simple_dbl,
+ ec_GFp_simple_invert,
+ ec_GFp_simple_is_at_infinity,
+ ec_GFp_simple_is_on_curve,
+ ec_GFp_simple_cmp,
+ ec_GFp_simple_make_affine,
+ ec_GFp_simple_points_make_affine,
+ ec_GFp_glv_mul,
+ ec_GFp_glv_precompute_mult,
+ ec_GFp_glv_have_precompute_mult,
+ ec_GFp_mont_field_mul,
+ ec_GFp_mont_field_sqr,
+ 0 /* field_div */,
+ ec_GFp_mont_field_encode,
+ ec_GFp_mont_field_decode,
+ ec_GFp_mont_field_set_to_one };
+
+#ifdef OPENSSL_FIPS
+ if (FIPS_mode())
+ return fips_ec_gfp_glv_method();
+#endif
+
+ return ret;
+ }
+
+/* GLV-related per-curve constants */
+static const unsigned char glv_constants_secp160k1[] = {
+ /* beta */
+ 0x9b,0xa4,0x8c,0xba
Re: [openssl.org #3607] nistz256 is broken.
Thanks for the reply, Rich. 2. When will RT2574 be integrated to protect our ECC keys in the inevitable presence of software defects like this? http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest Timing attacks on ECC isn't a very high priority right now, given all the other bigger easier to exploit issues with wider deployment :( The way I see it, the main purpose of that patch is to prevent bug attacks, not timing attacks. Hence the relation to the arithmetic bug. BBB __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3607] nistz256 is broken.
1. Where's the security analysis? Does https://eprint.iacr.org/2011/633 apply? 2. When will RT2574 be integrated to protect our ECC keys in the inevitable presence of software defects like this? http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest These questions are not necessarily for Adam, but the OpenSSL team. BBB On Sun, Nov 23, 2014 at 8:09 PM, Adam Langley via RT r...@openssl.org wrote: (Affects 1.0.2 only.) In crypto/ec/asm/ecp_nistz256-x86_64.pl, __ecp_nistz256_sqr_montq, under Now the reduction there are a number of comments saying doesn't overflow. Unfortunately, they aren't correct. Let f be a field element with value 52998265219372519138277318009572834528257482223861497652862868020346603903843. In Montgomery form, it's represented in memory as f*2^256 mod p, which is 58733536287848456860684025065811053850702581988990452502702607007944524443511. When passed to ecp_nistz256_sqr_mont, this results in the intermediate value (before any reduction) 0x41dd6e8bcf7e19f499c19d0f5f3bba78272201eee64c6a44ca8a4ff275b53fa93b41d5b7035af3e40a05dc36f424ab9438cdec4fa193faebf6ce951. r10 in this case contains 0x40a05dc3 and the high-word output of the multiplication after # First iteration is 0xfa193fad. The addition of r8 and r9 overflows into it leaving it as 0xfa193fae. The addition of rax and r9 also sets the carry flag thus the final add-with-carry of rdx into r10 easily overflows and leaves r10 as 0x3ab99d72. Additionally, I'm not sure about any of the other cases in the same function that have been annotated the same way. There is also a similar annotation in ecp_nistz256_mul_mont that I've not investigated. Cheers AGL __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2569] [PATCH] EC_POINT_invert checks wrong function pointer
Bump. Three year anniversary! Where's my leather gift?! At least libressl picked it up: https://github.com/libressl-portable/openbsd/commit/530a3e9ab5b28202266d1a443d4f0da1d2452372 BBB On Wed, Oct 16, 2013 at 1:08 PM, Billy Brumley bbrum...@gmail.com wrote: Bump. 2 years and counting. http://rt.openssl.org/Ticket/Display.html?id=2569user=guestpass=guest BBB On Wed, Mar 7, 2012 at 3:54 PM, Billy Brumley bbrum...@gmail.com wrote: Bump. On Fri, Jul 22, 2011 at 2:49 AM, Billy Brumley via RT r...@openssl.org wrote: In crypto/ec/ec_lib.c function EC_POINT_invert checks dbl function pointer instead of invert. Fix attached. Billy __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3425] Potential padding oracle in evp_enc.c
Its timing too. Not just return values. Early exit. BBB Not sure what you're pointing out. That there are different return values? This is a local API, so warning users to not expose detail errors would address this, right? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3416] PATCH: EVP_EncryptionInit and AES-NI note
Excellent. What about other cryptosystem implementations within OpenSSL? You should take a look at the DSA and ECDSA code and write a blog about that, too. BBB On Wed, Jul 2, 2014 at 9:13 PM, Huzaifa Sidhpurwala sidhpurwala.huza...@gmail.com wrote: Hi All, Since we are talking about AES implementation in OpenSSL, Andy and myself wrote a blog about it (well its actually about this paper claiming that AES is vulnerable to timing attacks but nicely describes how AES is implemented in OpenSSL) https://securityblog.redhat.com/2014/07/02/its-all-a-question-of-time-aes-timing-attacks-on-openssl/ On Thu, Jul 3, 2014 at 5:23 AM, noloa...@gmail.com via RT r...@openssl.org wrote: Since this may in future cover much more than just AES-NI... Good observation Doctor, done. Attached is the updated text. diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod index f6e4396..8d7636c 100644 --- a/doc/crypto/EVP_EncryptInit.pod +++ b/doc/crypto/EVP_EncryptInit.pod @@ -433,7 +433,10 @@ for AES. Where possible the BEVP interface to symmetric ciphers should be used in preference to the low level interfaces. This is because the code then becomes -transparent to the cipher used and much more flexible. +transparent to the cipher used and much more flexible. Additionally, the +BEVP interface will ensure the use of platform specific cryptographic +acceleration such as AES-NI (the low level interfaces do not provide the +guarantee). PKCS padding works by adding Bn padding bytes of value Bn to make the total length of the encrypted data a multiple of the block size. Padding is always * On Wed, Jul 2, 2014 at 12:08 PM, Stephen Henson via RT r...@openssl.org wrote: On Wed Jul 02 07:12:19 2014, noloa...@gmail.com wrote: Questions on AES-NI and how to enable them have come up twice recently on the stack exchanges (like stack overflow). This patch documents use of the AES-NI instruction by way of the EVP_* interface. Since this may in future cover much more than just AES-NI I'd suggest we say something like platform specific cryptographic acceleration such as AES-NI. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: speedup in ecdsa_do_verify by not using montgomery ladder for sidechannel silencing ?
ec_GFp_mont_field_mul is for the field multiplication. It depends on the curve, but most GF(p) curves will drill down to a function pointer to ec_wNAF_mul for the point multiplication. Check crypto/ec/ec_lib.c. BBB On Tue, Apr 22, 2014 at 7:10 PM, ; neura...@gmail.com wrote: Hi Guys Wouldnt it be much faster to non sidechannel silencing montgomery variants for muls in ecdsa_do_verify? I mean since for verify we use only public keys anyways. ecdsa_do_verify calls generic EC_POINT_mul which calls (plugged in during init) ec_GFp_mont_field_mul instead of ec_wNAF_mul ? wouldnt it be better then to call ec_wNAF_mul instead of EC_POINT_mul in ecdsa_do_verify ? Just thinking about it since speeding up indexing bitcoin on first start by speeding up ecc.verify would be great. Sorry for stupid idea ;) Ladislav Nevery -- -
Re: [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm
Say order is m bits. Then k+order is either m or m+1 bits. The condition fixes it at m+1. (You're right that for most standardized curves the branch is either negligibly taken or overwhelmingly taken, depending on what the order looks like.) BBB On Apr 23, 2014 12:52 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: 23-Apr-2014 20:48, Billy Brumley пишет: Please read CVE-2011-1945. You need to propagate the fix in gost2001_do_sign. If you're unsure, check the comments in crypto/ecdsa/ecs_ossl.c. I see the place you refer to. What I can't quite get in this piece is adding `order` 2 times. Shouldn't the first BN_add get us where we want (that is a number as wide as `order`)? /* We do not want timing information to leak the length of k, * so we compute G*k using an equivalent scalar of fixed * bit-length. */ if (!BN_add(k, k, order)) goto err; //---here I would expect k to be order afterwards if (BN_num_bits(k) = BN_num_bits(order)) // then this is trivially false? if (!BN_add(k, k, order)) goto err; //and this should not even be reached? ... BBB -- Dmitry Olshansky __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2569] [PATCH] EC_POINT_invert checks wrong function pointer
Bump. On Fri, Jul 22, 2011 at 2:49 AM, Billy Brumley via RT r...@openssl.org wrote: In crypto/ec/ec_lib.c function EC_POINT_invert checks dbl function pointer instead of invert. Fix attached. Billy __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2574] [PATCH] ECC point coordinate blinding
The attached patch is against openssl-1.0.1-stable-SNAP-20110729 and
implements coordinate blinding. This randomizes the representative of
an elliptic curve point in its equivalence class. (For methods that
use projective coords such as curves over prime fields; for affine
coords, it does nothing.)
Coordinate blinding is a generally useful side-channel countermeasure
and is (mostly) free. The function itself takes a few field mults, but
is usually only necessary at the beginning of a scalar multiplication
(as implemented in the patch). When used this way, it makes the values
that variables take (i.e., field elements in an algorithm state)
unpredictable.
Only affine coords are implemented for curves over binary fields. If
this changes in the future, the corresponding blinding function can
easily be added.
If there are questions/concerns, please ask.
Billy
diff -ur openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec2_smpl.c openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec2_smpl.c
--- openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec2_smpl.c 2011-06-06 19:00:23.0 +0300
+++ openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec2_smpl.c 2011-07-29 10:20:44.631809857 +0300
@@ -107,6 +107,7 @@
ec_GF2m_simple_add,
ec_GF2m_simple_dbl,
ec_GF2m_simple_invert,
+ 0 /* blind_coordinates */,
ec_GF2m_simple_is_at_infinity,
ec_GF2m_simple_is_on_curve,
ec_GF2m_simple_cmp,
diff -ur openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec_err.c openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec_err.c
--- openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec_err.c 2011-06-06 15:00:18.0 +0300
+++ openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec_err.c 2011-07-29 10:32:56.011974902 +0300
@@ -1,6 +1,6 @@
/* crypto/ec/ec_err.c */
/*
- * Copyright (c) 1999-2010 The OpenSSL Project. All rights reserved.
+ * Copyright (c) 1999-2011 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -161,6 +161,7 @@
{ERR_FUNC(EC_F_EC_KEY_SET_PUBLIC_KEY_AFFINE_COORDINATES), EC_KEY_set_public_key_affine_coordinates},
{ERR_FUNC(EC_F_EC_POINTS_MAKE_AFFINE), EC_POINTs_make_affine},
{ERR_FUNC(EC_F_EC_POINT_ADD), EC_POINT_add},
+{ERR_FUNC(EC_F_EC_POINT_BLIND_COORDINATES), EC_POINT_blind_coordinates},
{ERR_FUNC(EC_F_EC_POINT_CMP), EC_POINT_cmp},
{ERR_FUNC(EC_F_EC_POINT_COPY), EC_POINT_copy},
{ERR_FUNC(EC_F_EC_POINT_DBL), EC_POINT_dbl},
diff -ur openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec.h openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec.h
--- openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec.h 2011-06-06 17:00:17.0 +0300
+++ openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec.h 2011-07-29 10:32:56.011974902 +0300
@@ -592,6 +592,18 @@
*/
int EC_POINT_invert(const EC_GROUP *group, EC_POINT *a, BN_CTX *ctx);
+/* J. S. Coron: Resistance against Differential Power Analysis for Elliptic
+ * Curve Cryptosystems. CHES 1999: 292-302.
+ * Coordinate blinding from Sec. 5.3 is generally a useful countermeasure
+ * against many types of side-channel attacks because it introduces some
+ * randomness into the algorithm state and doesn't really cost anything.
+ * \param group underlying EC_GROUP object
+ * \param a EC_POINT object to be coord-blinded (it's used for the result as well)
+ * \param ctxBN_CTX object (optional)
+ * \return 1 on success and 0 if an error occured
+ */
+int EC_POINT_blind_coordinates(const EC_GROUP *group, EC_POINT *a, BN_CTX *ctx);
+
/** Checks whether the point is the neutral element of the group
* \param group the underlying EC_GROUP object
* \param p EC_POINT object
@@ -1048,6 +1060,7 @@
#define EC_F_EC_KEY_SET_PUBLIC_KEY_AFFINE_COORDINATES 229
#define EC_F_EC_POINTS_MAKE_AFFINE 136
#define EC_F_EC_POINT_ADD 112
+#define EC_F_EC_POINT_BLIND_COORDINATES 230
#define EC_F_EC_POINT_CMP 113
#define EC_F_EC_POINT_COPY 114
#define EC_F_EC_POINT_DBL 115
diff -ur openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec_lcl.h openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec_lcl.h
--- openssl-1.0.1-stable-SNAP-20110729-orig/crypto/ec/ec_lcl.h 2011-06-06 17:00:17.0 +0300
+++ openssl-1.0.1-stable-SNAP-20110729/crypto/ec/ec_lcl.h 2011-07-29 10:04:26.268336600 +0300
@@ -142,10 +142,11 @@
int (*oct2point)(const EC_GROUP *, EC_POINT *,
const unsigned char *buf, size_t len, BN_CTX *);
- /* used by EC_POINT_add, EC_POINT_dbl, ECP_POINT_invert: */
+ /* used by EC_POINT_add, EC_POINT_dbl, EC_POINT_invert, EC_POINT_blind_coordinates: */
int (*add)(const EC_GROUP *, EC_POINT *r, const EC_POINT *a, const EC_POINT *b, BN_CTX *);
int (*dbl)(const EC_GROUP *, EC_POINT *r, const EC_POINT *a, BN_CTX *);
int (*invert)(const EC_GROUP *, EC_POINT *, BN_CTX *);
+ int (*blind_coordinates)(const EC_GROUP *, EC_POINT *, BN_CTX *);
Re: help in edsa functions
I think you want a key, not the group.
EC_GROUP_new_by_curve_name = EC_KEY_new_by_curve_name
Billy
On Mon, Mar 2, 2009 at 6:15 PM, neorom neo...@gmail.com wrote:
I resolved my previous problem, the error came in the name of the
variable key which has to be named eckey. So there is a mistake in
the code in the documentation.
Now my problem is more difficult, because after :
Initialization of the structure :
EC_KEY *eckey = EC_KEY_new()
link with an elliptic curve :
eckey = EC_GROUP_new_by_curve_name(NID_secp192k1);
finally, the creation of this key :
if (!EC_KEY_generate_key(eckey))
{
printf(error key generation\n);
}
when I execute my code, I get a Semgentation Fault and gdb tell me
that the problem comes with the function : BN_copy()
Program received signal SIGSEGV, Segmentation fault.
0x0805fee8 in BN_copy ()
I am working with ubuntu and the libssl0.9.8g-10
Thanks in advance for your help,
Romain Hinfray
On Mon, Mar 2, 2009 at 2:57 PM, neorom neo...@gmail.com wrote:
Hello every body,
I'm new on this mailing list. I actually have to do a small program
which have to generate signature with the ecdsa algorithm and I have
never did it before.
For this I saw the documentation and the example on the openssl web
site (http://www.openssl.org/docs/crypto/ecdsa.html).
But on line 8 of this program : key-group =
EC_GROUP_new_by_nid(NID_secp192k1);
, I don't understood why the key structure isn't initialized before
and with struture defines it. Gcc tells me that : error: ‘key’
undeclared.
Can you help me please.
Thanks in advance
Romain Hinfray
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Google summer of code?
Note: This year, the mentoring organization application deadline is March 13. Billy On Wed, Feb 25, 2009 at 12:19 PM, Davide Vernizzi davide.verni...@polito.it wrote: On Wed, 2009-02-25 at 10:29 +0100, Emanuele Cesena wrote: On Sun, 2009-02-22 at 19:51 +0200, Billy Brumley wrote: Hi--hopefully this is the correct list. Is there any chance of openssl participating as a mentor organization for Google summer of code? I will also be very interested! I am also interested. Has OpenSSL ever participated to the google's summer of code? Anyone would be interested in doing so? -- Davide __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Google summer of code?
Perhaps I should be more detailed ;) I'm interested in providing Koblitz curve specific functionality to the elliptic curve portion of OpenSSL--they are currently treated as regular binary curves. All point doublings can be replaced by a simpler operation called the Frobenius map, leading to quite a speed improvement. I implemented a prototype for this, some details are given in (p5, Tbl 2), signing and verifications see roughly a 50% speedup: http://www.tcs.hut.fi/Publications/bbrumley/pla_implicitcerts_2008.pdf The implementation currently lives outside of OpenSSL, so it should be properly integrated and tightened up; Koblitz curves should then call down to this specific scalar multiplication function, instead of the generic Montgomery's ladder currently used for binary curves. Textbook LD coordinates are also included in the implementation. If there is any interest in this kind of functionality, I'm hoping an OpenSSL developer would be willing to act as a mentor for me to do the work as part of Google summer of code. If so, please feel free to reply here or contact me directly for more detailed discussions. Billy billy.brumley at hut dot fi On Sun, Feb 22, 2009 at 7:51 PM, Billy Brumley bbrum...@gmail.com wrote: Hi--hopefully this is the correct list. Is there any chance of openssl participating as a mentor organization for Google summer of code? Best, Billy __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Google summer of code?
Hi--hopefully this is the correct list. Is there any chance of openssl participating as a mentor organization for Google summer of code? Best, Billy __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
