I have flash drive with LUKS partition. I have created it by cryptsetup in Ubuntu with 4096 bytes key. Key stored in file. I use LibreCrypt version 6.2, downloaded from github and try to open my flash drive in Windows 7 (64 and 32 bit versions). In both versions i get error:
"Unable to open container. Please check your keyphrase and settings, and try again."
FreeOTFE version 5.21 opened this flash with the same key without any problems.
Maybe my key file need to be in some special format for LibreCrypt?

P.S. Sorry for my english.

Hello,

from the docs it seems we should be able to mount LUKS partitions :

Extract from https://github.com/t-d-k/doxbox/blob/master/docs/Linux_volumes.md

Mounting Volumes Created under Linux

Select "File | Linux volume | Mount file.../Mount partition".

But I dont see the "Mount partition" option in the menu, only "Mount file..." and "Mount file (hidden)..."

Other info on my environment :

• DoxBox 6.0 Beta
• Windows 7 64 bits

Am I missing something ?

When I install the program, open it and click on New button, to create a new container, it complains that MSVCR100.dll is missing.

Still, otfe container can be created and mounted without any issues.

I installed both
Microsoft Visual C++ 2010 Redistributable, and
Microsoft Visual C++ 2015 Redistributable

but still the program complains about MSVCR100.dll missing.

I searched the C drive for MSVCR100.dll and found it.

Why does the program complains about the file even when it is present after installation.
Please include MSVCR100.dll with setup or link it during setup .

I'm using Windows7 64bit Ultimate edition.

Support for EcryptFS, a popular file-based in stead of disk-based encryption method popularized by Ubuntu and children, would add popular possibilities such as encrypting part of a memory stick without sparse files or dedicated partitions, or having documents encrypted on cloud services such as Dropbox in a Linux compatible manner.

ref: #18

It still doesn't work =(
It tells me that my volume has been mounted , but in Windows Explorer the Volume has 0 bytes in size.

This is what i see in the Open LUKS partition dialog ( the partition with 930,79 GB is my LUKS one)

This are the LibreCrypt Container Properties after 'mounting':

And this is the end of the cryptsetup-Style dump:

Master Key

User supplied password : [omitted]
Password unlocks key slot: 0
Recovered master key :
00000000 | 3F 3F 3F 3F 3F 3F 3F 3F | ????????
00000008 | 3F 3F 3F 3F 3F 3F 3F 3F | ????????
00000010 | 3F 3F 3F 3F 3F 3F 3F 3F | ????????
00000018 | 3F 3F 3F 3F 3F B2 3F 3F | ?????.??
00000020 | 00 00 00 00 00 00 00 00 | ........
00000028 | 00 00 00 00 00 00 00 00 | ........
00000030 | 00 00 00 00 00 00 00 00 | ........
00000038 | 00 00 00 00 00 00 00 00 | ........

unfortunately this is not my luks master key :/

I am using Windows 10 64-bit and I am experiencing slow mount times.

The 100 MiB block file blkdev.vol was created in Debian Testing using

# cryptsetup -v --cipher aes-xts-plain64 --key-size 256 --hash sha256 --iter-time 2000 --use-urandom --verify-passphrase luksFormat blkdev.vol

(i.e., the default luksFormat options)

It takes 5-10 seconds to mount the volume in Windows.

Opening LUKS volumes seems not possible. Whenever I supply the password or keyfile I get the error

Unable to open Box.

Please check your keyphrase and settings, and try again.

The same one as if the password has been entered wrongly.

I have tried two different volumes:

Version:        1
Cipher name:    aes
Cipher mode:    xts-essiv:sha256
Hash spec:      sha256

and

Version:        1
Cipher name:    twofish
Cipher mode:    xts-benbi
Hash spec:      sha512

OS: Windows 7 x64, non-portable installation

Neither passwords nor keyfiles would work. Needless to say that I can open both volumes with cryptsetup on linux.

If I can supply any more information let me know.

Hi,
I have a problem when trying to open a container created within a container with Doxbox after forcefully closing it. Now it just gives me an error message and doesn't open. I use Librecrypt 6.2 on Windows 64x. Could someone please tell me if there is any way to recover the files within? I am a newbie so I am not good at this.
Thank you

In the end I managed to recover most of the files from another archive so it is only a minor problem now

Trying to open a LUKS-encrypted partition (GPT table) using DoxBox fails because DoxBox claims Unable to open Box. Please check your keyphrase and settings, and try again.
Testing with the luks.box from the test data everything works perfect.
LUKS dump of my partition shows

LUKS Dump

Dump Created By

Platform : PC
Application version : v6.00.00.0000
Driver ID : v5.00.0000

cryptsetup Style Dump

