profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ebiggers/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

google/syzkaller 3744

syzkaller is an unsupervised coverage-guided kernel fuzzer

google/fscrypt 605

Go tool for managing Linux filesystem encryption

google/adiantum 430

Adiantum and HPolyC specification and test vectors

ebiggers/libdeflate 429

Heavily optimized library for DEFLATE/zlib/gzip compression and decompression

ebiggers/ntfs-3g-system-compression 74

NTFS-3G plugin for reading "system compressed" files

google/fscryptctl 71

Small C tool for Linux filesystem encryption

ebiggers/avl_tree 68

High performance C implementation of AVL trees

ebiggers/xpack 24

Experimental compression format (unmaintained, do not use!)

ebiggers/wimlib 18

Mirror of git://wimlib.net/wimlib: Library supporting the Windows Imaging Format (WIM). Please file issues on the official forums (https://wimlib.net/forums/viewforum.php?f=1) rather than here.

ebiggers/fat-fuse 8

Simple readonly FUSE driver for FAT filesystems

release google/fscrypt

v0.3.1

released time in 4 days

push eventebiggers/fscrypt

Eric Biggers

commit sha b273e4158760a80f6496d815ab07f45cc1713a05

Release version v0.3.1

view details

push time in 4 days

PR closed google/fscrypt

Release version v0.3.1

Signed-off-by: Joe Richey joerichey@google.com

+1 -1

0 comment

1 changed file

josephlr

pr closed time in 4 days

created taggoogle/fscrypt

tagv0.3.1

Go tool for managing Linux filesystem encryption

created time in 4 days

delete branch ebiggers/fscrypt

delete branch : release

delete time in 4 days

PR merged google/fscrypt

Release version v0.3.1
+1 -1

0 comment

1 changed file

ebiggers

pr closed time in 4 days

push eventgoogle/fscrypt

Eric Biggers

commit sha b273e4158760a80f6496d815ab07f45cc1713a05

Release version v0.3.1

view details

push time in 4 days

PR opened google/fscrypt

Release version v0.3.1
+1 -1

0 comment

1 changed file

pr created time in 4 days

create barnchebiggers/fscrypt

branch : release

created branch time in 4 days

issue commentebiggers/libdeflate

Question, compatibility with alternative zlib implementations?

libdeflate uses the same data formats (DEFLATE, zlib, and gzip), so you can compress data with libdeflate and decompress it with other software that supports these formats, or alternatively compress with other software and decompress with libdeflate. However, the API isn't compatible. So e.g. if you have a program using the zlib library, you can't drop-in libdeflate as a replacement without changing the program's code to use libdeflate's API instead of zlib's API.

PhantomG27249

comment created time in 7 days

issue closedebiggers/libdeflate

Question, compatibility with alternative zlib implementations?

Just wondering if this might be compatible with alternative zlib and gzip implementations such as cloudflare or zlib-ng given that zlib and gzip are wrappers for the deflate stream. Cause it would be really cool to be able to use this with one of the optimized zlib/gzip implementations/wrappers.

closed time in 7 days

PhantomG27249

push eventebiggers/fscrypt

Eric Biggers

commit sha 7fed63a84963cbd790e86a0e59ff14724bcf33c4

Adjust recovery passphrase generation As per the feedback at https://github.com/google/fscrypt/issues/115 where users didn't understand that the recovery passphrase is important, restore the original behavior where recovery passphrase generation happens automatically without a prompt. This applies to the case where 'fscrypt encrypt' is using a login protector on a non-root filesystem. However, leave the --no-recovery option so that the recovery passphrase can still be disabled if the user really wants to. Also, clarify the information provided about the recovery passphrase. Update https://github.com/google/fscrypt/issues/115

view details

push time in 17 days

delete branch ebiggers/fscrypt

delete branch : recovery-passphrase

delete time in 17 days

push eventgoogle/fscrypt

Eric Biggers

commit sha 7fed63a84963cbd790e86a0e59ff14724bcf33c4

Adjust recovery passphrase generation As per the feedback at https://github.com/google/fscrypt/issues/115 where users didn't understand that the recovery passphrase is important, restore the original behavior where recovery passphrase generation happens automatically without a prompt. This applies to the case where 'fscrypt encrypt' is using a login protector on a non-root filesystem. However, leave the --no-recovery option so that the recovery passphrase can still be disabled if the user really wants to. Also, clarify the information provided about the recovery passphrase. Update https://github.com/google/fscrypt/issues/115

view details

push time in 17 days

PR merged google/fscrypt

Adjust recovery passphrase generation

As per the feedback at https://github.com/google/fscrypt/issues/115 where users didn't understand that the recovery passphrase is important, restore the original behavior where recovery passphrase generation happens automatically without a prompt. This applies to the case where 'fscrypt encrypt' is using a login protector on a non-root filesystem.

However, leave the --no-recovery option so that the recovery passphrase can still be disabled if the user really wants to. Also, clarify the information provided about the recovery passphrase.

