Langley's Chromium OpenSSL patches.
ok miod@

implementations. This largely pulls in Adam Langley's AEAD patches from
Chromium's OpenSSL.
ok miod@

required. try to document this fact and some of the history.
with feedback from deraadt guenther millert

implementation.
ok miod@

probably more 32-bit platforms).
Problem noticed by tobiasu@; ok tobiasu@ dtucker@ sthen@ benno@

of 64-bit data, and only used by DTLS, to libssl where it belongs.
Remove pqueue_print() which is a debugging interface and serves no useful
purpose, except for the regress test, which grows its own pqueue_print()
routine.
Bump libcrypto major and libssl minor.
WARNING: do not update your tree right now, more changes are coming, which
will ride the libcrypto major bump.

while changing things, add a crypt_checkpass wrapper that handles most of
the edge cases. (not quite ready for production, though.)
ok deraadt

It's not a standard interface, so it doesn't belong in libc.
I hate duplicating the code in client programs, so do beck@, kettenis@,
schwarze@, millert@, miod@... and they agree with libutil.

(mostly use a calloc function to avoid potential integer overflow)

deterministic behavior. four selected because it's more than three, less
than five. i.e., no particular reason.

can avoid reinventing the wheel
ok guenther schwarze

ok crickets@

the only useful option here is to specify an alternative config path,
which must be used for these operations as well as for startup.

beauty sleep.  He's probably having a nightmare about this right now....
ok tedu

these files similar in layout to the other md Makefile.inc; no functional
change.

wherever it decides it would like them. first step. ok deraadt dlg djm

uses the `umul' and `udiv' instructions directly, which are not supported
on v7 processors.

or the !SSLASM list of files applies. This allows for an arch-specific
Makefile.inc to not specify SSLASM.

The sparcv9 BN code is not enabled, as it expects to run on a 32-bit
userland and will need to be fixed for 64-bit userland first.

Note that GCM128 Neon code is currently not built (and thus not tested), as
the current toolchain does not support Neon instructions.

switch to generating them by default. prodded by deraadt and sthen

2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4. Slightly more consistent style between various parse and check and
increment operations on salt.
ok deraadt

OK millert@

- Explicitly cast double-precision constants as needed for
FLT_EVAL_METHOD = 2 archs
OK guenther@, ratchov@

Assembler bits for AES remain commented out as they run slower than the C code.

things. Worth doing as it's twice faster than the C code.

RC4 assembler code is not used, as it runs about 35% slower than the C code.

ok deraadt@