Rather than the FIPS module actively collecting entropy from the CPU or
OS, this change configures Android FIPS to passively receive entropy.
See FIPS IG 7.14 section two.
Change-Id: Ibfc5c5042e560718474b89970199d35b67c21296
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44305
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This should fix the Chromium roll.
Windows shared library builds are fussy about dllexport vs. dllimport in
a way that's incompatible with external uses of the asn1t.h macros. The
issue is the DECLARE_* macros will add dllexport vs. dllimport on the
assumption the symbols are defined in libcrypto, but external
definitions need a different selector.
Rather than add more complex macros for this, just exclude those tests.
Ideally we wouldn't supoport asn1t.h outside the library at all, if we
can manage it, so no sense in trying to make it work.
This excludes both the new and the old tests. Although this has been
working thus far, it only works because we've been setting the
BORINGSSL_IMPLEMENTATION symbol for test targets wrong in Chromium. I'm
confused how that's been working at all (maybe dllexport vs. dllimport
is more lax when it comes to functions rather than variables?), but when
I do it correctly, the ASN1_LINKED_LIST template breaks too.
Change-Id: I391edba1748f66c383ed55a9d23053674bbb876e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44484
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
8846533744 added a “power-on” test for the TLS KDF, but omitted to add
it to the documented list of these tests.
Change-Id: I13dbad4b9359e7dae0938d02ac53e5e011f50824
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44505
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This imports d741debb320bf54e8575d35603a44d4eb40fa1f9 from upstream.
We've been managing the shared libraries already because our
arm-xlate.pl automatically adds .hidden to .extern lines, but nice to
reduce the diff. (This does result in some duplicate .hidden lines in
the generated output, but we still want the arm-xlate.pl patch to
automatically hide .globl.)
Removing .comm lines does change the generated output, but having each
asm file define its own copy of OPENSSL_armcap_P as a common symbol
always seemed odd. I recall some weird issue where the armv4.pl files
subtly rely on it for iOS's strange .indirect_symbol machinery. (Not
actually because iOS wants a common symbol but because arm-xlate.pl
repurposes .comm to trigger .indirect_symbol.) Fortunately, aarch64 is
much better about PC-relative addressing, so it should be a no-op.
The .comm lines have also previously caused weird issues
(https://boringssl-review.googlesource.com/c/boringssl/+/32324), so
it's generally nice to get rid of them.
Update-Note: If aarch64 builds get some weird error about relocations,
it's this CL's fault.
Change-Id: I763ffa6cda750d99694ded8a5b68d7b27b09cfc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44464
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This imports 1ecc76f6746cefd502c7e9000bdfa4e5d7911386 and
41d62636fd996c031c0c7cef746476278583dc9e from upstream. These would have
rejected the mistake in OpenSSL's EDIPartyName sturcture.
Change-Id: I4eb218f9372bea0f7ff302321b9dc1992ef0c13a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44424
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change tweaks our ACVP config to better match what BoringCrypto
has previously tested with CAVP.
Change-Id: I7d7ce5153a3eb7355ae1516f06ff591ee2c9d902
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44385
Reviewed-by: David Benjamin <davidben@google.com>
See also CVE-2020-1971, f960d81215ebf3f65e03d4d5d857fb9b666d6920, and
aa0ad2011d3e7ad8a611da274ef7d9c7706e289b from upstream OpenSSL.
Unlike upstream's version, this CL opts for a simpler edipartyname_cmp.
GENERAL_NAME_cmp is already unsuitable for ordering, just equality,
which means there's no need to preserve return values from
ASN1_STRING_cmp. Additionally, the ASN.1 structure implies most fields
cannot be NULL.
(The change from other to x400Address is a no-op. They're the same type.
Just x400Address is a little clearer. Historical quirks of the
GENERAL_NAME structure.)
Change-Id: I4b0ffe8e931c8ef916794a486e6a0d6d684c0cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44404
Reviewed-by: Adam Langley <agl@google.com>
It's insufficient to signal an error when the PWCT fails. We
additionally need to ensure that the invalid key material is not
returned.
Change-Id: Ic5ff719a688985a61c52540ce6d1ed279a493d27
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44306
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
If I perturb kOrder in the malleability check, our and Wycheproof's
tests don't easily notice. This adds some tests with s above and below
the order. EdDSA hashes the public key with the message, which
frustrates constructing actual boundary cases. Instead, these inputs
were found by generating many signatures.
This isn't ideal, but it is sensitive to the most significant 32 bits.
Change-Id: I7fc03758ab97650d0e94478f355ea7085ae0559a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44346
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Iba527924a79733b28b12b65d8e1f613d7819eb34
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44345
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
<openssl/base.h> checks for a supported platform, but we don't check
endianness of ARM and MIPS, which are bi-endian. See
https://crbug.com/1153312#c7.
Switch this around. Documentation on which define is "official" is hard
to come by, so I mostly mimicked Chromium. Chromium detects
little-endian ARM and MIPS with __ARMEL__ and __MIPSEL__ respectively,
without looking at __arm__ or __mips__. It uses __aarch64__
instead of __AARCH64EL__, but I think that's an oversight. I can get
Clang to output for aarch64_be and that defines __aarch64__ with
__AARCH64EB__.
<openssl/arm_arch.h> (which we should simplify and align with base.h
once this CL sticks) also normalizes to __ARMEL__ over __BYTE_ORDER__
and friends. Although, interestingly, arm_arch.h defines its own
__ARMEL__ on GNUC aarch64, even though Clang does *not* define __ARMEL__
on aarch64. (I'm guessing this aligned for the benefit of the "armx"
bi-arch asm files.) This value is based on __BYTE_ORDER__, not
__ARMEL__, but it assumes GNUC arm always defines __ARMEL__, so I think
it's reasonable to assume GNUC aarch64 always defines __AARCH64EL__.
Given all this, probably the simplest thing that's most likely to work
is to use __ARMEL__, __MIPSEL__, and __AARCH64EL__. Note this does not
change the _M_* checks. _M_* are Windows's definitions, which I think we
can reasonably assume come with an endianness opinion. (Windows' ARM and
ARM64 ABIs mandate little-endian.) This aligns with Chromium.
Update-Note: CPU processor defines are a mess. If a little-endian ARM or
MIPS build breaks, some of the assumptions above may be wrong. In that
case, the output $CC -dM -E - < /dev/null on the offending toolchain
will be useful to fix it. If a big-endian ARM or MIPS build breaks, this
is working as intended. Any resulting binaries weren't producing the
right outputs.
Change-Id: I2a9e662d09df119a71226e91716d84e7ac3792aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44324
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected
by silicon errata #1742098 [0] and #1655431 [1], respectively, where the
second instruction of a AES instruction pair may execute twice if an
interrupt is taken right after the first instruction consumes an input
register of which a single 32-bit lane has been updated the last time it
was modified.
Shuffle the counter assignments around a bit so that the most recent
updates when the AES instruction pair executes are 128-bit wide.
[0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice
[1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice
(This is imported from upstream's
409c59e8f44ae56f2587cdd8a7ce611d0e3d91d9.)
The change is applied to both 32-bit and 64-bit for simplicity, but there
was no measurable performance difference, so leaving them aligned is
easiest.
Change-Id: Ic8e5f656f59ae8c2ecb2762a066c2c9064bb34c5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44284
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
No need to use |sk_new|, which allocates a buffer that will immediately
be realloced.
Change-Id: If0a787beac19933d93c5f9a3a8b560edd027c16c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44205
Reviewed-by: Adam Langley <agl@google.com>
Clarify that there are no truncation issues on targets where the range
of |unsigned| is smaller than the range of |size_t|.
Ensure that |poly1305_state| is (still) large enough. This is a good
idea independently of this change, but is especially important because
switching the fields to |size_t| might have enlarged the structures.
Change-Id: I16e408229c28fcba6c3592603ddb9431cf1f142d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44244
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The docs at os/signal.Notify warn about this signal delivery loss bug at
https://golang.org/pkg/os/signal/#Notify, which says:
Package signal will not block sending to c: the caller must ensure
that c has sufficient buffer space to keep up with the expected signal
rate. For a channel used for notification of just one signal value,
a buffer of size 1 is sufficient.
Discovered by one of Orijtech, Inc's internal static
analyzers that will eventually be donated to the Go project, and will
then be included when one runs:
go test
Change-Id: I5713f7087a195ac706240d32b53d2e4855d93a1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44264
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This covers the use of EVP_sha256() added in 8846533744.
Change-Id: I8cd4c8e271de6a0b9a926e7186c7b24ffe849d67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44224
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Almost everything in <openssl/asn1.h> uses ASN1_STRING, and there are a
lot of unspoken assumptions in the library about the type field, so it
needs quite a bit of text.
Change-Id: Ied56c9428069477da8ecb17a174da4320e573fa1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I08cc198f326f02b3f38234b938208ea49a13fab6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44164
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
It's not even accurate. The term "master key" dates to SSL 2, which we
do not implement. (Starting SSL 3, "key" was replaced with "secret".)
The field stores, at various points, the TLS 1.2 master secret, the TLS
1.3 resumption master secret, and the TLS 1.3 resumption PSK. Simply
rename the field to 'secret', which is as descriptive of a name as we
can get at this point.
I've left SSL_SESSION_get_master_key alone for now, as it's there for
OpenSSL compatibility, as well as references to the various TLS secrets
since those refer to concepts in the spec. (When the dust settles a bit
on rfc8446bis, we can fix those.)
Change-Id: I3c1007eb7982788789cc5db851de8724c7f35baf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44144
Reviewed-by: Adam Langley <agl@google.com>
These APIs were used by Chromium to control the carve-out for the TLS
1.3 downgrade signal. As of
https://chromium-review.googlesource.com/c/chromium/src/+/2324170,
Chromium no longer uses them.
Update-Note: SSL_CTX_set_ignore_tls13_downgrade,
SSL_set_ignore_tls13_downgrade, and SSL_is_tls13_downgrade now do
nothing. Calls sites should be removed. (There are some copies of older
Chromium lying around, so I haven't removed the functions yet.) The
enforcement was already on by default, so this CL does not affect
callers that don't use those functions.
Change-Id: I016af8291cd92051472d239c4650602fe2a68f5b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44124
Reviewed-by: Adam Langley <agl@google.com>
I got that wrong. It passes ownership to the caller. It calls
X509_PUBKEY_get which bumps the refcount.
Change-Id: I46b7eabcf56f68bb1f745bc2f64091640e97c0bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We have several implementations of this internally, so consolidate them.
Chromium also has a copy in net/der/parse_values.cc which could call
into this.
(I'm also hoping we can make c2i_ASN1_INTEGER call this and
further tighten up crypto/asn1's parser, but I see Chromium still has an
allow_invalid_serial_numbers option, so perhaps not quite yet.)
Update-Note: This CL does not change behavior, but I'm leaving a note to
myself to make net/der/parse_values.cc call the new functions.
Change-Id: If2aae6574ba6a30e343e1308da6af543616156ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44051
Reviewed-by: Adam Langley <agl@google.com>
This still needs some overall documentation describing ASN1_STRING's
relationship to all the other types, but start with the easy bits.
Change-Id: I968d4b1b3d57a9b543b3db489d14cf0789e30eb3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44049
Reviewed-by: Adam Langley <agl@google.com>
Not especially important, but leaving the input unchanged on malloc
failure is a little tidier.
Change-Id: Ia001260edcc8d75865d0d75ac0fe596205f83c48
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44048
Reviewed-by: Adam Langley <agl@google.com>
The free and dup macros are fine and can be replaced with their function
counterparts, but the new macros call ASN1_STRING_type_new with a
representative type in the CHOICE. This does not match what the
corresponding functions (e.g. ASN1_TIME_new) do.
The functions go through tasn_new.c and end up at ASN1_primitive_new.
That ends up creating an ASN1_STRING with type -1 and the
ASN1_STRING_FLAG_MSTRING flag set. X509_time_adj_ex uses the flag to
determine whether to trigger X.509's UTCTime vs GeneralizedTime
switching.
Confusingly, ASN1_TIME_adj, ASN1_UTCTIME_adj, and
ASN1_GENERALIZEDTIME_adj trigger this behavior based on the function
itself. That seems more robust (X509_set1_notBefore might accidentally
lose the flag), so maybe we can remove this flag. In the meantime, at
least remove the old macros so we don't create the wrong type.
Update-Note: Some M_ASN1 macros were removed. Code search says there
were no uses, and OpenSSL upstream removed all of them.
Change-Id: Iffa63f2624c38e64679207720c5ebd5241da644c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44047
Reviewed-by: Adam Langley <agl@google.com>
There is no ASN1_TIME_dup, so switch M_ASN1_TIME_dup to ASN1_STRING_dup
as upstream does. Switch M_ASN1_TIME_free to ASN1_TIME_free, also
matching upstream. This is a no-op, but less obviously so:
ASN1_TIME is an MSTRING defined in a_time.c. This defines an MSTRING
ASN1_ITEM. The new/free functions are then generated with
IMPLEMENT_ASN1_FUNCTIONS, which walks the ASN1_ITEM. ASN1_TIME_free then
goes through table-based free function, eventually running
ASN1_primitive_free, which calls ASN1_STRING_free on MSTRINGs.
Change-Id: I1765848a5301ecceeb74f91457351c969b741bb1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44046
Reviewed-by: Adam Langley <agl@google.com>
At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>
Some of the X509 functions are hard to document without first
documenting the ASN.1 types themselves. (ASN1_TYPE's goofy
representation is leaked everywhere.)
Change-Id: I0adcf055414925f9e39c8293cbd42d29f0db3143
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44044
Reviewed-by: Adam Langley <agl@google.com>
During the upstream review process a leading dot got removed by
accident. Missing this single character renders BoringSSL
Armv8.5-A BTI incompatible.
Also added two semicolons, just to be consistent.
Change-Id: I6c432d1c852129e9c273f6469a8b60e3983671ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44024
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
At the time, we hadn't taught clang-format how to handle STACK_OF
correctly.
Change-Id: Ia90c3bf443846a07eddaea5044b724027552ed30
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43964
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I77e08b88afa8a1f4e28449bf728eccc2c2f6f372
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43944
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
A few can be made static. Move the rest of asn1_locl.h.
Update-Note: Code search says these are unused. If someone's using them,
we can reexport them.
Change-Id: Ib41fd15792b59e7a1a41fa6b7ef5297dc19f3021
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43893
Reviewed-by: Adam Langley <agl@google.com>
This was used to register custom primitive types, namely some INTEGER
variations. We have since removed them all.
Change-Id: Id3f5b15058bc3be1cef5e0f989d2e7e6db392712
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43891
Reviewed-by: Adam Langley <agl@google.com>
Sadly we need to keep ASN1_put_eoc. Ruby uses it.
OpenSSL's PKCS#7 implementation generated an "ndef" variant of the
encoding functions, to request indefinite-length encoding. Remove the
support code for this.
Update-Note: Types that use one of the NDEF macros in asn1t.h will fail
to compile. This CL should not affect certificate parsing.
Change-Id: I6e03f6927ea4b7a6acd73ac58bf49512b39baab8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43889
Reviewed-by: Adam Langley <agl@google.com>
This is a remnant of an older incarnation of OpenSSL's ASN.1 code.
Update-Note: Types using IMPLEMENT_COMPAT_ASN1 from openssl/asn1t.h will
fail to compile. This CL should not affect certificate parsing.
Change-Id: I59e04f7ec219ae478119b77ce3f851a16b6c038f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43888
Reviewed-by: Adam Langley <agl@google.com>
This is never used. Remove the logic so we can gradually simply the
legacy ASN.1 code.
Update-Note: Types using ASN1_BROKEN_SEQUENCE from openssl/asn1t.h will
fail to compile. This CL should not affect certificate parsing.
Change-Id: I06b61ae2656a657aed81cd467051a494155b0963
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43887
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Adam Langley
David Benjamin
Dan McArdle
Aaron zhang
Brian Smith
Emmanuel T Odeke
Tamas Petz