[dm-crypt] (no subject)

[dm-crypt] (no subject)

[Hammad Siddiqi]

[-- Attachment #1: Type: text/plain, Size: 4232 bytes --]

Hi,No key available with this passphrase.

one of our host, running centos 7.1, crashed today with a kernel panic on
qemu-kvm process. the VM disks were stored on encrypted volume, which
became locked after reboot. the cryptseup luksOpen  command throws "No Key
available with this passphrase". The encrypted volume has a 512 bit key
without any password. we also backup our key and both backup and key
residing on server are same. We have tried to by pass current OS by booting
up using live CD of Centos 7.1, Linux Mint 17, Ubuntu 17.04 with different
versions of kernel and crypt setup. this did not succeed. we believe the
key is correct but the Encrypted volume is not accepting it. Can you please
help us on this. Please let me know if you need something else as well

* command used: cryptsetup luksOpen --key-file /etc/luks.key
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d raid10-2hs-island
* Host Kernel Version: 3.10.0-229.el7.x86_64
* Host Cryptsetup version: 1.6.6

**output of cryptsetup luksOpen**

 **cryptsetup luksOpen --key-file /etc/luks.key
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d raid10-2hs-island
--verbose --debug**
```
# cryptsetup 1.7.2 processing "cryptsetup luksOpen --key-file /etc/luks.key
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d raid10-2hs-island
--verbose --debug"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d context.
# Trying to open and read device
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d with direct-io.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d.
# Crypto backend (gcrypt 1.5.3) initialized in cryptsetup library version
1.7.2.
# Detected kernel Linux 3.10.0-229.el7.x86_64 x86_64.
# Reading LUKS header of size 1024 from device
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
# Key length 64, device size 15622799360 sectors, header size 4036 sectors.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 2000 miliseconds.
# Password retry count set to 1.
# Activating volume raid10-2hs-island [keyslot -1] using keyfile
/etc/luks.key.
# dm version   [ opencount flush ]   [16384] (*1)
# dm versions   [ opencount flush ]   [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.29.0.
# Device-mapper backend running with UDEV support enabled.
# dm status raid10-2hs-island  [ opencount flush ]   [16384] (*1)
# File descriptor passphrase entry requested.
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# Trying to open key slot 1 [INACTIVE].
# Trying to open key slot 2 [INACTIVE].
# Trying to open key slot 3 [INACTIVE].
# Trying to open key slot 4 [INACTIVE].
# Trying to open key slot 5 [INACTIVE].
# Trying to open key slot 6 [INACTIVE].
# Trying to open key slot 7 [INACTIVE].
No key available with this passphrase.
# Releasing crypt device
/dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 1: Operation not permitted
```

**cryptsetup luksDump:**

```
cryptsetup -v luksDump /dev/sdb
LUKS header information for /dev/sdb

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512
MK digest:      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
MK salt:        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
MK iterations:  36750
UUID:           #############################

Key Slot 0: ENABLED
        Iterations:             141435
        Salt:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        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
Command successful.
```

[-- Attachment #2: Type: text/html, Size: 5325 bytes --]

Re: [dm-crypt] (no subject)

[Arno Wagner]

Hi Hammad,

sounds like your one key-slot might have been damaged.

Please run the keyslot-checker found in misc/keyslot_checker
of the source package and report the results.

Regards,
Arno


On Sat, Apr 29, 2017 at 19:48:15 CEST, Hammad Siddiqi wrote:
>    Hi,No key available with this passphrase.
>    one of our host, running centos 7.1, crashed today with a kernel panic
>    on qemu-kvm process. the VM disks were stored on encrypted volume,
>    which became locked after reboot. the cryptseup luksOpen  command
>    throws "No Key available with this passphrase". The encrypted volume
>    has a 512 bit key without any password. we also backup our key and both
>    backup and key residing on server are same. We have tried to by pass
>    current OS by booting up using live CD of Centos 7.1, Linux Mint 17,
>    Ubuntu 17.04 with different versions of kernel and crypt setup. this
>    did not succeed. we believe the key is correct but the Encrypted volume
>    is not accepting it. Can you please help us on this. Please let me know
>    if you need something else as well
>    * command used: cryptsetup luksOpen --key-file /etc/luks.key
>    /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>    raid10-2hs-island
>    * Host Kernel Version: 3.10.0-229.el7.x86_64
>    * Host Cryptsetup version: 1.6.6
>    **output of cryptsetup luksOpen**
>     **cryptsetup luksOpen --key-file /etc/luks.key
>    /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>    raid10-2hs-island --verbose --debug**
>    ```
>    # cryptsetup 1.7.2 processing "cryptsetup luksOpen --key-file
>    /etc/luks.key /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>    raid10-2hs-island --verbose --debug"
>    # Running command open.
>    # Locking memory.
>    # Installing SIGINT/SIGTERM handler.
>    # Unblocking interruption on signal.
>    # Allocating crypt device
>    /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d context.
>    # Trying to open and read device
>    /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d with direct-io.
>    # Initialising device-mapper backend library.
>    # Trying to load LUKS1 crypt type from device
>    /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d.
>    # Crypto backend (gcrypt 1.5.3) initialized in cryptsetup library
>    version 1.7.2.
>    # Detected kernel Linux 3.10.0-229.el7.x86_64 x86_64.
>    # Reading LUKS header of size 1024 from device
>    /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>    # Key length 64, device size 15622799360 sectors, header size 4036
>    sectors.
>    # Timeout set to 0 miliseconds.
>    # Password retry count set to 3.
>    # Password verification disabled.
>    # Iteration time set to 2000 miliseconds.
>    # Password retry count set to 1.
>    # Activating volume raid10-2hs-island [keyslot -1] using keyfile
>    /etc/luks.key.
>    # dm version   [ opencount flush ]   [16384] (*1)
>    # dm versions   [ opencount flush ]   [16384] (*1)
>    # Detected dm-crypt version 1.13.0, dm-ioctl version 4.29.0.
>    # Device-mapper backend running with UDEV support enabled.
>    # dm status raid10-2hs-island  [ opencount flush ]   [16384] (*1)
>    # File descriptor passphrase entry requested.
>    # Trying to open key slot 0 [ACTIVE_LAST].
>    # Reading key slot 0 area.
>    # Using userspace crypto wrapper to access keyslot area.
>    # Trying to open key slot 1 [INACTIVE].
>    # Trying to open key slot 2 [INACTIVE].
>    # Trying to open key slot 3 [INACTIVE].
>    # Trying to open key slot 4 [INACTIVE].
>    # Trying to open key slot 5 [INACTIVE].
>    # Trying to open key slot 6 [INACTIVE].
>    # Trying to open key slot 7 [INACTIVE].
>    No key available with this passphrase.
>    # Releasing crypt device
>    /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d context.
>    # Releasing device-mapper backend.
>    # Unlocking memory.
>    Command failed with code 1: Operation not permitted
>    ```
>    **cryptsetup luksDump:**
>    ```
>    cryptsetup -v luksDump /dev/sdb
>    LUKS header information for /dev/sdb
>    Version:        1
>    Cipher name:    aes
>    Cipher mode:    xts-plain64
>    Hash spec:      sha1
>    Payload offset: 4096
>    MK bits:        512
>    MK digest:      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>    MK salt:        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>                    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>    MK iterations:  36750
>    UUID:           #############################
>    Key Slot 0: ENABLED
>            Iterations:             141435
>            Salt:
>    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> 
>    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>            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
>    Command successful.
>    ```

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] (no subject)

[Hammad Siddiqi]

[-- Attachment #1: Type: text/plain, Size: 5182 bytes --]

Hi,

here is the result, for some reason i  did not get Arno's email

[root@LA3-KVMISLAND08-20319 keyslot_checker]# /tmp/chk_luks_keyslots -v
/dev/sdb

parameters (commandline and LUKS header):
  sector size: 512
  threshold:   0.900000

- processing keyslot 0:  start: 0x001000   end: 0x03f800
- processing keyslot 1:  keyslot not in use
- processing keyslot 2:  keyslot not in use
- processing keyslot 3:  keyslot not in use
- processing keyslot 4:  keyslot not in use
- processing keyslot 5:  keyslot not in use
- processing keyslot 6:  keyslot not in use
- processing keyslot 7:  keyslot not in use




On Sat, Apr 29, 2017 at 10:48 PM, Hammad Siddiqi <hsiddiqi@gmail.com> wrote:

> Hi,No key available with this passphrase.
>
> one of our host, running centos 7.1, crashed today with a kernel panic on
> qemu-kvm process. the VM disks were stored on encrypted volume, which
> became locked after reboot. the cryptseup luksOpen  command throws "No Key
> available with this passphrase". The encrypted volume has a 512 bit key
> without any password. we also backup our key and both backup and key
> residing on server are same. We have tried to by pass current OS by booting
> up using live CD of Centos 7.1, Linux Mint 17, Ubuntu 17.04 with different
> versions of kernel and crypt setup. this did not succeed. we believe the
> key is correct but the Encrypted volume is not accepting it. Can you please
> help us on this. Please let me know if you need something else as well
>
> * command used: cryptsetup luksOpen --key-file /etc/luks.key
> /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d raid10-2hs-island
> * Host Kernel Version: 3.10.0-229.el7.x86_64
> * Host Cryptsetup version: 1.6.6
>
> **output of cryptsetup luksOpen**
>
>  **cryptsetup luksOpen --key-file /etc/luks.key /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
> raid10-2hs-island --verbose --debug**
> ```
> # cryptsetup 1.7.2 processing "cryptsetup luksOpen --key-file
> /etc/luks.key /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
> raid10-2hs-island --verbose --debug"
> # Running command open.
> # Locking memory.
> # Installing SIGINT/SIGTERM handler.
> # Unblocking interruption on signal.
> # Allocating crypt device /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
> context.
> # Trying to open and read device /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
> with direct-io.
> # Initialising device-mapper backend library.
> # Trying to load LUKS1 crypt type from device /dev/disk/by-uuid/92de4358-
> d815-496a-8a58-60e55346161d.
> # Crypto backend (gcrypt 1.5.3) initialized in cryptsetup library version
> 1.7.2.
> # Detected kernel Linux 3.10.0-229.el7.x86_64 x86_64.
> # Reading LUKS header of size 1024 from device /dev/disk/by-uuid/92de4358-
> d815-496a-8a58-60e55346161d
> # Key length 64, device size 15622799360 sectors, header size 4036 sectors.
> # Timeout set to 0 miliseconds.
> # Password retry count set to 3.
> # Password verification disabled.
> # Iteration time set to 2000 miliseconds.
> # Password retry count set to 1.
> # Activating volume raid10-2hs-island [keyslot -1] using keyfile
> /etc/luks.key.
> # dm version   [ opencount flush ]   [16384] (*1)
> # dm versions   [ opencount flush ]   [16384] (*1)
> # Detected dm-crypt version 1.13.0, dm-ioctl version 4.29.0.
> # Device-mapper backend running with UDEV support enabled.
> # dm status raid10-2hs-island  [ opencount flush ]   [16384] (*1)
> # File descriptor passphrase entry requested.
> # Trying to open key slot 0 [ACTIVE_LAST].
> # Reading key slot 0 area.
> # Using userspace crypto wrapper to access keyslot area.
> # Trying to open key slot 1 [INACTIVE].
> # Trying to open key slot 2 [INACTIVE].
> # Trying to open key slot 3 [INACTIVE].
> # Trying to open key slot 4 [INACTIVE].
> # Trying to open key slot 5 [INACTIVE].
> # Trying to open key slot 6 [INACTIVE].
> # Trying to open key slot 7 [INACTIVE].
> No key available with this passphrase.
> # Releasing crypt device /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
> context.
> # Releasing device-mapper backend.
> # Unlocking memory.
> Command failed with code 1: Operation not permitted
> ```
>
> **cryptsetup luksDump:**
>
> ```
> cryptsetup -v luksDump /dev/sdb
> LUKS header information for /dev/sdb
>
> Version:        1
> Cipher name:    aes
> Cipher mode:    xts-plain64
> Hash spec:      sha1
> Payload offset: 4096
> MK bits:        512
> MK digest:      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> MK salt:        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>                 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> MK iterations:  36750
> UUID:           #############################
>
> Key Slot 0: ENABLED
>         Iterations:             141435
>         Salt:                   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXX
>                                 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXX
>         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
> Command successful.
> ```
>

[-- Attachment #2: Type: text/html, Size: 6638 bytes --]

Re: [dm-crypt] (no subject)

[Hammad Siddiqi]

[-- Attachment #1: Type: text/plain, Size: 5492 bytes --]

Hi Team,

May I please get an update on this.

Thanks

Hammad Siddiqi

On Sun, Apr 30, 2017 at 12:19 AM, Hammad Siddiqi <hsiddiqi@gmail.com> wrote:

> Hi,
>
> here is the result, for some reason i  did not get Arno's email
>
> [root@LA3-KVMISLAND08-20319 keyslot_checker]# /tmp/chk_luks_keyslots -v
> /dev/sdb
>
> parameters (commandline and LUKS header):
>   sector size: 512
>   threshold:   0.900000
>
> - processing keyslot 0:  start: 0x001000   end: 0x03f800
> - processing keyslot 1:  keyslot not in use
> - processing keyslot 2:  keyslot not in use
> - processing keyslot 3:  keyslot not in use
> - processing keyslot 4:  keyslot not in use
> - processing keyslot 5:  keyslot not in use
> - processing keyslot 6:  keyslot not in use
> - processing keyslot 7:  keyslot not in use
>
>
>
>
> On Sat, Apr 29, 2017 at 10:48 PM, Hammad Siddiqi <hsiddiqi@gmail.com>
> wrote:
>
>> Hi,No key available with this passphrase.
>>
>> one of our host, running centos 7.1, crashed today with a kernel panic on
>> qemu-kvm process. the VM disks were stored on encrypted volume, which
>> became locked after reboot. the cryptseup luksOpen  command throws "No Key
>> available with this passphrase". The encrypted volume has a 512 bit key
>> without any password. we also backup our key and both backup and key
>> residing on server are same. We have tried to by pass current OS by booting
>> up using live CD of Centos 7.1, Linux Mint 17, Ubuntu 17.04 with different
>> versions of kernel and crypt setup. this did not succeed. we believe the
>> key is correct but the Encrypted volume is not accepting it. Can you please
>> help us on this. Please let me know if you need something else as well
>>
>> * command used: cryptsetup luksOpen --key-file /etc/luks.key
>> /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d raid10-2hs-island
>> * Host Kernel Version: 3.10.0-229.el7.x86_64
>> * Host Cryptsetup version: 1.6.6
>>
>> **output of cryptsetup luksOpen**
>>
>>  **cryptsetup luksOpen --key-file /etc/luks.key
>> /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d raid10-2hs-island
>> --verbose --debug**
>> ```
>> # cryptsetup 1.7.2 processing "cryptsetup luksOpen --key-file
>> /etc/luks.key /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>> raid10-2hs-island --verbose --debug"
>> # Running command open.
>> # Locking memory.
>> # Installing SIGINT/SIGTERM handler.
>> # Unblocking interruption on signal.
>> # Allocating crypt device /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>> context.
>> # Trying to open and read device /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>> with direct-io.
>> # Initialising device-mapper backend library.
>> # Trying to load LUKS1 crypt type from device
>> /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d.
>> # Crypto backend (gcrypt 1.5.3) initialized in cryptsetup library version
>> 1.7.2.
>> # Detected kernel Linux 3.10.0-229.el7.x86_64 x86_64.
>> # Reading LUKS header of size 1024 from device
>> /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>> # Key length 64, device size 15622799360 sectors, header size 4036
>> sectors.
>> # Timeout set to 0 miliseconds.
>> # Password retry count set to 3.
>> # Password verification disabled.
>> # Iteration time set to 2000 miliseconds.
>> # Password retry count set to 1.
>> # Activating volume raid10-2hs-island [keyslot -1] using keyfile
>> /etc/luks.key.
>> # dm version   [ opencount flush ]   [16384] (*1)
>> # dm versions   [ opencount flush ]   [16384] (*1)
>> # Detected dm-crypt version 1.13.0, dm-ioctl version 4.29.0.
>> # Device-mapper backend running with UDEV support enabled.
>> # dm status raid10-2hs-island  [ opencount flush ]   [16384] (*1)
>> # File descriptor passphrase entry requested.
>> # Trying to open key slot 0 [ACTIVE_LAST].
>> # Reading key slot 0 area.
>> # Using userspace crypto wrapper to access keyslot area.
>> # Trying to open key slot 1 [INACTIVE].
>> # Trying to open key slot 2 [INACTIVE].
>> # Trying to open key slot 3 [INACTIVE].
>> # Trying to open key slot 4 [INACTIVE].
>> # Trying to open key slot 5 [INACTIVE].
>> # Trying to open key slot 6 [INACTIVE].
>> # Trying to open key slot 7 [INACTIVE].
>> No key available with this passphrase.
>> # Releasing crypt device /dev/disk/by-uuid/92de4358-d815-496a-8a58-60e55346161d
>> context.
>> # Releasing device-mapper backend.
>> # Unlocking memory.
>> Command failed with code 1: Operation not permitted
>> ```
>>
>> **cryptsetup luksDump:**
>>
>> ```
>> cryptsetup -v luksDump /dev/sdb
>> LUKS header information for /dev/sdb
>>
>> Version:        1
>> Cipher name:    aes
>> Cipher mode:    xts-plain64
>> Hash spec:      sha1
>> Payload offset: 4096
>> MK bits:        512
>> MK digest:      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>> MK salt:        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>                 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>> MK iterations:  36750
>> UUID:           #############################
>>
>> Key Slot 0: ENABLED
>>         Iterations:             141435
>>         Salt:                   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>> XXXXXXXXXXXXXXX
>>                                 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>> XXXXXXXXXXXXXXX
>>         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
>> Command successful.
>> ```
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7190 bytes --]

Re: [dm-crypt] (no subject)

[Michael Kjörling]

On 1 May 2017 22:37 +0500, from hsiddiqi@gmail.com (Hammad Siddiqi):
> Hi Team,
> 
> May I please get an update on this.

Everyone here donates freely of their own time to help others. If you
require more than volunteer effort, then I recommend that you turn to
your contracted support provider to open a case with them.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] (no subject)

[Arno Wagner]

On Mon, May 01, 2017 at 20:45:15 CEST, Michael Kjörling wrote:
> On 1 May 2017 22:37 +0500, from hsiddiqi@gmail.com (Hammad Siddiqi):
> > Hi Team,
> > 
> > May I please get an update on this.
> 
> Everyone here donates freely of their own time to help others. If you
> require more than volunteer effort, then I recommend that you turn to
> your contracted support provider to open a case with them.
> 

Indeed. However the update here is pretty simple: It looks
like you have lost your LUKS container permanendly due to
causes unknown, likely localized corruption from bad RAM,
a bad bus or a bad controller somewhere. I recommend a look 
into FAQ section 6, "Backup and Data Recovery" for a future 
set-up.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] (no subject)

[Diagon]

On 05/01/2017 02:01 PM, Arno Wagner - arno@wagner.name wrote:
> On Mon, May 01, 2017 at 20:45:15 CEST, Michael Kjörling wrote:
>> On 1 May 2017 22:37 +0500, from hsiddiqi@gmail.com (Hammad Siddiqi):
>>> Hi Team,
>>>
>>> May I please get an update on this.
>>
>> Everyone here donates freely of their own time to help others. If you
>> require more than volunteer effort, then I recommend that you turn to
>> your contracted support provider to open a case with them.
>> 
> Indeed. However the update here is pretty simple: It looks
> like you have lost your LUKS container permanendly due to
> causes unknown, likely localized corruption from bad RAM,
> a bad bus or a bad controller somewhere. I recommend a look 
> into FAQ section 6, "Backup and Data Recovery" for a future 
> set-up.

For my own edification, could someone clarify this for me?  If he's got
a backup of his header, shouldn't he be able to unlock/open the device,
even if he doesn't find a filesystem on there?

> Regards,
> Arno

Dave.

Re: [dm-crypt] (no subject)

[Arno Wagner]

On Tue, May 02, 2017 at 02:29:06 CEST, Diagon wrote:
> On 05/01/2017 02:01 PM, Arno Wagner - arno@wagner.name wrote:
> > On Mon, May 01, 2017 at 20:45:15 CEST, Michael Kjörling wrote:
> >> On 1 May 2017 22:37 +0500, from hsiddiqi@gmail.com (Hammad Siddiqi):
> >>> Hi Team,
> >>>
> >>> May I please get an update on this.
> >>
> >> Everyone here donates freely of their own time to help others. If you
> >> require more than volunteer effort, then I recommend that you turn to
> >> your contracted support provider to open a case with them.
> >> 
> > Indeed. However the update here is pretty simple: It looks
> > like you have lost your LUKS container permanendly due to
> > causes unknown, likely localized corruption from bad RAM,
> > a bad bus or a bad controller somewhere. I recommend a look 
> > into FAQ section 6, "Backup and Data Recovery" for a future 
> > set-up.
> 
> For my own edification, could someone clarify this for me?  If he's got
> a backup of his header, shouldn't he be able to unlock/open the device,
> even if he doesn't find a filesystem on there?

I think the statement was that there is a backup of the passphrase,
but not of the header.

Regards,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] (no subject)

