You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 21, 2024. It is now read-only.
On my systems I encrypt the entire drives by default, but all types of encryption have an negative impact on performance. I have my drives encrypted to protect any sensitive data from being read from my drives when they are offline and to make it prohibitively difficult to tamper with any data or programs on the system without it being detected.
Given my requirements, full drive encryption is being used on data that need not be encrypted and causing unnecessary performance desegregation.
Most of the system configuration has no plain text secrets, but I do need to be able to verify that is has not been tampered with before it is used (on boot). This means it does not need to be encrypted.
Much of the user directories can contain data that needs to be protected, so keeping those encrypted makes sense.
Some of programs and config for the users is not sensitive and some of it is sensitive.
Much of the software that users build is sensitive and might rarely not be.
What this means for a system using nix
While the volatile and mutable data can easily just live encrypted home directories. Programs and config build with nix all end up in the nix store, but at the different levels (system/user/project) the need for encryption varies drastically. Unfortunately the files in the nix-store cannot easily be from a mix of encrypted and non-encrypted partitions. There might be somethings that can be done with linux overlayfs and maybe the in RFC feature "local-overlay" could help too.
Essentially we would need a nix store for the non-sensitive parts of the system. another for the sensitive parts of the system. Another nix store for the non-sensitive parts of the user config and another for the sensitive parts and another store of the possibly sensitive ad-hock shells. All of the sensitive stores can be on an (or many) encrypted partition(s).
This seems like it would be impossible or very inconvenient currently.
The text was updated successfully, but these errors were encountered:
Rosuavio
changed the title
Avoid preformce impack of encprting non-sensitive programs and data
Avoid performance impact of encrypting non-sensitive programs and data
Jul 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
On my systems I encrypt the entire drives by default, but all types of encryption have an negative impact on performance. I have my drives encrypted to protect any sensitive data from being read from my drives when they are offline and to make it prohibitively difficult to tamper with any data or programs on the system without it being detected.
Given my requirements, full drive encryption is being used on data that need not be encrypted and causing unnecessary performance desegregation.
Most of the system configuration has no plain text secrets, but I do need to be able to verify that is has not been tampered with before it is used (on boot). This means it does not need to be encrypted.
Much of the user directories can contain data that needs to be protected, so keeping those encrypted makes sense.
Some of programs and config for the users is not sensitive and some of it is sensitive.
Much of the software that users build is sensitive and might rarely not be.
What this means for a system using nix
While the volatile and mutable data can easily just live encrypted home directories. Programs and config build with nix all end up in the nix store, but at the different levels (system/user/project) the need for encryption varies drastically. Unfortunately the files in the nix-store cannot easily be from a mix of encrypted and non-encrypted partitions. There might be somethings that can be done with linux overlayfs and maybe the in RFC feature "local-overlay" could help too.
Essentially we would need a nix store for the non-sensitive parts of the system. another for the sensitive parts of the system. Another nix store for the non-sensitive parts of the user config and another for the sensitive parts and another store of the possibly sensitive ad-hock shells. All of the sensitive stores can be on an (or many) encrypted partition(s).
This seems like it would be impossible or very inconvenient currently.
The text was updated successfully, but these errors were encountered: