5 ms·

> Performance is great, nearly "metal" SSD speeds. But how does that compare exactly, performance wise, against Bitlocker and LUKS? (assuming similar strength

> Performance is great, nearly "metal" SSD speeds. But how does that compare exactly, performance wise, against Bitlocker and LUKS? (assuming similar strength encryption algorithms are selected)

Ayesh 3y ago
I haven't used BitLocker or anything else, so I can't really compare. Veracrypt has a neat benchmark tool so you know the speed beforehand. I suppose most CPUs have native support for the popular algorithms, so the bottleneck really is the disk, not CPU itself or the software.
deleted 3y ago
[deleted]
pulse7 3y ago
There is still an open issue in VeraCrypt (https://github.com/veracrypt/VeraCrypt/issues/136 https://github.com/veracrypt/VeraCrypt/issues/136) because of which BitLocker is much faster on SSDs then VeraCrypt... But if you don't need those speads, VeraCrypt is still great...
- huhtenberg 3y ago
  To nitpick - on _NVmE_ drives, not SSDs. The principal difference is the native speed of raw IO - NVmEs are an order of magnitude faster than SSDs. TC/VC don't use hardware acceleration, so all the encryption work falls on the CPU. On a machine with a reasonably modern CPU, TC/VC run nearly at drive's native speed.
  - seanw444 3y ago
    > TC/VC don't use hardware acceleration I assume by that you mean it doesn't use the AES instructions? That's odd to me.
    - fluoridation 3y ago
      No, that's wrong. VeraCrypt uses AES-NI when available. It seems the source of the issue is the IO design of the driver, which causes unnecessary context switches when operating on a raw device.
      - seanw444 3y ago
        Okay that makes more sense.
      - Ms-J 3y ago
        You can also explicitly disable the AES-NI in Veracrypt and use pure software implementation if you don't trust the hardware. I usually enable this option.
        zeroimpl 3y ago
        This option always seems funny to me. If I didn't trust the AES-NI instruction, why I would I trust the XOR instruction?
        seanw444 3y ago
        You could probably imagine the possibility of state actors and Intel, for example, conspiring to backdoor AES instructions of specific targets. Maybe possible with the IME. Not accusing them of this, but it's not out of the realm of possibility. The only things using the AES instructions are important data needing to be encrypted. On the other hand, trying to backdoor XOR would give you an astronomically higher amount of white noise. Finding important data mixed in with all the other things a computer XORs would be much harder.
        fluoridation 3y ago
        The CPU would "just" need to look at all executable pages to find binaries of common AES implementations, and when it finds one it could wait for the key to be loaded and then exfiltrate it. It could also detect (although at greater effort, possibly much greater) when you're using it to compile AES and inject spying code into the output, even if the target is a different architecture. If the attacker has access to your computer, you've already lost. If the attacker built your computer, it was never even a fight.
baxuz 3y ago
Bitlocker is Microsoft's closed-source product. How can you be sure it doesn't have backdoors?
- shim__ 3y ago
  That question is pointless if you're using windows
  - huhtenberg 3y ago
    In practice, it is most certainly not pointless. Given two USB drives, one encrypted with BitLocker and another with TC or VC, chances of master key recovery by Microsoft are definitely not the same.
    - maccard 3y ago
      > In practice, it is most certainly not pointless .... chances of master key recovery by Microsoft are definitely not the same. I don't think those two sentences hold water when put together. In practice, if your risk is master key leakage and theft of the encrypted data by microsoft, you shouldn't be using windows. If you suspect that, MS can have a kernel mode driver masquerading as anything else, and it can just siphon your master key whenever you enter it.
      - DarkmSparks 3y ago
        And now that ms auth is apparently mostly compromised, extend microsoft to any threat actor in the wild. I like VC for the portability of the encrypted .tc files. Keep all my backups as tc files, and recovered from more than one failure using them. Once had an issue where dropbox corrupted the duplicates, so dont use dropbox anymore.
        Jerrrry 3y ago
        >ms auth is apparently mostly compromised just gonna drop that like that aint a $10k+ implication, gonna need a src or ref thanks unless you mean by 3letters, which dont exactly give their backdoors to randoms. randoms aint coming across 3letter's backdoors, not active/modern ones anyway

> Performance is great, nearly "metal" SSD speeds. But how does that compare exactly, performance wise, against Bitlocker and LUKS? (assuming similar strength encryption algorithms are selected)

Ayesh 3y ago

I haven't used BitLocker or anything else, so I can't really compare. Veracrypt has a neat benchmark tool so you know the speed beforehand. I suppose most CPUs have native support for the popular algorithms, so the bottleneck really is the disk, not CPU itself or the software.

deleted 3y ago

[deleted]

pulse7 3y ago

There is still an open issue in VeraCrypt (https://github.com/veracrypt/VeraCrypt/issues/136 https://github.com/veracrypt/VeraCrypt/issues/136) because of which BitLocker is much faster on SSDs then VeraCrypt... But if you don't need those speads, VeraCrypt is still great...

huhtenberg 3y ago
To nitpick - on _NVmE_ drives, not SSDs. The principal difference is the native speed of raw IO - NVmEs are an order of magnitude faster than SSDs. TC/VC don't use hardware acceleration, so all the encryption work falls on the CPU. On a machine with a reasonably modern CPU, TC/VC run nearly at drive's native speed.
- seanw444 3y ago
  > TC/VC don't use hardware acceleration I assume by that you mean it doesn't use the AES instructions? That's odd to me.
  - fluoridation 3y ago
    No, that's wrong. VeraCrypt uses AES-NI when available. It seems the source of the issue is the IO design of the driver, which causes unnecessary context switches when operating on a raw device.
    - seanw444 3y ago
      Okay that makes more sense.
    - Ms-J 3y ago
      You can also explicitly disable the AES-NI in Veracrypt and use pure software implementation if you don't trust the hardware. I usually enable this option.
      - zeroimpl 3y ago
        This option always seems funny to me. If I didn't trust the AES-NI instruction, why I would I trust the XOR instruction?
        seanw444 3y ago
        You could probably imagine the possibility of state actors and Intel, for example, conspiring to backdoor AES instructions of specific targets. Maybe possible with the IME. Not accusing them of this, but it's not out of the realm of possibility. The only things using the AES instructions are important data needing to be encrypted. On the other hand, trying to backdoor XOR would give you an astronomically higher amount of white noise. Finding important data mixed in with all the other things a computer XORs would be much harder.
        fluoridation 3y ago
        The CPU would "just" need to look at all executable pages to find binaries of common AES implementations, and when it finds one it could wait for the key to be loaded and then exfiltrate it. It could also detect (although at greater effort, possibly much greater) when you're using it to compile AES and inject spying code into the output, even if the target is a different architecture. If the attacker has access to your computer, you've already lost. If the attacker built your computer, it was never even a fight.

baxuz 3y ago

Bitlocker is Microsoft's closed-source product. How can you be sure it doesn't have backdoors?

shim__ 3y ago
That question is pointless if you're using windows
- huhtenberg 3y ago
  In practice, it is most certainly not pointless. Given two USB drives, one encrypted with BitLocker and another with TC or VC, chances of master key recovery by Microsoft are definitely not the same.
  - maccard 3y ago
    > In practice, it is most certainly not pointless .... chances of master key recovery by Microsoft are definitely not the same. I don't think those two sentences hold water when put together. In practice, if your risk is master key leakage and theft of the encrypted data by microsoft, you shouldn't be using windows. If you suspect that, MS can have a kernel mode driver masquerading as anything else, and it can just siphon your master key whenever you enter it.
    - DarkmSparks 3y ago
      And now that ms auth is apparently mostly compromised, extend microsoft to any threat actor in the wild. I like VC for the portability of the encrypted .tc files. Keep all my backups as tc files, and recovered from more than one failure using them. Once had an issue where dropbox corrupted the duplicates, so dont use dropbox anymore.
      - Jerrrry 3y ago
        >ms auth is apparently mostly compromised just gonna drop that like that aint a $10k+ implication, gonna need a src or ref thanks unless you mean by 3letters, which dont exactly give their backdoors to randoms. randoms aint coming across 3letter's backdoors, not active/modern ones anyway