FSCRYPT In Linux 6.7 More Adaptable For Inline Encryption Hardware

[phoronix]

Phoronix: FSCRYPT In Linux 6.7 More Adaptable For Inline Encryption Hardware

Linux's FSCRYPT file-system encryption framework allows for native file encryption support on the likes of EXT4, F2FS, and UBIFS. FSCRYPT can make use of inline encryption hardware for accelerating the file-system encryption support and with the Linux 6.7 kernel will work for more scenarios...

https://www.phoronix.com/news/Linux-6.7-FSCRYPT

[bezirg]

I still have absolutely no clue to which hardware this inline encryption applies to.

[fallingcats]

Does this mean it can use aes-ni instructions now when it couldn't before? Because that's what it reads like, but I somehow doubt that.

[stormcrow]

I still have absolutely no clue to which hardware this inline encryption applies to.

Mostly mobile devices.

https://docs.kernel.org/filesystems/fscrypt.html Unless you want to learn everything about the kernel fscrypt API, skip down to "Inline encryption support".

Come on folks, you can use a search engine as well as I can.

Please note, that systems using fscrypt don't encrypt filesystem and file metadata. Quite often attackers don't need the contents of the files, all they need is to map the extensive metadata filesystems contain to do considerable amounts of event correlation. This is practical dead box forensics 101. Any cyber gang member worth his keyboard can cook a python script to map this stuff out let alone any TLA.

[OneTimeShot]

Ideally encrypted files should be independent of hardware, filesystem and block device.

If I want to encrypt the entire device, that should be a mount option. If I want to encrypt a file or directory content that shouldn't be restricted to a particular filesystem.

Also, it would be nice to have file signing in a similar way. So you can read a file and verify that it hasn't been maliciously altered by someone else...

(yeah - I know I can hack together bits of this without kernel support. A standard set of APIs)

[skeevy420]

Mostly mobile devices.

https://docs.kernel.org/filesystems/fscrypt.html Unless you want to learn everything about the kernel fscrypt API, skip down to "Inline encryption support".

Come on folks, you can use a search engine as well as I can.

Please note, that systems using fscrypt don't encrypt filesystem and file metadata. Quite often attackers don't need the contents of the files, all they need is to map the extensive metadata filesystems contain to do considerable amounts of event correlation. This is practical dead box forensics 101. Any cyber gang member worth his keyboard can cook a python script to map this stuff out let alone any TLA.

Please don't include additional directions like "scroll, bitch" when the content is damn near at the bottom of a very long page....

Where stormcrow wanted us to look for...

More Inline Encryption reading...

I read all that and I still don't know of any specific hardware outside of generic mobile and SOCs.

[CommunityMember]

Come on folks, you can use a search engine as well as I can.
.

If you have not figured it out, *you* have been assigned as the search engine (for it is always easier if someone else does the work).

As the returned results are acceptable, you will continue to be used.

[Jakobson]

I read all that and I still don't know of any specific hardware outside of generic mobile and SOCs.

To peek inside the Linux source code, navigate to the drivers/crypto directory and use a grep command to search for files containing inline crypto for e.g. AES-XTS:. you can search for files with .cra_name = "xts(aes)"

[stormcrow]

Please don't include additional directions like "scroll, bitch" when the content is damn near at the bottom of a very long page....

Where stormcrow wanted us to look for...

More Inline Encryption reading...

I read all that and I still don't know of any specific hardware outside of generic mobile and SOCs.

Seriously? You're complaining because you need to do a little look see? A little extra research? What I didn't give you the answers entirely on a platter? I gave you where to start looking. The rest is up to you. YOU asked the question. YOU want the answers. If YOU want the hardware specifics go find them. No, I'm not going to give a hint at this point. You made it personal with personal attacks. A 30k overview after reading the docs + a bit of the code was enough for me.

[skeevy420]

Seriously? You're complaining because you need to do a little look see? A little extra research? What I didn't give you the answers entirely on a platter? I gave you where to start looking. The rest is up to you. YOU asked the question. YOU want the answers. If YOU want the hardware specifics go find them. No, I'm not going to give a hint at this point. You made it personal with personal attacks. A 30k overview after reading the docs + a bit of the code was enough for me.

1. I didn't ask a question and neither did anyone else. bezirg made a statement that you answered with the ever so helpful reply of RTFM and then linked that entire section of manual.
2. I then replied that RTFM isn't helpful in my special, jovial manner and linked to the relevant part.
3. I did use a search engine and came up with a bunch of irrelevant information and devices. Honestly, I don't really care that much about this outside of a fleeting curiosity about what tech uses the stuff in the article I'm reading so there's a very good chance that my Google-Fu sucks and I'm using the wrong terms due to a lack of knowledge and interest in what I'm searching.
4. Since YOU want to be personal and YOU want to post in that tone of text with me, I don't know if I'd trust any answer YOU'D come up with after YOUR 30K overview of docs + code when YOU don't have the analytical skills to follow 6 posts in a thread.