[dm-crypt] Securely erase LUKS header

[dm-crypt] Securely erase LUKS header

[hephey]

I'm having trouble calculating the amount of data I need to erase in the
header.

The af-stripes appears to be hardcoded to 4000, according to the
specification [1].

First I made an encrypted loop-device, using default options:

  cryptsetup luksFormat /dev/loop0

I then made a header backup, using

  cryptsetup luksHeaderBackup --header-backup-file /tmp/header.img /dev/loop0

The size of this backup (/tmp/header.img) is exactly 1.052.672 bytes,
which fits with the number given in the FAQ (see 5.4) [2]. I'm asumming
that cryptsetup's calculation is correct.

In the FAQ it's also stated that to wipe the header, I need to use to
formula:

  header size = (keyslots x stripes x keysize) + offset bytes

I find the relevant values by issuing:

  cryptsetup luksDump /dev/loop0

The output of this command is on a pastebin here:
http://pastebin.com/Nw6NJaQc

It seems that my equation would be
  header size = (1 keyslot * 4000 stripes * 256 bits) + 4096 = 1.028.096
bytes

This size is smaller than the size given in the FAQ and the size of my
header backup - How come?

However, if I set the amount of stripes to 4096 in the formula, I get the
correct
size:

  header size = (1 keyslot * 4096 stripes * 256 bits) + 4096 = 1.052.672
bytes

What am I doing wrong here? Is luksDump showing the wrong amount of
stripes? I would like to make a dynamic script that could quickly determin
the correct values for the formula using luksDump and wipe whatever
luks-encrypted device that is given as an argument.

Please tell if you need more information.

------------------
REFERENCES
1: http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf
2:
https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects

Re: [dm-crypt] Securely erase LUKS header

[Milan Broz]

On 10.3.2013 14:19, hephey@lavabit.com wrote:
> I'm having trouble calculating the amount of data I need to erase in the
> header.
>
> The af-stripes appears to be hardcoded to 4000, according to the
> specification [1].
>
> First I made an encrypted loop-device, using default options:
>
>    cryptsetup luksFormat /dev/loop0
>
> I then made a header backup, using
>
>    cryptsetup luksHeaderBackup --header-backup-file /tmp/header.img /dev/loop0
>
> The size of this backup (/tmp/header.img) is exactly 1.052.672 bytes,
> which fits with the number given in the FAQ (see 5.4) [2]. I'm asumming
> that cryptsetup's calculation is correct.

luksHeaderBackup in older versions saved header including alignment area
(not used area between keyslots and data offset start).
I later changed that to save only real used data, so the backup is smaller.
(Check the latest version, I think you get slightly smaller backup file.)

FYI - the layout is basically (* == alignment area, unused)

|LUKShdr|*|slot1|*|slot2|*| ... |slot8|*|CIPHERTEXT DATA
                                         ^ data payload offset (luksDump)
           ^1      ^2 ...  slots offsets (see luksDump)

Keyslot oofsets are always aligned to multiple of 4096 bytes, data area
alignment depends paramaters, ususally it is aligned to multiple of 1MiB.

So numbers are correct. (From above, the simplest method to erase
it is to use data offset and wipe everyting before that).

> However, if I set the amount of stripes to 4096 in the formula, I get the

Stripe count is always hardcoded to 4000 for LUKS1 format.

You just see bigger backup file because of data alignment mentioned above.

Milan

Re: [dm-crypt] Securely erase LUKS header

[Arno Wagner]

On Sun, Mar 10, 2013 at 09:19:32AM -0400, hephey@lavabit.com wrote:
> I'm having trouble calculating the amount of data I need to erase in the
> header.
> 
> The af-stripes appears to be hardcoded to 4000, according to the
> specification [1].
> 
> First I made an encrypted loop-device, using default options:
> 
>   cryptsetup luksFormat /dev/loop0
> 
> I then made a header backup, using
> 
>   cryptsetup luksHeaderBackup --header-backup-file /tmp/header.img /dev/loop0
> 
> The size of this backup (/tmp/header.img) is exactly 1.052.672 bytes,
> which fits with the number given in the FAQ (see 5.4) [2]. I'm asumming
> that cryptsetup's calculation is correct.
> 
> In the FAQ it's also stated that to wipe the header, I need to use to
> formula:
> 
>   header size = (keyslots x stripes x keysize) + offset bytes

