Announcement

Collapse
No announcement yet.

Arch Linux Installer Preparing FIDO2 Support For Handling Disk Encryption

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by polarathene View Post

    Even if there isn't, as long as the key/input required to unlock is of high entropy (which would be expected with a security device), it should be fine.

    IIRC 128 bits of entropy would require enough energy to iterate through all possible values (roughly 340,000,000,000,000,000,000,000,000,000,000,000,00 0) to boil all of the oceans in the world (which is still the case for typical success rate at 50% of the keyspace, thus 2^127). My math might be off, but 2^127 would still take over 5 trillion years at a billion billion (1e9^2) attempts per second. Ultimately though, it's going to be cheaper/faster to just gain access via other means at that point.

    Which is sort of the point of using hardware for securing access, rather than remembering our own passwords which tend to be more prone to lower entropy. I don't know much about FIDO2 specifically, but that's only relevant for unlocking/deriving the actual key used to encrypt/decrypt right? Which should be a random 128-bit (or greater) key.

    So whatever has lower entropy to attack (the actual/master key, or the key(s) protecting the actual/master key - I'm not an expert, so apologies for lack of correct terminology :P ), will be where the security strength is.

    If the concern was with user password protection enumeration with paired FIDO2-device already in possession, then key stretching (or key derivation function, such as PBKDF, scrypt, argon2id) is presumably in use to deter brute-force attempts on that. You've probably configured that in the feature implementation, or it's handled with some sane default involved. That will slow down brute-force attempts considerably, and is part of how traditional password-based auth for user accounts is managed. This step increases effectively pads/increases the entropy of an input (but not beyond the output entropy), which is quite useful for non-machine generated passwords.
    I hoped that something like this was in play, thank you for taking the time to explain it in pretty simple terms. Made it pretty easy to digest ^^

    Comment


    • #32
      As far as I know FIDO2 requires LUKS2 to be used for disk encryption and last time I checked LUKS2 is not fully supported yet by grub. Are there any recent news about it?

      Comment


      • #33
        Originally posted by dremon_nl View Post
        As far as I know FIDO2 requires LUKS2 to be used for disk encryption and last time I checked LUKS2 is not fully supported yet by grub. Are there any recent news about it?
        I mean, we support that in archinstall.
        LUKS2 + GRUB is working pretty well.

        Comment

        Working...
        X