• communism@lemmy.ml
      link
      fedilink
      arrow-up
      11
      ·
      4 months ago

      Whole disk encryption wouldn’t change your daily usage, no. It just means that when you boot your PC you have to enter your passphrase. And if your device becomes unbootable for whatever reason, and you want to access your drive, you’ll just have to decrypt it first to be able to read it/write to it, e.g. if you want to rescue files from a bricked computer. But there’s no reason not to encrypt your drive. I can’t think of any downsides.

      • lemmyvore@feddit.nl
        link
        fedilink
        English
        arrow-up
        3
        ·
        4 months ago

        If any part of the data gets corrupted you lose the whole thing. Recovery tools can’t work with partially corrupted encrypted data.

        • communism@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          4 months ago

          I don’t think that’s a big deal with Signal data. You can log back into your account, you’d just lose your messages. idk how most people use Signal but I have disappearing messages on for everything anyway, and if a message is that important to you then back it up.

    • thayer@lemmy.ca
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      4 months ago

      No, the average user will never know the difference. I couldn’t tell you exactly what the current performance impact is for hardware encryption, but it’s likely around 1-4% depending on the platform (I use LUKS under Linux).

      For gamers, it’s likely a 1-5 FPS loss, depending on your hardware, which is negligible in my experience. I play mostly first and third person shooter-style games at 1440p/120hz, targeting 60-90 FPS, and there’s no noticeable impact (Ryzen 5600 / RX 6800XT).

      • refalo@programming.dev
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        4 months ago

        For gamers, it’s likely a 1-5 FPS loss

        I highly doubt it… would love to see some hard data on that. Most algorithms used for disk encryption these days are already faster than RAM, and most games are not reading gigabytes/sec from the disk every frame during gameplay for this to ever matter.

      • ruse8145@lemmy.sdf.org
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        4 months ago

        If it has to go to disk for immediate loading of assets while playing a video game you’re losing more than 1-5 fps

        • refalo@programming.dev
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          4 months ago

          Maybe, but not every frame while you’re playing. No game is loading gigs of data every frame. That would be the only way most encryption algorithms would slow you down.

          • ruse8145@lemmy.sdf.org
            link
            fedilink
            arrow-up
            1
            ·
            4 months ago

            Yeah was thinking about that (edited to add immediate) – games are certainly background loading nowadays but the stuff needed is intended to be in ram by the time it’s needed, afaik.

        • thayer@lemmy.ca
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          4 months ago

          Yeah, I’m sure there are a lot of variables there. I can only say that in my experience, I noticed zero impact to gaming performance when I started encrypting everything about 10 years ago. No stuttering or noticeable frame loss. It was a seamless experience and brings real peace of mind knowing that our financial info, photos, and other sensitive files are safely locked away.

          • ruse8145@lemmy.sdf.org
            link
            fedilink
            arrow-up
            1
            ·
            4 months ago

            For sure I’m just saying i’d guess that’s because at play time you’re loading everything into ram. For bulk loading I would encryption perf follows the general use case.

            (Tldr encryption shouldn’t matter for games)

    • devfuuu@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      4 months ago

      It’s transparent for end user basically, but protects the laptop at least when outside and if someone steals the computer. As long as it was properly shutdown.

        • refalo@programming.dev
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          4 months ago

          I think they’re just referring to an outdated concept of OSes with non-journaling filesystems that can cause data corruption if the disk is shut off abruptly, which in theory could corrupt the entire disk at once if it was encrypted at a device level. But FDE was never used in the time of such filesystems anyways.

        • devfuuu@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          4 months ago

          If you suspend the laptop when moving locations instead of shutting down or hibernating to disk then disk encryption is useless.

          • thayer@lemmy.ca
            link
            fedilink
            English
            arrow-up
            3
            ·
            4 months ago

            Most operating systems will require your desktop password upon resume, and most thieves are low-functioning drug users who are not about to go Hacker Man on your laptop. They will most likely just wipe the system and install something else; if they can even figure that out.

    • refalo@programming.dev
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      4 months ago

      It depends on how you set it up. I think the default in some cases (like Windows Bitlocker) is to store the key in TPM, so everything becomes transparent to the user at that point, although many disagree with this method for privacy/security reasons.

      The other method is to provide a password or keyfile during bootup, which does change something for the end user somewhat.