In 5.4, I state just to wipe the first 10MB to be safe. 
Do I have the formula above anywthere as explicitely
recommended for wipes? Is so, plese tell me where, so I 
can fix it.

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
----
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] hardware encryption

[lxnf98mm]

Can dm-crypt make use of the encryption capabilities of the cpu
I am probably not asking the right question but gotta start somewhere

Richard

Re: [dm-crypt] hardware encryption

[.. ink ..]

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

On Wed, Mar 13, 2013 at 5:45 PM, <lxnf98mm@gmail.com> wrote:

> Can dm-crypt make use of the encryption capabilities of the cpu
> I am probably not asking the right question but gotta start somewhere
>
>
The answer to your question according the  link given next is "yes" :
http://www.saout.de/pipermail/dm-crypt/2011-October/002092.html

best place to start with cryptsetup is to go through its FAQ located at:
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions

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

Re: [dm-crypt] hardware encryption

[lxnf98mm]

On Wed, 13 Mar 2013, .. ink .. wrote:

> On Wed, Mar 13, 2013 at 5:45 PM, <lxnf98mm@gmail.com> wrote:
>
>> Can dm-crypt make use of the encryption capabilities of the cpu
>> I am probably not asking the right question but gotta start somewhere
>>
>>
> The answer to your question according the  link given next is "yes" :
> http://www.saout.de/pipermail/dm-crypt/2011-October/002092.html
>
> best place to start with cryptsetup is to go through its FAQ located at:
> http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
>

This is probably not the place to ask but how about a Marvell 88F6281
www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
I tried openssl speed test and it out performs a 3.4Ghz Intel
Right now running dm-crypt on the Marvell uses about 50% cpu

Richard

Re: [dm-crypt] hardware encryption

[Michael Stapelberg]

Hi Richard,

lxnf98mm@gmail.com writes:
> This is probably not the place to ask but how about a Marvell 88F6281
> www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> I tried openssl speed test and it out performs a 3.4Ghz Intel Right
> now running dm-crypt on the Marvell uses about 50% cpu
I am using that SoC in my qnap TS-119P II. Can you please provide the
precise results you have? In my tests, the machine really did not
outperform my Intel box :).

-- 
Best regards,
Michael

Re: [dm-crypt] hardware encryption

[lxnf98mm]

On Thu, 14 Mar 2013, Michael Stapelberg wrote:

> Hi Richard,
>
> lxnf98mm@gmail.com writes:
>> This is probably not the place to ask but how about a Marvell 88F6281
>> www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
>> I tried openssl speed test and it out performs a 3.4Ghz Intel Right
>> now running dm-crypt on the Marvell uses about 50% cpu
> I am using that SoC in my qnap TS-119P II. Can you please provide the
> precise results you have? In my tests, the machine really did not
> outperform my Intel box :).
>
>

Been doing research and here is my take
I have a module mv_cesa that is the marvell crypto module
Offloading for dm_crypt is working
If you want offloading for ssl use cryptodev and recompile openssl
http://cryptodev-linux.org/
http://ortizaudio.blogspot.com/2011/10/using-dreamplugs-crypto-chip.html
http://forum.doozan.com/read.php?2,9619,9924,quote=1
http://www.newit.co.uk/forum/index.php/topic,2030.0.html



Before cryptodev

