[bcc tech-crypto@ tech-security@, followups to tech-userlevel@] I would like to import the fidocrypt(1) utility into base:
https://github.com/riastradh/fidocrypt/ fidocrypt(1) is a small program that lets you `store' a secret on U2F/FIDO keys, with a little state on disk that enables you to register or unregister keys without changing the secret, so that any one of the registered keys can be used to open the secret. Example: $ export FIDOCRYPT_RPID=fidocrypt.example.com $ fidocrypt enroll -N Falken -u falken -n yubi5nano example.crypt tap key to enroll; waiting... tap key again to verify; waiting... $ fidocrypt enroll -N Falken -u falken -n redsolokey example.crypt tap a key that's already enrolled; waiting... tap key to enroll; waiting... tap key again to verify; waiting... $ fidocrypt list example.crypt 2 redsolokey 1 yubi5nano $ fidocrypt get -F base64 example.crypt tap key; waiting... yTpyXp1Hk3F48Wx3Mp7B2gNOChPyPW0VOH3C7l5AM9A= The secret might be, for instance, a cgd(4) disk encryption key -- fidocrypt(1) can be used in a shell_cmd keygen block of a cgdconfig(8) parameters file. For this to work, fidocrypt(1) has to be available early at boot time before any file systems on cgd(4) volumes have been mounted -- this is why I suggest putting it in base and not just, say, in pkgsrc. The fidocrypt(1) program and associated libfidocrypt.so library are reasonably small, a couple hundred kilobytes on amd64, although having /bin/fidocrypt would require us to move libfido2.so and libsqlite3.so into /lib, adding a megabyte or two in total to / (not counting /rescue where it might also be worthwhile to add fidocrypt): text data bss dec hex filename 52160 2042 1864 56066 db02 fidocrypt 69332 1544 0 70876 114dc libfidocrypt.so 144480 2048 32 146560 23c80 libfido2.so 1136213 22504 1368 1160085 11b395 libsqlite3.so (Of course, sqlite3 in /lib might be useful for other purposes too!) Thoughts? (The `-N Falken -u falken' names, and the FIDOCRYPT_RPID relying party id, are required by the FIDO protocol, but have no significance to fidocrypt(1) itself -- other than that the relying party id can't be changed without creating a new fidocrypt file to encapsulate the same secret. The `-n yubi5nano' just gives a nickname to each registered key in case you want to revoke it later.)
