I’ve learned the encryption of SfOS is very weak since the encryption key is currently generated from the pin code and therefore the pin is the weak part.
Is there a limitation to the pin lenght, and if not, what would be the recommended pin lenght to achieve sufficient encryption (or is this not possible at all)?
Thanks.
2 Likes
Great question! I’ve been wondering this pin based system myself as well. As far as I’ve understood, if the count of tries can’t be limited, it is quite easy to decrypt the pin based encryption mechanism. I think that there are sophisticated software that can loop through the pin codes easily. If you have, let’s say 6 digit pin code, it will theoretically take 10^6 tries to find it out. However, with a sophisticated software the possible pin codes can be reduced if we consider that repetitive sequences like 111111 are not valid.
Personally, I would be very skeptic regarding sufficient pin code length when it comes to the encryption key. Of course the greater length the more tries it requires, but I’m not sure whether it really helps. Maybe someone who knows more can shed some light onto this 
if you consider a 10-character alphanumeric password (lowercase only) save, you got 36**10 combinations. To archive the same with 10 digits you take log base 10 of that:
log_10(36**10)=15.5
Thus a randomly generated 16 digit key is as secure as your 10 character fully random password.
Edit: the emphasize is on fully random here
3 Likes
A bit offtopic, but SATA drives that use BIOS level password protection have it “split in half”: the password the user enters protects the master encryption key, and the master encryption key protects the data. This way user can change the password without requiring to re-encrypt the whole disk again.
I don’t know if SFOS is implemented in the same way, but it would be nice… The PIN code would open the (procedurally generated, very long) master key, which then protects the data. In this scenario, the PIN is still the weak point, but at least the encryption would be strong… At this point, now that the encryption already exists and is deployed, all this discussion can end up being in vain. Oh well!
Another option would be using a separate password/passphrase for the encryption and ask it once per boot/reboot, but entering a long password using any OSD keyboard is…pain.
2 Likes
SailfishOS uses LUKS (1) for encryption. You can actually see this from the settings.
LUKS has a header written on the disk where the actual encryption key and parameters are stored.
The volume encryption key for the volume itsself is stored there encrypted by the password you provide. One nice thing about LUKS is, that the header has multiple “Keyslots”, thus you can use multiple passwords for the same encrypted volume.
Changing the Password is simple. Decrypt the volume encryption key by providing the old password. Encrypt it wiht the new password and replace the key in the keyslot.
Source: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf
1 Like