Home | History | Annotate | Download | only in libcrypto
History log of /src/sys/rump/kern/lib/libcrypto/Makefile
RevisionDateAuthorComments
 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 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...

RSS XML Feed