Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/tests/dev/cgd/Makefile

29 lines
525 B
Makefile
Raw Permalink Normal View History

cgdconfig(8): Add support for shared keys. New clause `shared <id> algorithm <alg> subkey <info>' in a keygen block enables `cgdconfig -C' to reuse a key between different params files, so you can, e.g., use a single password for multiple disks. This is better than simply caching the password itself because: - Hashing the password is expensive, so it should only be done once. Suppose your budget is time t before you get bored, and you calibrate password hash parameters to unlock n disks before you get bored waiting for `cgdconfig -C'. . With n password hashings the adversary's cost goes up only by a factor of t/n. . With one password hashing and n subkeys the adversary's cost goes up by a factor of n. And if you ever add a disk, rehashing it will make `cgdconfig -C' go over budget, whereas another subkey adds negligible cost to you. - Subkeys work for other types of keygen blocks, like shell_cmd, which could be used to get a key from a hardware token that needs a button press. The <info> parameter must be different for each params file; everything else in the keygen block must be the same. With this clause, the keygen block determines a shared key used only to derive keys; the actual key used by cgdconfig is derived from the shared key by the specified algorithm. The only supported algorithm is hkdf-hmac-sha256, which uses HKDF-Expand of RFC 5869 instantiated with SHA-256. Example: algorithm aes-cbc; iv-method encblkno1; keylength 128; verify_method none; keygen pkcs5_pbkdf2/sha1 { iterations 39361; salt AAAAgMoHiYonye6KogdYJAobCHE=; shared "pw" algorithm hkdf-hmac-sha256 subkey AAAAgFlw0BMQ5gY+haYkZ6JC+yY=; }; The key used for this disk will be derived by HKDF-HMAC-SHA256_k(WXDQExDmBj6FpiRnokL7Jg==), where k is the outcome of PBKDF2-SHA1 with the given parameters. Note that <info> encodes a four-byte prefix giving the big-endian length in bits of the info argument to HKDF, just like all other bit strings in cgdconfig parameters files. If you have multiple disks configured using the same keygen block except for the info parameter, `cgdconfig -C' will only prompt once for your passphrase, generate a shared key k with PBKDF2 as usual, and then reuse it for each of the disks.
2022-08-12 13:49:17 +03:00
# $NetBSD: Makefile,v 1.13 2022/08/12 10:49:17 riastradh Exp $
Add rudimentary cgd tests. The tests use cgd to transform a plaintext into into an encrypted image and back into plaintext by doing rump I/O on /dev/cgd. There is one test to check that giving the same password for both encryption and decryption produces the same plaintext and another to check that giving a different passwords does not produce the same plaintext. This could be fairly easily extended to test all feature of cgd (hint hint). For example, now cgd.conf is included in cvs, but the only reason for that is that without further hacking cgdconfig uses /dev/random quality random to generate the salt for a pkcsetcetc_kdf2 cgconfig -g, and making an automated test block on the entropy pool is just not good form. Details are everything.
2010-11-12 01:38:46 +03:00
#
.include <bsd.own.mk>
TESTSDIR= ${TESTSBASE}/dev/cgd
Retire the old C helper in h_img2cgd since we can now write everything with a shellscript in terms of rump.cgdconfig and dd.
2010-12-14 20:48:31 +03:00
FILES= paramsfile
FILESDIR= ${TESTSDIR}
Add rudimentary cgd tests. The tests use cgd to transform a plaintext into into an encrypted image and back into plaintext by doing rump I/O on /dev/cgd. There is one test to check that giving the same password for both encryption and decryption produces the same plaintext and another to check that giving a different passwords does not produce the same plaintext. This could be fairly easily extended to test all feature of cgd (hint hint). For example, now cgd.conf is included in cvs, but the only reason for that is that without further hacking cgdconfig uses /dev/random quality random to generate the salt for a pkcsetcetc_kdf2 cgconfig -g, and making an automated test block on the entropy pool is just not good form. Details are everything.
2010-11-12 01:38:46 +03:00
cgdconfig(8): New -t operation just prints the derived key in base64. For testing purposes.
2022-08-12 13:48:27 +03:00
TESTS_SH+= t_cgd
TESTS_SH+= t_cgdconfig
Don't build t_cgd_aes if ${MKCRYPTO} == "no".
2016-11-07 00:29:54 +03:00
cgdconfig(8): Add support for shared keys. New clause `shared <id> algorithm <alg> subkey <info>' in a keygen block enables `cgdconfig -C' to reuse a key between different params files, so you can, e.g., use a single password for multiple disks. This is better than simply caching the password itself because: - Hashing the password is expensive, so it should only be done once. Suppose your budget is time t before you get bored, and you calibrate password hash parameters to unlock n disks before you get bored waiting for `cgdconfig -C'. . With n password hashings the adversary's cost goes up only by a factor of t/n. . With one password hashing and n subkeys the adversary's cost goes up by a factor of n. And if you ever add a disk, rehashing it will make `cgdconfig -C' go over budget, whereas another subkey adds negligible cost to you. - Subkeys work for other types of keygen blocks, like shell_cmd, which could be used to get a key from a hardware token that needs a button press. The <info> parameter must be different for each params file; everything else in the keygen block must be the same. With this clause, the keygen block determines a shared key used only to derive keys; the actual key used by cgdconfig is derived from the shared key by the specified algorithm. The only supported algorithm is hkdf-hmac-sha256, which uses HKDF-Expand of RFC 5869 instantiated with SHA-256. Example: algorithm aes-cbc; iv-method encblkno1; keylength 128; verify_method none; keygen pkcs5_pbkdf2/sha1 { iterations 39361; salt AAAAgMoHiYonye6KogdYJAobCHE=; shared "pw" algorithm hkdf-hmac-sha256 subkey AAAAgFlw0BMQ5gY+haYkZ6JC+yY=; }; The key used for this disk will be derived by HKDF-HMAC-SHA256_k(WXDQExDmBj6FpiRnokL7Jg==), where k is the outcome of PBKDF2-SHA1 with the given parameters. Note that <info> encodes a four-byte prefix giving the big-endian length in bits of the info argument to HKDF, just like all other bit strings in cgdconfig parameters files. If you have multiple disks configured using the same keygen block except for the info parameter, `cgdconfig -C' will only prompt once for your passphrase, generate a shared key k with PBKDF2 as usual, and then reuse it for each of the disks.
2022-08-12 13:49:17 +03:00
SCRIPTSDIR= ${TESTSDIR}
SCRIPTS+= h_countkey.sh
Remove MKCRYPTO option. Originally, MKCRYPTO was introduced because the United States classified cryptography as a munition and restricted its export. The export controls were substantially relaxed fifteen years ago, and are essentially irrelevant for software with published source code. In the intervening time, nobody bothered to remove the option after its motivation -- the US export restriction -- was eliminated. I'm not aware of any other operating system that has a similar option; I expect it is mainly out of apathy for churn that we still have it. Today, cryptography is an essential part of modern computing -- you can't use the internet responsibly without cryptography. The position of the TNF board of directors is that TNF makes no representation that MKCRYPTO=no satisfies any country's cryptography regulations. My personal position is that the availability of cryptography is a basic human right; that any local laws restricting it to a privileged few are fundamentally immoral; and that it is wrong for developers to spend effort crippling cryptography to work around such laws. As proposed on tech-crypto, tech-security, and tech-userlevel to no objections: https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.html https://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.html https://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of *bad* crypto that was conditional on it, e.g. DES in telnet... That should probably be removed too, but on the grounds that it is bad, not on the grounds that it is (nominally) crypto.
2017-05-21 18:28:36 +03:00
.if ${MKRUMP} != "no"
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.
2020-06-30 02:44:01 +03:00
TESTS_C+= t_cgd_3des
TESTS_C+= t_cgd_adiantum
TESTS_C+= t_cgd_aes
TESTS_C+= t_cgd_blowfish
Add tests for not-yet-committed cgd algorithm AES-XTS. The tests are marked as expected failures.
2016-11-06 13:54:42 +03:00
Don't build t_cgd_aes if ${MKCRYPTO} == "no".
2016-11-07 00:29:54 +03:00
WARNS= 4
Add tests for not-yet-committed cgd algorithm AES-XTS. The tests are marked as expected failures.
2016-11-06 13:54:42 +03:00
CPPFLAGS+= -D_KERNTYPES
Centralize the base rump libraries into a variable used by all the other Makefiles so that we can make changes to it centrally as needed and have less mess. Fixes the sun2 build that needs rumpvfs after librump after the latest changes.
2020-03-01 21:08:12 +03:00
LDADD+= -lrumpdev -lrumpdev_disk -lrumpdev_cgd -lrumpkern_crypto ${LIBRUMPBASE}
LDADD+= -lutil
Don't build t_cgd_aes if ${MKCRYPTO} == "no".
2016-11-07 00:29:54 +03:00
.endif
Add rudimentary cgd tests. The tests use cgd to transform a plaintext into into an encrypted image and back into plaintext by doing rump I/O on /dev/cgd. There is one test to check that giving the same password for both encryption and decryption produces the same plaintext and another to check that giving a different passwords does not produce the same plaintext. This could be fairly easily extended to test all feature of cgd (hint hint). For example, now cgd.conf is included in cvs, but the only reason for that is that without further hacking cgdconfig uses /dev/random quality random to generate the salt for a pkcsetcetc_kdf2 cgconfig -g, and making an automated test block on the entropy pool is just not good form. Details are everything.
2010-11-12 01:38:46 +03:00
.include <bsd.test.mk>