@rinigus, as much I appreciate your pondering, I think you are looking too far ahead, because there no appropriate infrastructure exists for your ideas (at all).
- “I don’t know how flexible current solution is”
It is just a GUI dialogue callingcryptsetup luksOpenwith the entered passphrase (currently: PIN / numerical only). - “Using a TEE, because there is no other user-accessible secure element (like a TPM).”
But that would have to be a Free Software TEE, otherwise most people will not trust it. Do you trust Qualcomms binary BLOB TEE?
See also: [idea] SFOS Support for Secure Elements (SE) (or Trusted Execution Environment (TEE)) - together.jolla.com - “Using USB tokens, NFC tokens etc.”
This is too inconvenient for the average user (i.e., almost no one will use that), and the basic infrastructure for using such crypto tokens is missing rsp. NFC does not work at all AFAIK.
IMO, first and foremost we should push Jolla to enable the use of alphanumeric LUKS passphrases, which has been suggested long ago and is a rather minor change. This would enable users who want to input “high entropy passphrases” to do that easily.
I also do not understand, why community ports of SFOS are not able to follow this simple scheme (you sound like that is not the case).
BTW, “For opening LUKS container: a. get user password from user’s input b. generate user key from password and salt” is exactly what Cryptsetup-LUKS does (with a volume specific salt), then using this “user key” for en- and decryption of the specific LUKS-volume. You just want to add another indirection with an additional key from a different source.
P.S.: As I once pointed out, I am convinced, that the enhancements you are aiming at are absolute overkill with the current state of security in SailfishOS and its infrastructure: There are so many outdated components in SailfishOS with known security flaws (e.g., the SFOS browser, Gnupg and many more). Plus it would be easy to get a malicious “really cool app” (e.g., “The Ultimate File Browser”) into the Jolla Store, because there are no checks in place, which would prevent that (Jolla’s Store guidelines prevent many good apps from getting in, but not that); there already is a Flashlight app which calls home on every use. And at Openrepos “anything goes” anyway.
As discussed, why should an attacker invest time into a scheme, which needs physical access to every device hacked and is time consuming, if one could easily employ remotely exploitable scheme affecting many devices (no matter which cryptography scheme is used)?
Thus Jolla better invests their time to alleviate the real, pressing security issues SFOS and its infrastructure have, instead of designing, implementing and deploying an overly complex crypto scheme.
P.P.S.: I am surely becoming bashed again for this by the tinfoil hats who want a “100% secure crypto scheme”, because they do not understand the gaping security holes elsewhere, plus that no crypto scheme is able to counter them.