Very bad performance on NVME SSD

[stylersnico]

Hi,

Please don't take that as a complain, I only wish to help improve the software so I can use it.

I achieve very bad performance on Windows 10 LTSB 2016 with a Samsung EVO 960 250Gb and Veracrypt AES encryption:

Before :

After :

My hardware :

I7 7700k @ stock 16Gb Corsair DDR4 Samsung 960 Evo 250Gb with up to date Samsung NVME driver Windows 10 LTSB 2016 up to date Veracrypt 1.19 64 bits

Veracrypt Benchmark :

How can I manage to get close performance to non encrypted drive ? Is this even possible ?

Thanks and best regards, Nicolas

[ghost]

It is problem not only for SSD. I got the same problem with 2.5'' SSD and HDD with hardware RAID0. Very low IOPS... 3-10 times less depending on hardware. Common symptom: writing is less affected than reading.

Due to this issue CPU speed does not make a lot of sense to estimate how fast disk encryption will be. So it would be very good if somebody can help to at least understand the reason.

UPDATE

I had to switch my storage system to DiskCryptor solution due to this issue.
It has approximately the same speed as unencrypted volume.
Hardware HDD RAID0 with on-board RAM cache gives me 10 times more read IOPS and +170 MB/s for linear read speed. Single SSD setup has 8 times more IOPS and + 90 MB/s for linear read. So I can say it is 98% of "raw" speed.

The only drawback of DiskCryptor for me is no audits.
But I cannot accept so dramatic speed regression even if VeraCrypt is successor of TC and it was audited. I read some opinions that TC was also slow on fast SSD disks. So I afraid it is some architecture problem initially created in TC.

[RcTomcat]

Is there any news on this matter? It seems the iops still decrease drasticly.

[stylersnico]

@RcTomcat Unfortunatly I think it's not gonna change. If you want strong encryption it's the price to pay :/

[InSys]

No news on this task? I have the same problem:

Without encryption (Windows 10, samsung ssd 960 evo m2 500gb):

With encryption (AES, mounted file container)

As you can see in the screenshots - the speed is less than 10-20 times. read more

Are there ways to solve this problem?

[304NotModified]

@inSys I'm curious how DiskCryptor performs on your system.

[tomasz1986]

I have the exact same issue, just on regular SATA SSDs.

DiskCryptor and BitLocker both perform very well (maybe ~5-10% decrease in the disk I/O), but performance with VeraCrypt is just abysmal. And yes, it is noticeable in normal workload, especially when operating on many small files at once. For this reason I have been using BitLocker for now (because DiskCryptor seems abandoned and does not support GPT).

I do not have top-notch hardware here but still... (AMD A10-7860K, 16GB RAM, 2 x SanDisk x110 256GB, Windows 10 LTSB 2016).

[InSys]

@304NotModified

Comparison of VeraCrypt and DiskCryptor on SSD: As you can see, the performance is practically not degraded by DiskCryptor, but on VeraCrypt the performance drops in many times.

Click to view comparison of VeraCrypt and DiskCryptor on HDD

In order not to create a real HDD partition, I used a standard windows virtual disk real placed on single HDD: The degradation in performance on single HDD is not noticeable.

[nshtg]

Is there any effort to fix those ridiculous performance penaltys? Affect normal SSDs aswell not only NVMe ones.

[valnar1]

I noticed the same thing on a new laptop I planned to encrypt. I've loved TrueCrypt and VeraCrypt for a while now, but due to time constraints had to buy BestCrypt. I hope the devs get this figured out.

[ghost]

@tomasz1986

because DiskCryptor seems abandoned and does not support GPT

Why do you need GPT if you do not have partition more than 2TB? Even large array are possible with RAID controllers (including integrated RAID). Just create 2 disks: 1st - MBR (for booting, small up to 2TB), 2nd - GPT (any size).

[dartraiden]

Why do you need GPT

GPT is required for disabling CSM, And disabled CSM is required for SecureBoot.

[NameTheJew]

BUMP. Is this still an issue? Will using VeraCrypt FDE seriously drop write speeds down to 1MB/s? Is there a Fix?

Also how is Trim and Provisioning effected when software FDE is implemented?

[CrownVic2]