LUKS header information for \Device\Harddisk0\Partition8

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: b5 ad ec 33 6d d1 e4 7b f4 be 9e 4b a4 63 1f 45 5a 8b 81 ad
MK salt: 85 56 b6 94 57 e0 d0 d5 44 0d b5 70 c0 88 cc 0f
24 23 14 70 bb d2 a3 3b 75 ea ee 6b 26 0d 4a 12
MK iterations: 100375
UUID: cf2eb839-e1c1-4a4c-897b-574828b6ca85

Key Slot 0: ENABLED
Iterations: 400000
Salt: 39 50 c0 74 5d 0c 0a 3a 8b 54 fc 28 4a a1 bf 05
d8 d7 b4 9c 1c e8 fe db 3e f6 81 b6 16 72 88 ad
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Mapped FreeOTFE Drivers

Hash pretty title : SHA-1 (160/512)
Hash driver KM name : \Device\FreeOTFE\Hash{00000000-0000-0000-0000-0000000D0001}
Hash GUID : {00000000-0000-0000-0000-0000000D0002}
Cypher pretty title : AES (XTS; 128/128)
Cypher driver KM name : \Device\FreeOTFE\Cypher{00000000-0000-0000-0000-000000010001}
Cypher GUID : {00000000-0000-0000-0000-000000010202}
Sector IV generation : 32 bit sector ID

Master Key

User supplied password : funnypassword
No master key could be recovered with the specified password.
Needless to say that the password works as a charm under Linux. ;)

Hi,
I could not find (in the repo and librecrypt.eu) any signature for release files as mentioned in the Documentation.

I finally managed to import the PGP key from a key server with the Key-ID from the release page :
gpg --keyserver pool.sks-keyservers.net --recv-keys AD44979A
and verify the release files using GPG.

But it could be good to give the keys/files (.asc, .md5...) here instead. =)

Thanks.

Good job TDK, many thing have been sorted out! Here are some more tips to consider for further improvement:

• check for update feature still doesn't work in LC Explorer

• pls add in Options feature "Save window layout on exit", similarly as it is with LC Explorer. The new box-shaped LC's main window is just ugly and any shape/position customization is lost on exit

• pls do consider making these changes to button captions:

  • change "Open file" to "Mount file"
  • change "Open partition" to "Mount partition"
  • change "Lock all" to "Dismount all"

  apply all the above also to menus, drop-down boxes and status bar where appropriate

  • change "Use portable mode drivers" to just "Portable mode" to make it shorter as it sets the width of all buttons to too wide (which is not nice)

• remove "Open partition" from Open file's button drop-down box as this feature has a dedicated button

• menu "Help | User guide" is non-functional. Before it loaded help pages that were included with the program (=better choice), now they load a web page showing error

• pls allow to disable the update check's query on the internet connection. For those users continually on the internet this is just a nuisance and also prevents silent update check on the program's launch if no updates are available

• when hovering over the program's icon in the systray the caption displays just "L" instead of "LibreCrypt"

• LC Explorer's About box form has overlapping text, needs better alignment (also in the main LC prog's About box - word BETA and version number are not on the same line)

• I suggest that you center the text "This software is based..." on the LC Explorer's main form's bottom (currently it's left-aligned and breaks to other line unnicely)

More to come if determined...:-)

I have noticed the FreeOTFE driver allows any app with permissions to read and write to an arbitrary position on a hardware device.

This is a security risk because it allows any program to bypass windows permissions, e.g. A user app could read from files it doesn't have permission to, or could overwrite executables that run with admin rights with malware (this may be stopped by 'Windows File Protection').

This does not directly affect the security of your containers, it means malware running on your system can gain escalated privileges. It can indirectly affect the security, e.g .malware could replace the LibreCrypt executable.

So far there are no reports of any malware doing this - LC isn't popular, so benefits from security-by-obscurity at the moment.

Analysis

The driver provides functions that allow any caller to read or write from anywhere on any hardware device.
The main reason for these functions is to allow containers to be created without admin rights. The Windows API already has calls to read and write directly to a device, but obviously these need administrator rights.

Solution

The right thing to do long term is to move the logic that creates volumes into the driver from the GUI. This would mean volumes could still be created without admin rights but arbitrary apps couldn't overwrite with arbitrary data.
The driver would have to have logic to make sure the data being accessed was inside the volume opened/created. Malicious apps could still trash your disk, by creating a volume on it.
Making this change could take a while, because I would need to write a test harness for the driver code before making major changes. It will probably be impossible to do this with formats that don't store the volume size in the header - e.g. FreeOTE and dm-crypt. Meanwhile this weakness should be fixed.

The reason for reporting this issue is to get feedback from the community on the best way to fix it in the medium term.
There are 3 options:

1. Leave as is.

Any PC with LC installed will be vulnerable to privilege escalation by any malware on it.

2. Remove the call that allows arbitrary writing from the driver, but leave the call that allows reading.

Reading and writing to file-based volumes will use the standard windows calls, which do not need admin rights. Reading is used in opening volumes, so this should remain in the driver.

This will mean that to create partition/whole disk containers of any type you will need to run LC as administrator, but you will still be able to open all containers as normal, both file and disc based. You will be able to create file-based containers without administrator rights. Malware will be able to read any data on any disc but not write to it.

3. Remove both the read and write functions from driver.

Malware will not be able to read or write except as windows permissions allow (i.e. there will be no additional weakness). Creating and opening file based volumes will be as now, but you will need will admin rights to both create and open partition based volumes.

LC explorer is not affected by this issue or any fix.

Even these 'medium term' fixes will take time, so for now be especially careful not to run untrusted programs on a machine with the LC driver installed.

When mounting a LUKS partition, we need to enter the key. This is a complex string that no one remembers by heart.

LUKS saves this key in the partition header, encoded with a password or passphrase. There can be up to 8 passwords that resolve to the same key.

However, none of these passwords actually work when trying to mount in LibreCrypt. Does this mean that LibreCrypt is skipping the password slots and is expecting the actual key?

Also in Linux, the LUKS volume cannot mount with a wrong password. In LibreCrypt, the volume mounts just fine, but the host OS thinks it needs formatting.

Hi,
I have a rather special use case: I'm using a OpenGPG smartcard for most of my crypto operations, as it is more convenient for me than PKCS#11 (which I would almost exclusively use for gpg in the end... ;) )

So in Linux, I just call cat key.gpg | gpg | cryptsetup open /dev/sdb2 crypted and I'm golden.

Now I've stumbled over doxbox, and I'm really excited that I can access my encrypted device from windows, too.

But right now, to use doxbox, I would have to create a ramdisk, decrypt my keyfile there (which would at least keep it from the disk, but still potentially leak it to running software) and then use that keyfile with doxbox. Not really the use case I am intending.

So what I'm asking for is:

• would it either be possible to add the option to execute a program to get the key to the gui
• or add a switch to the command line tools to either execute a command for the key or read stdin?

I've written a similar patch for encfs4win, but my c++ sucks (really hard) and it never got reviewed/integrated (as that project seems to be dead), so I can't say much for the quality. Maybe it can be partly salvaged, either by you or I can try to integrate it myself if you can give me some hints on where to start to do it myself.
That commit can be found here: phryneas/encfs4win@ece8c18

(on an unrelated sidenote: where do I get the CLI tools? they are mentioned in the FAQ but not installed with the default installation - do I have to compile them myself?)

During volume creation, got an error that the app was unable to create enough random data with Windows Crypto library and to choose a different method.
Running Windows 10, version 1511 (OS build 10586.218), LibreCrypt version v6.2.00.0000 BETA 0.
Started to create a 200GB volume on a relatively empty 2TB spinning disk.
The process ran for a few hours before I left it overnight and came in with the error mentioned above. When I closed that dialog, the attached dialog was displayed. Sorry I didn't capture the first dialog...

After I wondered if the original author of FreeOTFE had disappeared when I couldn't get in touch, I started using a virtual machine running Ubuntu to mount my LUKS drive as a virtual share in Windows.

This is tedious, and I accidentally stumbled upon DoxBox LibreCrypt today, so I thought I'd bring back my quest to get the FreeOTFE DoxBox LibreCrypt drivers signed.

What I was originally trying to suggest to Sarah Dean (FreeOTFE author) is to ask these guys to review the code and help with driver signing: http://reactos.org/wiki/Driver_Signing

The ReactOS Foundation has a VeriSign code signing certificate that can be used to sign 64bit drivers for Windows. The Foundation is prepared to assist other open source projects that wish to distribute 64bit drivers but are not able to acquire a code signing certificate by signing their drivers. However, this offer is contingent on fulfilling the following conditions.

• The Foundation will only sign open source drivers.
• ...

If stable releases could be signed, the software would be more convenient and easy to use, and gain popularity.

It would be great to have a non-intrusive integration the way LUKS devices are handled in Ubuntu or regular non-encrypted devices in Windows. Especially the "Eject put device name here" from "Safely Remove Hardware and Eject Media" in the taskbar and "Eject" in Explorer's context menu would relieve some of the burden introduced by the current UI.

Same goes for mounting devices: Ideally you wouldn't need to click to get the password challenge (again, like it is done in Ubuntu). The next best two improvements are IMO:

• Remember the file system(s) that were previously mounted and immediately select the appropriate tab on "Open partition Box".
• Stop displaying the mount confirmation dialog.

I've create two LUKS partitions (with defaults) 20Gb both under Ubuntu 15.04: first on internal SSD with GPT, second on external HDD with MBR.
#1. EE: Unable to open container.

Please check your keyphrase and settings, and try again.
This error appears when I try to open one any LUKS partitions via
File / Linux container / Open LUKS partition...
#2. EE: LUKS container could not be created

Got this error when trying to create new LUKS via New... / New LUKS ...
#3. EE: Overwrite of data FAILED

Got this if on Stage 8 in New Container Wizard the "Type of overwrite data" is set to "Secure pseudorandom data"

Creation summary:

Partition: \Device\Harddisk1\Partition2
Container size: 21472738816 + 512 (for CDB) = 21472739328 bytes
CDB stored: At start of container file
Hash algorithm: SHA-512
  [Hash driver: \Device\FreeOTFE\Hash\{00000000-0000-0000-0000-0000000D0001}]
  [Hash GUID: {00000000-0000-0000-0000-0000000D0006}]
Key iterations: 2048
Cypher has fixed, defined blocksize; sector IVs will be used
Sector IV generation method: Null IV
A per-container IV will not be used
Cypher algorithm: AES (256 bit XTS)
  [Cypher driver: \Device\FreeOTFE\Cypher\{00000000-0000-0000-0000-000000010001}]
  [Cypher GUID: {00000000-0000-0000-0000-000000010204}]
Master key length: 512 bits
RNG: Microsoft CryptoAPI, cryptlib
Password: <entered>
Salt length: 256 bits
Requested drive letter: Use default

#4. Dump LUKS details is broken

LIbreCrypt produces that dump for both partitions:

LUKS Dump
=========

Dump Created By
---------------
Platform              : PC
Application version   : v6.2.5613.42403
Driver ID             : v5.00.0000
ERROR: Unable to read LUKS header?!

#4. FreeOTFE

At this time FreeOTFE almost successfully dump LUKS details from both partitions (only Master Key couldn't be recovered from drive with GPT) and could mount one of them (from drive with MBR of course)

LUKS partition on drive with GPT

LUKS Dump
=========

Dump Created By
---------------
Platform              : PC
Application version   : v5.21.00.4058
Driver ID             : v5.00.0000


cryptsetup Style Dump
---------------------
LUKS header information for \Device\Harddisk0\Partition4

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      da 91 ec 91 36 17 1e 8a 57 0c 55 8d 1b 5d e5 8b ef dc 29 44 
MK salt:        ba 56 99 84 da 7b b9 00 cc ec e3 69 4e 4d 36 af 
                b5 74 7c be ff ef a6 51 1d e2 a7 38 46 cf b8 23 
MK iterations:  121125
UUID:           263e4aeb-48c1-48bb-8ded-47145eb62930

Key Slot 0: ENABLED
        Iterations:             484847
        Salt:                   ef 04 f6 6b 05 e5 9e ad ae 48 f6 14 87 ad b6 f9 
                                67 c0 85 11 1b d0 65 23 c1 13 68 d3 b3 51 5d 55 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED


Mapped FreeOTFE Drivers
-----------------------
Hash pretty title         : SHA-1 (160/512)
Hash driver KM name       : \Device\FreeOTFE\Hash\{00000000-0000-0000-0000-0000000D0001}
Hash GUID                 : {00000000-0000-0000-0000-0000000D0002}
Cypher pretty title       : AES (XTS; 128/128)
Cypher driver KM name     : \Device\FreeOTFE\Cypher\{00000000-0000-0000-0000-000000010001}
Cypher GUID               : {00000000-0000-0000-0000-000000010202}
Sector IV generation      : 32 bit sector ID


Master Key
----------
User supplied password   : lollipop
No master key could be recovered with the specified password.

LUKS partition on drive with MBR

LUKS Dump
=========

Dump Created By
---------------
Platform              : PC
Application version   : v5.21.00.4058
Driver ID             : v5.00.0000


cryptsetup Style Dump
---------------------
LUKS header information for \Device\Harddisk1\Partition2

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      d2 ab 01 c1 9a f6 09 35 d3 a6 96 1c d6 cb 7e 40 87 c1 d8 b5 
MK salt:        3e b0 81 a5 a8 a4 0e d4 4c f8 3f f5 8d db 30 39 
                c7 97 e4 47 6f f8 1c dd 6a a4 a1 99 20 ea 3c 5e 
MK iterations:  119375
UUID:           6e97847a-a223-45d6-97b2-2d968f72148b

Key Slot 0: ENABLED
        Iterations:             488548
        Salt:                   f6 41 6f e1 41 4b 5a 2b 90 03 5f f1 05 8d 78 21 
                                0b 90 d6 38 48 03 63 32 35 16 56 fd e3 1a 0f c3 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED


Mapped FreeOTFE Drivers
-----------------------
Hash pretty title         : SHA-1 (160/512)
Hash driver KM name       : \Device\FreeOTFE\Hash\{00000000-0000-0000-0000-0000000D0001}
Hash GUID                 : {00000000-0000-0000-0000-0000000D0002}
Cypher pretty title       : AES (XTS; 128/128)
Cypher driver KM name     : \Device\FreeOTFE\Cypher\{00000000-0000-0000-0000-000000010001}
Cypher GUID               : {00000000-0000-0000-0000-000000010202}
Sector IV generation      : 32 bit sector ID


Master Key
----------
User supplied password   : lollipop
Password unlocks key slot: 0
Recovered master key     :
00000000 | BB AB 5F 91 31 DC 93 1A | .._.1...
00000008 | 29 63 83 7B 2A C2 A1 C7 | )c.{*...
00000010 | F5 BB 10 68 9A 07 4F B1 | ...h..O.
00000018 | E1 33 87 E4 51 92 7D 3E | .3..Q.}>