rray@nsa320:~$ openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 1613415 aes-128-cbc's in 2.97s
Doing aes-128-cbc for 3s on 64 size blocks: 488840 aes-128-cbc's in 2.93s
Doing aes-128-cbc for 3s on 256 size blocks: 129060 aes-128-cbc's in 2.93s
Doing aes-128-cbc for 3s on 1024 size blocks: 33071 aes-128-cbc's in 2.96s
Doing aes-128-cbc for 3s on 8192 size blocks: 4193 aes-128-cbc's in 2.99s
OpenSSL 1.0.1c 10 May 2012
built on: Wed Jun  6 17:45:51 UTC 2012
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc       8691.80k    10677.73k    11276.23k    11440.78k    11487.98k



With cryptodev

rray@nsa320:~$ openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 89917 aes-128-cbc's in 0.06s
Doing aes-128-cbc for 3s on 64 size blocks: 86802 aes-128-cbc's in 0.15s
Doing aes-128-cbc for 3s on 256 size blocks: 60712 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 1024 size blocks: 40407 aes-128-cbc's in 0.08s
Doing aes-128-cbc for 3s on 8192 size blocks: 8190 aes-128-cbc's in 0.01s
OpenSSL 1.0.1e 11 Feb 2013
built on: Thu Mar 14 15:12:52 CDT 2013
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      23977.87k    37035.52k   155422.72k   517209.60k  6709248.00k



Richard

Re: [dm-crypt] hardware encryption

[Matthias Schniedermeyer]

On 14.03.2013 06:12, lxnf98mm@gmail.com wrote:
> On Wed, 13 Mar 2013, .. ink .. wrote:
> 
> >On Wed, Mar 13, 2013 at 5:45 PM, <lxnf98mm@gmail.com> wrote:
> >
> >>Can dm-crypt make use of the encryption capabilities of the cpu
> >>I am probably not asking the right question but gotta start somewhere
> >>
> >>
> >The answer to your question according the  link given next is "yes" :
> >http://www.saout.de/pipermail/dm-crypt/2011-October/002092.html
> >
> >best place to start with cryptsetup is to go through its FAQ located at:
> >http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
> >
> 
> This is probably not the place to ask but how about a Marvell 88F6281
> www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> I tried openssl speed test and it out performs a 3.4Ghz Intel
> Right now running dm-crypt on the Marvell uses about 50% cpu

Given that openssl doesn't support AES-NI i'm not surprized.

Last time i looked AES-NI support in openssl was "in Limbo" and it may 
still take quite some time(years) until there is a release which 
officially supports AES-NI. This is despite first patches beeing made 
available before there was silicon, so openssl is quite a few years 
behind.

I'm using an unofficial "something" (Can't remember what it is excatly ) 
so that openssl can utelize AES-NI which in turn enables AES-NI usage 
for SSH, so i can use it for scp or rsync over SSH.
The difference is quite noticable, altough in LANs i just use ARCFOUR. 
No patching necesarry to saturate Gigabit. :-)

When i tested it some time back over loopback both AES-128-CBC(*) (with 
AES-NI) and ARCFOUR peaked at about 400MB/s(IIRC), so no problem doing 
the 110MB/s needed to saturate Gigabit.


*:
AES-128-CTR doesn't appeared to either support AES-NI or get any 
performance benefit from AES-NI.


-- 

Matthias

Re: [dm-crypt] hardware encryption

[Yves-Alexis Perez]

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

On jeu., 2013-03-14 at 14:14 +0100, Matthias Schniedermeyer wrote:
> Given that openssl doesn't support AES-NI i'm not surprized.

Where did you get that impression?
> 
> Last time i looked AES-NI support in openssl was "in Limbo" and it
> may 
> still take quite some time(years) until there is a release which 
> officially supports AES-NI. This is despite first patches beeing made 
> available before there was silicon, so openssl is quite a few years 
> behind.