I just encrypted my system drive with VeraCrypt (ver 1.23) on the almost identical HW configuration as listed in the first post. I see the same slow read speed in Samsung Magician and in CrystalDiskMark. Sequential read is down to 20% . Bitlocker compared to no-encryption is almost identical.

Now the good news. When I measured the real-time for programs to open, there wasn't much of a difference. Lightroom and Photoshop both take approx 2 seconds to be ready, just like with no encryption. Starting another windows 10 from Oracle VM VirtualBox takes 21.5 seconds with no encryption and 23 seconds with Veracrypt.

All programs are installed on my Samsung EVO 960 500GB and the startup time for each program is measured after a fresh system reboot.

[valnar1]

I know it costs money, but I'm very happy with BestCrypt. Also, the older DiskCryptor works great for a MBR SSD if you don't mind disabling UEFI and all the modern settings.

[ghost]

yeah but who wants to use something not open source to secure their shit

[valnar1]

Most people. We use Sophos Safeguard at work. Many use CheckPoint FDE. I build VPN's with Cisco, Fortinet, Palo Alto all day long. AES is a standard. Being open source is irrelevant.

[ghost]

Most people. We use Sophos Safeguard at work. Many use CheckPoint FDE. I build VPN's with Cisco, Fortinet, Palo Alto all day long. AES is a standard. Being open source is irrelevant.

Such tools like FDE, encrypting messengers and so on MUST be open source!

P.S. Let's stop flooding here.

[bxkx]

I've just ran into the same problem. Unfortunately I can't see a solid alternative... Bitlocker isn't available on all Windows versions and DiskCryptor is dead.

Btw, does your SSD also show a disk activity of 100% when only writing about 20 MB/s with a response time of a couple of thousands ms? I do have this problem when moving things from a HDD to encrypted SSD.

[valnar1]

bxkx, the people here would tell you not to use Bitlocker. Cuz it's not open source. sigh...

[ghost]

Plus bitlocker uses hardware-based encryption... which has it's own problems.

https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-encrypt-your-ssd-on-windows-10/

[idrassi]

VeraCrypt tends to be slower for random read/write access because of its driver architecture and the way it handles IRP for I/O.

Because VeraCrypt supports file containers (which is not the case of DiskCryptor and Bitlocker), it can not handle IRPs in place and it must create a new IRP to the holding file for every read and which in turn causes a thread context switch. This explains the performance drop.

VeraCrypt uses the same IRP logic for both file containers and disks. Ideally, we should handle IRP in place for disks without context switch to have maximum performance and this requires a big architecture in order to keep both IRP logic working at the same time (a user can mount a file container and a disk simultaneously).

Some time ago I have implemented a prototype with a dual logic for file containers and disks but there was huge stability and reliability problems and I could find an easy solution for them.

Clearly the next version of VeraCrypt must address this and I hope there will be enough resources to work on this. Of course, external help is welcomed for such complex technical task especially that we want to keep file containers support.

[ghost]

@idrassi thank you for the explanation!

[ghost]

It explains a lot, but regarding this:

VeraCrypt tends to be slower for random read/write access

All my above posts are about sequential read and write. So most likely it is also affected in some way by context switching. I am using Far Manager to measure real file reading (to nul device or to another physical disk).

[JsBergbau]

Is there any update about the issue / an estimated release date for solving this issue? VeraCrypt is a great software and I would never trust Bitlocker in any way.

EDIT: So if there would be two different IRP paths the performance suffer would still exist for containers. So If you have for example a D: drive on a fast storage you should not create there a container and mount it, but instead encrypt the whole device and mount that for maximum performance. Right?

[daiveedx]

