7

Since the future of TrueCrypt appears to be still unclear, I figured I'd try to get my stuff migrated into BitLocker at least for the time being. I nearly never have to access my encrypted data from anything that's not BitLocker-capable, so cross-platform compatibility isn't a big deal to me at this time.

However, I am having a bit of an issue understanding the minimum requirement of a 64 MB volume. With TrueCrypt, I was able to protect small files (and most of my protected files are fairly small) in containers down to 300 KB or even less. When I finally created a VHD of an appropriate size last night (100 MB), it seemed the file system itself only took up about 3 MB and encrypting it with BitLocker didn't appear to take up any more.

While 3 MB is still an order of magnitude larger than the smallest volume I could make with TrueCrypt, it's still relatively reasonable in comparison to 64 MB. This is an especially large amount of overhead (and largely wasted at that, since it's mostly empty space for now) when I consider that some of these volumes will be stored and synced in the cloud.

What possible reasons could BitLocker have for needing volumes to be 64 MB large, when it's not even appearing to use that space?

BitLocker FAQ on TechNet

Iszi
  • 13,775
  • 2
    The present of BitLocker is much more unclear. I would recommend to stay on TrueCrypt 7.1a and not upgrade until the situation is really clarified. – dolmen Jun 02 '14 at 21:13
  • I've skimmed through the official BitLocker documentation, and apparently the reason for such requirement is not explained anywhere. – and31415 Jun 02 '14 at 21:16
  • 1
    I did some tests, and I found out that the documentation isn't entirely correct. A volume is deemed too small to be protected when its size is less than 55 MiB (57671680 bytes). After further research it turned out the value is hard-coded in the fveapi.dll library file. For what is worth, by using 58 MiB VHD containers, you could save up to 10% space: http://i.stack.imgur.com/Bunxx.png – and31415 Jun 03 '14 at 09:56
  • 1
    @and31415 Thanks for the information. Now the question still remains open as to what technically justifiable reason there is for this. – Iszi Jun 03 '14 at 14:15
  • Iszi, I think there is no such reason. MS considers drive-level encryption to be a different market segment from file- & folder-level encryption, and uses this arbitrary limit to encourage that. To be honest, I kinda agree. If you're really worried about wasted space, the unnecessary overhead of MBR, FAT, etc is a reason you shouldn't be using BitLocker for small containers. – Foo Bar Jul 03 '14 at 16:21
  • @FooBar Perhaps, but BitLocker imposes much more unnecessary overhead by far than the file systems do. And, since TrueCrypt has been abandoned (at least until someone forks it) I'm not aware of any other reasonably trusted and free file/container encryption software that's being actively maintained. – Iszi Jul 03 '14 at 18:45

2 Answers2

1

The limit is probably for marketing/branding rather than technical reasons. BitLocker's purpose is to encrypt entire drives, rather than individual files or folders. Microsoft wants people to use Encrypting File System instead for file-level security.

p.s. Considering the smallest flash sticks you can buy these days are 8 GB, 64 MB ought to be little enough for anyone.

Foo Bar
  • 468
1

My guess on this one is that the overheads related to encrypting a volume using BitLocker are slightly under 64 MB, hence this lower limit, otherwise the overheads would exceed the size of the volume. These overheads include any metadata as well as some temporary space used while files are being encrypted.

  • In fact a 64MB drive seems to have 40.9MB of free space once it has been formatted and has Bitlocker on it. – gordon613 Jun 19 '16 at 15:11