wireguard-openbsd/lib/libcrypto/arch/hppa, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/lib/libcrypto/arch/hppa?h=jd%2Fqueueboosts2019-05-11T13:05:24ZRemove commented out rc5 bits2019-05-11T13:05:24Ztbtb@openbsd.org2019-05-11T13:05:24Zurn:sha1:d4aaf8fb7e640b846aec16bec35a1d7f2c9759faRemove I386_ONLY define. It was only used to prefer a2016-11-04T13:56:04Zmiodmiod@openbsd.org2016-11-04T13:56:04Zurn:sha1:4647d16fb4cbf0d3331c83027d620ec393564786
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.
ok tom@ bcook@
Disable ENGINE_load_dynamic (dynamic engine support).2015-06-19T06:05:11Zbcookbcook@openbsd.org2015-06-19T06:05:11Zurn:sha1:9b08b2044f70fb2b1351755a86e57b1ab331448c
We do not build, test or ship any dynamic engines, so we can remove the dynamic
engine loader as well. This leaves a stub initialization function in its place.
ok beck@, reyk@, miod@
In the neverending saga of enabling and disabling assembler code for sha2015-03-18T05:26:10Zmiodmiod@openbsd.org2015-03-18T05:26:10Zurn:sha1:aa11dfc3eb22d757e0d9c150a76a30b7656f0a42
routines on hppa, the cause for sha512-parisc subtly misbehaving has been
found: despite having fallback pa1.1 code when running on a 32-bit cpu, the
shift constants used in the sigma computations in sha512 are >= 32 and are
silently truncated to 5 bits by the assembler, so there is no chance of
getting this code to work on a non-pa2.0 processor.
However, the pa1.1 fallback code for sha256 is safe, as it never attempts to
shift by more than 31, so reenable it again.
Do not use sha512-parisc for now, as it is subtly bugged - passes the sha2015-03-05T20:35:28Zmiodmiod@openbsd.org2015-03-05T20:35:28Zurn:sha1:9332cfbe2e07ec9566e9d14e0d92b7536a92a593
regress tests but causes tls ciphersuite using sha386 to fail; found the
hard way by henning@.
I can't see anything wrong in the generated assembly code yet, but building
a libcrypto with no assembler code but sha512_block_data_order() is enough
to trigger Henning's issue, so the bug lies there.
No ABI change; ok deraadt@
Add the Cammelia cipher to libcrypto.2014-11-17T20:31:20Zmiodmiod@openbsd.org2014-11-17T20:31:20Zurn:sha1:21c207d43b7a2bbf1e5af079673191b332e39cc3
There used to be a strong reluctance to provide this cipher in LibreSSL in the
past, because the licence terms under which Cammelia was released by NTT were
free-but-not-in-the-corners, by restricting the right to modify the source
code, as well retaining the right to enforce their patents against anyone
in the future.
However, as stated in http://www.ntt.co.jp/news/news06e/0604/060413a.html ,
NTT changed its mind and made this code truly free. We only wish there had
been more visibility of this, for we could have had enabled Cammelia
earlier (-:
Licence change noticed by deraadt@. General agreement from the usual LibreSSL
suspects.
Crank libcrypto.so minor version due to the added symbols.
Revert r1.5 and reenable assembler version of ghash now that it has been2014-09-27T20:42:38Zmiodmiod@openbsd.org2014-09-27T20:42:38Zurn:sha1:9ffb6228728b0b56cc26815b14d8230cbd977714
fixed.
Disable assembler code for ghash on hppa, causes wrong computations in some2014-09-27T12:29:31Zmiodmiod@openbsd.org2014-09-27T12:29:31Zurn:sha1:e9409066dbe2c5ef6bf1f212c0bc0834a91cdea0
cases and breaks TLS 1.2; crank libcrypto.so minor version out of safety and
to be able to tell broken versions apart easily.
i'm a dumbdumb. fix build.2014-07-11T14:32:59Ztedutedu@openbsd.org2014-07-11T14:32:59Zurn:sha1:2d03d1cb16f932679be3ce45b285fa08b24b740dmove all the feature settings to a common header.2014-07-11T14:01:38Ztedutedu@openbsd.org2014-07-11T14:01:38Zurn:sha1:5e5c016ed07331adde9d77d6745a6e2a3f77889b
probably ok beck jsing miod