[Milan Broz]

On 06/20/2016 01:45 PM, RAS RAS wrote:
> I meant for the zip file I downloaded.

That is not any official release, if it is something automatically generated,
then it is basically just git snapshot. I have no idea where you get it,
better use git directly if you want devel code.

Proper releases are signed with my key, both in git (signed tag) and in archives,
all in o is on the project page  https://gitlab.com/cryptsetup/cryptsetup .

Milan

> 
> 
>     Monday, June 20, 2016 9:52 AM +02:00 from Milan Broz <gmazyland@gmail.com>:
> 
>     On 06/18/2016 11:40 PM, RAS RAS wrote:
>     > Why there is no sha 256 for cryptsetup-master-16fab74ab1b2a4b95f4fc449c18d3b89c59a3429.zip
> 
>     If you mean default hash for LUKS header, see defaults in configure.ac:
> 
>     CS_STR_WITH([luks1-hash], [hash function for LUKS1 header], [sha256])
> 
>     Please use subject in email next time.
> 
>     Milan
> 
> 
> 
> Best regards,
> RAS RAS
> ras-os@mail.ru

Re: [dm-crypt] (no subject)

[Milan Broz]

On 06/18/2016 11:40 PM, RAS RAS wrote:
> Why there is no sha 256 for cryptsetup-master-16fab74ab1b2a4b95f4fc449c18d3b89c59a3429.zip

