That doesn’t tell me which version of argon2. libargon-tools in 4.1 same as in 3.4?
OK, I misunderstood. It is from Chum: GitHub - sailfishos-chum/libargon2 . So same version for all supported versions.
Thanks! I’ll have a look!
EDIT: in the original, it looks like the default is to build all the variants (Argon2i, Argon2d, and Argon2id are parametrized by:…)
use Argon2d instead of Argon2i callargon2d_hash_rawinstead ofargon2i_hash_raw`
Are these available?
1 Like
It is calling with -id option that should combine d and i after each other. As far as I understood, this is a recommended way of key derivation by argon2
Cool. I’m going to have to try this, but it probably makes more sense to get version 4.1 running on my second volla phone, or?. I also have an fp2 with 3.4 that might do.
Sadly, I still haven’t been able to flash 4.1 on the volla.
I am writing now startup wizard and settings app. It has started with support library which would be responsible for the actions. It would make sense to wait with trials until those are sorted. Then testing by myself, testing by you, and I hope someone can take time and review the code. After that, roll out 
So, in this respect - you have few days to sort out Volla situation
Cool. I’ll get the next test device going.
Got first version of setup wizard written and managed to hit …
https://forum.sailfishos.org/t/allow-to-decouple-luks-password-from-used-security-code
Edit: found a workaround
1 Like
We have just reached the state where all the initially planned functionality is ready. All packages involved in providing encryption solution as discussed above are tagged with their first release tags. I am planning to roll out this solution on Sony Tama port and I hope other devices will follow.
12 Likes
@rinigus If the subsystem is based on LUKS2 (@jolla) it would inheriting argon2i as PBKDF. A far better brute force protection …
On the released version (4.2 SFOS, Tama port and I presume some others as well), LUKS2 is used with argon2 based keygen. However, this is insufficient. Don’t forget that our phone CPUs are way weaker than your PC CPU. So, number of iterations done by argon2 is smaller than would be needed to protect against attack on PC/server. Hence, in the community encryption, hardware backed key is used as a part of the key generation procedure. This essentially limits the attack to be performed on phone itself - it is just too time consuming to start guessing the key otherwise. As hardware key access can be limited, it makes brute force attack rather unattractive option - something we, as users, would prefer to have.
is it possible now that i can use this on my Sony xperia 10 ? and how can i set it up ? can someone help me please ?
No, not yet. Official ports have LUKS password the same as your PIN. So, you cannot really do much with such setup. When asked on the community meeting regarding their LUKS alphanumeric passwords, Jolla developers replied that they don’t plan to use open-sourced solution, as it was developed here, and, instead, cruft something themself.
Now, I expect that they will have to drop this “brilliant” idea of having coupled LUKS password and PIN in that case. Which should allow to replace Jolla’s solution with this one if someone will want it. Hence, “not yet”. Let’s see whether such decoupling will happen with 4.4.
1 Like
Do we know what they did?
I’m still confused why I have two passcodes and I don’t know how to change either. I’d certainly like SF to stop asking for one. I’d guess the other linked to the encryption key is virtually impossible to change.
Cause we are doing it wrong. And the whole situation messes with the UX.
As a user, just a few considerations:
- relying on android doesnt differentiate sfos
if we use (for example) TEE with blobs; or hwcomposer; then whats the point of having a separate OS? - is TEE an open spec? See open-tee for example
- whats the counterpart of TEE on sony devices?
- if the pin code is too short; how about limiting retries to a smaller ammount before back-off time (i.e. 3/4 times)?
I am sure it has been all discussed above. In short, the solution using underlying TEE or similar ensures that it is impossible to brute-force decrypt the volume after you DD-copy it from the device. Such 3-4 entry limitation on software (SFOS) level will not work for such case. In principle, you can use any HW-assisted key generation for encryption, I used the one that is readily available. That’s, obviously, for the version described here - “community” encryption.
For “official” encryption, solution is based on longer PINs/PWDs. I presume it is still connecting PIN/PWD check with LVM decryption - so the same PIN/PWD has to be used for the both operations.
Whether TEE is open SPEC - no idea, haven’t checked it.
yes. I have 2 headers of LUKS volume and exchanging them with dd on-the-fly (and then trying to unlock the phone) clearly shows that.