Update https://github.com/google/fscrypt/issues/115

+80 -40

1 comment

8 changed files

ebiggers

pr closed time in 17 days

issue commentgoogle/fscrypt

auto-unlock over ssh stopped working

Are you logging in using password authentication or using public key authentication? pam_fscrypt can only unlock directories if the login happens using password authentication. See https://github.com/google/fscrypt#directories-using-my-login-passphrase-are-not-automatically-unlocking

hagelschaden

comment created time in 17 days

issue commentsystemd/systemd

homectl: subcommand to restore a missing or corrupt .identity file inside encrypted home directory

yeah, iirc fscrypt uses a borked KDF. They implemented it themselves, and really shouldn't have. We use OpenSSL. This means the hashes don't match even though on paper we implement the same stuff.

I'm not sure what you're talking about here. v2 encryption policies did switch to a better KDF in the kernel for deriving per-file keys, but this has nothing to do with the password-based KDF in userspace, and the fact that systemd doesn't create metadata that is compatible with the fscrypt tool. Although systemd and the fscrypt tool use the same underlying kernel feature, they do the userspace part of key management in different ways, so there is no compatibility between the two.

Now, I'm not necessarily saying there should be compatibility -- it looks like it was necessary to do things yourself anyway? But I'm not sure why you're claiming that systemd-homed fscrypt directories can be accessed using standard tools.

zackw

comment created time in 18 days

issue commentsystemd/systemd

homed: add knob for dropping caches on logout (and make it default enabled for fscrypt)

That's how key management with fscrypt works: it's a bit nuts.

Only once you flush the buffer caches the decrypted data is removed from memory.

dropping all caches on logout sounds a bit heavy handed... but i guess we could add a knob for that...

As I mentioned 2 years ago on the original systemd-homed pull request (https://github.com/systemd/systemd/pull/14096#discussion_r355036704), there is an ioctl to remove fscrypt keys. It's unclear why systemd still isn't using it, and is instead considering implementing deprecated workarounds.

Well, as they say: you can lead a horse to water, but you can't make it drink.

JackCasual

comment created time in 18 days

issue commentgoogle/fscrypt

Guidance on upgrading fscrypt

You should uninstall libpam-fscrypt too. No, this won't decrypt your files; it just removes the packages needed to unlock them.

Whether /etc/fscrypt.conf is removed depends on your distro's policy for when configuration files for uninstalled packages are kept. Either way, unless you changed settings in it that you want preserved, it doesn't matter.

If you aren't manually running fscrypt unlock, then yes you are using pam_fscrypt; that's the only other way to unlock encrypted directories.

Those steps sound fine.

talha-opteran

comment created time in 18 days

issue commentgoogle/fscrypt

Guidance on upgrading fscrypt

  1. Do I need to uninstall this version to upgrade from source or just overwrite?

If installing from source, you should uninstall your distro's version first.

  1. Do I need to take any precautions?

If you're relying on pam_fscrypt unlocking your home directory at login, it could be a good idea to also allow logging in using an alternate account (which could be root) that doesn't rely on that, so that you can manually unlock your home directory if you mess up the PAM configuration.

  1. What about related configuration files?

You will need to update your PAM configuration as described in the README.

  1. I take it I need to reencrypt the home folder?

If you want to upgrade to v2 encryption policies and not just upgrade your version of fscrypt, then yes you'll need to reencrypt your home directory as described in the README.

talha-opteran

comment created time in 19 days

issue commentgoogle/fscrypt

Explain threat model and improve comparison with other encryption solutions

Yes, because ZFS is a copy-on-write filesystem. Traditional filesystems which overwrite blocks in-place require dm-integrity. Hence my mention of how dm-integrity would not be required in the cases of F2FS in LFS-only mode or BTRFS. However as-is almost all users of the kernel side of fscrypt use either ext4, or F2FS in the default mode, which would both require dm-integrity in order to support authenticated encryption. You are not the first person to think about this; this is something people have been trying to solve for years/decades. It's been learned that a practical solution requires either hardware that natively supports per-block metadata (ideal), or the use of a nontraditional filesystem (less ideal as authenticating filesystem metadata properly can be hard, but filesystems can be designed to do it well).

robszy

comment created time in a month

issue commentgoogle/fscrypt

Explain threat model and improve comparison with other encryption solutions

But i would be convenient for fscrypt users because it will be lightweight fast and solid solution for people who don't want to use dmcrypt which is slow as you've said

To re-iterate, the use of dm-integrity comes with a heavy performance cost. This is because it needs to use data journaling to maintain consistency; otherwise your filesystem will be corrupted on crashes and power cuts. This is true regardless of what is being used on top of it (e.g. dm-crypt, fscrypt, both, or neither).

But who can change it if not google enginners :)