If you mean default hash for LUKS header, see defaults in configure.ac:

CS_STR_WITH([luks1-hash],   [hash function for LUKS1 header], [sha256])

Please use subject in email next time.

Milan

[dm-crypt] (no subject)

[RAS RAS]

[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

 Why there is no sha 256 for cryptsetup-master-16fab74ab1b2a4b95f4fc449c18d3b89c59a3429.zip 


Best regards,
RAS RAS
ras-os@mail.ru

[-- Attachment #2: Type: text/html, Size: 173 bytes --]

Re: [dm-crypt] (no subject)

[Arno Wagner]

Hi,

first, please update cryptsetup to a current version. It reads 
the parameters from the LUKS header and hence will work with 
older settings in there.

Second, what is different when it works vs. when it does not work?
Xterm vs. text-console? Uses some program that may have changed
the charset? Section 1.2 of the FAQ may provide some hints:
  https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

Does this happen with a passphrase that has no spaical characters and 
only 7-bit ASCII ones?

Arno

On Mon, May 04, 2015 at 16:50:34 CEST, janemba wrote:
> Hi,
> 
> I have an issue with LUKS. I have a new external hard drive with the
> following characteristics :
> 
> Host scsi11: usb-storage
> Vendor: Seagate (2TB)
> Product: Expansion
> Serial Number: xxx
> Protocol: Transparent SCSI
> Transport: Bulk
> Quirks: SANE_SENSE
> 
> Also I have cryptsetup install on my box with version 1.4.3 and kernel
> 3.14.5. I can't update cryptsetup on this box as I ciphered the hard drive
> with this version and I'm afraid to not be able to deciphered the hard
> drive if cryptsetup version change.
> 
> Moreover, I'm using the external hard drive only with this box. This mean I
> setup nad I use cryptsetup on my external hard drive only with the box
> above.
> 
> My issue is each time I open the device I got the following error :
> "No key available with this passphrase."
> 
> I open it like below :
>  $ cryptsetup luksOpen  /dev/sdb1 safehd
> 
> But sometimes it works so this is not a password issue. Also, I setup again
> the hard drive by zeroing the whole device and I got the exact same issue.
> 
> Do you know whats going ?
> 
> Please let me know if you want further information.
> 
> Thanks

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

[dm-crypt] (no subject)

[janemba]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

Hi,

I have an issue with LUKS. I have a new external hard drive with the
following characteristics :

Host scsi11: usb-storage
Vendor: Seagate (2TB)
Product: Expansion
Serial Number: xxx
Protocol: Transparent SCSI
Transport: Bulk
Quirks: SANE_SENSE

Also I have cryptsetup install on my box with version 1.4.3 and kernel
3.14.5. I can't update cryptsetup on this box as I ciphered the hard drive
with this version and I'm afraid to not be able to deciphered the hard
drive if cryptsetup version change.

Moreover, I'm using the external hard drive only with this box. This mean I
setup nad I use cryptsetup on my external hard drive only with the box
above.

My issue is each time I open the device I got the following error :
"No key available with this passphrase."

I open it like below :
 $ cryptsetup luksOpen  /dev/sdb1 safehd

But sometimes it works so this is not a password issue. Also, I setup again
the hard drive by zeroing the whole device and I got the exact same issue.

Do you know whats going ?

Please let me know if you want further information.

Thanks

[-- Attachment #2: Type: text/html, Size: 1437 bytes --]

[dm-crypt] (no subject)

[Redwood Hyd]

Hi All ,

I did an experimental kernel change in linux/drivers/md/dm-crypt.c for
improving crypto HW performance.
Here is brief of it
static void crypt_io_hints(struct dm_target *ti,
                            struct queue_limits *limits)
{
  limits->physical_block_size = 32768;
  blk_limits_io_min(limits, 32768);
  blk_limits_io_opt(limits, 32768);
}

It works (passed iozone -a,  robocopy from samba client) and doubled
performance of dm-crypt WRITES !

Problem -
After above change cryptsetup luks format started failing disk
validations so additionally in
Cryptsetup-1.1.3  I  did  following changes to pass disk validation:
========================================================
/* Change-1 to overcome validation failure from dm-table.c that
"adding target device  caused an alignment inconsistency"  */
#define LUKS_STRIPES increased from  4000 to 524288

/* Change-2 to overcome validation failure in dm-table.c
"device-mapper: table: 253:1 start=8 not aligned to h/w logical block
size 32768 of dm-0" */
#define LUKS_ALIGN_KEYSLOTS  increased from  4096 to 32768

/* Change-3 Additionally did following change */
#define DEFAULT_ALIGNMENT    increased from  4096 to 32768

Question - Can someone recommend any later  version of cryptsetup
package where I don't need to change
                 cryptsetup and luks format can still pass
validate_hardware_logical_block_alignment() in dm-table.c  for 32k
encrypt block device ?

Performance related changes are experimental - If someone can suggest
things around this I will post my results to forum.

Regards and Thanks in advance
Redwood hyd

[dm-crypt] (no subject)

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

A user of cryptsetup(through zuluCrypt) asked me a question i can not
answer and asking it here.

In his system,"cryptsetup benchmark" gives the following results:

[root@sheep 13] ~ > cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       341333 iterations per second
PBKDF2-sha256     193607 iterations per second
PBKDF2-sha512      64125 iterations per second
PBKDF2-ripemd160  303758 iterations per second
PBKDF2-whirlpool   64125 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   183,6 MiB/s   215,4 MiB/s
 serpent-cbc   128b    68,0 MiB/s    68,9 MiB/s
 twofish-cbc   128b   167,7 MiB/s   177,5 MiB/s
     aes-cbc   256b   142,3 MiB/s   161,5 MiB/s
 serpent-cbc   256b    69,7 MiB/s    67,0 MiB/s
 twofish-cbc   256b   170,1 MiB/s   177,8 MiB/s
     aes-xts   256b   201,2 MiB/s   205,6 MiB/s
 serpent-xts   256b    69,7 MiB/s    67,6 MiB/s
 twofish-xts   256b   180,5 MiB/s   175,6 MiB/s
     aes-xts   512b   147,0 MiB/s   152,5 MiB/s
 serpent-xts   512b    70,5 MiB/s    67,8 MiB/s
 twofish-xts   512b   182,0 MiB/s   176,0 MiB/s

The system is decent enought.

The write speed he is getting though through the mapper is unusually
slow,the test is below:


[root@sheep 8] ~ > dd if=/dev/zero of=test.img bs=70M count=1
1+0 Datensätze ein
1+0 Datensätze aus
73400320 Bytes (73 MB) kopiert, 2,58497 s, 28,4 MB/s

[17.03.2013 21:50 Uhr]
[root@sheep 9] ~ > cryptsetup create test test.img
Passsatz eingeben:

[17.03.2013 21:51 Uhr]
[root@sheep 10] ~ > dd if=/dev/zero of=/dev/mapper/test bs=10M count=1
1+0 Datensätze ein
1+0 Datensätze aus
10485760 Bytes (10 MB) kopiert, 67,2014 s, 156 kB/s

[17.03.2013 21:52 Uhr]
[root@sheep 11] ~ > cryptsetup remove test

As the test show,He is getting 156kB/s when using dd over the encryption
mapper verses 28MB/s when using dd straight.

Where is the wrong in his system? version of cryptsetup used is 1.6.0

[-- Attachment #2: Type: text/html, Size: 2201 bytes --]

Re: [dm-crypt] (no subject)

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

> Seems it was combination of not-too-much compatible change in libdevmapper
> (it stat() the path and fails earlier) and combination of new features in
> tcrypt.
>
> Should be fixed in git tree now.
>
> Thanks,
> Milan
>
Just updated from git and the problem seem to be fixed.
Thanks for maintaining the old behavior.

[-- Attachment #2: Type: text/html, Size: 594 bytes --]

Re: [dm-crypt] (no subject)

[Milan Broz]

On 12/30/2012 10:19 AM, .. ink .. wrote:
> Device-mapper programs usually strip path if it is default
> /dev/mapper though. Anyway, I'll check what can be done here (mainly
> if it worked before).
> 
> 
> It always worked with full path,In my test here,full path still works
> with plain volumes as well as luks volumes.Only truecrypt volumes
> have a problem and this suggests code paths specific to truecrypt
> volumes are at fault.

Seems it was combination of not-too-much compatible change in libdevmapper
(it stat() the path and fails earlier) and combination of new features in tcrypt.

Should be fixed in git tree now.

Thanks,
Milan

Re: [dm-crypt] (no subject)

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

> Device-mapper programs usually strip path if it is default /dev/mapper
> though.
> Anyway, I'll check what can be done here (mainly if it worked before).
>

It always worked with full path,In my test here,full path still works with
plain volumes as well as luks volumes.Only truecrypt volumes have a problem
and this suggests code paths specific to truecrypt volumes are at fault.

[-- Attachment #2: Type: text/html, Size: 643 bytes --]

Re: [dm-crypt] (no subject)

[Milan Broz]

On 12/30/2012 08:12 AM, .. ink .. wrote:
> 
> As the above two commands show with "status" argument,the command fail when the given path is full path.

Hm, because full path was never supported in fact as parameter (in API, cmdline should support it)
(it should be the same identifies as you see in dmsetup).

Device-mapper programs usually strip path if it is default /dev/mapper though.
Anyway, I'll check what can be done here (mainly if it worked before).

Thanks,
Milan

Re: [dm-crypt] (no subject)

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Sat, Dec 29, 2012 at 6:39 PM, Milan Broz <gmazyland@gmail.com> wrote:

> On 12/30/2012 12:15 AM, .. ink .. wrote:
> >
> > i meant "tcrypt" for "truecrypt".
> >
> > Way to test.
> > 1. create a truecrypt mapper.
> > 2. call "crypt_init_by_name" to create context through the opened mapper
> and the function call will fail.
>
> interesting, cryptsetup close (action_close) uses this and it doesn't fail
> here...
>
>
I think i have found the problem,here is a test to show it:

[root@mtz build]# cryptsetup open --type tcrypt /home/ink/src/truecrypt
tcrypt
Enter passphrase:

[root@mtz build]# cryptsetup status /dev/mapper/tcrypt
/dev/mapper/tcrypt is active.
Device /dev/mapper/tcrypt_1 not found

[root@mtz build]# cryptsetup status tcrypt
/dev/mapper/tcrypt is active.
  type:    TCRYPT
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/loop0
  loop:    /home/ink/src/truecrypt
  offset:  256 sectors
  size:    40448 sectors
  skipped: 256 sectors
  mode:    read/write

As the above two commands show with "status" argument,the command fail when
the given path is full path.

"crypt_init_by_name" shows the same behavior,it fail when the path given is
full path and pass if it is only the name of the mapper.

I have always used full path on the second argument with
"crypt_init_by_name".

[-- Attachment #2: Type: text/html, Size: 2012 bytes --]

Re: [dm-crypt] (no subject)

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

the truecrypt container file was created by truecrypt version 7.0a using
default options

The truecrypt mapper was created using cryptsetup 1.6.0-rc1 in my previous
post.My own tool can open and close truecrypt volumes so all other
functions seem to work except this one.

you can look at line 365 in the below link to see the my current work
around for this problem.

http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/status.c?spec=svn48c37c189cb6b69b73b8760b4bc86236f5bde5b7&r=48c37c189cb6b69b73b8760b4bc86236f5bde5b7




On Sat, Dec 29, 2012 at 6:39 PM, Milan Broz <gmazyland@gmail.com> wrote:

> On 12/30/2012 12:15 AM, .. ink .. wrote:
> >
> > i meant "tcrypt" for "truecrypt".
> >
> > Way to test.
> > 1. create a truecrypt mapper.
> > 2. call "crypt_init_by_name" to create context through the opened mapper
> and the function call will fail.
>
> interesting, cryptsetup close (action_close) uses this and it doesn't fail
> here...
>
> How do you create that truecrypt device? (It cannot use devices directly
> mapped by
> truecrypt itself, cryptsetup will handle only devices which have proper DM
> UUID,
> activated by cryptsetup).
>
> Can you send me some code sample which fails?
>
> Milan
>

[-- Attachment #2: Type: text/html, Size: 1971 bytes --]

Re: [dm-crypt] (no subject)

[Milan Broz]

On 12/30/2012 12:15 AM, .. ink .. wrote:
> 
> i meant "tcrypt" for "truecrypt".
> 
> Way to test.
> 1. create a truecrypt mapper.
> 2. call "crypt_init_by_name" to create context through the opened mapper and the function call will fail.

interesting, cryptsetup close (action_close) uses this and it doesn't fail here...

How do you create that truecrypt device? (It cannot use devices directly mapped by
truecrypt itself, cryptsetup will handle only devices which have proper DM UUID,
activated by cryptsetup).

Can you send me some code sample which fails?

Milan

Re: [dm-crypt] (no subject)

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

i meant "tcrypt" for "truecrypt".

Way to test.
1. create a truecrypt mapper.
2. call "crypt_init_by_name" to create context through the opened mapper
and the function call will fail.

It used to work at some point with git version after truecrypt
functionality was added.I noticed it stopped working last night and i just
tested it with the just released rc and noticed the breakage is still there
and thats what i am reporting.

i tested it with a device file.



On Sat, Dec 29, 2012 at 5:46 PM, Milan Broz <gmazyland@gmail.com> wrote:

> On 12/29/2012 11:22 PM, .. ink .. wrote:
> >
> > test with 1.6.0.-rc1
> >
> > crypt_init_by_name doesnt seem to work when the second argument is a
> mapper to a lcrypt volume
>
> Please better create an issue on project page and add more context there.
> (perhaps I am too tired but ... I do not understand what you are saying.
> What is lcrypt? :)
>
> Milan
>

[-- Attachment #2: Type: text/html, Size: 1504 bytes --]

Re: [dm-crypt] (no subject)

[Milan Broz]

On 12/29/2012 11:22 PM, .. ink .. wrote:
> 
> test with 1.6.0.-rc1
> 
> crypt_init_by_name doesnt seem to work when the second argument is a mapper to a lcrypt volume

Please better create an issue on project page and add more context there.
(perhaps I am too tired but ... I do not understand what you are saying. What is lcrypt? :)

Milan

[dm-crypt] (no subject)

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

test with 1.6.0.-rc1

crypt_init_by_name doesnt seem to work when the second argument is a mapper
to a lcrypt volume

[-- Attachment #2: Type: text/html, Size: 152 bytes --]

Re: [dm-crypt] (no subject)

[Claudio Moretti]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

On Wed, Oct 10, 2012 at 11:09 PM, ffrizzy <ffrizzy@gmail.com> wrote:

> GET ME OUT OF YOUR LOSTS
> ASAP
> THANKS
>


http://www.saout.de/mailman/listinfo/dm-crypt

Unsubscribe yourself.

ASAP.

Thanks.

[-- Attachment #2: Type: text/html, Size: 578 bytes --]

[dm-crypt] (no subject)

[ffrizzy]

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

Hi

I have no interest in your mails - I do not know why you send me your mails.
And i demand that you delete my address from you correspondence
Thanks

[-- Attachment #2: Type: text/html, Size: 210 bytes --]

[dm-crypt] (no subject)

[ffrizzy]

[-- Attachment #1: Type: text/plain, Size: 37 bytes --]

GET ME OUT OF YOUR LOSTS
ASAP
THANKS

[-- Attachment #2: Type: text/html, Size: 68 bytes --]

[dm-crypt] (no subject)

[ffrizzy]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

I di dnot ask to subscribe
I have nothongto do with you
TAKE MY ADRESSDOWN !
DO NOT SWEND ME ANYTHING !!

[-- Attachment #2: Type: text/html, Size: 160 bytes --]

[dm-crypt] (no subject)

[ffrizzy]

[-- Attachment #1: Type: text/plain, Size: 55 bytes --]

get me out of your list
di not send me anything
thanks

[-- Attachment #2: Type: text/html, Size: 86 bytes --]

Re: [dm-crypt] (no subject)

[Arno Wagner]

On Mon, Sep 03, 2012 at 06:20:35PM -0700, Anil wrote:
> Newbie here. I need to use dm-crypt with aes-xts. How is dm-crypt called? 

Refer to the man-page and the FAQ. 

> Is it possible to encrypt data while being saved on the fly?

That is its job. It is not possible to do it in any other way.

> Will there be file filters to encrypt/decrypt while saving 
> and opening the file?

No.

> Is aes-xts provided elsewhere as a plugin? or is it part of dmcrypt?

Ciphers and modes are the job of the kernel, not dm-crypt.
It just uses them. 

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

[dm-crypt] (no subject)

[Anil]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

Newbie here. I need to use dm-crypt with aes-xts. How is dm-crypt called? Is it possible to encrypt data while being saved on the fly?
Will there be file filters to encrypt/decrypt while saving and opening the file?
Is aes-xts provided elsewhere as a plugin? or is it part of dmcrypt?

[-- Attachment #2: Type: text/html, Size: 466 bytes --]

[dm-crypt] (no subject)

[Ingo Schmitt]

[dm-crypt] (no subject)

[Rookcifer]

-- 
--Waiting on ECC