FSCRYPT In Linux 6.7 More Adaptable For Inline Encryption Hardware

[cj.wijtmans]

its the hardware RAID vs software RAID all over again. We cant trust hardware for encryption or security. Of course microsoft and intel and perhaps AMD want to convince you otherwise that their security platforms provide security (FROM you). Linux is more secure than windows but that is a meaningless statement. Linux is just as insecure as windows is. Chromium based browser store thesecurity key to your passwords in plaintext in the user home folder. There is no app to app sandboxing at all.So we do have user-to-user security... but whats the point when the user is very vulnerable with app-to-app security? Anyway i am not going to trust TPM whatsoever. If we are going to take security seriously we need drastic changes in app-to-app sanboxing(and encryption) on top of user-to-user sanboxing(and encryption) without locking out the user out of their app files and allowing the drive to go out of the computer and into another one while still being secure and accessible. It is not an easy task. Anddroid doesnt look too bad designed now(if it wasnt for the google spyware). In the last few years software has had to fortify itself very hard from the CPU "leaks"(backdoors for whatever big govt).

[linuxgeex]

From what I understand, this patch supports aligning the block writes to the device block size when OPAL is being used on SSDs. ie it prevents write fragmentation, or write amplification, within the block device, while the data is passed *unencrypted* via the device interface.

If you trust that the bus won't be snooped, and you trust that the encryption performed by the device is secure, ie the keys aren't accessible when the system is power cycled / rebooted and/or the device yanked for analysis... or if you feel no need to mitigate such attacks, then this patch is for you.

However, on Linux, the overhead of doing the encryption in software is very low. Typically <2%. And crash recovery with LUKS is far more robust than with OPAL. Therefore if you care more about your data security from an accessibility perspective than you do about <2% performance loss , then I strongly recommend you stick with LUKS instead of OPAL.

[Luke]

<snip> Anddroid doesnt look too bad designed now(if it wasnt for the google spyware). In the last few years software has had to fortify itself very hard from the CPU "leaks"(backdoors for whatever big govt).

Android can be stripped of Google spyware. Most of it (though not all) is in or depends on Google Play Services. Disable device adminstrator apps (usually FindMyPhone) that depend on it, then disable it. If the vendor locks you out of this, remove it over ADB. An Android phone without Google Maps, Google Contacts, Gboard, Chrome, etc and with replacement FOSS apps installed cuts off more than 90% of the phone-home-to-google shit. Tracker Control can block the rest, and it's instructive to use Tracker Control on a phone both with and without Google Play Services and see how much SHIT you block by divorcing your phone from Google's "services" and app store.

Then there are the privacy-focussed/high security replacement phone OS's based on AOSP and fully de-googled. If you have any reason whatsoever to believe you are a personal target of a well funded enemy, you need to use one of these.

[yump]

Chromium based browser store thesecurity key to your passwords in plaintext in the user home folder.

I'm pretty sure this is incorrect. When I set up autologin for my parents' desktop, I had to also set the Gnome keyring to use an empty password. Otherwise they got prompted for it immediately on launching Chromium anyhow.

[cj.wijtmans]

I'm pretty sure this is incorrect. When I set up autologin for my parents' desktop, I had to also set the Gnome keyring to use an empty password. Otherwise they got prompted for it immediately on launching Chromium anyhow.

Perhaps chromium based browsers work differently on linux then. Because this is mostly on windows. Youtubers get tricked by fake sponsors to download a piece of software, the software just gets the plain text key to the encrypted passwords and their channel gets stolen, its that easy. If chromium uses whatever keyring i geuss its more secur but still not good enough.

[yump]

Perhaps chromium based browsers work differently on linux then. Because this is mostly on windows. Youtubers get tricked by fake sponsors to download a piece of software, the software just gets the plain text key to the encrypted passwords and their channel gets stolen, its that easy. If chromium uses whatever keyring i geuss its more secur but still not good enough.

That might "only" be stealing session cookies, rather than passwords. If the cookie jar is stored in plaintext in a world-readable location, all current logged in sessions are exposed to malware. Once you've logged in, the session cookie is as good as the password until it gets revoked. Best case, session cookies become invalid when you log out through the site's UI, and are only valid for one IP address (although that might be problematic for mobile clients). Worst case, they're valid essentially forever.

See https://www.reddit.com/r/firefox/com...ented/jaw0h6l/

On desktop OSes that don't have app-private data storage it is difficult or impossible to prevent this kind of attack.

[cj.wijtmans]

That might "only" be stealing session cookies, rather than passwords. If the cookie jar is stored in plaintext in a world-readable location, all current logged in sessions are exposed to malware. Once you've logged in, the session cookie is as good as the password until it gets revoked. Best case, session cookies become invalid when you log out through the site's UI, and are only valid for one IP address (although that might be problematic for mobile clients). Worst case, they're valid essentially forever.

See https://www.reddit.com/r/firefox/com...ented/jaw0h6l/

On desktop OSes that don't have app-private data storage it is difficult or impossible to prevent this kind of attack.

Nope, not just session data(which is most likely IP-bound anyway). But passwords.

https://nandynarwhals.org/sieberrsec-ctf-3.0-digginginthedump/

another good read

https://palmenas.medium.com/forensic-recovery-of-chrome-based-browser-passwords-e8df90d4a3cd

Take note of the difference between old ways and new ways. Anyway the encryption key was somewhere on disk in plain text.
On another note, since there is no app sandboxing and chromium is open source, any spying software can just emulate chromium.