Actually, OpenSSL supports AES-NI since 1.0.1 (see
http://www.openssl.org/news/changelog.html)
> 
> I'm using an unofficial "something" (Can't remember what it is excatly
> ) 
> so that openssl can utelize AES-NI which in turn enables AES-NI usage 
> for SSH, so i can use it for scp or rsync over SSH.
> The difference is quite noticable, altough in LANs i just use
> ARCFOUR. 
> No patching necesarry to saturate Gigabit. :-)
> 
> When i tested it some time back over loopback both AES-128-CBC(*)
> (with 
> AES-NI) and ARCFOUR peaked at about 400MB/s(IIRC), so no problem
> doing 
> the 110MB/s needed to saturate Gigabit.

It all really depends on block size. But on my (Core i7 L640) laptop,
there's really no reason to use rc4 anymore. CBC is not the best
example, aes-128-cbc is indeed accelerated by AES-NI instructions but
you really go fast with a mode using PCLMULQDQD like XTS:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes
rc4             255340.98k   469098.47k   599298.65k   658621.73k
679368.02k
aes-128 cbc      85363.96k    91553.34k    93105.32k    93570.31k
93784.75k
aes-128-xts     272573.48k   849359.06k  1540640.28k  1956586.50k
2111556.27k

It's even stronger when you use authenticated ciphers like GCM if you
compare it against enc+mac. You can't openssl speed on those but using
1k blocs:

for cipher in aes-128-cbc-hmac-sha1 aes-128-gcm rc4-hmac-md5; do echo
$cipher; dd if=/dev/zero bs=1k count=1M | openssl enc -${cipher} -pass
pass:foo > /dev/null; done 
aes-128-cbc-hmac-sha1
1048576+0 records in
1048576+0 records out
1073741824 bytes (1,1 GB) copied, 3,27757 s, 328 MB/s
aes-128-gcm
1048576+0 records in
1048576+0 records out
1073741824 bytes (1,1 GB) copied, 1,90992 s, 562 MB/s
rc4-hmac-md5
1048576+0 records in
1048576+0 records out
1073741824 bytes (1,1 GB) copied, 3,40679 s, 315 MB/s

It's a bit out of scope for this list, but that means using dm-crypt
aes-xts-plain64 on an AES-NI CPU really makes sense. On those boxes it
might be even faster to use aes-256-xts than aes-128-cbc.

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [dm-crypt] hardware encryption

[Yves-Alexis Perez]

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

On jeu., 2013-03-14 at 21:50 +0100, Yves-Alexis Perez wrote:
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> rc4             255340.98k   469098.47k   599298.65k   658621.73k
> 679368.02k
> aes-128 cbc      85363.96k    91553.34k    93105.32k    93570.31k
> 93784.75k
> aes-128-xts     272573.48k   849359.06k  1540640.28k  1956586.50k
> 2111556.27k

And really openssl speed is a bad benchmark. -evp isn't always passed
like it should:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4             228707.92k   454028.37k   585298.60k   659777.58k   616865.85k
aes-128-cbc     632020.45k   733300.57k   750031.70k   760410.41k   755897.69k
aes-128-xts     257314.54k   806366.02k  1490648.92k  1946742.50k  2119215.79k

Sorry for that.
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [dm-crypt] hardware encryption

[Matthias Schniedermeyer]

On 14.03.2013 21:50, Yves-Alexis Perez wrote:
> On jeu., 2013-03-14 at 14:14 +0100, Matthias Schniedermeyer wrote:
> > Given that openssl doesn't support AES-NI i'm not surprized.
> 
> Where did you get that impression?
> > 
> > Last time i looked AES-NI support in openssl was "in Limbo" and it
> > may 
> > still take quite some time(years) until there is a release which 
> > officially supports AES-NI. This is despite first patches beeing made 
> > available before there was silicon, so openssl is quite a few years 
> > behind.
> 
> Actually, OpenSSL supports AES-NI since 1.0.1 (see
> http://www.openssl.org/news/changelog.html)

I stand corrected.
I appears the last time i look was january 2012 which was about 2 month 
before 1.0.1.
Which is still quite a few years late and only just before the 3rd 
generation of silicon (a.k.a. Ivy Bridge) was released.

> > I'm using an unofficial "something" (Can't remember what it is excatly
> > ) 
> > so that openssl can utelize AES-NI which in turn enables AES-NI usage 
> > for SSH, so i can use it for scp or rsync over SSH.
> > The difference is quite noticable, altough in LANs i just use
> > ARCFOUR. 
> > No patching necesarry to saturate Gigabit. :-)
> > 
> > When i tested it some time back over loopback both AES-128-CBC(*)
> > (with 
> > AES-NI) and ARCFOUR peaked at about 400MB/s(IIRC), so no problem
> > doing 
> > the 110MB/s needed to saturate Gigabit.
> 
> It all really depends on block size. But on my (Core i7 L640) laptop,
> there's really no reason to use rc4 anymore. CBC is not the best
> example, aes-128-cbc is indeed accelerated by AES-NI instructions but
> you really go fast with a mode using PCLMULQDQD like XTS:

