ftmp4 is assigned immediately before receiving the reduced output of the
multiplication of ftmp and ftmp3, without being read inbetween these
assignments. Remove redundant assignment.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19766)
Originally the code to im/export the EC pubkey was meant to be consumed
only by the im/export functions when crossing the provider boundary.
Having our providers exporting to a COMPRESSED format octet string made
sense to avoid memory waste, as it wasn't exposed outside the provider
API, and providers had all tools available to convert across the three
formats.
Later on, with #13139 deprecating the `EC_KEY_*` functions, more state
was added among the params imported/exported on an EC provider-native
key (including `OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT`, although it
did not affect the format used to export `OSSL_PKEY_PARAM_PUB_KEY`).
Finally, in #14800, `EVP_PKEY_todata()` was introduced and prominently
exposed directly to users outside the provider API, and the choice of
COMPRESSED over UNCOMPRESSED as the default became less sensible in
light of usability, given the latter is more often needed by
applications and protocols.
This commit fixes it, by using `EC_KEY_get_conv_form()` to get the
point format from the internal state (an `EC_KEY` under the hood) of the
provider-side object, and using it on
`EVP_PKEY_export()`/`EVP_PKEY_todata()` to format
`OSSL_PKEY_PARAM_PUB_KEY`.
The default for an `EC_KEY` was already UNCOMPRESSED, and it is altered
if the user sets `OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT` via
`EVP_PKEY_fromdata()`, `EVP_PKEY_set_params()`, or one of the
more specialized methods.
For symmetry, this commit also alters `ec_pkey_export_to()` in
`crypto/ec/ec_ameth.c`, part of the `EVP_PKEY_ASN1_METHOD` for legacy EC
keys: it exclusively used COMPRESSED format, and now it honors the
conversion format specified in the EC_KEY object being exported to a
provider when this function is called.
Expand documentation about `OSSL_PKEY_PARAM_PUB_KEY` and mention the
3.1 change in behavior for our providers.
Fixes#16595
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19681)
(cherry picked from commit 926db476bc)
Comments in felem_inv refer to the logarithm with respect to in of the
element that has just been computed. The last two such annotations are
incorrect. By Fermat's last theorem, we hope to compute in^(p-2) in
GF(2^521-1), as such we expect the final index we reach to be 2^521-3.
CLA: Trivial
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19765)
And so clean a few useless includes
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19721)
This mandates following SP 800-56A which, in 5.6.2.4, mandates a comparision
against a newly calculated public key.
Co-authored-by: Randall Steck <rsteck@thinqsoft.com>
Co-authored-by: Mark J. Minnoch <mark@keypair.us>
Co-authored-by: Steve Weymann <steve@keypair.us>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/19510)
partially revamped from #16712
- fall thru -> fall through
- time stamp -> timestamp
- file name -> filename
- host name -> hostname
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19059)
Also ASN1_OBJECT_free() never needs to be called on objects returned
from OBJ_nid2obj().
Fixes#19138
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19367)
Since OPENSSL_malloc() and friends report ERR_R_MALLOC_FAILURE, and
at least handle the file name and line number they are called from,
there's no need to report ERR_R_MALLOC_FAILURE where they are called
directly, or when SSLfatal() and RLAYERfatal() is used, the reason
`ERR_R_MALLOC_FAILURE` is changed to `ERR_R_CRYPTO_LIB`.
There were a number of places where `ERR_R_MALLOC_FAILURE` was reported
even though it was a function from a different sub-system that was
called. Those places are changed to report ERR_R_{lib}_LIB, where
{lib} is the name of that sub-system.
Some of them are tricky to get right, as we have a lot of functions
that belong in the ASN1 sub-system, and all the `sk_` calls or from
the CRYPTO sub-system.
Some extra adaptation was necessary where there were custom OPENSSL_malloc()
wrappers, and some bugs are fixed alongside these changes.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19301)
except those throwing ERR_R_MALLOC_FAILURE
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19302)
The code is derived from @sftcd's work in PR #17172.
This PR puts the DHKEM algorithms into the provider layer as
KEM algorithms for EC and ECX.
This PR only implements the DHKEM component of HPKE as specified in
RFC 9180.
crypto/hpke/hpke_util.c has been added for fuctions that will
be shared between DHKEM and HPKE.
API's for EVP_PKEY_auth_encapsulate_init() and EVP_PKEY_auth_decapsulate_init()
have been added to support authenticated encapsulation. auth_init() functions
were chosen rather that a EVP_PKEY_KEM_set_auth() interface to support
future algorithms that could possibly need different init functions.
Internal code has been refactored, so that it can be shared between the DHKEM
and other systems. Since DHKEM operates on low level keys it needs to be
able to do low level ECDH and ECXDH calls without converting the keys
back into EVP_PKEY/EVP_PKEY_CTX form. See ossl_ecx_compute_key(),
ossl_ec_public_from_private()
DHKEM requires API's to derive a key using a seed (IKM). This did not sit
well inside the DHKEM itself as dispatch functions. This functionality
fits better inside the EC and ECX keymanagers keygen, since
they are just variations of keygen where the private key is generated
in a different manner. This should mainly be used for testing purposes.
See ossl_ec_generate_key_dhkem().
It supports this by allowing a settable param to be passed to keygen
(See OSSL_PKEY_PARAM_DHKEM_IKM).
The keygen calls code within ec and ecx dhkem implementation to handle this.
See ossl_ecx_dhkem_derive_private() and ossl_ec_dhkem_derive_private().
These 2 functions are also used by the EC/ECX DHKEM implementations to generate
the sender ephemeral keys.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19068)
Derivation via ecx-methods did not properly set the length. Make the code
more similar to common code and set the length property.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19158)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/18668)
Flags for ASM implementations of EC curves were only passed to the FIPS
provider and not to the default or legacy provider. This left some potential
for optimization. Pass the correct flags also to these providers.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18791)
This can be reproduced with my error injection patch.
The test vector has been validated on the 1.1.1 branch
but the issue is of course identical in all branches.
$ ERROR_INJECT=1656112173 ../util/shlib_wrap.sh ./x509-test ./corpora/x509/fe543a8d7e09109a9a08114323eefec802ad79e2
#0 0x7fb61945eeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x402f84 in my_malloc fuzz/test-corpus.c:114
#2 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#3 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#4 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#5 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#6 0x7fb618e7aa13 in asn1_string_to_bn crypto/asn1/a_int.c:503
#7 0x7fb618e7aa13 in ASN1_INTEGER_to_BN crypto/asn1/a_int.c:559
#8 0x7fb618fd8e79 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:814
#9 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#10 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#11 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#12 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#13 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#14 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#15 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#16 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#21 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#22 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#23 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#24 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#25 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#26 0x402afb in testfile fuzz/test-corpus.c:182
#27 0x402656 in main fuzz/test-corpus.c:226
#28 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#29 0x402756 (/home/ed/OPC/openssl/fuzz/x509-test+0x402756)
=================================================================
==12221==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef5f11 in BN_new crypto/bn/bn_lib.c:246
#3 0x7fb618ef82f4 in BN_bin2bn crypto/bn/bn_lib.c:440
#4 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#5 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#6 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#7 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#8 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#9 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#10 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#11 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#12 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#16 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#17 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#20 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#21 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#22 0x402afb in testfile fuzz/test-corpus.c:182
#23 0x402656 in main fuzz/test-corpus.c:226
#24 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#3 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#4 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#5 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#6 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#7 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#8 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#9 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#10 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#11 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#12 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#13 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#14 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#15 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#16 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#21 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#22 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#23 0x402afb in testfile fuzz/test-corpus.c:182
#24 0x402656 in main fuzz/test-corpus.c:226
#25 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/18633)
Otherwise the information that the EC group was imported from
explicit parameters is lost when the key is moved across providers.
Fixes#18600
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/18609)
evp_pkey_get_legacy() will return NULL on failure, however several
uses of it or its wrappers does not check the return value of
evp_pkey_get_legacy(), which could lead to NULL pointer dereference.
Fix those possible bugs by adding NULL checking.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17967)
This happens for instance with
fuzz/corpora/asn1/65cf44e85614c62f10cf3b7a7184c26293a19e4a
and causes the OPENSSL_malloc below to choke on the
zero length allocation request.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18365)
This is reproducible with my error injection patch.
The test vector has been validated on the 1.1.1 branch
but the issue is of course identical in all branches.
$ ERROR_INJECT=1652710284 ../util/shlib_wrap.sh ./server-test ./corpora/server/4e48da8aecce6b9b58e8e4dbbf0523e6d2dd56dc
140587884632000:error:03078041:bignum routines:bn_expand_internal:malloc failure:crypto/bn/bn_lib.c:282:
140587884632000:error:10103003:elliptic curve routines:ec_key_simple_oct2priv:BN lib:crypto/ec/ec_key.c:662:
140587884632000:error:100DE08E:elliptic curve routines:old_ec_priv_decode:decode error:crypto/ec/ec_ameth.c:464:
140587884632000:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:
140587884632000:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:309:Type=X509_ALGOR
140587884632000:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=pkeyalg, Type=PKCS8_PRIV_KEY_INFO
140587884632000:error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib:crypto/pem/pem_pkey.c:88:
=================================================================
==19676==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fdd2a6bb09f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fdd2a2fa430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fdd2a15df11 in BN_new crypto/bn/bn_lib.c:246
#3 0x7fdd2a15df88 in BN_secure_new crypto/bn/bn_lib.c:257
#4 0x7fdd2a247390 in ec_key_simple_oct2priv crypto/ec/ec_key.c:655
#5 0x7fdd2a241fc5 in d2i_ECPrivateKey crypto/ec/ec_asn1.c:1030
#6 0x7fdd2a23dac5 in old_ec_priv_decode crypto/ec/ec_ameth.c:463
#7 0x7fdd2a109db7 in d2i_PrivateKey crypto/asn1/d2i_pr.c:46
#8 0x7fdd2a33ab16 in PEM_read_bio_PrivateKey crypto/pem/pem_pkey.c:84
#9 0x7fdd2a3330b6 in PEM_read_bio_ECPrivateKey crypto/pem/pem_all.c:151
#10 0x402dba in FuzzerTestOneInput fuzz/server.c:592
#11 0x40370b in testfile fuzz/test-corpus.c:182
#12 0x402846 in main fuzz/test-corpus.c:226
#13 0x7fdd297b9f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18366)
Rename x86-32 assembly files from .s to .S. While processing the .S file
gcc will use the pre-processor whic will evaluate macros and ifdef. This
is turn will be used to enable the endbr32 opcode based on the __CET__
define.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18353)
Both are the same issue and both as false positives. Annotate the line so
that this is ignored.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/18012)
The assert added cannot ever fail because (current & 0xFFFF) != 0 from the
while loop and the trailing zero bit count therefore cannot be as large as 32.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/17892)
Including e_os.h with a path from a header file doesn't work well on
certain exotic platform. It simply fails to build.
Since we don't seem to be able to stop ourselves, the better move is
to move e_os.h to an include directory that's part of the inclusion
path given to the compiler.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17641)
Add copyright to files that were missing it.
Update license from OpenSSL to Apache as needed.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17606)
Description:
Mark Wooden and Franck Rondepierre noted that the square-root-mod-p
operations used in the EdDSA RFC (RFC 8032) can be simplified. For
Ed25519, instead of computing u*v^3 * (u * v^7)^((p-5)/8), we can
compute u * (u*v)^((p-5)/8). This saves 3 multiplications and 2
squarings. For more details (including a proof), see the following
message from the CFRG mailing list:
https://mailarchive.ietf.org/arch/msg/cfrg/qlKpMBqxXZYmDpXXIx6LO3Oznv4/
Note that the Ed448 implementation (see
ossl_curve448_point_decode_like_eddsa_and_mul_by_ratio() in
./crypto/ec/curve448/curve448.c) appears to already use this simpler
method (i.e. it does not follow the method suggested in RFC 8032).
Testing:
Build and then run the test suite:
./Configure -Werror --strict-warnings
make update
make
make test
Numerical testing of the square-root computation can be done using the
following sage script:
def legendre(x,p):
return kronecker(x,p)
# Ed25519
p = 2**255-19
# -1 is a square
if legendre(-1,p)==1:
print("-1 is a square")
# suppose u/v is a square.
# to compute one of its square roots, find x such that
# x**4 == (u/v)**2 .
# this implies
# x**2 == u/v, or
# x**2 == -(u/v) ,
# which implies either x or i*x is a square-root of u/v (where i is a square root of -1).
# we can take x equal to u * (u*v)**((p-5)/8).
# 2 is a generator
# this can be checked by factoring p-1
# and then showing 2**((p-1)/q) != 1 (mod p)
# for all primes q dividing p-1.
g = 2
s = p>>2 # s = (p-1)/4
i = power_mod(g, s, p)
t = p>>3 # t = (p-5)/8
COUNT = 1<<18
while COUNT > 0:
COUNT -= 1
r = randint(0,p-1) # r = u/v
v = randint(1,p-1)
u = mod(r*v,p)
# compute x = u * (u*v)**((p-5)/8)
w = mod(u*v,p)
x = mod(u*power_mod(w, t, p), p)
# check that x**2 == r, or (i*x)**2 == r, or r is not a square
rr = power_mod(x, 2, p)
if rr==r:
continue
rr = power_mod(mod(i*x,p), 2, p)
if rr==r:
continue
if legendre(r,p) != 1:
continue
print("failure!")
exit()
print("passed!")
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17544)
Also update and slightly extend the respective documentation and simplify some code.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16251)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17276)
If an ECX key is created and the private key is too short, a fromdata
call would create the key, and then later detect the error and report it
after freeing the key. However freeing the key was calling
OPENSSL_secure_clear_free() and assuming that the private key was of the
correct length. If it was actually too short this will write over memory
that it shouldn't.
Fixes#17017
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17041)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16918)
EVP_PKEY_CTX_new_from_pkey() and EVP_CIPHER_CTX_new().
Otherwise may result in memory errors.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16892)
This change adds optional support for
- Armv8.3-A Pointer Authentication (PAuth) and
- Armv8.5-A Branch Target Identification (BTI)
features to the perl scripts.
Both features can be enabled with additional compiler flags.
Unless any of these are enabled explicitly there is no code change at
all.
The extensions are briefly described below. Please read the appropriate
chapters of the Arm Architecture Reference Manual for the complete
specification.
Scope
-----
This change only affects generated assembly code.
Armv8.3-A Pointer Authentication
--------------------------------
Pointer Authentication extension supports the authentication of the
contents of registers before they are used for indirect branching
or load.
PAuth provides a probabilistic method to detect corruption of register
values. PAuth signing instructions generate a Pointer Authentication
Code (PAC) based on the value of a register, a seed and a key.
The generated PAC is inserted into the original value in the register.
A PAuth authentication instruction recomputes the PAC, and if it matches
the PAC in the register, restores its original value. In case of a
mismatch, an architecturally unmapped address is generated instead.
With PAuth, mitigation against ROP (Return-oriented Programming) attacks
can be implemented. This is achieved by signing the contents of the
link-register (LR) before it is pushed to stack. Once LR is popped,
it is authenticated. This way a stack corruption which overwrites the
LR on the stack is detectable.
The PAuth extension adds several new instructions, some of which are not
recognized by older hardware. To support a single codebase for both pre
Armv8.3-A targets and newer ones, only NOP-space instructions are added
by this patch. These instructions are treated as NOPs on hardware
which does not support Armv8.3-A. Furthermore, this patch only considers
cases where LR is saved to the stack and then restored before branching
to its content. There are cases in the code where LR is pushed to stack
but it is not used later. We do not address these cases as they are not
affected by PAuth.
There are two keys available to sign an instruction address: A and B.
PACIASP and PACIBSP only differ in the used keys: A and B, respectively.
The keys are typically managed by the operating system.
To enable generating code for PAuth compile with
-mbranch-protection=<mode>:
- standard or pac-ret: add PACIASP and AUTIASP, also enables BTI
(read below)
- pac-ret+b-key: add PACIBSP and AUTIBSP
Armv8.5-A Branch Target Identification
--------------------------------------
Branch Target Identification features some new instructions which
protect the execution of instructions on guarded pages which are not
intended branch targets.
If Armv8.5-A is supported by the hardware, execution of an instruction
changes the value of PSTATE.BTYPE field. If an indirect branch
lands on a guarded page the target instruction must be one of the
BTI <jc> flavors, or in case of a direct call or jump it can be any
other instruction. If the target instruction is not compatible with the
value of PSTATE.BTYPE a Branch Target Exception is generated.
In short, indirect jumps are compatible with BTI <j> and <jc> while
indirect calls are compatible with BTI <c> and <jc>. Please refer to the
specification for the details.
Armv8.3-A PACIASP and PACIBSP are implicit branch target
identification instructions which are equivalent with BTI c or BTI jc
depending on system register configuration.
BTI is used to mitigate JOP (Jump-oriented Programming) attacks by
limiting the set of instructions which can be jumped to.
BTI requires active linker support to mark the pages with BTI-enabled
code as guarded. For ELF64 files BTI compatibility is recorded in the
.note.gnu.property section. For a shared object or static binary it is
required that all linked units support BTI. This means that even a
single assembly file without the required note section turns-off BTI
for the whole binary or shared object.
The new BTI instructions are treated as NOPs on hardware which does
not support Armv8.5-A or on pages which are not guarded.
To insert this new and optional instruction compile with
-mbranch-protection=standard (also enables PAuth) or +bti.
When targeting a guarded page from a non-guarded page, weaker
compatibility restrictions apply to maintain compatibility between
legacy and new code. For detailed rules please refer to the Arm ARM.
Compiler support
----------------
Compiler support requires understanding '-mbranch-protection=<mode>'
and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT
and __ARM_FEATURE_PAC_DEFAULT). The current state is the following:
-------------------------------------------------------
| Compiler | -mbranch-protection | Feature macros |
+----------+---------------------+--------------------+
| clang | 9.0.0 | 11.0.0 |
+----------+---------------------+--------------------+
| gcc | 9 | expected in 10.1+ |
-------------------------------------------------------
Available Platforms
------------------
Arm Fast Model and QEMU support both extensions.
https://developer.arm.com/tools-and-software/simulation-models/fast-modelshttps://www.qemu.org/
Implementation Notes
--------------------
This change adds BTI landing pads even to assembly functions which are
likely to be directly called only. In these cases, landing pads might
be superfluous depending on what code the linker generates.
Code size and performance impact for these cases would be negligible.
Interaction with C code
-----------------------
Pointer Authentication is a per-frame protection while Branch Target
Identification can be turned on and off only for all code pages of a
whole shared object or static binary. Because of these properties if
C/C++ code is compiled without any of the above features but assembly
files support any of them unconditionally there is no incompatibility
between the two.
Useful Links
------------
To fully understand the details of both PAuth and BTI it is advised to
read the related chapters of the Arm Architecture Reference Manual
(Arm ARM):
https://developer.arm.com/documentation/ddi0487/latest/
Additional materials:
"Providing protection for complex software"
https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software
Arm Compiler Reference Guide Version 6.14: -mbranch-protection
https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en
Arm C Language Extensions (ACLE)
https://developer.arm.com/docs/101028/latest
Addional Notes
--------------
This patch is a copy of the work done by Tamas Petz in boringssl. It
contains the changes from the following commits:
aarch64: support BTI and pointer authentication in assembly
Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791
URL: https://boringssl-review.googlesource.com/c/boringssl/+/42084
aarch64: Improve conditional compilation
Change-Id: I14902a64e5f403c2b6a117bc9f5fb1a4f4611ebf
URL: https://boringssl-review.googlesource.com/c/boringssl/+/43524
aarch64: Fix name of gnu property note section
Change-Id: I6c432d1c852129e9c273f6469a8b60e3983671ec
URL: https://boringssl-review.googlesource.com/c/boringssl/+/44024
Change-Id: I2d95ebc5e4aeb5610d3b226f9754ee80cf74a9af
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16674)
It is better to use array bounds for improved
gcc warning checks.
While "uint8_t*" allows arbitrary pointer arithmetic
using "uint8_t[SER_BYTES]" limits the pointer arithmetic
to the range 0..SER_BYTES.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16376)
Check that there's at least one byte in params->base before trying to
read it.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: David Benjamin <davidben@google.com>
It is possible to call built-in EVP_PKEY_METHOD functions with a provided
key. For example this might occur if a custom EVP_PKEY_METHOD is in use
that wraps a built-in EVP_PKEY_METHOD. Therefore our EVP_PKEY_METHOD
functions should not assume that we are using a legacy key. Instead we
get the low level key using EVP_PKEY_get0_RSA() or other similar functions.
This "does the right thing" if the key is actually provided.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16118)
That check was seen as necessary at the time, but other changes have
been made since, so we now have better control on when we're handling
legacy structures and methods, making it safe to run the export_to
function on keys with foreign methods.
The basic message is that foreign methods must set key structure
values according to our standards no matter what, or not set them at
all. This has really always been the case, but was harder to see at
the time because of interaction with other bugs.
Fixes#15927
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15996)
