[dm-crypt] Re: [RFC] Partial support for reading DiskCryptor volumes

[Milan Broz <gmazyland@gmail.com>]

Hi,

On 31/10/2021 23:36, Mateusz Jończyk wrote:
> Hello,
> 
> Back in June, I wrote to the mailing list seeking some help with
> reverse-engineering the DiskCryptor volume format [1].
> 
> Since then, I have implemented decryption of the volume header (for all
> cipher combinations, with autodetection) and would like to know whether
> you would be interested in merging support for opening DiskCryptor
> volumes once it is ready.
> 
> The DiskCryptor development has largely stalled, with the last beta
> release in April 2020. Releases by DavidXanatos have the following
> problem [3]:
> 
>>         The Disk Cryptor driver needed to be updated, and since the
>>         ReactOS foundation no longer offer a driver signing service, I
>>         head to use a leaked code signing certificate I found laying
>>         around the Internets. This means some anti malware applications
>>         may wrongfully flag it as potentially dangerous.

How much is DiskCryptor used in reality? The note above would qualify
it as a regular malware for me :-)


I would like to have support for various formats, but the line where
it becomes bloatware is very thin...

Anyway, if
  - code is licensed under LGPL (no new GPL-only code in libcryptsetup)
  - it only allows to open existing formats (no code to modify metadata;
    our primary format is LUKS and it will stay this way)
  - it does not add complicated dependences
    (I think we should care about memory footprint more now)

then the best is perhaps open merge request (or issue) on the project
page and discuss it there.

(For now, the code looks simple enough.)

What is missing to more "stable" code? Only the parts marked TODO,
or something crucial for format parsing?


Thanks,
Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de