home.social

#disk-encryption — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #disk-encryption, aggregated by home.social.

fetched live
  1. The data that I didn’t know I didn’t have to back up to Microsoft’s cloud

    I spent more time than I’d planned Friday afternoon poking around the security settings of my Windows laptop, then undoing one setting that I am somewhat embarrassed to admit I had scarcely thought about over the previous two and a half years of using this HP.

    The FBI gets some credit for that for making me rethink my own device security after some of its agents raided Washington Post reporter Hannah Natanson’s home two weeks ago and seized several of her devices–an obvious move to intimidate journalists– leaving the storage encryption on that hardware as the last line of defense for her data.

    Forbes security writer Thomas Brewster gets the rest of the credit for a strong post Friday morning unpacking how Microsoft’s approach to device encryption via its BitLocker software can leave Windows computers open to law enforcement investigators who bring a valid legal order to the company requesting a particular user’s encryption recovery key.

    “It’s possible for users to store those keys on a device they own, but Microsoft also recommends BitLocker users store their keys on its servers for convenience,” Brewster wrote. “While that means someone can access their data if they forget their password, or if repeated failed attempts to login lock the device, it also makes them vulnerable to law enforcement subpoenas and warrants.”

    He reported that Microsoft gets about 20 requests a year for BitLocker keys but cannot respond to many of them because the customers involved didn’t back up those keys to its cloud.

    Windows 11 Home’s Device Encryption isn’t branded as BitLocker in the Settings app, but it runs on the same framework. And as in the Pro, Enterprise and Education editions of Windows 11, it allows a choice of key-backup locations–which I did not realize until eyeballing Microsoft’s documentation after I’d read Brewster’s post.

    I had gone unthinkingly with the default of having the recovery key backed up to my Microsoft 365 cloud storage; I don’t remember even being presented with a choice when I set up the computer in August of 2023. But since the key is only a string of 48 numbers periodically separated by dashes, there was no point in keeping it there.

    Instead, I saved it in my end-to-end-encrypted password manager 1Password, where the security design does not expose backdoors that can be opened with a court order. Then I deleted the backed-up recovery key from my M365 storage after clicking a checkbox to confirm that I’d saved the key elsewhere–along with seven older ones I found saved there, going back to a Surface laptop I reviewed a decade or so ago.

    (I don’t know how long it will take for this data to be gone from my online storage, although there is the option of decrypting and re-encrypting the laptop to ensure the old key is useless.)

    I never should have taken Microsoft up on this offer. But Microsoft should not be leaving users in this position–as Johns Hopkins University cryptography professor Matthew Green told Brewster in that article. Apple’s FileVault device encryption now automatically encrypts recovery keys backed up to the company’s iCloud service (see this explainer from my friend Glenn Fleishman at Six Colors), leaving nothing for a third party to inspect with a warrant.

    There are many areas where Microsoft can’t readily catch up with Apple, starting with having a mobile platform to complement its desktop operating system. But this should not be one of them.

    #BitLocker #diskEncryption #encryption #FBI #HannahNatanson #keyEscrow #M365 #Microsoft365 #MicrosoftBackup #Windows11Home #WindowsDeviceEncryption

  2. OpenBSD users, can you tell me your experience of full-disk encryption on a SSD?

    Is the encryption overhead noticiable compared to plain SSD? Or is it as slow as HDD?
    How often have you lost files due to a poweroff letting your partition on an inconsistent state?

    #openbsd #ssd #fde #DiskEncryption

  3. @darkling @nicholasr @nixCraft #btrfs does indeed support swap files, they problebly work fine, they are just very unorthodox and therefore difficult to setup.

    The swap file you would use if you want #diskencryption, in theory at least...
    #diskencryption brings mé more issues than what's worth!

  4. From #Debian 13, would you use VeraCrypt or ZuluCrypt to create an encrypted disk accessible from any OS ?

    Veracrypt hasn't released a .deb yet for Debian 13, so the generic installer must be used. Not sure how well it's supposed to work.

    #DiskEncryption #VeraCrypt

  5. So. Linux 🐧

    My PC runs Linux (Fedora) and with the current gen Hardware in it the ancient old Question pops up again: Full Disk Encryption or not?

    At least some ciphers should be HW-accellerated (AES-SNI). But then there is the hassle of entering the password. And the annoyance.

    But on the other side...

    What do you guys think?

    #linux #encrypt #encryption #diskencryption #security #admin

  6. CW: software recommendations request :boost_requested:, encryption related

    anyone aware of disk/container encryption software that works on both macOS and linux?

    I'm aware of veracrypt but I'm looking for more of something similar to that (and also strongly preferring FOSS)

    I'm using it to store a bunch of files for games data and apps data, so an encrypted container/filesystem is fine (and pretty much what I'm looking for)

    :boost_requested:

    I do not want: cloud storage (even self-hosted), single file encryption (I'm encrypting multiple files and not for one time use)

    already suggested: veracrypt, cryptomator, kryptor, gocryptfs, linsk, picocrypt, cryfs, ZFS, BTRFS, age

    use case, and considered solutions: micro.jacksonchen666.com/@jack

    #encryption #DiskEncryption #macOS #linux

  7. CW: Switching from Fedora to Debian, but keeping the old root fs (LUKS+btrfs)

    For increased challenge, #Fedora was installed on an encrypted #btrfs partition, which I wanted to keep (btrfs directly on #LUKS, no LVM).

    Do not follow my instructions without testing/practicing in VM first! I may have forgotten something or your case might be different.

    Steps:

    (0) Make backups of /boot, /boot/efi and btrfs subvolumes.

    (1) Flash the #Debian installer image to a USB thumb drive. I used the 4GB DVD image.

    (2) Boot the installer and install Debian to the external SSD. When setting up partitions, choose encrypted drive (with LVM) to decrease chances of extra surprises when transferring the new OS to the old encrypted fs. Then change the root fs from the default ext4 to btrfs.

    (3) Reboot to Debian. Use `cryptsetup open <device> <name>` to unlock the old encrypted btrfs partition on the internal SSD. Mount the internal filesystems somewhere side-by-side (the root of the btrfs fs tree, /boot, /boot/efi), e.g. at /mnt/internal-fs-tree, /mnt/internal-boot, /mnt/internal-efi.

    NOTE: The mapped name you choose at this point for the unlocked LUKS partition will be permanent and difficult to change later! Debian will boot using it. (I followed Fedora's convention and named it luks-<UUID>.)

    (4) To prevent accidental changes, make the old subvolumes readonly using `btrfs property set`.

    (5) Take a snapshot of the root subvolume of the Debian on the external SSD and use `btrfs send` & `btrfs receive` to transfer it to the internal SSD's btrfs. Rename subvolumes if necessary. In the end, the Debian subvolume should be e.g. at /mnt/internal-fs-tree/rootsubvol.

    (6) Replace the internal SSD's /mnt/internal-boot/ with files from the external /boot/ using `rsync -a --delete`. Make sure that the dir /mnt/internal-efi/EFI/debian/ exists. If not, copy it from the external SSD's /boot/efi/EFI/ (I think in my case the installer updated the efi partition of the internal SSD).

    (7) Clean up the first line of the file /mnt/internal-efi/EFI/debian/grub.cfg and change the disk UUID to point to the internal SSD's boot partition. In my case the line now reads `search.fs_uuid <UUID> root`. You can use e.g. `lsblk -f` to list the UUIDs of your devices and partitions.

    (8) Change /mnt/internal-fs-tree/rootsubvol/etc/fstab and rootsubvol/etc/crypttab to the desired final configuration. I just used the old files from Fedora. Also, either comment out the line in rootsubvol/etc/initramfs-tools/conf.d/resume or remove the file.

    IMPORTANT: The mapped name of the encrypted root partition in rootsubvol/etc/crypttab MUST be the same you used in step (3) or Debian won't find it at boot. (Naming of it is surprisingly inflexible in both Fedora and Debian and I had to learn this the hard way. Debian installer makes it even worse by naming it after its /dev/xxx name at the time of installation, e.g. sdc3_crypt.)

    (9) Unmount the partitions of the internal SSD and remount root and boot partitions to /mnt/debian and /mnt/debian/boot to prepare a chroot environment. The root subvolume must be mounted directly like it would at boot (i.e. `mount -o subvol=/rootsubvol ...`) instead of bind mount, because bind doesn't play nice with chroot.

    (10) Bind mount /dev, /proc and /sys (i.e. `mount -o bind /dev /mnt/debian/dev` etc) and run `chroot /mnt/debian /bin/bash`.

    (11) Once in chroot run `update-initramfs -u -k all` and `grub-mkconfig -o /boot/grub/grub.cfg`.

    Done! Exit chroot, reboot and remove the external SSD.

    #Linux #DiskEncryption

  8. "A swap file can be used to reserve swap-space within an existing partition & may also be setup inside an encrypted blockdevice's partition."
    So all I had to do is make sure swap file is setup in fstab & just point all resume=UUID= to the UUID of primary partition where the #swap file is & that is it. my brain exploded🤯 from how easy it was.
    p.s. reminder to anyone doing #LUKS it is only as good as the password you pick so pick something good!
    #CryptSetup #Linux #LVM #hibernate #DiskEncryption

  9. Long ago when I was installing #Kali #Linux on my #Dell Latitude E5570 #Laptop
    I went with LVM on LUKS wiki.archlinux.org/title/dm-cr
    & at the time I thought I'd go with a swap file on / (I was unaware of Swap crypt🙄)
    I was never able to get hibernate to work, until now😀...
    Let me say many websites & forums all say if you want hibernate to work on LUKS, you have to go with swap crypt.
    Not true, if you read wiki.archlinux.org/title/Dm-cr
    #CryptSetup #LVM #LUKS #SWAP #hibernate #DiskEncryption

  10. Thanks for all the suggestions and links.

    I will try putting a new / temporary key into the initramfs just for while I am out of town - the chance of power outage is higher than the chance of burglary.

    I'll remove the temp key and rebuild the initramfs after I get back home. Normally, I'm in front of the computer when it reboots, so entering the password manually (as I've been doing for a few years) is fine.

    #DMCrypt #DiskEncryption #Linux

  11. Is there a good way to have a #Linux server reboot unattended when the root partition is dm_crypt encrypted? I'm not super worried about bad guys being physically present. More just worried that a power outage might initiate a reboot while I am not present.

    Is including the key file in the initramfs (correct terminology?) that horrible a thing if physical access to the machine is not a concern?

    Thoughts or advice?

    #DMCrypt #DiskEncryption

  12. (1/2)

    #Linux #DiskEncryption I want to check that I'm thinking about this in a way that makes sense. Context is a laptop with a #LUKS partition.

    I see a lot of how-to articles floating around about using #tpm2 for LUKS decryption on device boot.
    I understand that this gives convenience over a separate passphrase for decryption and still prevents:

    An adversary from removing the hard drive when your machine is off and decrypting it (because the adversary won't have the TPM to decrypt).
    An adversary from modifying anything in the secure boot chain and accessing a decrypted drive (because the device will then refuse to boot and decrypt the LUKS partition).

  13. Can I suggest using a landscape UI, rather than a portrait, for entering an encryption passphrase when booting a mobile device? That would allow for a larger keyboard, as well as a longer area for the dots that appear as a user types each passphrase character.

    #mobileGNU #PinePhone #Librem5 #DiskEncryption

    @postmarketOS @PINE64 @purism
    @mobian

  14. Newly added to the Trade-Free Directory:

    VeraCrypt

    VeraCrypt is a free open source disk encryption software for Windows, Mac OSX and Linux. Brought to you by IDRIX (https://www.idrix.fr) and based on TrueCrypt 7.1a.

    #disk-encryption

    More here:

    https://www.directory.trade-free.org/goods-services/veracrypt/