Some don't have sections to go with yet, but will later.
Bug: 426
Change-Id: I903a8bf8c33cdc026a79601a8fd37469c839fa00
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53335
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Although it contains an X509_NAME (by way of GENERAL_NAME), the
GENERAL_NAME field does not participate in serialization, so it is
actually const.
Bug: 407
Change-Id: I299815789744597e2b355cb0b996ba90c3b6a72f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53334
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I can't find any users of these APIs. If we remove them, the only
publicly exposed operation on PKCS8_PRIV_KEY_INFO becomes
EVP_PKCS82PKEY. We can then parse it without a dependency on the legacy
ASN.1 stack.
While I'm here, remove the callback on the structure. OPENSSL_free
automatically calls OPENSSL_cleanse in BoringSSL, so the call is
redundant.
Update-Note: Removed some unused accessors.
Change-Id: I400748463abe3c28dfa42ae9de9be59cb76cd2b2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53332
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There's a lot of these, so toss them into a corner somewhere.
I've added a note to note to discourage using them with memory BIOs.
Memory BIOs are, by far, the most common use I've seen for i2d_*_bio and
d2i_*_bio. It works, but it's unnecessary.
Bug: 426
Change-Id: I8645207a4ac9f1223d0739b5351c99a55400195f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53331
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
It doesn't hash the SPKI, just the BIT STRING in it.
Bug: 426
Change-Id: Ib5b8f14f530cc8045a60ac1e9780779d90f5a3bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53330
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Update-Note: Suite B flags in the X.509 stack are no longer supported.
This isn't expected to affect anything but bindings wrapping unused
options.
Change-Id: Ia0770e545d34e041ab995e80ea11b4dd4a5e47ef
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53329
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This was originally added for the openssl command-line utility and
otherwise is not very useful. I found no callers, so drop it.
Update-Note: An unused function was removed.
Change-Id: I12aa314fd3d8f1dad79eb5a07e0dea662dd9b4a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53328
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL has a large exported API surface for exporting the policy tree
out of an X509_STORE_CTX. As far as I can tell, no one uses any of these
APIs. Remove them.
Update-Note: It is no longer possibly to see the policy tree after an
X.509 verification. As far as we can tell, this feature is unused.
Change-Id: Ieab374774805e90106555ce4e4155f8451ceb5b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53327
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Unfortunately, these functions are not const-correct, even the
accessors. Document what they should have been, especially since
mutating an X509_NAME_ENTRY directly won't even update the 'modified'
bit correctly.
Do a pass at adding consts to our code internally, but since the
functions return non-const pointers, this isn't checked anywhere. And
since serializing an X509_NAME is not always thread-safe, there's a
limit to how much we can correctly mark things as const.
Bug: 426
Change-Id: Ifa3d8bafb5396fbe7b91416f234de4585284c705
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53326
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL calls the timestamp on the CRL lastUpdate, but it's actually
called thisUpdate in RFC 5280.
Bug: 426
Change-Id: I8a34f3de24e1914eda17d300321febe0205b2ec1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53310
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
In particular, since mutating X509s (and X509_CRLs and X509_REQs) does
confusing things, I've split the mutation functions into their own
section, which discusses constructing new objects.
Bug: 426
Change-Id: I1f7dbc5e47f78433e34c74f0cd966803a213e59a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53309
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This only does a few of them for now, in preparation for the following
CL, which tries to group things into sections.
Bug: 426
Change-Id: I4604d458ff2d8e81c8c8f0361a519e5291b8e119
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53308
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I found no uses of this. If we have to put it back, it's no big deal,
but one less group of functions to have to document. (SEQUENCE OF
AlgorithmIdentifier is mostly a weird PKCS#7 thing.)
Update-Note: X509_ALGORS is removed. If someone was relying on it, we
can re-export it.
Change-Id: I2b8e8d0d1d56d2debf99687023bc3621e92f6b08
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53307
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Types which do not contain an X509_NAME can be const. X509_NAME still
requires some thought. (i2d_X509_NAME can mutate the object and isn't
even thread-safe when modified.)
Bug: 407
Change-Id: Iceafa2b4ea9c4194cfcc3044d90393b5d91f7c11
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53305
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
No sense in keeping two around. This does cause the functions to reject
some previously accepted invalid inputs. These were intentionally
accepted by
https://boringssl-review.googlesource.com/c/boringssl/+/13082 for
an old version of M2Crypto, but I belive we no longer need to be
compatible with that.
Update-Note: ASN1_TIME_print, ASN1_UTCTIME_print, and
ASN1_GENERALIZEDTIME_print will no longer accept various invalid inputs.
Change-Id: I4606d0b39585a19eb4b984ac809706e497a3f799
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53090
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Certain applications of Trust Token need to be able to generate
a large number of keys, instead of storing them all, we provide
an API to take a secret that can be used to generate keys
in a deterministic manner.
Change-Id: I2b61958d1e949a3a47a3c91ab3a866c2e33a9d1d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53011
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Refuse to parse times that are invalid according to RFC 5280, with
a few exceptions for compatibility. This can affect test code that
relies on making and parsing certificates that contain invalid times.
Update-Note: Certificates containing invalid ASN.1 times will no longer parse.
Bug: 491, 427
Change-Id: I2a3fe3a4d359ac662340a225d05b360718eb8c29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52665
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This results in one change, which is the comparison function goes from:
typedef char *OPENSSL_STRING;
static int sk_strcmp(const OPENSSL_STRING *a,
const OPENSSL_STRING *b);
which is:
static int sk_strcmp(char *const *a, char *const *b)
into:
static int sk_strcmp(const char **a, const char **b)
Neither is correct (both consts should be there), but switching the
defintion is necessary to attach the 'const' to 'char' itself. Otherwise
it wouldn't see through the typedef. Fixing the rest of the calling
convention will finish the job. Plan there is, when
I00d13c949a535c0d60873fe4ba2e5604bb585cca lands, I'll switch Envoy to
call that. Then we should be clear to const-correct the callback.
(While STACK_OF(OPENSSL_STRING) is used externally, nothing external
touches the comparison function.)
Bug: 498
Change-Id: I77bdf2a72b2553bf9409a1d39326890ed5c3582c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53008
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
SSL_load_client_CA_file can just call
SSL_add_file_cert_subjects_to_stack.
SSL_add_file_cert_subjects_to_stack itself is rewritten to use scopers
and also give subquadratic running time. Sorting after every insertion
does not actually help. (It would have been faster to do a linear
search.) Instead, gather the names first, then sort and deduplicate.
Finally, add a SSL_add_bio_cert_subjects_to_stack. This is both to
simplify testing and because Envoy code copied from
SSL_add_file_cert_subjects_to_stack, complete with the quadratic
behavior. It is the only external project that depends on the
STACK_OF(T) comparison function. To simplify making that const-correct,
just export the function they needed anyway.
Bug: 498
Change-Id: I00d13c949a535c0d60873fe4ba2e5604bb585cca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53007
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
MSVC 2022's C4191 warns on most function pointer casts. Fix and/or
silence them:
connect.c is an unavoidable false positive. We're casting the pointer to
the correct type. The problem was that the caller is required to first
cast it to the wrong type in OpenSSL's API, due to the BIO_callback_ctrl
calling convention. Suppress it.
LHASH_OF(T) and STACK_OF(T)'s defintions also have a false positive.
Suppress that warning. Calling the functions through the casted types
would indeed be UB, but we don't do that. We use them as goofy
type-erased types. The problem is there is no function pointer
equivalent of void*. (Using actual void* instead trips a GCC warning.)
The sk_sort instance is a true instance of UB. The problem is qsort
lacks a context parameter. I've made sk_sort call qsort_s on _MSC_VER,
to silence the warning. Ideally we'd fix it on other platforms, but
qsort_r and qsort_s are a disaster. See
https://stackoverflow.com/a/39561369
Fixed: 495
Change-Id: I0dca80670c74afaa03fc5c8fd7059b4cfadfac72
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53005
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
bind uses this function.
Change-Id: I97ba86d9f75597bff125ae0b56952effc397e6b8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53010
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
OpenSSL 1.1.1 added HKDF support, but by sticking it into
EVP_PKEY_derive, the API meant for Diffie-Hellman-like primitives.
Implement it for OpenSSL compatibility.
This does unfortunately mean anything using EVP now pulls in HKDF. HKDF
isn't much code, but we should make EVP more static-linker-friendly.
(Filed https://crbug.com/boringssl/497)
Change-Id: I90b9b0d918129829eb36ba9d50ff4d8580346ff0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52829
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These functions aid in meeting specific compliance goals and allows
configuration of things like TLS 1.3 cipher suites, which are otherwise
not configurable.
Change-Id: I668afc734a19ecd4b996eaa23be73ce259b13fa2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52625
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
For AEADs (our only EVP_CIPH_FLAG_CUSTOM_CIPHER is GCM), EVP_Cipher is
not a one-shot operation. It is a thin wrapper over the internal
cipher callback in the EVP_CIPHER, complete with treating in == NULL as
EVP_CipherFinal_ex. Also document that you should not do this.
Also document how you feed in the AAD for an AEAD EVP_CIPHER. (Although
callers really should use EVP_AEAD for a much less complex interface.)
Bug: 494
Change-Id: I0beb1c88cdf0406506af2772e53e9d3f8d07172a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52727
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
If we're to have any hope of fixing EVP_CIPHER_CTX's calling convention, we
need to be able to change the shape of its method table.
Looking back, it looks like we exported this in
https://boringssl-review.googlesource.com/4330, for OpenSSH. I don't
remember exactly what OpenSSH was doing, but I see in this commit, they
removed a bunch of custom EVP_CIPHERs which would definitely have
required an exported EVP_CIPHER struct:
cdccebdf85
That's been gone for a while now, so hopefully we can hide it again. (If
a project needs a cipher not implemented by OpenSSL, it's not strictly
necessarily to make a custom EVP_CIPHER. It might be convenient to reuse
the abstraction, but you can always just call your own APIs directly.)
Update-Note: EVP_CIPHER is now opaque. Use accessors instead.
Bug: 494
Change-Id: I9344690c3cfe7d19d6ca12fb66484ced57dbe869
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52725
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
While C allows function pointer casts, it is UB to call a function with
a different type than its actual type signature. That is, even though
`void f(int *)` and `void g(void *)` have the same ABI, it is UB to
cast `f` to a `void(*)(void *)` and then call it through that pointer.
Clang CFI will try to enforce this rule.
The recent CL to call X509_print in tests revealed that all the i2? and
?2i callbacks in X509V3_EXT_METHODs were implemented with functions of
the wrong type, out of some combination of missing consts and void*
turned into T*.
This CL fixes this. Where the function wasn't exported, or had no
callers, I just fixed the function itself. Where it had extension
callers, I added a wrapper function with a void* type.
I'm not positive whether the wrappers are the right call. On the one
hand, keeping the exported functions as-is is more type-safe and more
OpenSSL-compatible. However, most (but not all) uses of these are in
other code defining X509V3_EXT_METHODs themselves, so the void*
signature is more correct for them too. And the functions have a type
signature meant for X509V3_EXT_METHOD, complete with method pointer.
I've gone with leaving the exported ones as-is for now. Probably the
right answer anyway is to migrate the external callers, of either type
signature.
Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This has no callers, and seems to be practically unusable. The only way
to set an X509_CRL_METHOD is X509_CRL_set_default_method, which is not
thread-safe and globally affects the CRL implementation across the
application.
The comment says it's to handle large CRLs, so lots of processes don't
have to store the same CRL in memory. As far as I can tell,
X509_CRL_METHOD cannot be used to help with this. It doesn't swap out
storage of the CRL, just signature verification and lookup into it. But
by the time we call into X509_CRL_METHOD, the CRL has already been
downloaded and the data stored on the X509_CRL structure. (Perhaps this
made more sense before the structure was made opaque?)
Update-Note: APIs relating to X509_CRL_METHOD are removed.
Change-Id: Ia5befa2a0e4f4416c2fb2febecad99fa31c1c6ac
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52687
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is cribbed, with perimssion, from AWS-LC. The FIPS service
indicator[1] signals when an approved service has been completed.
[1] FIPS 140-3 IG 2.4.C
Change-Id: Ib40210d69b3823f4d2a500b23a1606f8d6942f81
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52568
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This aligns X509_REQ's and X509_CRL's parsers to the changes already
made with X509; we reject invalid versions and check that extensions are
only with the corresponding version. For now, we still allow X509v1 CRLs
with an explicit version, matching certificates. (The DEFAULT question
is moot for X509_REQ because CSRs always encode their version, see RFC
2986.)
In addition to rejecting garbage, this allows for a more efficient
representation once we stop using the table-based parser: X509 and
X509_CRL can just store a small enum. X509_REQ doesn't need to store
anything because the single version is information-less.
Update-Note: Invalid CRL and CSR versions will no longer be accepted.
X509_set_version, etc., no longer allow invalid versions.
Fixed: 467
Change-Id: I33f3aec747d8060ab80e0cbb8ddf97672e07642c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52605
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The manual construction of the version integer is odd. The default is
already zero, and as of
https://boringssl-review.googlesource.com/c/boringssl/+/51632, we've
settled on the empty string as the ASN1_INTEGER representation of zero.
But there don't seem to be any uses of this function, so just remove it.
Update-Note: Removed seemingly unused public API.
Change-Id: I75f8bcdadb8ffefb0b2da0fcb0a87a8cb6398f70
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52585
Reviewed-by: Adam Langley <agl@google.com>
CPython and wpa_supplicant are using this nowadays. To avoid needing to
tweak the ticket nonce derivation, I've just internally capped the
number of tickets at 16, which should be plenty.
Change-Id: Ie84c15b81a2abe8ec729992e515e0bd4cc351037
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52465
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
For now, the tests assert the existing behavior of X509_NAME_print, but
there are several bugs in it.
Change-Id: I9bc211a880ea48f7f756650dbe1f982bc1ec689d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52366
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Inspired by Joel Sing's work in libre.
Change-Id: I17267af926b7d42472f7dae3205fda9aabdfa73d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52385
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
MSVC is a little behind, but otherwise we should be able to assume C11
support in all our compilers. The only C99 builds should just be stale
build files. Such consumers are leaving performance on the table, by
using the worse refcounting implementation.
For now, don't require it in public headers. Android's build is still
defaulting to C99, which means requiring C11 will be disruptive. We can
try the public headers after that's fixed.
Update-Note: If the build fails with an error about C11, remove -std=c99
or -std=gnu99 from your build. Refcounting will get faster.
Change-Id: I2ec6f7d7acc026a451851d0c38f60c14bae6b00f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52247
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Now that we've dropped MSVC 2015, I believe we can rely on C++14 (which
is now seven years old). This switches the build to require C++14. I've
gone ahead and switched code in both public headers and within the
library, but if the public headers are a problem, we can revert those
separately.
C++14 doesn't get us quite as much as C++17, but see if we can get to
C++14 first. Still, std::enable_if_t and the less restricted constexpr
are nice wins.
Update-Note: C++14 is now required to build BoringSSL. If the build
breaks, make sure your compiler is C++14-capable and is not passing
-std=c++11. If this is causing problems for your project, let us know.
Change-Id: If03a88e3f8a11980180781f95b806e7f3c3cb6c3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52246
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
[UNIVERSAL 0] is reserved by X.680 for the encoding to use. BER uses
this to encode indefinite-length EOCs, but it is possible to encode it
in a definite-length element or in a non-EOC form (non-zero length, or
constructed).
Whether we accept such encodings is normally moot: parsers will reject
the tag as unsuitable for the type. However, the ANY type matches all
tags. Previously, we would allow this, but crypto/asn1 has some ad-hoc
checks for unexpected EOCs, in some contexts, but not others.
Generalize this check to simply rejecting [UNIVERSAL 0] in all forms.
This avoids a weird hole in the abstraction where tags are sometimes
representable in BER and sometimes not. It also means we'll preserve
this check when migrating parsers from crypto/asn1.
Update-Note: There are two kinds of impacts I might expect from this
change. The first is BER parsers might be relying on the CBS DER/BER
element parser to pick up EOCs, as our ber.c does. This should be caught
by the most basic unit test and can be fixed by detecting EOCs
externally.
The second is code might be trying to parse "actual" elements with tag
[UNIVERSAL 0]. No actual types use this tag, so any non-ANY field is
already rejecting such inputs. However, it is possible some input has
this tag in a field with type ANY. This CL will cause us to reject that
input. Note, however, that crypto/asn1 already rejects unexpected EOCs
inside sequences, so many cases were already rejected anyway. Such
inputs are also invalid as the ANY should match some actual, unknown
ASN.1 type, and that type cannot use the reserved tag.
Fixed: 455
Change-Id: If42cacc01840439059baa0e67179d0f198234fc4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52245
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
VS 2017 was released in March 2017, five years ago now. This means VS
2015 is now past our support window.
This will make the unmarked and "vs2017" configs in CI/CQ do the same
thing. I'll follow up with a separate CL in infra/config to switch the
test VS 2019 instead.
Update-Note: BoringSSL may no longer build with VS 2015. Consumers
should upgrade to the latest Visual Studio release. VS 2017 or later is
required.
Change-Id: I477759deb95a27efe132de76d9ed103826110df0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52085
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It appears to be unused. It has global effects and is not thread-safe.
Rather than try to make the double-function-pointer declaration
readable, remove it.
Change-Id: If58ecd0c9367bbb27cf8c5e27ac9997fe4c1225d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51965
Reviewed-by: Alex Gaynor <alex.gaynor@gmail.com>
Reviewed-by: Adam Langley <agl@google.com>
Our FIPS module only claims support for RSA signing/verification, and
|RSA_generate_key_fips| already performs a sign/verify pair-wise
consistency test (PCT). For ECDSA, |EC_KEY_generate_fips| performs a
sign/verify PCT too. But when |EC_KEY_generate_fips| is used for key
agreement a sign/verify PCT may not be correct.
The FIPS IG[1], page 60, says:
> Though not a CAST, a pairwise consistency test (PCT) shall be
> conducted for every generated public and private key pair for the
> applicable approved algorithm (per ISO/IEC 19790:2012 Section
> 7.10.3.3). To further clarify, at minimum, the PCT that is required by
> the underlying algorithm standard (e.g. SP 800- 56Arev3 or SP
> 800-56Brev2) shall be performed.
SP 800-56Ar3, page 36, says:
> For an ECC key pair (d, Q): Use the private key, d, along with the
> generator G and other domain parameters associated with the key pair,
> to compute dG (according to the rules of elliptic-curve arithmetic).
> Compare the result to the public key, Q. If dG is not equal to Q, then
> the pair-wise consistency test fails
But |EC_KEY_generate_fips| has always done that via
|EC_KEY_check_key|. So I believe that |EC_KEY_generate_fips| works for
either case.
This change documents that.
[1] FIPS 140-3 IG dated 2022-03-14 and with SHA-256
2f232f7f5839e3263284d71c35771c9fdf2e505b02813be999377030c56b37e4
Change-Id: I4b4e2ed92ae3d59e2f2404c41694abeb3eb283f4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51988
Reviewed-by: David Benjamin <davidben@google.com>
We need a function that returns a version that links to a certificate.
Previously we have used the git hash as the version of our modules but
the source cannot contain its own hash. Thus this change defines a new
format for FIPS module versions which will be filled in once we're ready
to define a version.
Change-Id: Ie4641945119106bc47e8da94ed8a45a86abb6f92
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51986
Reviewed-by: David Benjamin <davidben@google.com>
David Benjamin
Adam Langley
Steven Valdez
Bob Beck
Rebecca Chang Swee Fun
Alex Gaynor