* Package name : cryptsetup-2fa Version : 0.1 Upstream Contact: YunQiang Su <syq@debian.org> * URL : https://github.com/wzssyqa/cryptsetup-2fa/ * License : BSD-2 Programming Lang: SHELL Description : 2FA plugin for cryptsetup 2 mthods are supported for 2 FA: - Yubikey Challenge - TPM2 Keypair PIN-less is also supported, if the PINs are present in /etc/cryptsetup/2fa.conf. Since I am not expert of security and encrypt: CODE Review is requested here, too.
What are the benefits of this compared to systemd-cryptenroll?
Marco d'Itri <md@linux.it> 于2023年12月31日周日 19:27写道： systemd-cryptenroll cannot work with cryptsetup-suspend.
It seems to be a more featureful implementation and also doesn't require storing PINs in plain text in configuration files like /etc/cryptsetup/2fa/2fa.conf as README instructs users to do here. Nor does it store plain text credentials in /var/cache. Ansgar PS: I also don't understand why cryptsetup-2fa-enroll(1) references privacyIDEA.
Ansgar <ansgar@43-1.org> 于2023年12月31日周日 20:51写道： Yes. I tried to use systemd-cryptenroll, while it cannot work with cryptsetup-suspend. I need a way to suspend or hibernate without disks decrypted. My script doesn't *require* storing PIN. You can just leave the config blank, it will prompt for PIN. This is used, if a user has multi disks/partitions, and all of them have same PIN, to ask for PIN only one time. The passphrase is stored in /var/cache, and switch_root will clean all of them, so I guess it won't leak. Thanks. Removed.
Hi, If your concern is to make these work with cryptsetup-initramfs, there are #1023700 and #1031254 open against src:cryptsetup. The plan is to have that in trixie. Did you check if the solutions proposed there cover your use case? Otherwise, IMHO a wishlist bug against src:cryptsetup would be better than using a separate source package. I'm not really thrilled to see /etc/cryptsetup (and /lib/cryptsetup) used outside src:cryptsetup. These directories are not documented as drop-in.
Guilhem Moulin <guilhem@debian.org> 于2023年12月31日周日 21:23写道： I tried some methods before I write this script, and I also tried dracut. Yes, dracut works well with cryptsetup-initramfs. The problem for me is that none of these ways, can work with suspend. I mean that when the PC resumes from suspend, I wish that the disk is encrypted instead of decrypted. In fact, hibernate is an option for me, but currently, Linux kernel cannot support hibernate if crypt disk is used. If this scripts can be accepted into src:cryptset, I will be very glad to help it happen. Yes, I noticed cryptsetup-suspend does in src:cryptsetup, while src:yubikey-luks is a seperate source package. I tried src:yubikey-luks, while it leaks some features, and upstream seems not active now. https://github.com/cornelinux/yubikey-luks/pull/92
Seems like this should be a wishlist bug against cryptsetup-suspend not an ITP. I don't foresee any reason why this wouldn't work once #1023700 and #1031254 are fixed. The partition might be backed by plain-test drives or similar, so it can't be used to write sensitive data.
Guilhem Moulin <guilhem@debian.org> 于2023年12月31日周日 21:50写道： systemd-cryptsetup doesn't have suspend support. cryptsetup-suspend will fails. I tried with "systemd-cryptsetup detach", while it is not allowed for a using system. This script will only in initramfs, so /var/cache will always be an ramfs.
Hence a wishlish bug? :-) FWIW I'm part of the cryptsetup packaging team, which is upstream for cryptsetup-suspend. cryptsetup-suspend supports all unlock methods supported by cryptsetup-initramfs, and I believe this will remain the case once FIDO2 and TPM support is added to cryptsetup-initramfs. It can and does, but the initramfs needs some logic to unlock the disks holding the resume device(s). It already works in interactive mode or when unlocking via key files, smartcards, kernel keyring, etc. For FIDO2 resp. TPM, it'll work once #1023700 resp. #1031254 is fixed. You might intend to use it that way, but AFAICT there is nothing preventing its use outside an initramfs.