The kernel side of fscrypt is upstream Linux kernel code; anyone is welcome to contribute. I would be happy to consider patches that add authenticated encryption support via dm-integrity, if someone was interested in implementing it. I don't currently plan to implement this feature myself, as it doesn't currently appear to be a very useful feature. It can sound useful to crypto people ("of course you should be using authenticated encryption"), but with a performance hit of 2-3x (very roughly) due to the write amplification and extra syncs required to maintain data consistency, no one will actually use it other than a few power users. One possibility is to support it only on F2FS in LFS-only mode instead of requiring dm-integrity, but that would be a pretty significant limitation. Another possibility would be to support it on BTRFS if/when it adds encryption support. Of course there is still the question of how much authenticated encryption of file contents matters if filesystem metadata isn't being authenticated too.

robszy

comment created time in a month

issue commentgoogle/fscrypt

Explain threat model and improve comparison with other encryption solutions

It could be supported if the filesystem is located on top of a dm-integrity device, although it wouldn't be very practical due to the heavy performance cost of dm-integrity.

Also note that if you are trying to harden the system to such an extent that you are worried about attackers manipulating AES-XTS ciphertexts, you probably should be encrypting the whole disk (either by using dm-crypt + fscrypt, or dm-crypt by itself if applicable for your use case) so that the filesystem metadata is protected too.

robszy

comment created time in a month

issue commentgoogle/fscrypt

Explain threat model and improve comparison with other encryption solutions

Yes, AES-GCM is an authenticated encryption algorithm. The kernel side of fscrypt doesn't support any authenticated encryption algorithms, due to the difficulty in dealing with ciphertext expansion. The Linux kernel does contain implementations of some authenticated encryption algorithms including AES-GCM, but they are only used by other Linux kernel features such as VPN support. LUKS/dm-crypt can use authenticated encryption, but only if it is set up on top of dm-integrity, which isn't too practical.

robszy

comment created time in a month

issue commentgoogle/fscrypt

Explain threat model and improve comparison with other encryption solutions

There is no single answer to that question as it depends on many things. All else being equal, encrypting more is obviously better than encrypting less and thus the FDE version would be better, but there many other factors to consider such as:

  • Whether the use of FDE implies a less well-protected key, as is often the case in practice for usability reasons or to support multiple users or profiles. (If it's a true single user system and the user is a "power user" who cares a lot about encryption, this won't be the case as they will set a strong boot-time password. But in practice that isn't the only case, as I've explained previously.)

  • Where the executable code is stored and how it is authenticated, if at all. Authentication could happen through partition-level hashes, e.g. dm-verity; file-level hashes, e.g. IMA appraisal or something based on fs-verity; or disk/file encryption, which isn't actually authenticated, but can be (ab)used as "poor man's authentication". If the system relies on encryption as "poor-man's authentication" for executable code, then removing or not applying encryption to such files would be a problem. However, if the system already uses a proper authentication mechanism for such files (as it should) then not encrypting those files wouldn't be a problem, as far as an offline attacker trying to change these files is concerned.

  • How other on-disk data such as configuration files and filesystem metadata are authenticated, and whether the attacker is "advanced" enough to e.g. mount an attack using a zero-day memory unsafety bug in a Linux filesystem implementation to get code execution, vs. just modifying some code on-disk which is a much more straightforward attack.

Note that Chrome OS both implements Verified Boot and uses the kernel side of fscrypt. If you have questions about Chrome OS security, they have some pretty detailed security model documents available.

robszy

comment created time in a month

issue commentgoogle/fscrypt

Emphasise in readme that fscrypt is not access control mechanism

The comparison between fscrypt and other encryption systems does need to be reworked, but most of your suggestions are just plain wrong. Most of your complaint is that fscrypt (by itself) doesn't protect against evil maid attacks, with an assumption that LUKS/dm-crypt (FDE) would protect against such attacks. However, actually the way that LUKS/dm-crypt is used on Linux (outside of Chrome OS and Android) doesn't protect from such attacks either. The author of systemd just posted a detailed blog post on this, which I'd highly recommend reading: http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html. Fixing that issue (by implementing "Verified Boot") is largely orthogonal to what type of encryption you are using.

robszy

comment created time in a month

push eventebiggers/fscrypt

Eric Biggers

commit sha ee5e47f3481c7f09f4f3f4bdf360f2c8b1b59a1e

README: mention LTS kernel versions with symlink bug fix Resolves https://github.com/google/fscrypt/issues/305

view details

Joseph Richey

commit sha 4d20c7b6eda7f4e9f25442e0ec48bdf5f959853b

Merge pull request #317 from ebiggers/readme-symlink-bug README: mention LTS kernel versions with symlink bug fix

view details

push time in a month

delete branch ebiggers/fscrypt

delete branch : readme-symlink-bug

delete time in a month

pull request commentgoogle/fscrypt

Adjust recovery passphrase generation

@josephlr any feedback on this?

ebiggers

comment created time in a month

PR opened google/fscrypt

README: mention LTS kernel versions with symlink bug fix

Resolves https://github.com/google/fscrypt/issues/305

+5 -4

0 comment

1 changed file

pr created time in a month