The current design requires the fido2 token to be present for every operation, which is a big inconvenience. This is because the symmetric key (the HMAC challenge response) is directly used as the encryption key.
One way to solve this would be to use the symmetric key as a seed to generate an asymmetric key pair, and use the public key as the recipient. I chose to keep it simple and not do it because this exceeded my knowledge and the amount of complexity I was comfortable dealing with. However, if there's a well defined and secure way of deriving keypairs from 32 random bytes, the spec could in the future be changed to use that instead (while still keeping backwards compatibility to the current format).
olastor
commented
4 months ago
The current design requires the fido2 token to be present for every operation, which is a big inconvenience. This is because the symmetric key (the HMAC challenge response) is directly used as the encryption key.
One way to solve this would be to use the symmetric key as a seed to generate an asymmetric key pair, and use the public key as the recipient. I chose to keep it simple and not do it because this exceeded my knowledge and the amount of complexity I was comfortable dealing with. However, if there's a well defined and secure way of deriving keypairs from 32 random bytes, the spec could in the future be changed to use that instead (while still keeping backwards compatibility to the current format).