Onlykey and dm-crypt

I’m trying to get Onlykey to with with full-disk encryption, using dm-crypt and LUKS. Of course, it is trivial to simply have Onlykey enter a password, but I would very much like to use some of the higher-entropy options available to Yubikey users.

In crypttab(5), they have an example using an RSA-key stored on a yubikey accessed through PKCS#11. I was able to get to the point where I have a key saved on my unlocked onlykey, but when I run p11tool --list, my Onlykey is nowhere to be found.

Is there some other method I can use, or is there a way to get the method described in the man pages working with Onlykey?

OnlyKey is not a smart card, PKCS#11 is for smart cards so no this would not work.

Well, neither is a yubikey, but it emulates the functionality.

But ok, that’s not currently possible, got it. Is there any other method you know of which might work? The Arch wiki lists three alternatives for yubikeys, are there any of those you think look possible?

We tried to get this one to add OnlyKey support -

It looks like they just closed the issue. OnlyKey does support challenge-response using the yubikey-personalization library but it requires the product vendor to add support as by default the library only opens devices with Yubico USB VID/PID.

The github issue mentions this -
Onlykey does support the hmac-extension but we have not tested this software.

Thank you. I will try it out.

question is how high enntropy does this all go.

I mean apparently the HMAC runs sha1, and I assumed it isnt changed all the time, so it’s basically just a static 160 bit password in the end. no idea whether luks/dm-crypto has a limit on the password length, but with just 64 characters of a hexadecimal style set like yubico’s modhex (because it is fairly compatible among keyboard layouts, so that wouldnt create any problems) you have 256 bit of entropy which is FAR higher than some SHA1 stuff.

@My1 I am not sure what the question is here. A 58 character random password is quite a bit stronger than a 256 bit key in terms of brute force attack. An hmac sha1 challenge response changes based on the input so that is up to the application requesting the response, which yes they typically change the challenge each time.

On a random authentication thing you can use dynamic tokens because the data valve works however when used with encryption you can’t use a data valve mechanism, because the data is already there, usually things like disk encryption or offline password containers just abuse the hmac mechanism and get a static result.