![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/h1ChnLuBHr.png)
If someone gets access they can delete your keys, or set up something that can intercept your keys in other ways.
The security of data at rest is just one piece of the puzzle. In many systems the access to the data is considered much more important than whether the data itself is encrypted in one particular scenario.
If you don’t already know the benefits it’s unlikely it solves a problem you have.
Even among its users many are using it because it’s cool rather than because they actually need it.
It’s a declarative system, meaning you can describe how it should be setup (using a magic strings you have to look up online) and then it “sets up itself” according to the description.
It’s normally something you’d use for mass and/or repetitive deployments.
It’s usefulness for a single system is debatable, considering you can achieve very close to 100% of “reproducibility” anyway by copying /home and /etc and fetching a copy of the package list.
Where the prescriptive approach is supposed to help is when you attempt to reproduce the system a long time later, after things like config files and packages have changed. But it doesn’t help with /home, it hasn’t been tested over long intervals, and in fact nobody guarantees long term compatibility for Nix state.