I'd like my device encryption password to be very long and complicated but a short screen lock password for convenience. Is this possible?
On old devices with Full Disc Encryption (FDE) this was possible for rooted devices. But on modern devices that use File Based Encryption (FBE) this is no longer possible nor necessary:
In the old times of FDE the use password was directly used to derive the cryptographic key that protected the encrypted user data partition.
On modern devices user authentication and encryption root-key management is executed in the Trusted Execution Engine (TEE) of your CPU. There the Android Gatekeeper code is running that checks the login/screen lock password and is e.g. able to apply anti-brute force measures like enforcing increasing wait times if multiple false passwords were entered. As long as the TEE is secure this makes the device more secure than a long password.
The detailed process of the key-derivation for file-based encryption, according to the AOSP documentations is:
File-based encryption keys, which are 512-bit keys, are stored encrypted by another key (a 256-bit AES-GCM key) held in the TEE. To use this TEE key, three requirements must be met:
- The auth token
- The stretched credential
- The “secdiscardable hash” The auth token is a cryptographically authenticated token generated by Gatekeeper when a user successfully logs in. The TEE will refuse to use the key unless the correct auth token is supplied. If the user has no credential, then no auth token is used nor needed.
The stretched credential is the user credential after salting and stretching with the scrypt algorithm. The credential is actually hashed once in the lock settings service before being passed to vold for passing to scrypt. This is cryptographically bound to the key in the TEE with all the guarantees that apply to KM_TAG_APPLICATION_ID. If the user has no credential, then no stretched credential is used nor needed.
The secdiscardable hash is a 512-bit hash of a random 16 KB file stored alongside other information used to reconstruct the key, such as the seed. This file is securely deleted when the key is deleted, or it is encrypted in a new way; this added protection ensures an attacker must recover every bit of this securely deleted file to recover the key. This is cryptographically bound to the key in the TEE with all the guarantees that apply to KM_TAG_APPLICATION_ID.