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 th
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 their outputs are fully
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 ecp_nistz256_is_affine_G, you'll
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 difference in semanti
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 partially reduced. Bu
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 (e.g. 1).
For example,
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 or how the input Y
>>
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
Brian Smith 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 convenient example.
So
Brian Smith 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 convenient example.
So
valent, where ZERO is all-zeros and 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 wrote:
>
> Brian Smith wr
valent, where ZERO is all-zeros and 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 wrote:
>
> Brian Smith wr
Brian Smith via RT 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":
https://gi
Brian Smith via RT 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":
https://gi
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 t
Brian Smith 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 instead checks for (X, Y) == (0,
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
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 rem
:sigh: I forgot the attachment with my test vectors. Here it is.
On Tue, Jun 28, 2016 at 10:43 AM, Brian Smith 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 ha
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, th
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 to pay
attention to
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/
-
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: https://mta.openssl.org/mailman/lis
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
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 shouldn't be actually
>
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 that AVX2 is requir
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 thi
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:
https://boringssl.googlesource.com/boringssl/+/2477adcf6236c3040a291ad1bfd53f
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 see. I admit I didn'
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 compiled on the target ma
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 wh
Andy Polyakov wrote:
>Brian Smith wrote:
>> See
>> https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631
>>
>> + volatile BN_ULONG *table = (volatile BN_ULONG *)buf;
>>
>> Why is `volati
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 functions that Google ch
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
Brian Smith 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
> this issue.
Just to fol
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 and rather unwise. So I thin
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 dNSName/iPAddress iif
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 dNSName/iPAddress iif
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 i
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 oth
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 when __TARGET_PROFILE
[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. Please, double-check.
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
computed first, th
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 8:
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: ht
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.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/memset_s.3.ht
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.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/memset_s.3.ht
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, when SecureZeroMemory
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, when SecureZeroMemory
Alessandro Ghedini 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 a project to be
b
Andy Polyakov 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" binary, one t
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 becam
On Tue, Aug 4, 2015 at 2:47 PM, Salz, Rich 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 question.
>
Nope
On Tue, Aug 4, 2015 at 10:53 AM, Salz, Rich 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 them. That's
On Fri, Jul 31, 2015 at 12:29 PM, Hanno Böck wrote:
> "Salz, Rich" 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 leave it up to the
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 use
On Fri, Apr 24, 2015 at 5:54 AM, Emilia Käsper 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 particularly non-obvio
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 Op
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 (!BN_nnmod(tm
Emilia Käsper wrote:
> On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith 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
Brian Smith 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 to send t
Erik Tkal 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 sessionTicket extension i
Short, Todd via RT 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.
>
> Github lin
Short, Todd via RT 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.
>
> Github lin
Very cool.
Short, Todd 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 you correctly.
C
On Tue, Feb 10, 2015 at 4:25 PM, Salz, Rich 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 OPENSSL_
Salz, Rich 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 possible to buil
Hubert Kario 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 flaw.
>> Surel
d2i ()
#1 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,
B
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"; \
echo
70 matches
Mail list logo