There is currently no sane way of getting your hands on the common name or
subject alternative name of the peer certificate from libtls. It is possible
to extract it from the peer cert's PEM by hand, but that way lies madness.
While the common name is close to being deprecated in the webpki, it is
still the de facto standard to identify client certs. It would be nice to
have a way to access the subject alternative names as well, but this is a
lot more difficult to expose in a clean and sane C interface due to its
multivaluedness.
Initial diff from henning, with input from beck, jsing and myself
henning and bluhm have plans of using this in syslogd.
ok beck
and document them properly in their own manual page, including the control
commands EVP_CTRL_SET_RC2_KEY_BITS and EVP_CTRL_GET_RC2_KEY_BITS that were
so far undocumented.
Arguably, the main benefit is another small step making the important,
but still obese EVP_EncryptInit(3) manual page more palatable.
This refactors the wNAF multiplication further and introduces a small API
that manages the wNAF digits for bn and the multiples of digit * point in
a single struct that is initialized and freed in two API calls in the main
function, ec_wNAF_mul(). This way the main algorithm is no longer cluttered
with logic to keep various arrays in sync, helper functions calculating the
wNAF splitting of bn and multiples of the point do not need to deal with
memory management, and a pair of accessors obviates previously missing
bounds checking.
At this point we have reached a relatively clean and straightforward wNAF
implementation that fits precisely the purpose needed in libcrypto, i.e.,
ECDSA verification instead of being generalized and optimized to the max
for no good reason apart from endowing the author with an academic degree.
Popper's famous maxim "if you can't say it clearly, keep quiet, and keep
working until you can" very much applies to code as well. In other words,
shut up and hack (and don't pour too much energy into commit messages, tb).
ok jsing
because tb@ deleted almost all functions documented there from the API
in evp.h 1.127 on March 2 this year, but move the functions
EVP_PKEY_CTX_set_data(3) and EVP_PKEY_CTX_get_data(3) that we still
support to EVP_PKEY_keygen(3), because that page already documents
EVP_PKEY_CTX_set_app_data(3) and EVP_PKEY_CTX_get_app_data(3).
This provides a SHA-1 assembly implementation for amd64, which uses
the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This
provides a 2-2.5x performance gain on some Intel CPUs and many AMD CPUs.
ok tb@
It's so non-obvious that even i had to do some research to find out.
Source: The file "doc/ssleay.doc" from SSLeay 0.8.1b,
see for example OpenSSL commit d02b48c6 on Dec 21, 1998.
We match curve parameters against the builtin curves and only accept
them if they're encoding a curve known to us. After getting rid of the
wtls curves, some of which used to coincide with secp curves (sometimes
the wrong ones), the nid is unambiguous. Setting the nid has no direct
implications on the encoding.
This helps ssh avoid doing ugly computations during the key exchange
for PEM keys using this encoding.
ok djm joshua jsing
Rename it to DSA_prime_checks and add an XXX comment mentioning that
we could reduce the number of rounds thanks to BPSW. There are no
plans of changing that as DSA is on its way out.
discussed with miod
As already done for SHA-256 and SHA-512, replace the perlasm generated
SHA-1 assembly implementation with one that is actually readable. Call the
assembly implementation from a C wrapper that can, in the future, dispatch
to alternate implementations. On a modern CPU the performance is around
5% faster than the base implementation generated by sha1-x86_64.pl, however
it is around 15% slower than the excessively complex SSSE2/AVX version that
is also generated by the same script (a SHA-NI version will greatly
outperform this and is much cleaner/simpler).
ok tb@
This should really have been using SECP 160R2, not SECP 160R1. Of course
this means in particular that nobody ever used this curve, at least not
against another implementation than OpenSSL. Quasi-monocultures are
poisonous whether the monopolist is benevolent and competent or not.
Like most of the "group" methods these are shared between Montgomery
curves and simple curves. There's no point in five methods hanging off
the EC_METHODS struct whne they can just as well be inlined in the
public API. It makes all files involved shorter...
ok jsing
While there likely won't be enough BNs already available in the ctx, and
thus it won't greatly reduce the amount of allocated BNs, it simplifies
the exit path quite a bit.
review feedback from jsing
It is unclear how the original code was supposed to work. It clearly
missed a few corner cases (like handling points at infinity correctly)
and the badly mangled comment that was supposed to display a binary
search tree didn't help at all.
Instead do something much more straightforward: multiply all the non-zero
Z coordinates of the points not at infinity together, keeping track of the
intermediate products. Then do a single expensive modular inversion before
working backwards to compute all the inverses. Then the transformation from
Jacobian coordinates to affine coordiantes (x, y, z) -> (x/z^2, y/z^3, 1)
becomes cheap. A little bit of care has to be taken for Montgomery curves
but that's very simple compared to the mess that was there before.
ok jsing
This is a cleaned up version of:
commit 0fe73d6c3641cb175871463bdddbbea3ee0b62ae
Author: Bodo Moeller <bodo@openssl.org>
Date: Fri Aug 1 17:18:14 2014 +0200
Simplify and fix ec_GFp_simple_points_make_affine
(which didn't always handle value 0 correctly).
Reviewed-by: emilia@openssl.org
In the unlikely event that we should ever decide to implement this after
a quarter century of not needing it, we can readily put this back. Until
then this is dead weight.
prompted by a question by djm
ok jsing
fd which is passed as argument.
This is needed because on Linux the control messages used to pass fds
are not acting as a barrier and ensuring that the fd is passed with the
first byte of the read call. Instead we need to mark the message that
holds to fd and the scan for that message in the stream.
While there also adjust imsgbuf_set_maxsize() to return an int to
indicate an error if the requested size is out of range.
Problem reported and fix tested by nicm@ on a linux system.
OK tb@
There are only two flag values that libcrypto understands and the default
value is 1 while, helpfully, the undesirable non-default is 0. The few
existing callers set OPENSSL_EC_NAMED_CURVE or OPENSSL_EC_EXPLICIT_CURVE.
Nevertheless, the flag should be checked properly as a flag. The recent
upstream checks for EC_GROUP_get_asn1_flag(group) == OPENSSL_EC_NAMED_CURVE
don't look right either...
ok jsing
such that it becomes intelligible but not too long or prominent.
In particular, don't talk about EVP_PKEY_CTX_new(3), don't forget to
mention EVP_PKEY_keygen(3), mention EVP_PKEY_OP_KEYGEN, and mention
how to proceed once you have the desired EVP_PKEY object in hand.
Substantial feedback and OK tb@.
This disables all the curves over fields < 224 bits and a few others.
Specifically:
SECG: 112r1 112r2 128r1 128r2 160k1 160r1 160r2 192k1 192r1 192v{1,2,3}
WTLS: 6 7 8 9 12
Brainpool: P160r1 P160t1 P192r1 P192t1
These are below or at the limit of what is acceptable nowadays. This is
less aggressive than what some enterprise linux distributions are using
in their patched OpenSSL versions where everything over fields < 256 bits
is disabled with the exception of P-224, so interoperability should not
be a problem.
The curves are left in the tree for now and can be re-enabled by compiling
libcrypto with -DENABLE_SMALL_CURVES. They will be fully removed later.
One nice benefit of doing this is that the incorrect parameters for WTLS 7
are fixed (obviously nobody uses this one) and now all the builtin curves
have a unique corresponding OID (nid).
Something like this was suggested a while back by beck, makes sense to sthen
ok jsing
Rather than having blocks of code that are conditional on
BYTE_ORDER != LITTLE_ENDIAN, use le64toh() and htole64() unconditionally.
In the case of a little endian platform, the compiler will optimise this
away, while on a big endian platform we'll either end up with better code
or the same code than we have currently.
ok tb@
The big change is that the "rows" are no longer slices of val[] but
that they actually own the points they contain. The price for this
is an extra allocation for val[] and to piece it together from the
two rows. That's ugly, but less ugly than before.
Add a helper for freeing a row of points. It can deal with a NULL
row so, we can remove a couple of complications.
The second change is that the logic for preparing the rows is pulled
back into ec_wNAF_mul[]. This way the m * G + n * P logic is in the
one function that needs to know about it, the rest just deals with
a pair of a point and a scalar.
This starts resembling actual code...
ok jsing
