I thought it was maybe a yubikey extension that made it possible to manage the resident keys, but relieved to know that it is in CTAP2.1. I wonder when we’ll see keys with 1k or 10k slots so that we don’t have to worry about this? But for know I’ll probably store important credentials on the physical key and less important on some software solution (google/apple/microsoft/bitwarden/1password/…)
What happened to the U2F feature where the scope (domain name) is appended to the secret key as extra material, giving infinite keys for no added storage?
That’s what the non-resident keys are using. You HMAC the scope to get the credential id you then give to the yubikey.
WebAuthn libraries can decide whether they want to use that, or resident keys, and now it seems like more and more resident keys are what’s preferred (even though it has massive drawbacks)
Generally, resident key slots are at a premium on a security key. Nitrokeys for example only support 8 resident keys. Yubikeys generally support between 20 and 32.
Why such an absurdly small limit? Keys are tiny! Even a 4096-bit RSA keys is ½ a kilobyte. 32 keys would be like 16KB. I can’t think of any other storage medium I’ve owned with so little capacity.
Is this just a case of security-key designers saying “who could possibly need more than ___ private keys?”
This was my thought as well. I went looking into the flash allocation, but couldn’t find it. But e.g. solokeys seems to have a chip with 256kB flash. So the question is how much is needed for code etc. And what can be used for keys. Sounds like more than 25 or 50 should easily be possible.
I thought it was maybe a yubikey extension that made it possible to manage the resident keys, but relieved to know that it is in CTAP2.1. I wonder when we’ll see keys with 1k or 10k slots so that we don’t have to worry about this? But for know I’ll probably store important credentials on the physical key and less important on some software solution (google/apple/microsoft/bitwarden/1password/…)
What happened to the U2F feature where the scope (domain name) is appended to the secret key as extra material, giving infinite keys for no added storage?
That’s what the non-resident keys are using. You HMAC the scope to get the credential id you then give to the yubikey.
WebAuthn libraries can decide whether they want to use that, or resident keys, and now it seems like more and more resident keys are what’s preferred (even though it has massive drawbacks)
Why such an absurdly small limit? Keys are tiny! Even a 4096-bit RSA keys is ½ a kilobyte. 32 keys would be like 16KB. I can’t think of any other storage medium I’ve owned with so little capacity.
Is this just a case of security-key designers saying “who could possibly need more than ___ private keys?”
The microchips with secure storage are not (logically) large.
This was my thought as well. I went looking into the flash allocation, but couldn’t find it. But e.g. solokeys seems to have a chip with 256kB flash. So the question is how much is needed for code etc. And what can be used for keys. Sounds like more than 25 or 50 should easily be possible.
Why not keep the data encryption key on the secure storage and use it to encrypt private keys on normal multi-GB storage chips?
complexity?