| Age | Commit message (Collapse) | Author |
|---|
|
bn_print.c r1.29 added length checks to avoid overflowing the BIGNUM.
If these checks are hit in length-only mode, i.e., bn is NULL, the
error path dereferences bn. Change goto err to an early return to
avoid this.
ok jsing
|
|
|
|
All other wrappers in the same file that use a temporary array of
degrees size that array dynamically, such that they are able to
handle reducing polynomials of arbitrary lengths. BN_GF2m_mod(3)
was the only one that used a static array of size 6 instead, limiting
it to trinomials and pentanomials and causing it to fail for longer
reducing polynomials.
Make this more uniform and less surprising by using exactly the
same code as in all the other wrappers, such that BN_GF2m_mod(3)
works with reducing polynomials of arbitrary length, too, just like
the others.
Again, tb@ points out this quirk is very unlikely to cause
vulnerabilities in practice because cryptographic applications do
not use longer reducing polynomials.
This patch is not expected to significantly impact performance
because the relevant caller, BN_GF2m_mod_div(3), already uses dynamic
allocation via BN_GF2m_mod_mul(3).
OK tb@
|
|
If the last argument, the size of the output array, is too small to
contain all degrees present in the input polynomial plus one for the
terminating -1, the function is documented to return the size of the
output array that would be needed (in comments in the source code, in
the new manual page, and by the way how the function is used by other
functions in the same file). However, in case of overflow, the existing
code failed to include the element needed for the terminating -1 in the
return value, wrongly indicating success if everything but the -1 did
fit and reporting failure with a size that was still too small otherwise.
According to tb@, this is very unlikely to cause vulnerabilities in
practical applications because there is no real reason to pick a
reducing polynomial longer than a pentanomial, because all known
callers use either fixed size arrays of size 6 or dynamic allocation,
because use of GF(2^m) is rare in practice, and GF(2^m) with custom
reducing polynomials even more so.
OK tb@
|
|
It was placed and formatted weirdly. Fix the title of the book referenced
and complete the reference's information.
|
|
Since DSA_sign() and DSA_verify() ignore their type argument, don't bother
to determine it here. Check all size_t for overflow before passing them as
int arguments. Follow OpenSSL and add a check to see if the tbs blob's
length matches the one of the md, in case it is set on the EVP_PKEY_CTX.
Fix return value check of DSA_sign().
ok jsing
|
|
Change DSA_sign() to single exit and check the signed i2d_DSA_SIG() return
value before assigning it to an unsigned int.
In DSA_verify() let d2i_DSA_SIG() handle the allocation, split error check
of i2d_DSA_SIG() from signature check and change an unnecessary freezero()
to free.
ok jsing
|
|
Dealing with elliptic curves makes some people think that it would be kind
of neat to multiply types with variable names. Sometimes. Only in function
definitions.
|
|
|
|
|
|
|
|
This is an undocumented feature of openssl genpkey for testing purposes.
Emilia removed support for this 'bogus private key format' from OpenSSL
in 2017 in commit c26f655fdd18ac19016c1c0496105f5256a1e84d.
ok jsing
|
|
Avoids a segfault when both priv == NULL and os == NULL.
ok miod
|
|
|
|
Obviously, the brilliant API design kitchen decided that an interface
carrying public and private key in its name (so that every sane person
thinks of asymmetric cryptography), is also perfectly suitable for MACs.
Wire up HMAC since Ruby's OpenSSL gem uses these bindings if the build
system detects that EVP_PKEY_new_raw_public_key() is available in evp.h.
While there, also add the missing pub_cmp() ameth, which obviously
treats two things as equal by returning 1.
Reported by jeremy and anton, fixes regress/lib/libssl/openssl-ruby tests
ok jsing
|
|
Now that EVP_PKEY is opaque, there is no reason to keep the ptr member
of the pkey union as a weird char pointer, a void pointer will do. This
avoids a few stupid casts and simplifies an upcoming diff.
ok jsing
|
|
discussed with schwarze
|
|
ok schwarze
|
|
concerning arithmetic in Galois fields of power-of-2 order
|
|
Add a check that ensures that the upper half s of an Ed25519 signature is
bounded by the group order, i.e, 0 <= s < order. This is required by the
Verify procedure in RFC 8032, section 5.1.7, step 1, and prevents simple
modifications of signatures such as adding (a multiple of) the group order
to the upper half of the signature.
Found with EdDSA testcase 63 of project Wycheproof.
ok beck jsing
|
|
Programs assume that a successful call to getaddrinfo(3) validates the
input as "safe", but that's not true. Characters like '$', '`', '\n'
or '*' can traverse the DNS without problems, but have special
meaning, for example a shell.
There is a function res_hnok() already in libc, but it validates if a
string is a host name, which is too strict in practice. For example
foo-.example.com is not a valid host name, but is used on the
Internet.
Posix has this to say:
"The getaddrinfo() function shall translate the name of a service
location (for example, a host name)"
It hints that the input should be a host name, but it does not
restrict it to it.
This introduces a function hnok_lenient() which restricts the input to
getaddrinfo(3) to the set [A-z0-9-_.]. Additionally two consecutive
dots ('.') are not allowed nor can the string start with - or '.'.
glibc introduced a similar restriction years ago, so this should not
cause problems.
It has been known in the DNS community for years, probably decades
that getaddrinfo(3) is too lenient what it accepts, but it has always
been kicked down the road as "not a DNS problem". Unfortunately this
information never made it out of the DNS community and no coordinated
effort happened to have this addressed in operating systems.
David Leadbeater recently demonstrated how ssh(1) and ftp(1) are too
trusting with what getaddrinfo(3) accepts. Both have been fixed
independently of this.
Input deraadt, eric
OK millert, deraadt
|
|
There are some possible strange side effects noticed by the
openssl cms regress tests that I missed. Backing this out
until I untangle it
ok tb@
|
|
uppercase.
While here use the correct idiom of casting to unsigned char.
OK millert, farewell to ultrix deraadt
|
|
and BN_X931_generate_Xpq as intentionally undocumented because
they are unused outside OpenSSL/LibreSSL and deprecated in OpenSSL 3.0
|
|
and X509_STORE_set_verify(3) and document X509_STORE_get_verify(3)
which tb@ all provided with x509_vfy.h revisions 1.48 and 1.49
|
|
which tb@ provided with x509_vfy.h revisions 1.48 and 1.49
|
|
It appears to be intended for internal use by DSA_do_verify(3) and using
codesearch.debian.net, i found nothing outside OpenSSL/LibreSSL using it.
In April 2018, jsing@ questioned whether the five related functions
BN_mod_exp_mont() and friends should even be exposed by <openssl/bn.h>,
so we decided to not document them. Now tb@ agrees that there is no
reason to document BN_mod_exp2_mont() as long as we don't want to
document BN_mod_exp_mont().
|
|
|
|
|
|
|
|
ok tb@
|
|
|
|
1. Explain up front what "ASN1_TIME" is (suggested by beck@, wording by me).
2. For opaque structs, use the generic term "object",
like we already do it in many other LibreSSL manual pages.
3. Drop some redundant phrases.
4. Improve the EXAMPLES section (by beck@, with fixes by me).
6. Add a STANDARDS section.
...and some other minor polishing.
OK beck@
|
|
Historically the standards let the implementation decide to
either check or ignore the certificate properties of trust anchors.
You could either use them simply as a source of a public key which
was trusted for everything, or you were also permitted to check the
certificate properties and fully enforce them. Hooray for freedumb.
OpenSSL changed to checking these with :
commit 0daccd4dc1f1ac62181738a91714f35472e50f3c
Author: Viktor Dukhovni <openssl-users@dukhovni.org>
Date: Thu Jan 28 03:01:45 2016 -0500
BoringSSL currently does not check them, as it also inherited
the previous OpenSSL behaviour. It will change to check them in
the future.
(https://bugs.chromium.org/p/boringssl/issues/detail?id=533)
|
|
libcrypto now provides Ed25519 and the raw public key API, so neuter the
compat implementations. Also link libfido against libcrypto.
The #ifdefs were upstreamed in https://github.com/Yubico/libfido2/pull/645
no objection djm
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
This adds the EVP_PKEY_ED25519 and EVP_PKEY_X25519 aliases for the NIDs
and exposes the raw public key API.
The ED25519_KEYLEN and X25519_KEYLEN defines are still kept internal for
now to match what OpenSSL have. We may want to expose those later.
|
|
The Ed25519 versions already existed, but OpenSSL chose to uppercase the D.
|
|
This is needed to print the 32-byte Ed25519 keys which aren't handled
as BNs.
|
|
ok jsing@
|
|
ok jsing@
|
|
This applies the guentherizer 9000(tm) to pkcs7, after moving
several pkcs7 funcitions back to pkcs7 that were in x509/x_all.c
for reasons known only to the miasma.
ok jsing@
|
|
Automated change from the first attempts at the semi automated
Guentherizer 2000.
ok jsing@ tb@ joshua@
|
|
This converts the legacy TLS stack to tls_content - records are now
opened into a tls_content structure, rather than being written back into
the same buffer that the sealed record was read into.
This will allow for further clean up of the legacy record layer.
ok tb@
|
|
While grouping the API by its purpose is nice, it doesn't help much if >90%
is "general API".
ok jsing
|
|
Requested by tb@
|
