Thanks for the info! Do you think there would be major push back against implementing a generic challeng response mechanism? The idea is to popen out to programs/scripts which then do the vendor specific implementation, but over stdin/stdout use a common protocol. That way cryptsetup does not need to know anything about implementation, including whether it is vendor specific. Then it is up to people other than cryptsetup to manage this, including adding new scripts/programs to do this. I'm keen to get your thoughts on this. Thanks, Dan Farrell On Wed, 8 Apr 2020 at 10:19, JT Morée <moreejt@xxxxxxxxx> wrote: > > I have been in discussions on this list recently working toward tighter integration of LUKS with smart cards. You can view my progress here: > > https://sites.google.com/site/jtmoree/knowledge-base/cryptsetup-luks-and-smart-cards > > I don't pretend to speak for the project but i have concluded > * dmcrypt would rather not implement vendor specific solutions ( I agree) > * the project has been working toward smart card features > * 2.4.0-RC0 will be a milestone in this regard > > Feel free to provide feedback if I have anything incorrect on my writeup. > > JT > > p.s. I think yahoo mail messes up the quotes of previous replies. Leaving the below for context > > On Wednesday, April 8, 2020, 3:09:56 AM MST, Nikolay Kichukov <hijacker@xxxxxxxxx> wrote: > > I am also interested, HMAC/SHA challenge-response for OnlyKey would be > great addition to cryptsetup. > > I do not think this should be product specific implementation, but > general for all hardware tokens that support it: OnlyKey, Yubikey, > Nitrokey, etc. > > ... > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > https://www.saout.de/mailman/listinfo/dm-crypt _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