Bonjour @idrassi, based on your comment about IRP, what about having 2 separate "versions" of Veracrypt, one that supports both disk and file as you envision and one that implements IRP in place, supports only disk container and doesn't incur such performance loss. Users could then have the choice. I've been using Veracrypt with joy for so long but the more I invest in high-perf SSD the more I feel the pain of performance loss :( Would you give guidelines to potential contributors on where exactly to look in the code for such separate implementation? Or maybe the dual logic prototype you mentioned is indeed about that?

[er1z]

@steamp0rt — it is possible to disable hardware encryption in group policy.

[fti7]

Any Updates here? This is a really high performance impact

[imennodenis]

Agree with @daiveedx comment. It would be nice to have two versions or even better to have an option while installing VeraCrypt (to support file containers or not). @idrassi, what do you think? Thanks!

[CyberGonzo]

a user can mount a file container and a disk simultaneously

What about 2 instances in memory ? One for files and one for disks. Don't know much about driver development so I may be missing the ball entirely.

[megapro17]

It's already three years and still no progress!!! Veracrypt:

-----------------------------------------------------------------------
CrystalDiskMark 5.1.2 x64 (C) 2007-2016 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

   Sequential Read (Q= 32,T= 1) :   443.195 MB/s
  Sequential Write (Q= 32,T= 1) :   401.027 MB/s
  Random Read 4KiB (Q= 32,T= 1) :    44.960 MB/s [ 10976.6 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :    87.532 MB/s [ 21370.1 IOPS]
         Sequential Read (T= 1) :   442.259 MB/s
        Sequential Write (T= 1) :   422.815 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    21.657 MB/s [  5287.4 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    53.360 MB/s [ 13027.3 IOPS]

  Test : 1024 MiB [H: 0.3% (0.1/19.5 GiB)] (x3)  [Interval=5 sec]
  Date : 2020/01/24 0:09:42
    OS : Windows 10 Enterprise [10.0 Build 18363] (x64)

DiskCryptor:

   Sequential Read (Q= 32,T= 1) :   539.805 MB/s
  Sequential Write (Q= 32,T= 1) :   506.737 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   199.227 MB/s [ 48639.4 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   210.223 MB/s [ 51324.0 IOPS]
         Sequential Read (T= 1) :   445.409 MB/s
        Sequential Write (T= 1) :   457.458 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    34.845 MB/s [  8507.1 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    78.314 MB/s [ 19119.6 IOPS]

Bitlocker:

   Sequential Read (Q= 32,T= 1) :   535.229 MB/s
  Sequential Write (Q= 32,T= 1) :   504.131 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   224.108 MB/s [ 54713.9 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   276.413 MB/s [ 67483.6 IOPS]
         Sequential Read (T= 1) :   503.674 MB/s
        Sequential Write (T= 1) :   466.702 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    32.395 MB/s [  7908.9 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    78.547 MB/s [ 19176.5 IOPS]

Without:

  Sequential Read (Q= 32,T= 1) :   537.022 MB/s
  Sequential Write (Q= 32,T= 1) :   501.266 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   178.927 MB/s [ 43683.3 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   173.009 MB/s [ 42238.5 IOPS]
         Sequential Read (T= 1) :   505.753 MB/s
        Sequential Write (T= 1) :   470.623 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    38.418 MB/s [  9379.4 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    78.865 MB/s [ 19254.2 IOPS]

As we see veracrypt sucks the most

[Protonator]

Here are my recent CrystalDiskMark 7.0.0 results with a Samsung 970 EVO Plus fresh out of the box:

Unencrypted:

[Read]
Sequential 1MiB (Q=  8, T= 1):  3576.613 MB/s [   3410.9 IOPS] <  2344.33 us>
Sequential 1MiB (Q=  1, T= 1):  2840.806 MB/s [   2709.2 IOPS] <   368.88 us>
    Random 4KiB (Q= 32, T=16):  1140.156 MB/s [ 278358.4 IOPS] <  1837.44 us>
    Random 4KiB (Q=  1, T= 1):    50.536 MB/s [  12337.9 IOPS] <    80.90 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):  3289.359 MB/s [   3137.0 IOPS] <  2546.52 us>
Sequential 1MiB (Q=  1, T= 1):  3101.017 MB/s [   2957.4 IOPS] <   337.88 us>
    Random 4KiB (Q= 32, T=16):  2668.898 MB/s [ 651586.4 IOPS] <   785.02 us>
    Random 4KiB (Q=  1, T= 1):   197.097 MB/s [  48119.4 IOPS] <    20.66 us>

Profile: Default
   Test: 1 GiB (x3) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/03/05 16:08:41
     OS: Windows 10 Professional [10.0 Build 18363] (x64)

Encrypted with Bitlocker (Software mode, XTA-AES 128):

[Read]
Sequential 1MiB (Q=  8, T= 1):  3575.815 MB/s [   3410.2 IOPS] <  2344.75 us>
Sequential 1MiB (Q=  1, T= 1):  2793.688 MB/s [   2664.3 IOPS] <   375.11 us>
    Random 4KiB (Q= 32, T=16):  1144.593 MB/s [ 279441.7 IOPS] <  1830.92 us>
    Random 4KiB (Q=  1, T= 1):    51.424 MB/s [  12554.7 IOPS] <    79.52 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):  3290.061 MB/s [   3137.6 IOPS] <  2545.71 us>
Sequential 1MiB (Q=  1, T= 1):  2643.481 MB/s [   2521.0 IOPS] <   396.38 us>
    Random 4KiB (Q= 32, T=16):  2162.285 MB/s [ 527901.6 IOPS] <   968.41 us>
    Random 4KiB (Q=  1, T= 1):   181.470 MB/s [  44304.2 IOPS] <    22.47 us>

Profile: Default
   Test: 1 GiB (x3) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/03/07 2:25:58
     OS: Windows 10 Professional [10.0 Build 18363] (x64)

Encrypted with VeraCrypt 1.24 Update4:

[Read]
Sequential 1MiB (Q=  8, T= 1):  1398.332 MB/s [   1333.6 IOPS] <  5994.17 us>
Sequential 1MiB (Q=  1, T= 1):  1275.925 MB/s [   1216.8 IOPS] <   821.47 us>
    Random 4KiB (Q= 32, T=16):    39.254 MB/s [   9583.5 IOPS] < 53087.53 us>
    Random 4KiB (Q=  1, T= 1):    19.746 MB/s [   4820.8 IOPS] <   207.26 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):  1376.346 MB/s [   1312.6 IOPS] <  6083.48 us>
Sequential 1MiB (Q=  1, T= 1):  1158.987 MB/s [   1105.3 IOPS] <   904.39 us>
    Random 4KiB (Q= 32, T=16):    29.428 MB/s [   7184.6 IOPS] < 70740.18 us>
    Random 4KiB (Q=  1, T= 1):    31.237 MB/s [   7626.2 IOPS] <   130.97 us>

Profile: Default
   Test: 1 GiB (x3) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/03/05 16:54:11
     OS: Windows 10 Professional [10.0 Build 18363] (x64)

[ghost]

@megapro17 I think he did it for some stats.
Though your stats @Protonator is wrong. CrystalDiskMark never shows correct result.
The most correct way to test SSD on Linux and Windows without hitting OS cache is using fio.
But only in combination with pre-allocated files and when cache is dropped (sync on Linux and Empty Standby List in RAMMap tool on Windows).

[sergeevabc]

@hardhub, I managed to grab RAMMap and Fio for Windows. The latter is a CLI utility with a lot of switches, definitely a scary sight to begin with. Would you care to advise on how to proceed?

[ghost]

@hardhub, I managed to grab RAMMap and Fio for Windows. The latter is a CLI utility with a lot of switches, definitely a scary sight to begin with. Would you care to advise on how to proceed?

OK

1) Put fio to drive which you want to test. 2) Run test, for example 4K, 1 thread (real random reading most valuable for all programs except video cutting).

fio --name=randread --iodepth=1 --rw=randread --bs=4k --direct=0 --size=4G --numjobs=1 --runtime=30 --group_reporting

3) After test finished you will see files for tests created in the same directory as fio itself. Do not delete them, so fio will not create them again on next start. 4) Go to RAMMap tool. And clear OS disk cache. To do that use this menu item:

5) After that run fio once again.

6) So in No 5 you will make "cold run". If you will run it twice it will not be cold-run anymore and may differ.