Not for SSH. It's either CBC or CTR.
Core i7 2600, openssl 1.0.1e:
aes-128-cbc     664319.53k   725474.88k   734899.20k   739633.83k   741460.93k
aes-128-ctr     435376.52k  1366581.94k  2590570.68k  3404566.09k  3712237.79k

ctr benchmarks good, but SSH does something wrong, copying a 1GB file 
from tmpfs to tmpfs via loopback:
scp -c aes128-cbc .... 100% 1024MB 256.0MB/s   00:04
scp -c aes128-ctr .... 100% 1024MB  78.8MB/s   00:13

That is the same speed as software AES, maybe it doesn't select the 
right engine or something like that.

ssh -V
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013

> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> rc4             255340.98k   469098.47k   599298.65k   658621.73k
> 679368.02k
> aes-128 cbc      85363.96k    91553.34k    93105.32k    93570.31k
> 93784.75k
> aes-128-xts     272573.48k   849359.06k  1540640.28k  1956586.50k
> 2111556.27k
> 
> It's even stronger when you use authenticated ciphers like GCM if you
> compare it against enc+mac. You can't openssl speed on those but using
> 1k blocs:
> 
> for cipher in aes-128-cbc-hmac-sha1 aes-128-gcm rc4-hmac-md5; do echo
> $cipher; dd if=/dev/zero bs=1k count=1M | openssl enc -${cipher} -pass
> pass:foo > /dev/null; done 
> aes-128-cbc-hmac-sha1
> 1048576+0 records in
> 1048576+0 records out
> 1073741824 bytes (1,1 GB) copied, 3,27757 s, 328 MB/s
> aes-128-gcm
> 1048576+0 records in
> 1048576+0 records out
> 1073741824 bytes (1,1 GB) copied, 1,90992 s, 562 MB/s
> rc4-hmac-md5
> 1048576+0 records in
> 1048576+0 records out
> 1073741824 bytes (1,1 GB) copied, 3,40679 s, 315 MB/s
> 
> It's a bit out of scope for this list, but that means using dm-crypt
> aes-xts-plain64 on an AES-NI CPU really makes sense. On those boxes it
> might be even faster to use aes-256-xts than aes-128-cbc.

You would have to try it with cryptsetup and i can say XTS, on a Core i7 
3770, peaks at over 1GB/s. I'd say that is plenty fast. :-)

Highest number i personally achieved was decrypting an old loopaes 
DVD-image-file with aespipe (V1 format, which means: aes-128-CBC). It 
took about 3 seconds to decrypt the 4489 MB file (tmpfs to tmpfs) so 
nearly 1.5 GB/s. :-)





-- 

Matthias

Re: [dm-crypt] hardware encryption

[Thomas Bächler]

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

Am 13.03.2013 22:45, schrieb lxnf98mm@gmail.com:
> Can dm-crypt make use of the encryption capabilities of the cpu
> I am probably not asking the right question but gotta start somewhere
> 
> Richard

In short, dm-crypt uses whatever the kernel's crypto API provides. For
details on that, refer to the configuration of your kernel.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]