[openssl-dev] The new OpenSSL license should be made GPLv2 compatible

Hi, I'm one of the people that received the email asking for permission to relicense code to the new license, Apache 2.0. A major problem with the Apache 2.0 license is that it is frequently seen as being incompatible with the GPL2 license. Although many people consider it to be compatible with

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

Andy Polyakov wrote: > It appears to me that with multiplication, squaring, subtraction, > negation, halving *preserving* property of being fully reduced (i.e. if > inputs are fully reduced, then output is too), we only have to watch out > for mul_by_[23], i.e. ensure that

Re: [openssl-dev] ecp_nistz256 is_one is too liberal with what it considers to be one

Andy Polyakov wrote: >>if (P256_LIMBS == 8) { >> res |= a[4] ^ ONE[4]; >> res |= a[5] ^ ONE[5]; >> res |= a[6] ^ ONE[6]; >> +res |= a[7] ^ ONE[7]; >>} > > It's not actually a coincidence that it ends with a[6]. If you have > close look at

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

Andy Polyakov wrote: >> My understand after talking with Vlad that the "sbb \$0, $acc2" makes >> this equivalent to (r >= 2**256) ? (r - q) : r. If the "sbb \$0, >> $acc2" line were removed then it would be equivalent to (r >= q) ? (r >> - q) : r. My understanding is that the

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

Andy Polyakov wrote: > And it's not only that multiplication (and squaring) result is fully > reduced, it, multiplication (ans squaring) subroutine can actually > manage partially reduced input. On related note one can point out that > result of addition (and mul_by_[2|3]) is

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

Andy Polyakov wrote: > No, it subtraction subroutine uses *borrow* to determine if modulus is > to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b > are less than P, then result is less than P. Consider the case where a > P and a >= b and b is very small

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

Andy Polyakov wrote: >> Note in particular that, IIUC, ecp_nistz256_neg will never get an >> unreduced input when applied to the the based point multiples, because >> those are already fully reduced. But, when it is used in >> ecp_nistz256_windowed_mul, it isn't clear whether

[openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

I was curious about the function ecp_nistz256_neg. This function seems to work exactly how I expect for reduced inputs; i.e. inputs in the range [0, P). And, it also seems to work how I expect for P: ecp_nistz256_neg(P) == ecp_nistz256_neg(0) == 0. So, everything seems fine for inputs in the range

[openssl-dev] [openssl.org #4626] Re: Are the point-at-infinity checks in ecp_nistz256 correct?

Brian Smith <br...@briansmith.org> wrote: > The issue is particularly clear when we multiply the generator by > zero. Note that in general, an application shouldn't multiply the > generator by zero since there's no useful cryptographic purpose for > doing so. But, this is a

Re: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?

Brian Smith <br...@briansmith.org> wrote: > The issue is particularly clear when we multiply the generator by > zero. Note that in general, an application shouldn't multiply the > generator by zero since there's no useful cryptographic purpose for > doing so. But, this is a

[openssl-dev] [openssl.org #4625] Re: Are the point-at-infinity checks in ecp_nistz256 correct?

where is_infinity is the result of checking if (x, y) == (0, 0). This is just one example of an edge case that is handled in a surprising way. I think there are more, as described in the quoted message below. Cheers, Brian Brian Smith <br...@briansmith.org> wrote: > > Brian Smith

Re: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?

where is_infinity is the result of checking if (x, y) == (0, 0). This is just one example of an edge case that is handled in a surprising way. I think there are more, as described in the quoted message below. Cheers, Brian Brian Smith <br...@briansmith.org> wrote: > > Brian Smith

Re: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values

Brian Smith via RT <r...@openssl.org> wrote: > Finally, as I mentioned on the mailing list, it seems the function is_zero > is missing a comparison of the last limb in the 32-bit case. > And of course, when I said "is_zero" I meant "is_one": http

Re: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values

Brian Smith via RT <r...@openssl.org> wrote: > Finally, as I mentioned on the mailing list, it seems the function is_zero > is missing a comparison of the last limb in the 32-bit case. > And of course, when I said "is_zero" I meant "is_one": http

[openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values

I verified with the authors of the nistz256 code that all the arithmetic is done mod P256 (P), but the results might be unreduced if they are less than 2**256. Thus, all the arithmetic must handle the cases where its inputs are in the range [0, 2**256 - 1], not just [0, P). And, it must deal with

Re: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?

Brian Smith <br...@briansmith.org> wrote: > When doing math on short Weierstrass curves like P-256, we have to > special case points at infinity. In Jacobian coordinates (X, Y, Z), > points at infinity have Z == 0. However, instead of checking for Z == > 0, p256-x86-64 instea

[openssl-dev] ecp_nistz256 is_one is too liberal with what it considers to be one

Please see the attached program and consider the following change: ``` if (P256_LIMBS == 8) { res |= a[4] ^ ONE[4]; res |= a[5] ^ ONE[5]; res |= a[6] ^ ONE[6]; +res |= a[7] ^ ONE[7]; } ``` Cheers, Brian -- https://briansmith.org/ #include #include #include #include

[openssl-dev] A faster addition chain for use in P-256 inversion mod n

Hi, I saw Vlad Krasnov's patch to optimize inversion mod n for the P-256 curve. Please see [1], which presents an addition chain that uses 9 fewer multiplications (but two more squarings, IIRC). I spent some non-trivial effort to optimize this chain, but I wouldn't be surprised to see somebody

Re: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?

:sigh: I forgot the attachment with my test vectors. Here it is. On Tue, Jun 28, 2016 at 10:43 AM, Brian Smith <br...@briansmith.org> wrote: > When doing math on short Weierstrass curves like P-256, we have to > special case points at infinity. In Jacobian coordinates (X, Y,

[openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?

When doing math on short Weierstrass curves like P-256, we have to special case points at infinity. In Jacobian coordinates (X, Y, Z), points at infinity have Z == 0. However, instead of checking for Z == 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it does, in some sense,

Re: [openssl-dev] Bugs fixed in one place but not another

Salz, Rich wrote: >> Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2]. >> Please make sure you consider the impact of those changes on your own >> projects. > > Not sure what you're asking for. In general, I noticed that OpenSSL and LibreSSL don't seem

[openssl-dev] Bugs fixed in one place but not another

Hi, Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2]. Please make sure you consider the impact of those changes on your own projects. [1] https://boringssl.googlesource.com/boringssl/+log/ [2] https://github.com/briansmith/ring Cheers, Brian -- https://briansmith.org/

Re: [openssl-dev] Assembler warns about constants in poly1306-x86_64.pl

Andy Polyakov wrote: > I can't reproduce this. Sorry! You already fixed it here: https://github.com/openssl/openssl/commit/284116575d375729e672256cb2b754e8362c5bce on May 4. Cheers, Brian -- https://briansmith.org/ -- openssl-dev mailing list To unsubscribe:

[openssl-dev] Assembler warns about constants in poly1306-x86_64.pl

Yasm 1.3.0 (Like nasm, but it embeds debug symbols into the asm code on Windows) reports: poly1305-x86_64.asm(456): warning : value does not fit in 32 bit field poly1305-x86_64.asm(459): warning : value does not fit in 32 bit field poly1305-x86_64.asm(1346): warning : value does not fit in 32 bit

Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds

Andy Polyakov wrote: > In other words we *are* talking about super-custom code with very > special needs. As already mentioned, it would be next to impossible to > justify customization of OpenSSL to accommodate overly specific > requirements. And given above description it

Re: [openssl-dev] Stitched AES-NI AES-GCM code & AVX2

Andy Polyakov wrote: >> But, I think the stitched AES-NI AES-GCM code requires AVX2, not just >> AVX. > > No, it doesn't. It requires exactly AVX+MOVBE. I see. I was confused because the code says: if ($avx>1) {{{ I had been thinking the whole time that "$avx > 1" means

[openssl-dev] Stitched AES-NI AES-GCM code & AVX2

Hi, I see that the stitched AES-NI AES-GCM code will be used if : gctx->ctr==aesni_ctr32_encrypt_blocks && \ gctx->gcm.ghash==gcm_ghash_avx) In gcm128, I see that it decides to use gcm_ghash_avx if: /* AVX+MOVBE */ if (((OPENSSL_ia32cap_P[1] >> 22) & 0x41) == 0x41) { But, I

[openssl-dev] Notes on stitched AESNI-GCM implementation details

In the course of reviewing the code for the stitched AESNI-GCM code, a group of people found it difficult to understand some aspects of how the code works. After spending some time studying the code, I wrote these notes:

Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds

On Wed, Jun 8, 2016 at 12:40 AM, Andy Polyakov wrote: >> I noticed that the `H` member of `gcm128_context` seems to be >> unnecessary for builds that aren't using the 1-bit GCM math. > > Not true. It is actually used in s390x assembly module. And I mean both > H and Htable. I

Re: [openssl-dev] Making assembly language optimizations working onCortex-M3

Peter Waltenberg wrote: > IF you are in the situation where you are compiling for a space > constrained embedded processor then hopefully your engineers also have > enough smarts to fix the code. I'd also point out that a lot of dev. setups > for embedded aren't actually

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

Andy Polyakov wrote: >> > Cortex-M platforms are so limited that every bit of performance and >> > space savings matters. So, I think it is definitely worthwhile to >> > support the non-NEON ARMv7-M configuration. One easy way to do this >> > would be to avoid

Re: [openssl-dev] Why is `volatile` used in MOD_EXP_CTIME_COPY_FROM_PREBUF?

Andy Polyakov <ap...@openssl.org> wrote: >Brian Smith wrote: >> See >> https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631 >> >> + volatile BN_ULONG *table = (volatile BN_ULONG *)buf;

Re: [openssl-dev] Syncing OpenSSL and BoringSSL mont ASM code

Andy Polyakov wrote: >> 1. Please >> see >> https://boringssl.googlesource.com/boringssl/+/75b833cc819a9d189adb0fdd56327bee600ff9e9. >> >> I think it would be good for OpenSSL to work with Google to integrate >> this patch. > > Will be looked into... Awesome! Besides the

[openssl-dev] Removing gcm128_context->H for non-1-bit builds

I noticed that the `H` member of `gcm128_context` seems to be unnecessary for builds that aren't using the 1-bit GCM math. Since this member is large (128-bits) and some applications may have lots of GCM contexts relative to the amount of memory they have, I think it would be great to only put the

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

Brian Smith <br...@briansmith.org> wrote: > It seems that 32-bit ARM has the same limitation as x86 that the input and > output pointers must match or the input and output buffers must not overlap > at all. I'm not sure which ARM code path (NEON or non-NEON, or both) has >

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

On Mon, May 30, 2016 at 5:58 PM, Viktor Dukhovni wrote: > Name constraints in the X.509v3 PKI have not worked well, and are > rarely used. The attack requires a issuing CA to be willing to > issue certificates beyond its constraints, that would be quite > noticeable

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

Salz, Rich via RT wrote: > > Note that other implementations treated this as a bug and fixed it a > long time > > ago. > > What other implementations, and what did they do? Always treating a CN as > a DNS name? We can't. > As one example, mozilla::pkix treats the CN as a

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

Salz, Rich via RT wrote: > > Note that other implementations treated this as a bug and fixed it a > long time > > ago. > > What other implementations, and what did they do? Always treating a CN as > a DNS name? We can't. > As one example, mozilla::pkix treats the CN as a

[openssl-dev] Syncing OpenSSL and BoringSSL mont ASM code

1. Please see https://boringssl.googlesource.com/boringssl/+/75b833cc819a9d189adb0fdd56327bee600ff9e9 . I think it would be good for OpenSSL to work with Google to integrate this patch. 2. Is the `__chkstk` code that was added [1] to `bn_mul_mont` really necessary? I noticed that when BoringSSL

[openssl-dev] Why is `volatile` used in MOD_EXP_CTIME_COPY_FROM_PREBUF?

See https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631 + volatile BN_ULONG *table = (volatile BN_ULONG *)buf; Why is `volatile` used here? Is it to work around the effective type (strict aliasing) violations or for some

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

Andy Polyakov wrote: > > Cortex-M platforms are so limited that every bit of performance and > > space savings matters. So, I think it is definitely worthwhile to > > support the non-NEON ARMv7-M configuration. One easy way to do this > > would be to avoid building NEON code

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

[Sorry for the **long** delay in responding.] Andy Polyakov wrote: > > http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=11208dcfb9105e8afa37233185decefd45e89e17 > made whole assembly pack Thumb2-friendly, so that now you should be able > to compile all modules.

Re: [openssl-dev] [openssl.org #4521] openssl GCM ordering

Praveen Kariyanahalli via RT wrote: > Is there is a reason why openssl has restriction of auth before encrypt > order ? I dont believe there is an algo restriction, was wondering why > openssl has this. > It *is* inherent in the algorithm. The authentication tag for the AAD is

Re: [openssl-dev] Consistent way of making a const bignum

Feel free to take the patch at https://boringssl.googlesource.com/boringssl/+/7af36e1e38f54051559e2a40e6461a0c3b23b3fc%5E%21/#F0 if it helps you. In particular, crypto/ec (ecp_nistz256, at least) also needs this, and in fact this is already defined there. Cheers, Brian On Wed, Apr 20, 2016 at

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

It seems that 32-bit ARM has the same limitation as x86 that the input and output pointers must match or the input and output buffers must not overlap at all. I'm not sure which ARM code path (NEON or non-NEON, or both) has this issue. Cheers, Brian -- https://briansmith.org/ -- Ticket here:

Re: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse()

Alessandro Ghedini via RT wrote: > I was also wondering whether it would make sense to just drop the asm > implementations. Does the speed-up justify the added complexity? > IMO, it should work like this: * memset_s when memset_s is available. * Otherwise, SecureZeroMemory,

Re: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse()

On Sat, Oct 31, 2015 at 11:50 AM, Alessandro Ghedini via RT wrote: > In any case memset_s is not available anywhere anyway, so that doesn't > really > matter. > Is it available in some places, e.g.

Re: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse()

On Sat, Oct 31, 2015 at 11:50 AM, Alessandro Ghedini via RT wrote: > In any case memset_s is not available anywhere anyway, so that doesn't > really > matter. > Is it available in some places, e.g.

Re: [openssl-dev] Continuous Integration for OpenSSL

Alessandro Ghedini alessan...@ghedini.me wrote: Travis has some limitations though, like the fact that it only supports Linux and OS X, with fairly old compiler versions (e.g. gcc 4.6). Take a look at .travis.yml and mk/update-travis-yml.py in https://github.com/briansmith/ring, which allows

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

Andy Polyakov ap...@openssl.org wrote: Cortex-M3 and Cortex-M4 processors are -mthumb, -march=armv7-m, which is exactly the problematic configuration, if I understand that comment correctly. The comment in question applies *exclusively* to cases when you attempt to build universal

[openssl-dev] Making assembly language optimizations working on Cortex-M3

Hi, In ./Configure, there is this comment: # big-endian platform. This is because ARMv7 processor always # picks instructions in little-endian order. Another similar # limitation is that -mthumb can't cross -march=armv6t2 # boundary, because that's where it became

Re: [openssl-dev] We're working on license changes

On Tue, Aug 4, 2015 at 10:53 AM, Salz, Rich rs...@akamai.com wrote: How about getting a second opinion? You want to hire us legal counsel who understands the issues? Great. Who is us? It is natural for a lawyer to tell you to require lots of things to protect whatever entity is paying

Re: [openssl-dev] We're working on license changes

On Tue, Aug 4, 2015 at 2:47 PM, Salz, Rich rs...@akamai.com wrote: It is natural for a lawyer to tell you to require lots of things to protect whatever entity is paying them. Well, yeah, sure. But I would hope that the bono-fides of the SFLC and Eben Moglen aren't being called into

Re: [openssl-dev] We're working on license changes

On Fri, Jul 31, 2015 at 12:29 PM, Hanno Böck ha...@hboeck.de wrote: Salz, Rich rs...@akamai.com wrote: Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some more details. Summary: Moving to Apache 2, CLA's coming, it will take time. This is a huge step if it works (I

[openssl-dev] Concerns regarding bn_wexpand/bn_expand2/bn_expand_internal

Although bn_wexpand is a private function within the crypto/bn module, it is exposed to other modules through bn_int.h. It is used from outside crypto/bn quite frequently. bn_wexpand is implemented in terms of a function called bn_expand2: /* * This is an internal function that should not be

Re: [openssl-dev] ecp_nistz256 correctness/constant-timedness

On Fri, Apr 24, 2015 at 5:54 AM, Emilia Käsper emi...@openssl.org wrote: commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2). commit 53dd4ddf71 fixes 5 and some of 4. Still ploughing my way through the rest of error checking. Great. I want to call your attention to one

[openssl-dev] ecp_nistz256 correctness/constant-timedness

Hi, I have some questions regarding this implementation. https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c 1. In ecp_nistz256_points_mul, we have this code: if ((BN_num_bits(scalar) 256) { ... if

[openssl-dev] ec_wNAF_precompute_mult sometimes calls BN_CTX_end without BN_CTX_start

See https://boringssl.googlesource.com/boringssl/+/d6405beb2c75564edbbb7f4203252aa5edee2359 It seems OpenSSL has the same bug, although the code is slightly different, and my fix for BoringSSL should be easy to adapt for OpenSSL. It may be worth trying to find the same pattern elsewhere in the

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Emilia Käsper emi...@openssl.org wrote: On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith br...@briansmith.org wrote: If OpenSSL's client code were changed to always use an empty session ID when attempting resumption using a session ticket, then the EAP-FAST case wouldn't be different from

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Erik Tkal etks...@gmail.com wrote: In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s-hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Brian Smith br...@briansmith.org wrote: Although the RFC4851 (an informational RFC documenting EAP-FAST) does not require the server to send the session ticket extension during resumption, it is based on RFC4507/RFC5077 (which are on the standards track), which *does* require the server

Re: [openssl-dev] [openssl.org #3721] Patch for additional checking of self-signed certificates

Short, Todd via RT r...@openssl.org wrote: Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer. Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that.

Re: [openssl-dev] [openssl.org #3721] Patch for additional checking of self-signed certificates

Short, Todd via RT r...@openssl.org wrote: Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer. Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that.

Re: [openssl-dev] OpenSSL patches and enhancements from Akamai

Very cool. Short, Todd tsh...@akamai.com wrote: * Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer Could you explain this one? It isn't necessarily the case that a self-signed subject has a self-signed issuer in PKIX, if I am understanding

Re: [openssl-dev] Seeking feedback on some #ifdef changes

On Tue, Feb 10, 2015 at 4:25 PM, Salz, Rich rs...@akamai.com wrote: Please continue to make it possible to build the crypto part of OpenSSL, without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that don't need that code. You can build crypto without ssl. And the only place

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_CHAIN_VERIFY OPENSSL_NO_RFC3779 OPENSSL_NO_TLS OPENSSL_NO_TLS1 OPENSSL_NO_TLS1_2_CLIENT OPENSSL_NO_TLSEXT OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY Please continue to make it

Re: [openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions

Hubert Kario hka...@redhat.com wrote: Actually it does not introduce it as OpenSSL does send the notification as TLS_EMPTY_RENEGOTIATION_INFO_SCSV, not the extension. On Sunday 30 November 2014 20:36:20 Richard Moore wrote: That would introduce security issues such as the TLS renegotiation

[openssl.org #1680] Possible Bug: x509_name_ex_d2i segmentation fault under IA-64

0x400ad1f0 in ASN1_item_ex_d2i () #2 0x400ae1a0 in ASN1_item_d2i () #3 0x4011a860 in ASN1_item_dup () #4 0x400a5b90 in X509_NAME_dup () #5 0x400a5cb0 in X509_NAME_set () #6 0x400bd760 in X509_REQ_set_subject_name () Thanks, Brian Smith Detail

compile failure on Solaris for X86

Your INSTALL file says to mail the make errors here. Hope you can make more sense of this than I can! I tried making this with/without the no-asm option installed with the same results both times. I am trying to compile openssl-0.9.4 making all in crypto... ( echo "#ifndef MK1MF_BUILD"; \