My own example:

First run when files are created and then read immediately (4K test):

randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=windowsaio, iodepth=1
fio-3.1
Starting 1 thread
randread: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=169MiB/s,w=0KiB/s][r=43.4k,w=0 IOPS][eta 00m:00s]
randread: (groupid=0, jobs=1): err= 0: pid=9268: Sun Mar 8 22:19:22 2020
   read: IOPS=45.1k, BW=176MiB/s (185MB/s)(4096MiB/23251msec)
    slat (usec): min=7, max=490, avg=14.65, stdev= 7.53
    clat (nsec): min=260, max=570637, avg=6541.01, stdev=5751.03
     lat (usec): min=12, max=599, avg=21.19, stdev= 9.57
    clat percentiles (usec):
     |  1.00th=[    6],  5.00th=[    6], 10.00th=[    6], 20.00th=[    6],
     | 30.00th=[    6], 40.00th=[    6], 50.00th=[    6], 60.00th=[    7],
     | 70.00th=[    7], 80.00th=[    7], 90.00th=[    8], 95.00th=[    9],
     | 99.00th=[   12], 99.50th=[   14], 99.90th=[   45], 99.95th=[   77],
     | 99.99th=[  359]
   bw (  KiB/s): min=165824, max=240616, per=100.00%, avg=180448.46, stdev=22282.35, samples=46
   iops        : min=41456, max=60154, avg=45112.11, stdev=5570.59, samples=46
  lat (nsec)   : 500=0.08%, 750=0.22%, 1000=0.03%
  lat (usec)   : 2=0.02%, 4=0.08%, 10=97.75%, 20=1.65%, 50=0.08%
  lat (usec)   : 100=0.05%, 250=0.02%, 500=0.02%, 750=0.01%
  cpu          : usr=8.60%, sys=64.52%, ctx=0, majf=0, minf=0
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=176MiB/s (185MB/s), 176MiB/s-176MiB/s (185MB/s-185MB/s), io=4096MiB (4295MB), run=23251-23251msec