Currently I am attempting to use the Librecrypt CLI to send a command to mount some LUKS partitions via a script. The command I am sending is:
"LibreCrypt.exe /mount /volume .\PhysicalDrive1\Partition1 /linux /password password"

Doing this brings up an error message that I need to be an administrator to run this command, even though I already am one.

I know I am running as an admin because I start CMD as an administrator (right click, run as administrator). I've also done some other simple tests to make sure I am an admin. I can open the Librecrypt GUI as an admin to open my partition with no errors, but the CLI complains that I need to be an administrator. I can actually run some commands using the CLI, for example I believe I ran the "/count" command just fine.

Any help would be appreciated, thank you.

In the "New Container Wizard" when I select "Partition/entire disk" and click on Finish following error message appears: "Overwrite of data FAILED."

Well done with the new color interface and all the changes and bug fixes made! It's good to see this great prog alive and kicking...:-)
Here are also some observations and tips for further improvement:

• link to an update from the update check loads a Page Not Found error 404 (http://doxbox.squte.com/download.html); the download link has to be searched on the web manually
• installer speaks about v6.1 but the About box and update check about v6.01. So which version is it after all?
• minimize on start (autostart) still doesn't work; suggest to look at the workaround which was used in the latest release of FOTFE, there it worked perfectly
• pls add an option to silently check for the new version on each program's start. Many users would welcome this
• clicking on the drive letter of an opened box in the program's main window doesn't load the Explorer and returns an error (before it did load it OK)
• when opening a Box and loading the Key Dialog, pls do focus the cursor by default inside the Keyphrase memo box to easily continue with typing without having to click there beforehand. Do the same also to the first Keyprase memo box of the new Box creation wizard and allow it to jump to the second (Confirm Keyphrase) memo box on pressing Tab key on the keyboard (currently the focus/cursor quite illogically jumps to Back button)
• after autoformatting the new Box and clicking OK on finished format have the Format Removable Disk window closed automatically
• DoxBox Explorer still has an update problem: it shows "This version" as v6.01 BETA 9, suggesting to download "Latest version" v6.01, but on download and install the update check returns still the same result...

Looking back through the linux scripts and being a daily and avid luks user those ciphers are often no longer consider worth a damn... have forked and planning to start a update for the dependencies and such but lack of user defined functions and options is also less then optimal..

I created a whole drive LUKS container for my USB drive on Ubuntu 14.04 formatted as NTFS, there are no partitions on the drive, inside or outside the container. The container mounts successfully in LibreCrypt by going to File -> Linux container -> Open LUKS partition and checking the "entire drive" checkbox. It assigns the drive letter but windows thinks the drive is unformatted. Any ideas? When I do a LUKS info dump I get this:

Application version : v6.2.5613.42403
Driver ID : v5.00.0000
Unable to read LUKS header; this does not appear to be a LUKS container.

Hi there, I'm Tomb's developer, see https://github.com/dyne/tomb

Our tool is widely used on gnu/linux platform and I'm sure many people would find it handy to open tombs also on win. Would you be interested in adding support to open tombs in doxbox? It should be simple, since you have already LUKS covered: Tombs are LUKS volumes whose keys are password-protected files symmetrically encrypted with GnuPG (and optionally steg-hidden inside JPG images).

In any case, thanks for your effort!

Running Windows 8.1 on Lenovo G580
Downloaded yesterday and installed.
Your on-site instructions say, "On Windows 8 please turn off 'Safe Boot' and disklocker before installing."
I can't figure out how to find or "turn off" either thing. Searching the disk does not turn up anything with either name.
When booting DoxBox, immediately an error box pops up: "DoxBox: ... has stopped working. A problem caused the program to stop working ... [Close Program]" and the program goes away. Similarly, if I try to run DoxBox Explorer, it seems to come up but when clicking on New or anything an error message pops up: "DoxBoxExplorer.exe - System Error. The program can't start because MSVCR100D.dll is missing from the computer. Try reinstalling the software. [OK]" and then that ends.
Yes, I've done a full cold reboot, twice.
Help.
Thanks.

As the title, I was wondering if it is due to the OS or it is a known issue.

Currently libtomcrypt is used for AES encryption. However, it is very old and does not support the AES-NI instruction set. An alternative library is eg the Gladman AES implementation (some implementations by Gladman seem to be already used for something): http://www.gladman.me.uk/AES

Alternatively it might be worth considering using a widely-spread crypto library like gcrypt or openssl that is well reviewed and can be expected to be updated/maintained in the future.

I understand eCryptfs support is a huge request, but if no one asks, it doesn't have a chance. I also understand the project might not be at a point it could take on such a request.

The biggest use case I have found for eCryptfs is it works on a USB flash drive with a FAT32 file system. I can have encrypted and non-encrypted files on the same file system. I am not stuck with a fully encrypted drive. I can still plug my flash drive into consumer products like a copier and save scanned documents to the flash drive. Who really wants to carry 2 flash drives around, one encrypted, one not? Since MS Windows has the forced limitation on USB flash drives that only the first partition can be mounted, 2 partitions (one encrypted, one not) is out of the question. Even it that was possible, I would be allocating a specific amount of space for encrypted and not, instead of them sharing the same storage capacity.

Please give this real consideration.

When selecting option "minimize on start" the program loads to systray but also to taskbar and has to be fully minimized to systray only manually. This worked OK in the last FOTFE version.

Also - DoxBox Explorer fails to open a FOTFE volume and returns error "Division by zero".

Also - DoxBox Explorer on update check checks version (1.00) but finds latest version 6.00, which is obviously DoxBox latest version, not the DoxBox Explorer's...

Tested in Win7x86 Ent SP1.

The last idea for improvement is the text at the status bar when hovering mouse: the caption should perhaps be disabled on hover over status bar as it shows this unnicely and also the http link format should be pruned of unnecessary technicals A HREF=...

The same goes for DoxBox Explorer.

After reading documentation on main page I thought Test mode only applied to running LC in portable mode, so I installed it properly. "Test mode" label is in the right bottom corner of the desktop. Mounting partitions works OK though.
I tried to allow test-signed drivers -> reboot -> disallow test-signed drivers -> reboot - that leaves me with no "Test mode" label on desktop, but LC is not working, saying it cannot load drivers.
Windows 7 SP1 64

Some have objected to the name 'DoxBox' saying it doesn't evoke the idea of encryption software.
Other suggestions are 'libreCrypt' or 'libreLocker'.
I have created a survey to find what name people prefer.
Please click here and take the survey, or add any comments below.

Hi,

I think it's a security risk if this mount-option always points to my windows-directory, where I stored my container.
I searched the options to maybe disable this behavior, but I didn't find any possible option for it. The maximum-count volumes to be shown in history (maybe its name is different in English, I use the German translation) i set to 0.

Kind regards,
ssdnvv

We should be able to restrict specific parts of LibreCrypt via registry to allow system administrators to have a better management of who can do what.

Containers are defined as a crypted file containing the data in this message, volume are crypted volume, disks are crypted disks.

Restrictions could be stored per users in HKCU\Software\Policies\t-d-k\LibreCrypt and per machines in HKLM\Software\Policies\t-d-k\LibreCrypt , obviously the HKLM path will affect all users.

These keys should be available both per user and per machines, if a key is missing, it is treated as true.
If some of these settings can be managed by the user itself, theses rules should silently overwrite user's settings.
Please note
This suggestion is bound to #38 as it probably require rewriting big chunk of code to check these settings correctly. It aims to improve security on multi-user systems.
System is always elevated, as it is not affected by UAC, we should not need to make exception to the HKCU or HKLM rules for NT AUTHORITY\System
Users running as NT SERVICE have their own home folder and registry hive like any user, we should not need to make exception to the HKCU or HKLM rules for them, an administrator can manage the settings for these services using regedit or policies as usual.
If this project need userspace filesystem to mount a container, volume or drive only for one user, we can make use of dokany. (Open source + Signed drivers, works from Win7 to 10)

AllowMountingContainer
AllowMountingContainerWithoutElevation (don't require UAC elevation to mount)
AllowUnmountingContainer
AllowUnmountingContainerWithoutElevation (don't require UAC elevation to unmount)
AllowMountingVolume
AllowUnmountingVolume
DisallowMountingVolumeWithoutElevation (Require elevation for action)
DisallowUnmountingVolumeWithoutElevation (Require elevation for action)
AllowMountingDisk
AllowUnmountingDisk
DisallowMountingDiskWithoutElevation (Require elevation for action)
DisallowUnmountingDiskWithoutElevation (Require elevation for action)
AllowRemovableMediaVolume (Includes mounting and unmounting to prevent data loss)
AllowRemovableMediaVolumeWithoutElevation (Don't require UAC elevation to (un)mount)
AllowCreatingVolume (If disabled, even administrators cannot create crypted volumes, but still can create containers)
DisallowCreatingVolumeWithoutElevation
AllowCreatingDisk (If disabled, even administrators cannot crypt whole disk, but can still create containers)
DisallowCreatingDiskWithoutElevation
AllowCreatingRemovableMediaVolume (Same as AllowCreatingVolume, but affects removable media)
AllowCreatingRemovableMediaVolumeWithoutElevation (Don't require UAC elevation for action)
AllowCreatingRemovableMediaDisk (Same as AllowCreatingDisk, but affects removable media)
AllowCreatingRemovableMediaDiskWithoutElevation (Don't require UAC elevation for action)
MountContainerForCurrentUser (Mount containers only for current user, regardless of user choice)
MountContainerForAllUsersWithoutElevation (Mounting for all users doesn't require UAC elevation)
AllowMountVolumeForAllUsers (Allow user to mount volume for all users)
AllowMountDiskForAllUsers (Allow user to mount disk for all users)
UnmountingOtherUserContainersRequireElevation (Unmounting containers you didn't mount require elevation)
UnmountingOtherUserVolumeRequireElevation (Unmounting volumes you didn't mount require elevation)
UnmountingOtherUserDiskRequireElevation (Unmounting disks you didn't mount require elevation)

HKLM specifics rules
UserBeforeMachine (HKCU rules take precedence over HKLM rules in case of conflict)
SystemMountContainerForAllUsers (Containers mounted by NT AUTHORITY\System are mounted for everyone by default)
SystemMountVolumeForAllUsers (Volumes mounted by NT AUTHORITY\System are mounted for everyone by default)
SystemMountDiskForAllUsers (Disks mounted by NT AUTHORITY\System are mounted for all users by default)
ServiceMountContainerForAllUsers.$ServiceName (Containers mounted by $ServiceName are mounted for everyone by default)
ServiceMountVolumeForAllUsers.$ServiceName (Volumes mounted by $ServiceName are mounted for everyone by default)
ServiceMountDiskForAllUsers.$ServiceName (Disks mounted by $ServiceName are mounted for everyone by default)

Quite a lot of time has passed since the latest LibreCrypt update. Even though not all suggestions and reported bugs have been sorted out by now, would it be possible to expect a release of at least what has been successfully done so far?

It seems the donation button on the main page leads to a Paypal page as it should. But I can only select England and GBP currency. The button in the "donate.md" page works as expected.

EDIT: My bad. It's the address line that only shows UK addresses.

i installed LibreCrypt and opened it, and clicked on the dropdown arrow beside the New button to create "New Luks Container" , it complains of
Access violation at address 00000000. Read of address 00000000.

Creating luks container is much needed to ensure compatibility between operating systems.

I'm using Windows7 64bit Ultimate edition.

Hello, I installed DoxBox on Windows 8.1 and it works fine. However, when I try use command line commands, I've figured out, that /dismount disk_letter doesn't work. But /dismont all works perfectly.
Does someone faced with this problem?
P.S. Sorry, if I have any mistakes in description, I'm not very good in English

It connects to the internet without warning the user, both for updates and on clicking help menu items.
This contradicts the FAQ.

I noted with big disappointment that you removed the drag and drop functionality from the password edit box in the latest release 6.2.5806.40706 marked as v 6.3 beta (I downloaded it from https://github.com/t-d-k/LibreCrypt/releases/tag/6.3), which was fully functional up to the previous release 6.2.5613.42403. The password could have been very securely delivered by, e.g. KeePass or HashPass, etc.

This is a big pity because now the password may be entered only by keyboard or clipboard, and both can be easily monitored.

Return to the previous functionality of drag and drop would be most appreciated, I trust by many... Else it just cannot beat the previous releases, whatever other improvements are made.

Greetings,

I'm following along with the documentation, or trying to, on this site. It's a bit confusing since some of your links point to the DoxBox site. In any case, both links regarding removing the Test Build text from my desktop are broken. There's one here (under "Automatic Installation"):

• Link: https://github.com/t-d-k/LibreCrypt/blob/master/docs/installation_and_upgrading__PC.md
• Points here (404): https://github.com/t-d-k/LibreCrypt/blob/master/docs/impact_of_kernel_driver_signing.html

There's another here on DoxBox (also in the "Automatic Installation" section):

• Link: http://doxbox.squte.com/doxbox/installation_and_upgrading__PC.html
• Points here (404): http://doxbox.squte.com/doxbox/impact_of_kernel_driver_signing.html

Can you provide the correct link or these instructions and update the docs?

(ansi) strings are used to store sensitive data like keys /random data. These are typically reset by assigning ''; but this doesn't clear the memory, so it could be sniffed or read from a memory dump.
You can't easily overwrite all copies of a string because of Delphi's reference counting, so random data should use a dedicated byte array type.
From the FreeOTFE 6.0 code, it looks like Sarah Dean was starting to make this change.

A "force dm-crypt" checkbox in "Open partition..." dialog would give a workaround the problem of not opening LUKS partitions on Windows 7 and 8.

Related to #24

This is similar to #38, in that it has the same symptoms, but a different cause and fix.
The driver allows a caller to open any device as an encrypted drive, with no checks on the headers, after that any data can be read or written.
Although this data is encrypted and decrypted as it is accessed, the caller has access to all keys, including master keys and the salt in the header so can reverse this process to arbitrarily read and write to anywhere on disc.
So a malware app can:

• Open a device, say C:, as a volume (say Z:).
• Read from Z:\ and encrypt that data to get the plaintext stored on C:.
• Decrypt some plaintext and write to Z: to overwrite plaintext on C:.

This bypasses Windows file-system access restrictions.

In short this allows a malware app on a PC where LC is installed to read and write arbitrarily anywhere on any physical device, without admin rights.

There are different solutions for the different container types:

• For FreeOTFE and LUKS volumes, which have distinctive headers, the driver should check the header and refuse to open the volume if it isn't valid (currently this is done in the GUI only).
• For plain dm-crypt, its more complicated, because dm-crypt has no header - in this case the driver should only allow opening if it's an inner container, and completely within the outer container. If the user has admin access, it can allow opening of an outer container.

I still cannot open LUKS disks.. I can only open file containers.

Is this not implemented yet or is there a problem with my system configuration?

I've been attempting to open LUKS partitions which I created using cryptsetup in Ubuntu on a Samsung SSD 850 PRO but I've had some issues. I'm on a Windows 7 64 bit laptop. I am using an eSATA cable to connect directly to the laptop, I have also tried using an eSATA to USB 3.0 adapter cable.

I create the LUKS partition in Ubuntu using cryptsetup and then make a fat32 filesystem inside of the LUKS partition. When I attempt to open the partition in Librecrypt, Librecrypt recognizes the partition as being LUKS. When I enter the password and hit OK I get the message "Unable to open container. Please check your keyphrase and settings, and try again."

When I use the exact same process on a USB flashdrive, the process works as expected and I can open the LUKS partition which I create in the exact same way.

Other things I have tried include using the 6.3 alpha executable and using FreeOTFE both of which behave similarly and did not fix my issue.

I was wondering if anyone has had this issue and might know how to fix it, thank you.

I have a home server with 3 external HDd attached. When I have to reboot the system, I am never sure which is the new order of the hard disks decided by windows, and for some reasons I have to assign the same mount letter to the same HD. To obtain so, I rely on a particular ID found in Disks managment > properties of a disk. I was wondering if it was possible / useful to have that ID displaying also in the selection window, to know which physical hd we are dealing with.

I have found that in rare circumstances the driver can cause a BSoD. This is a bug inherited from FreeOTFE.
It happens if you create a hidden volume that starts near the end of an outer volume (within 3MB), open the volume, open a file on it, and then force-dismount the volume. It only occurs when running as a non-administrator.
Finding the root cause may take some time, because I’m still working on a test harness for the drivers. But it's easy to work-around in the GUI, by preventing a user from creating a hidden volume that close to the end of an outer volume, and this has been done. However, it's still possible for a third party app (e.g. malware) to call the driver with the right parameters and create a BSoD.
I have decided not to let this block the 6.1 release. Because it's a pre-existing bug, releasing an unfixed version won’t make things worse.
It also only happens when the volume is mounted as a fixed disk, With 6.1 removable discs will be the default.

Hi, Using Windows 10 dev preview, I have installed DoxBox with no issues. Only the explorer program complains about not finding the drivers and suggest rebooting (doesn't solve the issue).

On a side note, the FAQ mentions that explorer can be used under Wine, however it also complains about not finding drivers and I cannot use DoxBox proper to install the drivers because it doesn't run under Wine.

reported by comicfans:

seems that doxbox can not read luks partition, luks dump just failed (but freeotfe works)

doxbox output

LUKS Dump

Dump Created By

Platform : PC
Application version : v6.00.00.0000
Driver ID : v5.00.0000
ERROR: Unable to read LUKS header?!

freeotfe output

LUKS Dump

Dump Created By

Platform : PC
Application version : v5.21.00.4058
Driver ID : v5.00.0000

cryptsetup Style Dump

LUKS header information for \Device\Harddisk0\Partition6

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 512
MK digest: 1d 19 ff f1 5a cd 98 a1 f1 db 17 0b cc 1a 78 b4 bc 6c 6c 1c
MK salt: 75 5f fc ea 01 6a 36 b2 0c 7a 5c 65 df 6b a5 ea
9a b2 c1 af d1 02 53 06 70 37 d5 df 14 60 24 c1
MK iterations: 79125
UUID: 6ef4d308-4ff7-46c9-81ff-074993e80f53

Key Slot 0: ENABLED
Iterations: 308805
Salt: c6 da 2c e2 c1 5a 9a 43 e7 8e 52 9e fe 3d b2 82
69 c1 8d 2b 41 f6 ae 1f 09 03 8c cd d9 fd 71 ec
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Mapped FreeOTFE Drivers

Hash pretty title : SHA-1 (160/512)
Hash driver KM name : \Device\FreeOTFE\Hash{00000000-0000-0000-0000-0000000D0001}
Hash GUID : {00000000-0000-0000-0000-0000000D0002}
Cypher pretty title : AES (XTS; 256/128)
Cypher driver KM name : \Device\FreeOTFE\Cypher{00000000-0000-0000-0000-000000010001}
Cypher GUID : {00000000-0000-0000-0000-000000010204}
Sector IV generation : 32 bit sector ID

Master Key

User supplied password :
No master key could be recovered with the specified password.