Open Redsandro opened 8 years ago
I hit the same issue, none of my passwords work when trying to mount in LibreCrypt.
Works just fine here with passphrase in first slot. I'm using pretty vanilla LUKS partition:
$ dd if=/dev/sdb2 bs=512 count=1 | strings -n 3
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000878214 s, 583 kB/s
LUKS
aes
xts-plain64
sha1
You probably have some exotic key passphrase hashing function?
The only issue I'm hitting is windows 10 kernel panic when trying to dismount the partition, not sure this is fault of ext2fsd or librecrypt.
Hash algorithm is sha1, the same as yours.
You probably have some exotic key passphrase hashing function?
I use the standard LUKS creation tool in Ubuntu / Linux Mint disk manager. Doesn't get much more native than that, right?
Also, dismount
is a weird word when used to describe the act of unmounting a volume. Dismounting is the act of stepping off a horse or person after 'riding'. I'd vote for changing this word in the UI.
mount/dismount is elevation related. mount/unmount is file system related.
@Redsandro, sudo cryptsetup luksDump /dev/sdX(Y) OR /dev/mapper/foo shows what exactly?
@linux-modder That will show private info :) Note that librecrypt can process only v1 headers, but is there even other version?
Anyhow, this is really weird. I located the source file and it does proper key generation from passphrase to decrypt master key from slots:
https://github.com/t-d-k/LibreCrypt/blob/master/src/PC/gui/common/LUKSTools.pas#L1125
I'm using this build:
@Redsandro @crylium : it works for me, although there is a known bug where it only works with the first keyslot. It also won't open LVM volumes, non-windows filesystems (without a third party driver) and certain hash-crypto combinations. Can you please post the output of luksDump, removing anything sensitive.
Would you please list the hash-crypto combinations, that are not supported?
I was thinking of this issue #3 . You can get an idea of the supported hashes and cyphers by looking at the drivers dialog. The safest way is to create a LUKS container in LC.
The problem is - I can't even open the LUKS partitions that were created in LC.
Here's the luksDump for my partition: root@machine:/home/user# cryptsetup luksDump /dev/sdb3LUKS header information for /dev/sdb3
Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha512 Payload offset: 4096 MK bits: 256 MK digest: - MK salt: - MK iterations: - UUID: -
Key Slot 0: ENABLED Iterations: - Salt: - 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
Perhaps there is an issue with big partitions? Mine is about 9TB...
My disk is portable 1TB USB 3.0 drive, not that it should matter really.
# cryptsetup luksDump /dev/sdc
LUKS header information for /dev/sdc
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest:
MK salt:
MK iterations:
UUID:
Key Slot 0: ENABLED
Iterations:
Salt:
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
@My fault - I found the correct entrance... you have to choose file -> linux container -> open LUKS-partition. Now it mounts that partition as a removable disk and that disk is shown und the chosen drive letter, but when I select that drive letter, I get a
Please insert a disk into removable disk [chosen drive letter]
Error. What do I have to do in order to mount that partition successfully?
It seems there is no option anymore to mount (a partition) as a disk but only to mount it as a removable disk. - I assume as of reaction towards #17 Perhaps this could be the reason for my problem?
@ssdnvv The option to mount as a fixed disc was removed as a work-around to #17. I'd be surprised if this was related to the issue. Is this a volume you created in LC, and did you format it after creating it?
@crylium That should be OK. What filesystem are you using, and are you using LVM?
@t-d-k OK, it's a 1TB /dev/sdc device (not partitioned) encrypted with LUKS on Debian, and I've put an NTFS-3g on top of it to be able use with Linux and Windows. There is no LVM, just one big NTFS partition. I can open it with FreeOTFE v5.21, but zero luck with LibreCrypt so far.
@crylium It's puzzling. Could you please try opening the file 'luks.box' from https://github.com/t-d-k/LibreCrypt/tree/master/test_vols with the password 'password'. Does LC come up with the LUKS password dialog when you try to open your volume? It should say "Key Phrase For LUKS Container" as a title.
Here is what I did that far:
Created the volume within lc (newer lc-exe) that uses the following parameters:
Then I switched to 6.2b and did the following by choosing to open LUKS-partition:
And "mount for all users"-option checked. After mounting I get the following error trying to format the drive:
in english: "Windows was unable to complete the format"
looking towards linux, debian gives me the following luksDump
root@machine:/home/user# cryptsetup luksDump /dev/sdb3 LUKS header information for /dev/sdb3 Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha512 Payload offset: 4096 MK bits: 256 MK digest: - MK salt: - MK iterations: - UUID: - Key Slot 0: ENABLED Iterations: - Salt: - 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
It's interesting, that those information doesn't match the values lc told me it was using (see above). Another point is, that this partition cannot be opened on Debian:
Error unlocking /dev/sdb3: Command-line `cryptsetup luksOpen "/dev/sdb3" "luks-UUID" ' exited with non-zero exit status 2: No key available with this passphrase. (udisks-error-quark, 0)
freeotfe doesn't even recognize the disk - perhaps because of gpt?
that is really weird - is the window used to mount LUKS-volumes the same as used to mount dm-crypt-Volumes?
I just realized that because when I use the newer lc-exe, and select the LUKS-partition it says
@ssdnvv You have to be careful, if you open a volume as a dm-crypt one, when it is a LUKS volume, and save anything or format the drive, you will corrupt the LUKS header. It looks like that might have happened, because the dm-crypt dialog is showing, not the LUKS dialog. I suggest you start from scratch, creating the volume, then try to open it in LC. If you get the dm-crypt password dialog above, instead of the LUKS password dialog, then please click 'cancel' and then let me know.
Ok, started from scratch:
But unfortunately there is no opened LUKS-Partition:
Then I go to file -> open LUKS partition, choose disk 2 partition 3 and get the following result:
Switching to Linux, I get the following LUKSDump:
LUKS header information for /dev/sdb3 Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha512 Payload offset: 4096 MK bits: 256 MK digest: 5f 0b 2f ae a3 52 2c ee cd 7d 8a 59 21 a2 48 8d f5 c5 ab 3e MK salt: a9 61 d0 6f 78 62 54 a2 c9 85 75 70 da 69 5f d7 70 5e 3e 43 79 f8 bc 18 3a ab c0 24 60 4e 5f d8 MK iterations: 27375 UUID: caa9e996-8876-402c-80fb-165b95824c88 Key Slot 0: ENABLED Iterations: 109588 Salt: 29 e9 24 a6 39 e8 0b 57 f1 72 f0 6b 19 91 dc f4 2a 78 62 19 6b 34 fa 03 dc f3 6f 4f 20 09 c1 8a 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
and again: the LUKS-partition cannot be opened:
Error unlocking /dev/sdb3: Command-line `cryptsetup luksOpen "/dev/sdb3" "luks-UUID" ' exited with non-zero exit status 2: No key available with this passphrase. (udisks-error-quark, 0)
switching back to lc, I choose file -> linux containers -> open LUKS partition and get the dm-crypt dialog. Up to here I didn't even mention the partition to choose. So it has to be issue in lc (in lctest it's another one, here the former created LUKS-volume is not recognized or it has not been formatted correctly).
If you compare the LUKS-dump
LUKS header information for /dev/sdb3 Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha512 Payload offset: 4096 MK bits: 256 MK digest: 5f 0b 2f ae a3 52 2c ee cd 7d 8a 59 21 a2 48 8d f5 c5 ab 3e MK salt: a9 61 d0 6f 78 62 54 a2 c9 85 75 70 da 69 5f d7 70 5e 3e 43 79 f8 bc 18 3a ab c0 24 60 4e 5f d8 MK iterations: 27375 UUID: caa9e996-8876-402c-80fb-165b95824c88 Key Slot 0: ENABLED Iterations: 109588 Salt: 29 e9 24 a6 39 e8 0b 57 f1 72 f0 6b 19 91 dc f4 2a 78 62 19 6b 34 fa 03 dc f3 6f 4f 20 09 c1 8a 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
to the settings set by lc
I would guess that lc doesn't format the partition correctly. Or, more precisely, it doesn't format it at all - because the LUKS-dump is showing the settings I chose while creating the LUKS-volume on linux...
@ssdnvv It certainly looks as if LC isn't writing the LUKS header at all. It works for me, but the largest partition I have to test with is about 60GB, so it's possible it's related to large partitions. I could give you a build that writes out a log, which would help investigate it,if you're willing to run it and send the log back. Failing that, all I can suggest is creating the LUKS volume in Linux.
@Redsandro Can I ask the size of the partition you were using?
I've had a similar problem: Creating a 2TB LUKS partition in lc6.2 didnt't work, but it worked in lc6.3
And I can't add passphrases/keyfiles using linux:
# cryptsetup luksAddKey /dev/sdb1
Geben Sie irgendeine bestehende Passphrase ein:
Geben Sie die neue Passphrase für das Schlüsselfach ein:
Passphrase bestätigen:
Material für Schlüsselfach 1 enthält zu wenige Streifen. Manipulation des Headers?
Translated:
# cryptsetup luksAddKey /dev/sdb1
Enter existing passphrase:
Enter new passphrase for keyslot:
Confirm passphrase:
Material for keyslot 1 contains too less stripes. Manipulation of Header?
Is this related to an old version of Luks headers created by lc?
I've got another 2TB drive not in use so I could do some tests if you tell me what exactly to test :)
@t-d-k : Sure, please advice me how to help you in order to solve this bug. I just received my two backup-hard discs (identical to the one already in use), so I'll be able to create different/special scenarios. What I've been wondering about: Could you give me the correct command to create a LUKS-volume in linux that can be opened in lc?
@reklrekl : Has the disk you're talking about been initialised using MBR oder GPT?
@ssdnvv it's an mbr disk
@reklrekl Are you able to open it in linux?
@ssdnvv yes, i can open it and mount the encrypted ntfs filesystem in linux. But I can't add any keyslots...
ok, that proofs something went wrong in my scenario...
@reklrekl I've moved your problem to a new issue #55, because it's unrelated to this.
@ ssdnvv cryptsetup --cipher aes-xts-plain64 --key-size 256 --hash sha256 --luksFormat <device>
should work OK.
Thanks for your offer, I'll make a new build of LC with some debugging in, for you to test with.
Ok, I used your command and got the following luksDump:
LUKS header information for /dev/sdb3 Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 256 MK digest: 3a ac ef dc 67 29 a5 db 8e ca f0 3b e6 da ee 50 bd b2 2b 72 MK salt: ec 13 8f cf 3e 0b f6 f2 7c d0 ab 67 e5 88 fc 1a 70 33 e3 98 d8 c5 06 9f 74 d6 bd fa 8a 13 f4 4b MK iterations: 38750 UUID: 5437e649-627c-42ba-818f-dee8dd6a0642 Key Slot 0: ENABLED Iterations: 154588 Salt: 01 cb ec e3 d6 62 5f a1 29 aa 42 bd f1 19 95 87 92 60 0c 89 e2 7a 6e 6c 24 9e ed a0 55 7b 9a 38 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
unfortunately it still doesn't work:
last-ditch attempt (so far): recreated partitions within linux (former within Win7Pro64bit), but still same error...
@ssdnvv I'll make a new build of LC with some debugging in, for you to test with, that should give a better idea of what's going on.
@t-d-k
@Redsandro Can I ask the size of the partition you were using?
Sorry for the late reply. Honestly I have to admit that I've stopped using LibreCrypt
for now because it's too time consuming for me to get it to work. I don't fully understand the problems and I might have been too impatient. I'm just so busy lately and it really makes me want to be lazy and only use things that 'just work' and save time.
In my workflow I use different ((simple(r)) people's) Windows machines and I don't want to do the test mode dance and explain I'm not black-hat-hacking their system either. That's why I secretly hoped it wasn't so much trouble to get a driver-signed version.
These days I just bring a small linux netbook everywhere I go. Not ideal. I'm hoping the soon to be released Linux subsystem for Windows 10 will allow for either EcryptFS or LUKS mounts. Probably not out of the box but I'm hoping someone will figure something out for mounting in general.
TL;DR: The partition was 3 TB on a 4 TB drive using GPT.
@t-d-k I'm eagerly awaiting it (the current necessarity to open a luks volume via samba share in a linux-vm is really getting me crazy... and win10/linux subsystem is no choice because of M$ data-acquisitiveness).
@t-d-k apologies for the delay, but I didn't have the time to do any testing. FreeOTFE works fine for me and TBH, I didn't want to mess around it (because it works). I'm in the same boat as @Redsandro - it's too time consuming for me.
@crylium I understand
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.