Second run when files are existing but cache is cleaned by RAMMap (4K test):

randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=windowsaio, iodepth=1
fio-3.1
Starting 1 thread
Jobs: 1 (f=1): [r(1)][100.0%][r=25.8MiB/s,w=0KiB/s][r=6594,w=0 IOPS][eta 00m:00s]
randread: (groupid=0, jobs=1): err= 0: pid=12980: Sun Mar 8 22:22:25 2020
   read: IOPS=6027, BW=23.5MiB/s (24.7MB/s)(706MiB/30001msec)
    slat (usec): min=57, max=10359, avg=155.80, stdev=43.14
    clat (nsec): min=260, max=856476, avg=8381.18, stdev=9191.83
     lat (usec): min=63, max=10374, avg=164.19, stdev=45.56
    clat percentiles (usec):
     |  1.00th=[    4],  5.00th=[    6], 10.00th=[    6], 20.00th=[    6],
     | 30.00th=[    7], 40.00th=[    7], 50.00th=[    7], 60.00th=[    8],
     | 70.00th=[    8], 80.00th=[   12], 90.00th=[   13], 95.00th=[   15],
     | 99.00th=[   20], 99.50th=[   24], 99.90th=[   68], 99.95th=[  120],
     | 99.99th=[  388]
   bw (  KiB/s): min=18256, max=26608, per=99.84%, avg=24072.95, stdev=3446.57, samples=59
   iops        : min= 4564, max= 6652, avg=6018.24, stdev=861.64, samples=59
  lat (nsec)   : 500=0.04%, 750=0.25%, 1000=0.10%
  lat (usec)   : 2=0.38%, 4=0.36%, 10=74.55%, 20=23.43%, 50=0.72%
  lat (usec)   : 100=0.09%, 250=0.04%, 500=0.02%, 750=0.01%, 1000=0.01%
  cpu          : usr=0.00%, sys=23.33%, ctx=0, majf=0, minf=0
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=180841,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=23.5MiB/s (24.7MB/s), 23.5MiB/s-23.5MiB/s (24.7MB/s-24.7MB/s), io=706MiB (741MB), run=30001-30001msec

It is needed to get correct results with fio.

--

And now a bit about CrystalDiskMark.

I have difference between CrystalDiskMark and fio in 30%. CDM shows better values.

So why fio? My opinion that: 1) It has stable results. Sometimes Crystal Disk Mark shows significantly different values. 2) SQLIO looks closer to fio. I assumed it shows more correct values. 3) And of course I can see all details including IOPS so why do I need CDM then? ))

Also it is important to know that I am using DiskCryptor and do not have unencrypted partitions for moment (though tested before).
DiskCryptor impacts 4K performance (but much less than TrueCrypt).

