| History log of /src/sys/rump/kern/lib/libcrypto |
| Revision | Date | Author | Comments |
| 1.24 | 26-Jul-2024 |
riastradh | sys/crypto/sodium: Add a self-test for IETF ChaCha20/Poly1305 AEAD.
PR kern/58468
|
| 1.23 | 21-Aug-2021 |
christos | branches: 1.23.4; 1.23.10;
rename glue.c to sodium_module.c
|
| 1.22 | 21-Aug-2021 |
christos | Add glue.c for libsodium (suggested by riastradh). Tidy up.
|
| 1.21 | 27-Aug-2020 |
riastradh | Move address hashing from init_main.c to kern_sysctl.c.
This way rump gets it automatically. Make sure blake2s is in
librumpkern.so, not just in librumpkern_crypto.so, for this to work.
|
| 1.20 | 26-Aug-2020 |
riastradh | Tidy up libsodium makefile and config fragments.
|
| 1.19 | 21-Aug-2020 |
riastradh | Disable libsodium HAVE_TI_MODE for now.
This may reduce performance by not taking advantage of 64x64->128
multiplications on some platforms, but let's worry about that later
and fix the build on the other platforms instead.
|
| 1.18 | 21-Aug-2020 |
riastradh | Split flags onto separate lines, sorted, to make diffs easier.
|
| 1.17 | 21-Aug-2020 |
riastradh | Disable -Wshadow for libsodium.
Evidently ed25519_ref10.c has a global and a local both named `d'.
|
| 1.16 | 20-Aug-2020 |
riastradh | Missed a spot -- add sys/crypto/blake2 to .PATH here.
|
| 1.15 | 20-Aug-2020 |
riastradh | Fix vestiges of libb2.
|
| 1.14 | 20-Aug-2020 |
riastradh | [ozaki-r] Changes to the kernel core for wireguard
|
| 1.13 | 28-Jul-2020 |
riastradh | Rewrite cprng_fast in terms of new ChaCha API.
|
| 1.12 | 26-Jul-2020 |
riastradh | Fix more sort order.
|
| 1.11 | 26-Jul-2020 |
riastradh | Add missing aes_ccm.c, aes_ccm_mbuf.c. Fix sort order.
|
| 1.10 | 26-Jul-2020 |
riastradh | Add chacha to rump libcrypto.
|
| 1.9 | 25-Jul-2020 |
riastradh | Remove now-unused legacy rijndael API.
|
| 1.8 | 29-Jun-2020 |
riastradh | New cgd cipher adiantum.
Adiantum is a wide-block cipher, built out of AES, XChaCha12,
Poly1305, and NH, defined in
Paul Crowley and Eric Biggers, `Adiantum: length-preserving
encryption for entry-level processors', IACR Transactions on
Symmetric Cryptology 2018(4), pp. 39--61.
Adiantum provides better security than a narrow-block cipher with CBC
or XTS, because every bit of each sector affects every other bit,
whereas with CBC each block of plaintext only affects the following
blocks of ciphertext in the disk sector, and with XTS each block of
plaintext only affects its own block of ciphertext and nothing else.
Adiantum generally provides much better performance than
constant-time AES-CBC or AES-XTS software do without hardware
support, and performance comparable to or better than the
variable-time (i.e., leaky) AES-CBC and AES-XTS software we had
before. (Note: Adiantum also uses AES as a subroutine, but only once
per disk sector. It takes only a small fraction of the time spent by
Adiantum, so there's relatively little performance impact to using
constant-time AES software over using variable-time AES software for
it.)
Adiantum naturally scales to essentially arbitrary disk sector sizes;
sizes >=1024-bytes take the most advantage of Adiantum's design for
performance, so 4096-byte sectors would be a natural choice if we
taught cgd to change the disk sector size. (However, it's a
different cipher for each disk sector size, so it _must_ be a cgd
parameter.)
The paper presents a similar construction HPolyC. The salient
difference is that HPolyC uses Poly1305 directly, whereas Adiantum
uses Poly1395(NH(...)). NH is annoying because it requires a
1072-byte key, which means the test vectors are ginormous, and
changing keys is costly; HPolyC avoids these shortcomings by using
Poly1305 directly, but HPolyC is measurably slower, costing about
1.5x what Adiantum costs on 4096-byte sectors.
For the purposes of cgd, we will reuse each key for many messages,
and there will be very few keys in total (one per cgd volume) so --
except for the annoying verbosity of test vectors -- the tradeoff
weighs in the favour of Adiantum, especially if we teach cgd to do
>>512-byte sectors.
For now, everything that Adiantum needs beyond what's already in the
kernel is gathered into a single file, including NH, Poly1305, and
XChaCha12. We can split those out -- and reuse them, and provide MD
tuned implementations, and so on -- as needed; this is just a first
pass to get Adiantum implemented for experimentation.
|
| 1.7 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation.
2. Replace it by BearSSL's constant-time 32-bit logic.
=> Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5.
=> We could conditionally adopt the 64-bit logic too, which would
likely give a modest performance boost on 64-bit platforms
without AES-NI, but that's a bit more trouble.
3. Select the AES implementation at boot-time; allow an MD override.
=> Use self-tests to verify basic correctness at boot.
=> The implementation selection policy is rather rudimentary at
the moment but it is isolated to one place so it's easy to
change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves
the way to take advantage of CPU support for AES -- both things we
should've done a decade ago. Downside: Computing AES takes 2-3x the
CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp
dd if=/dev/zero of=/tmp/disk bs=1m count=512
vnconfig -cv vnd0 /tmp/disk
cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero
dd if=/dev/rcgd0d of=/dev/null bs=64k
dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it
is inherently sequential; the AES-CBC decryption impact is closer to
2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
| 1.6 | 05-Dec-2019 |
riastradh | Missed a spot in the crypto/arc4 deletion.
|
| 1.5 | 02-Sep-2019 |
riastradh | Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security'
- better resistance to timing side channels than AES
- a better-understood security story (https://eprint.iacr.org/2018/349)
- no loss in compliance with US government standards that nobody ever
got fired for choosing, at least in the US-dominated western world
- no dirty endianness tricks
- self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements
=> possible to mitigate by using hardware SHA-256 instructions
=> all you really need is 32 bytes to seed a userland PRNG anyway
=> if we just used ChaCha this would go away...
XXX pullup-7
XXX pullup-8
XXX pullup-9
|
| 1.4 | 19-Oct-2015 |
pooka | branches: 1.4.10; 1.4.18; 1.4.22;
Add a COMMENT describing what each component roughly does.
"make describe" prints the comment.
Requested/inspired by Vincent Schwarzer on rumpkernel-users
|
| 1.3 | 17-Jan-2014 |
pooka | branches: 1.3.4; 1.3.6; 1.3.8; 1.3.12;
Use subr_cprng.c instead of stub implementation. Rijndael migrates from
rumpkern_crypto to rumpkern due to it being mandatory for cprng.
|
| 1.2 | 14-Jan-2014 |
pgoyette | Add the MODULE parts for blowfish and des.
Add camellia algorithm. (pooka@ says no lib version change required)
|
| 1.1 | 05-Dec-2010 |
pooka | branches: 1.1.6; 1.1.10; 1.1.20; 1.1.24;
rumpcrypto should never have been its own faction, so finally make
it a component under kern, i.e. rumpcrypto -> rumpkern_crypto.
|
| 1.1.24.1 | 18-May-2014 |
rmind | sync with head
|
| 1.1.20.2 | 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.1.20.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.1.10.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
|
| 1.1.6.2 | 05-Mar-2011 |
rmind | sync with head
|
| 1.1.6.1 | 05-Dec-2010 |
rmind | file Makefile was added on branch rmind-uvmplock on 2011-03-05 20:56:13 +0000
|
| 1.3.12.1 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1
sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1
sys/rump/kern/lib/libcrypto/Makefile: revision 1.5
sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1
sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal
sys/conf/files: revision 1.1238
sys/dev/rndpseudo.c: revision 1.38
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal
sys/sys/cprng.h: revision 1.13 - 1.15
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal
sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal
sys/kern/subr_cprng.c: revision 1.31
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include
headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security'
- better resistance to timing side channels than AES
- a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>)
- no loss in compliance with US government standards that nobody ever
got fired for choosing, at least in the US-dominated western world
- no dirty endianness tricks
- self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements
=> possible to mitigate by using hardware SHA-256 instructions
=> all you really need is 32 bytes to seed a userland PRNG anyway
=> if we just used ChaCha this would go away...
|
| 1.3.8.1 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1
sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1
sys/rump/kern/lib/libcrypto/Makefile: revision 1.5
sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1
sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal
sys/conf/files: revision 1.1238
sys/dev/rndpseudo.c: revision 1.38
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal
sys/sys/cprng.h: revision 1.13 - 1.15
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal
sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal
sys/kern/subr_cprng.c: revision 1.31
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include
headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security'
- better resistance to timing side channels than AES
- a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>)
- no loss in compliance with US government standards that nobody ever
got fired for choosing, at least in the US-dominated western world
- no dirty endianness tricks
- self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements
=> possible to mitigate by using hardware SHA-256 instructions
=> all you really need is 32 bytes to seed a userland PRNG anyway
=> if we just used ChaCha this would go away...
|
| 1.3.6.1 | 27-Dec-2015 |
skrll | Sync with HEAD (as of 26th Dec)
|
| 1.3.4.1 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1
sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1
sys/rump/kern/lib/libcrypto/Makefile: revision 1.5
sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1
sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal
sys/conf/files: revision 1.1238
sys/dev/rndpseudo.c: revision 1.38
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal
sys/sys/cprng.h: revision 1.13 - 1.15
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal
sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal
sys/kern/subr_cprng.c: revision 1.31
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include
headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security'
- better resistance to timing side channels than AES
- a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>)
- no loss in compliance with US government standards that nobody ever
got fired for choosing, at least in the US-dominated western world
- no dirty endianness tricks
- self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements
=> possible to mitigate by using hardware SHA-256 instructions
=> all you really need is 32 bytes to seed a userland PRNG anyway
=> if we just used ChaCha this would go away...
|
| 1.4.22.1 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #173):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1
sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1
sys/rump/kern/lib/libcrypto/Makefile: revision 1.5
sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1
sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal
sys/conf/files: revision 1.1238
sys/dev/rndpseudo.c: revision 1.38
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal
sys/sys/cprng.h: revision 1.15
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal
sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal
sys/kern/subr_cprng.c: revision 1.31
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security'
- better resistance to timing side channels than AES
- a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>)
- no loss in compliance with US government standards that nobody ever
got fired for choosing, at least in the US-dominated western world
- no dirty endianness tricks
- self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements
=> possible to mitigate by using hardware SHA-256 instructions
=> all you really need is 32 bytes to seed a userland PRNG anyway
=> if we just used ChaCha this would go away...
XXX pullup-7
XXX pullup-8
XXX pullup-9
|
| 1.4.18.2 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 1.4.18.1 | 08-Apr-2020 |
martin | Merge changes from current as of 20200406
|
| 1.4.10.1 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1365):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1
sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1
sys/rump/kern/lib/libcrypto/Makefile: revision 1.5
sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1
sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal
sys/conf/files: revision 1.1238
sys/dev/rndpseudo.c: revision 1.38
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal
sys/sys/cprng.h: revision 1.13 - 1.15
sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal
sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal
sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal
sys/kern/subr_cprng.c: revision 1.31
sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include
headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security'
- better resistance to timing side channels than AES
- a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>)
- no loss in compliance with US government standards that nobody ever
got fired for choosing, at least in the US-dominated western world
- no dirty endianness tricks
- self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements
=> possible to mitigate by using hardware SHA-256 instructions
=> all you really need is 32 bytes to seed a userland PRNG anyway
=> if we just used ChaCha this would go away...
|
| 1.23.10.1 | 02-Aug-2025 |
perseant | Sync with HEAD
|
| 1.23.4.1 | 09-Oct-2024 |
martin | Pull up following revision(s) (requested by riastradh in ticket #933):
sys/external/isc/libsodium/src/sodium_module.c: revision 1.2
sys/external/isc/libsodium/include/core.h: revision 1.2
sys/external/isc/libsodium/include/stdlib.h: revision 1.2
sys/modules/sodium/Makefile.sodmod: revision 1.4
sys/external/isc/libsodium/include/crypto_verify_16.h: revision 1.2
sys/external/isc/libsodium/include/errno.h: file removal
sys/crypto/sodium/sodium_selftest.h: revision 1.1
sys/external/isc/libsodium/include/stdint.h: revision 1.2
sys/crypto/sodium/sodium_selftest.h: revision 1.2
sys/external/isc/libsodium/include/assert.h: file removal
sys/external/isc/libsodium/conf/files.libsodium: revision 1.7
sys/rump/kern/lib/libcrypto/Makefile: revision 1.24
sys/external/isc/libsodium/src/sodium_selftest.c: revision 1.1
sys/external/isc/libsodium/src/sodium_selftest.c: revision 1.2
sys/external/isc/libsodium/include/string.h: revision 1.2
sys/crypto/sodium: Add a self-test for IETF ChaCha20/Poly1305 AEAD.
PR kern/58468
sys/crypto/sodium: Fill out crypto_verify_16 stub.
Without this change, libsodium silently accepts forgeries.
This one's a doozy, and it's a sobering reminder that:
(a) wg(4) is still experimental (only user of libsodium in kernel;
both are available only through default-off optional modules).
(b) Known-answer test vectors are critical, including negative tests
(test that forgeries are rejected), and must be mandatory for all
new crypto code -- and should be added to old crypto code too.
(c) Crypto code must also have self-tests that run in the same
environment, not just the same code in a different build or test
environment -- the libsodium code itself is fine, but we built it
differently and need to exercise it differently from upstream's
automatic tests.
It's my fault for not catching this earlier. What happened is:
1. ozaki-r@ adapted libsodium to build in the kernel with various
glue to build code meant for standard userland C, like errno.h and
string.h.
2. Since libsodium's crypto_verify_16.c uses various SIMD intrinsics
on various architectures, it couldn't be used directly in the
kernel build, because -- at the time -- we hadn't wired up any
header files for SIMD intrinsics or any runtime support for saving
and restoring SIMD state appropriately in the kernel.
3. ozaki-r@ put a similar glue header file crypto_verify_16.h to
override libsodium's, with a stub to be implemented later, and
presumably forgot to remind me about it.
4. I missed the stub in crypto_verify_16.h when reviewing the
libsodium import and wg(4) code because it was in the same
directory as various other simple glue code that I deemed
low-risk.
(I did make one change to that glue code, to replace cprng_fast by
cprng_strong, but I suspect I found that by searching for
cprng_fast users rather than by reviewing this code.)
5. I broke my own rule about always having known-answer test vectors
for crypto code because I figured libsodium was well-enough
exercised that we could skimp on it for now, and my focus was more
on the state machine and synchronization logic than on the crypto.
6. I had not yet written known-answer test vectors for the
higher-level wg(4) protocol messages.
Before we can remove the `experimental' tag from wg(4) we will need
to (among other things):
i. Write self-tests for the rest of (what we use from) libsodium.
ii. Write extensive known-answer test vectors for all the wg(4)
protocol messages (and ideally state machine transitions).
iii. Write self-tests for a reasonable subset of the wg(4) KATs.
iv. Review all of the libsodium glue code I neglected to review.
PR kern/58468
sys/crypto/sodium: Simplify string.h stub.
Not sure of any particular problem with the previous stub, but let's
make sure to use the same prototypes for memset/memcpy/memmove as
everything else in the kernel.
PR kern/58468
sys/crypto/sodium: Nix unused assert.h stub.
Maybe this was a vestige of an earlier draft of the libsodium import,
but it doesn't appear to be needed now by any libsodium files we use.
PR kern/58468
sys/crypto/sodium: Nix risky defines from core.h stub.
These are risky not because they might cause crypto flaws, but
because they might cause usage of the SIMD unit in the kernel along
paths where we haven't made it safe.
That said -- no change to the amd64 module .o and .kmod files, so
this doesn't currently make a difference; it's just risky to have
around in case we later include other parts of libsodium that it does
affect, like the Salsa20 code.
PR kern/58468
sys/crypto/sodium: Nix unused errno.h.
Maybe this was a vestige of an earlier draft of the libsodium import,
but it doesn't appear to be needed now by any libsodium files we use.
PR kern/58468
sys/crypto/sodium: Simplify stdint.h stub.
No change to the .o or .kmod files; just the .d make dependency files
change.
PR kern/58468
sys/crypto/sodium: Tighten stdlib.h glue.
1. Make sure nothing uses malloc and free. All of the routines we
need should work in fixed-size, caller-allocated buffers and
reasonable stack space.
2. Make panic message for abort() stub clearer. There are calls to
it, but they imply internal errors inside libsodium which should
not happen unless there is an unrecoverable software bug in
libsodium.
PR kern/58468
sys/crypto/sodium: Add self-test for XChaCha20/Poly1305 AEAD.
PR kern/58468
|
| 1.2 | 02-Dec-2014 |
pooka | Remove shlib_version files and just use Makefile SHLIB_MAJOR/MINOR,
with the default provided by Makefile.rump (they're all 0.0 anyway)
|
| 1.1 | 05-Dec-2010 |
pooka | branches: 1.1.6; 1.1.20; 1.1.38;
rumpcrypto should never have been its own faction, so finally make
it a component under kern, i.e. rumpcrypto -> rumpkern_crypto.
|
| 1.1.38.1 | 06-Apr-2015 |
skrll | Sync with HEAD
|
| 1.1.20.1 | 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.1.6.2 | 05-Mar-2011 |
rmind | sync with head
|
| 1.1.6.1 | 05-Dec-2010 |
rmind | file shlib_version was added on branch rmind-uvmplock on 2011-03-05 20:56:13 +0000
|
