While that Android feature is called "Device encryption", it doesn't encrypt everything.
For instance, on a Galaxy SIII, enabling "Device encryption" only encrypts the USERDATA partition.
As the encrypted partitions have to be opened, and that the user need to type a password, code has to run to prompt user for the password and open the encrypted partition. That code cannot come from within the encrypted partition.
This is why "full disk encryption" or "device encryption" schemes often have parts that are unencrypted.
By default on Android, the encryption password is the same as the lockscreen password. As users tend to use a simple PIN, password or pattern for the lockscreen, the encryption can be easily circumvented with a brute-force attack.
Replicant allows to set an encryption password that is not tied to the lockscreen:If a separate encryption password is in place and a PIN or password is set for the lockscreen, another security measure is active: After five unsuccessful attempts to unlock the screen, the device is rebooted and the attacker is faced with the much stronger encryption passphrase. This makes brute-force attacks on the lockscreen much harder.
As Android uses cryptsetup, most or all the Cryptsetup FAQ also apply to Replicant as well.
That FAQ has a Security Aspects section where it details the cost of breaking a passphrase in a table like this one:
Passphrase entropy | Cost to break |
---|---|
50 bit | EUR/USD 600k |
55 bit | EUR/USD 20M |
70 bit | EUR/USD 600B |
75 bit | EUR/USD 20T |
Be sure to look at the FAQ for potentially more up to date figures and the details that goes with them.
As for calculating the passphrase entropy, tools like keepassxc (which is available in Parabola) have a password generator that is able to calculate the entropy. At the time of writing, in keepassxc, this can be found in Tools->Password generator
.
Replicant
as a password is a very bad idea for several reasons: