Re: Looking for LUKS GUI

I have never used qubes-os but my understanding is that it intends to
provide a secure environment without the loopholes you have mentioned.

btw, I use LUKS encryption with a Yubico Bio key so decryption requires
a password and a pin and a thumb print.  I hope this prevents someone
with a key logger from getting access but I can't be sure.  The Yubikey
emits FIDO2 credentials that LUKS uses for the decryption key.

I will write up the process I use and send it to the list so others can
criticize it or benefit from it.

Bill

On Sat, 2025-04-05 at 17:47 +0000, Michael Kjörling wrote:
> On 5 Apr 2025 16:22 +0000, from [email protected] (Darek Hisc):
> > > I tried to find Linux GUI install guide, but I can’t find it.
> > 
> > Try ZuluCrypt https://github.com/mhogomchungu/zuluCrypt
> 
> I'm not familiar with ZuluCrypt (looks like it's just a front-end for
> creating and mounting encrypted block devices?) but keep in mind that
> temporary files can be left scattered around the file system,
> particularly in places like /tmp, ~/.cache, ~/.local/state and
> ~/.local/tmp.
> 
> The minimum for a situation like you describe should probably be:
> 
> - LUKS for full-disk encryption at the system level _including_ the
>   boot loader and kernel
> - Optionally separate encryption of different projects' data
> - Different, _unrelated_ passphrases for each such container
> - Use tmpfs for /tmp
> - Use encrypted swap with an ephemeral encryption key
> - A drop-by-default firewall configuration
> - Always make sure you are running up-to-date software, and be
>   _extremely_ restrictive about installing from third-party
>   repositories
> - Strong, unique passwords/passphrases _everywhere_
> - Maintain physical control of the hardware (so that an adversary
>   can't, for example, plug in a flush-with-the-port USB key logger
>   while you are out for lunch)
> 
> Your system might already be configured to do some of this;
> especially
> the last is not about software at all; and this mailing list is the
> wrong place to go into depth on how to set it all up. My point is
> that
> although LUKS and full-disk encryption can be an important component,
> _just_ LUKS (especially if used only for select data) probably won't
> be enough especially if an adversary is able to image the storage.
> 
> For passwords and passphrases, I have a web page at
> <https://michael.kjorling.se/password-tips/> which is pretty much
> what
> it says on the tin. It's meant to be applicable to and _actionable_
> by
> the general public; I basically wrote it because I grew tired of
> having to repeat it. :-)
> 
> 
> > > how really secure LUKS?
> > 
> > TLDR: This is a golden standard for Linux for many years to encrypt
> > FDE (whole disk) in all Linux distributions I know.
> > To encrypt files, use ZuluCrypt or VeraCrypt (create containers for
> > files).
> 
> Unless you go out of your way to do otherwise, LUKS (via cryptsetup)
> uses well-understood industry-standard algorithms, and also includes
> techniques to make adversarial key recovery more difficult. (For
> example, the "anti-forensic stripes" or AF stripes in the LUKS header
> means that even a partially overwritten LUKS header is essentially
> useless for gaining access to the contents of the container it is
> associated with, often _even if_ you know a valid passphrase.
> Exceptions to this exist, but they are highly specific.)
> 
> Essentially, if a LUKS container created with modern defaults uses a
> strong passphrase, then even for a highly resourceful adversary, it
> is
> believed to be computationally infeasible to gain access to the
> contents of that container _without_ actually somehow knowing a valid
> passphrase.
> 
> Note all the caveats in that sentence, because they _are_ important.
> 
> There _is_ a possibility that a weakness would be found in, say,
> Argon2 or AES-XTS which would change the security assumptions
> underlying LUKS; but personally, I would consider that unlikely, and
> if it were to happen, you certainly won't be alone in being in
> trouble
> with regards to data confidentiality.
> 
> https://xkcd.com/538/ applies.