So if I you have another results on Encrypted / Unencrypted partitions you are welcome.
It will be interesting to read if I am wrong and CDM is good (especially latest versions which not tested by me).

[inliquid]

I have a ridiculous ~50 times drop in drive performance (concurrent random read) after encrypting it with just AES. i7 9700 32 GB WDC 1TB NVMe

Before (first run):

After (first run):

In simple words it means that it turns multi-threaded system into single-threaded when it comes to real world drive i/o. I have been using VeraCrypt for years but still not addressing this issue is insane. Will go for anything alternative.

[megapro17]

@inliquid just use bitlocker

[Noob567]

Has anyone tried creating a system partition of half of the size of SSD and encrypting it instead of encrypting the whole drive? Maybe that could improve performance since lots of SSD sectors will be left empty for "swapping data during read/write operations"? Can't find any research on that but it's worth to experiment with that maybe?

[ThinkingMonkeyv2]

@Noob567 While I'm no crypto expert or know anything really except to accomplish whatever problem it is I'm trying to solve at the time, it's my understanding that doing what you mentioned is a horrible idea.

SSDs will write to areas that have no partition at all (see "overprovisioning", but it's nothing more than an unpartitioned space on the drive, usually 10-20% of the drive capacity). So to divide the drive into 2 or more partitions and encrypt only the OS one, it's not only possible but likely that the system will write (at least temporarily, but that's way too long) files or parts of files to one of the un-encrypted partitions (or even to a part of the drive where there is no partition), thus leaving stuff that's well encrypted on your OS partition and locked tight to be perfectly in the clear some other place on the drive.

This data is then trivial to recover. I used to work for a law enforcement firm doing forensic data recovery for them, and publicly available software (some free, some expensive) can recover the data even after all the partitions are destroyed. If I did that to your drive, your OS partition files will be gibberish, of course, but I might very likely find those secret files of yours some other place on the drive. Again, partition or no partition makes no difference because SSDs write "all over the place".

Just like everything else to do with computers and the Internet in general, the information you find depends on where you look and who you believe.

For example, Tom's Hardware says "Unless the drive gets near being full there is no benefit to overprovisioning. Making sure you never fill the drive has the same effect as over-provisioning." implying data never (or has any reason to, anyway) gets written outside its own partition.

Whereas Seagate says "SSDs periodically go through a process called garbage collection to clear out invalid pages of data. During this process, the SSD controller, or flash controller, that manages NAND flash memory in an SSD, reads all the good pages of a block (skipping the invalid pages), and writes them to a newly erased block. Then the original block is erased, thus preparing it for new data. All SSDs reserve some amount of space [overprovisioning] for these extra write operations, as well as for the controller firmware, failed block replacements, and other unique features that vary by SSD controller manufacturer." implying that SSDs can very well write to unencrypted places on the drive.

With that in mind, and with experiences I've had, personally, my OS drive will not be overprovisioned, and the drive will be encrypted all or nothing.

Edit to add a final note: Someone smarter than me will have to address this for you but Seagate also mentions that due to the fact that "Many people are blissfully unaware that one gigabyte (GB) is precisely 1,000,000,000 bytes, and one gibibyte (GiB) is precisely 2^30 = 1,073,741,824 bytes, or about 7.37% more than a GB." and that 7.37% difference is used as a "built-in" space in which to do garbage collection, etc. This space is presumably not able to be reduced to zero by the user. This leads one to believe (me, anyway) that SSDs can never be made perfectly secure even with FDE.

Or perhaps they can. My ex-wife tells me that I'm not very smart and she is in fact a paragon of wisdom, judgment, and reason.

[ghost]

I switched from BitLocker to VeraCrypt and I am pretty happy, except for this issue. While it's not bad enough for me to switch back (open source is great, performance is bearable), it is bad enough for me to pony up some cash to help move this along.

I don't see VeraCrypt on IssueHunt, but I'm willing to put $300 in escrow for this to be fixed and pulled.

Any takers? @idrassi? :smiley:

[Noob567]

Thanks for the anwers. I'm also willing to give some cash, provided that it's gonna be REALLY fixed once and for good. Is anyone aware btw what causes that much hindered performance?

[tonyrulez]

Any update on this? As I could put it together, the problem is with the ability to use containers, which impacts badly the full drive encryptions, and this could be solved by having an other version of VeraCrypt that supports only full drive encryption. Was going to encrypt my laptop with VC, however findig this years old thread did stop me from that. DiskCryptor speeds look great, however the last stable build is from 2016 and the latest beta build installer is instantly deleted by Windows Defender.

Would love to have a VeraCrypt version with disk-only encryption and BitLocker/DiskCryptor speeds.

[Noob567]

Why should container support have impact on full-disk encryption speed?

[tonyrulez]

I read it here and also on Sourceforge. Maybe container support is not the problem, but definitely a setback:

This issue is still open. As Alex explained, it requires changes on the driver handling of IRP which is not trivial and unfortunately, file container support make things complicate for any change of this part.

Currently I'm think of creating a different version of VeraCrypt driver that is dedicated to disks and so we can have more freedom about the implementation of the driver. And the user can switch between a "file contaner+ disk" driver and "disk only" driver using an option in the UI. source

And also https://github.com/veracrypt/VeraCrypt/issues/136#issuecomment-443522115

[ghost]

I read it here and also on Sourceforge. Maybe container support is not the problem, but definitely a setback:

This issue is still open. As Alex explained, it requires changes on the driver handling of IRP which is not trivial and unfortunately, file container support make things complicate for any change of this part. Currently I'm think of creating a different version of VeraCrypt driver that is dedicated to disks and so we can have more freedom about the implementation of the driver. And the user can switch between a "file contaner+ disk" driver and "disk only" driver using an option in the UI. source

And also #136 (comment)

Why not use 2 drivers at the same time? 1 per each type of storage (disk/container)?

[ThinkingMonkeyv2]

Why should container support have impact on full-disk encryption speed?

@Noob567 The developer, Mounir Idrassi, explained in a post above in a very simple fashion exactly precisely why container support hinders full-disk encryption speed:

TL;DR: Thread context switching.

To quote: "VeraCrypt tends to be slower for random read/write access because of its driver architecture and the way it handles IRP for I/O.

Because VeraCrypt supports file containers (which is not the case of DiskCryptor and Bitlocker), it can not handle IRPs in place and it must create a new IRP to the holding file for every read and which in turn causes a thread context switch. This explains the performance drop.

VeraCrypt uses the same IRP logic for both file containers and disks. Ideally, we should handle IRP in place for disks without context switch to have maximum performance and this requires a big architecture in order to keep both IRP logic working at the same time (a user can mount a file container and a disk simultaneously)."

[inliquid]

This "explanation" does not explain 50 times drop in concurrent random read. "Bad architecture" in general does, but looks like exact place is still to be discovered.

[daiveedx]

Bonjour @idrassi ,

We got it from your last message on this thread (pretty active recently btw ;) that you were willing to keep support for both container and file at the same time in Veracrypt. However, wouldn't you consider the possibility of an additional "container only" version of VC that focuses on performance with that IRP in place implementation you mentioned? People could then just choose their version based on the use case :

• Performance for "container only" users
• Flexibility and comfort for "file or mixed" users

Your message mentioned the architecture / challenge for dual IRP logic was complex, but is that the case for pure IRP in place appproach? Would it be doable by volunteers with your guidance? I have no specific expertise in driver development but I'm happy to help somehow ... (I've checked the IRP part of the driver code, and I have the remote feeling that it's a doable thing ...)

Veracrypt is a jewel in the "encryption world", it feels like the removal of that performance hit would make it the "youkounkoun" ;)

[JsBergbau]

Because VeraCrypt supports file containers (which is not the case of DiskCryptor and Bitlocker),

Bitlocker supports Filecontainers that way, that you create a virutal VHD(X) harddisk and enable bitlocker on that disk. Perhaps this is also an option for VeraCrypt file containers.

[AdiK87]

This issue made me switch from VeraCrypt to BitLocker. Would happily switch back when this is resolved....

[DeVIL-I386]

tomasz1986 commented on 15 Apr 2018

because DiskCryptor seems abandoned and does not support GPT

bxkx commented on 2 Dec 2018

and DiskCryptor is dead.

DavidXanatos takes care of DiskCryptor maintenance since December 2019. Since January 2020 UEFI is also supported. Of course he is happy about donations.