> Over-the-air updates do not change the encryption scheme of a device, because it requires a complete re-encryption of the userdata partition. JFC that one wo

> Over-the-air updates do not change the encryption scheme of a device, because it requires a complete re-encryption of the userdata partition. JFC that one would have been obvious to think ahead of: what to do if the key derivation becomes compromised? In an ideal system, each file's metadata should not just specify which master key is to be used, but also which version/KDF scheme was used - that way, newly created files could benefit from stronger encryption schemes and existing files be transparently re-encrypted in the background (or in the foreground, which may be easier to implement technically, but people won't want to wait hours for their upgrade to finish). Passwords have been doing this for decades, every password in /etc/shadow carries a prefix indicating the hash scheme and settings (salt, rounds), and if the system default changes (like Arch did last year [1]), users get their password updated at login. In user space, for example PHP has a function to check if a re-hash is needed [2]. [1] https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ https://archlinux.org/news/changes-to-default-password-hashi... [2] https://www.php.net/manual/en/function.password-needs-rehash.php https://www.php.net/manual/en/function.password-needs-rehash...