All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-crypt] Cascading two plain dm-crypt volumes
@ 2013-11-28 23:32 anderson jackson
       [not found] ` <CAMw1ynShpDpGVNWZGfHNkvApbiMadidiBkVStDsL9AUkbZ+B9w@mail.gmail.com>
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: anderson jackson @ 2013-11-28 23:32 UTC (permalink / raw)
  To: dm-crypt

Hello, 

I have a small question regarding luks and plain dm-crypt, and I am unsure
what to use. 

I feel that the advantages provided by Luks obviously offers extra security
compared to plain, however I feel uneasy about the obviousness of the fact
that the drive is encrypted. Mainly because a disk with just random data could
have been wiped instead of encrypted. I would like the extra security provided
by luks without it being obvious that the disk is encrypted. To combat this I
was thinking about doing a cascade of two identical ciphers in plain mode, in
this case AES because the AES-NI acceleration will severely limit the
performance penalty of cascading two ciphers, I had the following setup in
mind:

first step: cryptsetup –-cipher=aes-xts-plain –-offset=0 –-key-size=512
open –-type=plain /dev/sdx cascade1, with the first independend password.
Second step: cryptsetup –-cipher=aes-xts-plain –-offset=0 –-key-size=512
open –-type=plain /dev/mapper/cascade1 cascade2, with the second independed
unrelated password.
Third step: nwipe --rounds=1 --noblank --prng=twister --method=random
/dev/mapper/cascade2, this will fill the last block device with random data to
completely fill up the entire disk. 
Fourth step: format the last block device with ext4.

My theory then is, that even when an attacker finds the first passwords, he
will never know he has because the result will be random just as with a wrong
password. In fact all possible passwords will result in random data. The
attacker has no way of knowing if there are cascades and how many. Am I right
to come to this conclusion or should I stick with luks and deal with it being
an obvious encrypted disk?

Kind regards. 



____________________________________________________________
South Africas premier free email service - www.webmail.co.za 

Save 25% on insurance – Dial Direct
http://www.dialdirect.co.za/smart-gets-a-tomtom?vdn=15752

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
       [not found] ` <CAMw1ynShpDpGVNWZGfHNkvApbiMadidiBkVStDsL9AUkbZ+B9w@mail.gmail.com>
@ 2013-11-29  0:08   ` Claudio Moretti
  2013-11-29  0:32     ` Arno Wagner
  0 siblings, 1 reply; 10+ messages in thread
From: Claudio Moretti @ 2013-11-29  0:08 UTC (permalink / raw)
  To: dm-crypt

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

Forgot to hit "reply to all". Forwarding to the list.
---------- Messaggio inoltrato ----------
Da: flyingstar16@gmail.com
Data: 29/nov/2013 00:06
Oggetto: Re: [dm-crypt] Cascading two plain dm-crypt volumes
A: anderson jackson <thewizard@mighty.co.za>
Cc:


Il 28/nov/2013 23:32 "anderson jackson" <thewizard@mighty.co.za> ha scritto:
>
> Hello,
>
> I have a small question regarding luks and plain dm-crypt, and I am unsure
> what to use.
>
> I feel that the advantages provided by Luks obviously offers extra
security
> compared to plain, however I feel uneasy about the obviousness of the fact
> that the drive is encrypted. Mainly because a disk with just random data
could
> have been wiped instead of encrypted. I would like the extra security
provided
> by luks without it being obvious that the disk is encrypted. To combat
this I
> was thinking about doing a cascade of two identical ciphers in plain mode

I may be mistaken, but (a) if you're using plain mode, there is no
indication that the disk is encrypted; from the FAQ

"Plain format is just that: It has no metadata on disk, reads all
parameters from the commandline (or the defaults), derives a master-key
from the passphrase and then uses that to de-/encrypt the sectors of the
device, with a direct 1:1 mapping between encrypted and decrypted sectors."

And if you're worried about the fact that if a hacker gets you password
right he will be able to decrypt your disk, there is no guarantee that it
can happen twice. True, the probability get extremely reduced, but AFAIK
current estimates say that to crack AES128 you need 30 years of continuous
computing, so...

If instead you meant two cascaded luks partition, you still need the luks
identifier in the "inner" partition so an attacker would know when your
partition is open because the luks header of the partition will be in
plaintext.

All of this is to the best of my actual knowledge, if I got something
wrong, please correct me.

Cheers,

Claudio

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-28 23:32 [dm-crypt] Cascading two plain dm-crypt volumes anderson jackson
       [not found] ` <CAMw1ynShpDpGVNWZGfHNkvApbiMadidiBkVStDsL9AUkbZ+B9w@mail.gmail.com>
@ 2013-11-29  0:27 ` Arno Wagner
  2013-11-29 10:55 ` Matthias Schniedermeyer
  2 siblings, 0 replies; 10+ messages in thread
From: Arno Wagner @ 2013-11-29  0:27 UTC (permalink / raw)
  To: dm-crypt

Hi,

On Fri, Nov 29, 2013 at 00:32:30 CET, anderson jackson wrote:
> Hello, 
> 
> I have a small question regarding luks and plain dm-crypt, and I am unsure
> what to use. 
> 
> I feel that the advantages provided by Luks obviously offers extra
> security compared to plain, however I feel uneasy about the obviousness of
> the fact that the drive is encrypted.

That issue question crops up from time to time. 
See also FAQ Item 5.18.

> Mainly because a disk with just random data could have been wiped instead
> of encrypted.  I would like the extra security provided by luks without it
> being obvious that the disk is encrypted. To combat this I was thinking
> about doing a cascade of two identical ciphers in plain mode, in this case
> AES because the AES-NI acceleration will severely limit the performance
> penalty of cascading two ciphers, I had the following setup in mind:

The problem you now have is that you asked about this here. If you
do such a set-up and somebody (law enforcement, e.g.) finds a
"randomized" partition, they can just use that as argumentation
why you are likely hiding an encrypted partition. Remember that
law enforcement is an authoritarian concept and they do not care 
about right or wrong, but desire that you bow to their wishes. So 
if they have enough to hold you, they will just imprison you for 
a while until you hand them the key. If they do not, you can just 
refuse to give out the LUKS key. For LUKS, you can always claim 
that it was an old experiment and you do not know the passphrase
anymore. Gives about as much protection. 

Same applies in even worse form if somebody extorts you or 
kidnaps you together with your disk. 

> first step: cryptsetup –-cipher=aes-xts-plain –-offset=0 –-key-size=512
> open –-type=plain /dev/sdx cascade1, with the first independend password.
> Second step: cryptsetup –-cipher=aes-xts-plain –-offset=0 –-key-size=512
> open –-type=plain /dev/mapper/cascade1 cascade2, with the second independed
> unrelated password.
> Third step: nwipe --rounds=1 --noblank --prng=twister --method=random
> /dev/mapper/cascade2, this will fill the last block device with random data to
> completely fill up the entire disk. 
> Fourth step: format the last block device with ext4.
> 
> My theory then is, that even when an attacker finds the first passwords, he
> will never know he has because the result will be random just as with a wrong
> password. 

With the fist password correct, you see the LUKS header.

> In fact all possible passwords will result in random data. The attacker
> has no way of knowing if there are cascades and how many.  Am I right to
> come to this conclusion or should I stick with luks and deal with it being
> an obvious encrypted disk?

Stick with LUKS and know it is obvious (and prevent the situation
where you may have to lie to the attacker "it is not an encrypted
partition", and may later have to retract that lie resulting in
additional problems). Refuse to provide the passphrase before
talking to an attorney for "legal" attacks or plain refuse for 
others. 

Alternatively, use a plain dm-crypt container, do the random wiping
as well, and use a better passphrase. See FAQ Item 5.1 for my 
current recomendations for LUKS and plain.

In both cases, make sure your attacker cannot brute-force the
passphrase. At this time, I would recommend using at least
100 bit of entropy for both LUKS and plain if you want to be
sure. 

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-29  0:08   ` Claudio Moretti
@ 2013-11-29  0:32     ` Arno Wagner
  2013-11-29  0:49       ` anderson jackson
  0 siblings, 1 reply; 10+ messages in thread
From: Arno Wagner @ 2013-11-29  0:32 UTC (permalink / raw)
  To: dm-crypt

On Fri, Nov 29, 2013 at 01:08:25 CET, Claudio Moretti wrote:
> Forgot to hit "reply to all". Forwarding to the list.
> ---------- Messaggio inoltrato ----------
> Da: flyingstar16@gmail.com
> Data: 29/nov/2013 00:06
> Oggetto: Re: [dm-crypt] Cascading two plain dm-crypt volumes
> A: anderson jackson <thewizard@mighty.co.za>
> Cc:
> 
> 
> Il 28/nov/2013 23:32 "anderson jackson" <thewizard@mighty.co.za> ha scritto:
> >
> > Hello,
> >
> > I have a small question regarding luks and plain dm-crypt, and I am unsure
> > what to use.
> >
> > I feel that the advantages provided by Luks obviously offers extra
> security
> > compared to plain, however I feel uneasy about the obviousness of the fact
> > that the drive is encrypted. Mainly because a disk with just random data
> could
> > have been wiped instead of encrypted. I would like the extra security
> provided
> > by luks without it being obvious that the disk is encrypted. To combat
> this I
> > was thinking about doing a cascade of two identical ciphers in plain mode
> 
> I may be mistaken, but (a) if you're using plain mode, there is no
> indication that the disk is encrypted; from the FAQ
> 
> "Plain format is just that: It has no metadata on disk, reads all
> parameters from the commandline (or the defaults), derives a master-key
> from the passphrase and then uses that to de-/encrypt the sectors of the
> device, with a direct 1:1 mapping between encrypted and decrypted sectors."

Correct, but incomplete. There is also no indication that the disk
is _not_ encrypted. Remember than often, if there is initial 
suspicion, you will have to prove your innocence.
 
> And if you're worried about the fact that if a hacker gets you password
> right he will be able to decrypt your disk, there is no guarantee that it
> can happen twice.  True, the probability get extremely reduced, but AFAIK
> current estimates say that to crack AES128 you need 30 years of continuous
> computing, so...

Depends entirely on passphrase quality, see FAQ Item 5.1.
If an attacker guesses that there will be some non-random
data at the start (the LUKS header), breaking both encryptions 
is just as hard as breaking the LUKS one, if bothe pass-hrases
are of similar quality. The plain mapping will be about 
100'000 times easier, as it does not iterate the hash.

> If instead you meant two cascaded luks partition, you still need the luks
> identifier in the "inner" partition so an attacker would know when your
> partition is open because the luks header of the partition will be in
> plaintext.

If I understood this right, it is plain(luks(data))
 
> All of this is to the best of my actual knowledge, if I got something
> wrong, please correct me.

See above.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-29  0:32     ` Arno Wagner
@ 2013-11-29  0:49       ` anderson jackson
  2013-11-29  1:03         ` Arno Wagner
  0 siblings, 1 reply; 10+ messages in thread
From: anderson jackson @ 2013-11-29  0:49 UTC (permalink / raw)
  To: dm-crypt, Arno Wagner

On Fri, 29 Nov 2013 01:32:51 +0100 Arno Wagner <arno@wagner.name> wrote

> If I understood this right, it is plain(luks(data))

No actually I meant plain(plain(data)). Therefore you won't see the luks
header when the attacker finds the correct pass but just random data.



____________________________________________________________
South Africas premier free email service - www.webmail.co.za 

Save 25% on insurance – Dial Direct
http://www.dialdirect.co.za/smart-gets-a-tomtom?vdn=15752

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-29  0:49       ` anderson jackson
@ 2013-11-29  1:03         ` Arno Wagner
  2013-11-29  1:31           ` anderson jackson
  0 siblings, 1 reply; 10+ messages in thread
From: Arno Wagner @ 2013-11-29  1:03 UTC (permalink / raw)
  To: dm-crypt

On Fri, Nov 29, 2013 at 01:49:57 CET, anderson jackson wrote:
> On Fri, 29 Nov 2013 01:32:51 +0100 Arno Wagner <arno@wagner.name> wrote
> 
> > If I understood this right, it is plain(luks(data))
> 
> No actually I meant plain(plain(data)). Therefore you won't see the luks
> header when the attacker finds the correct pass but just random data.
> 

That is not really more secure than just plain with the two 
passphrases concatenated (as long as the entropy does not
exceed the key length). No reason to do this, except if you 
mistrust the ciphers and want to use two different ones.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-29  1:03         ` Arno Wagner
@ 2013-11-29  1:31           ` anderson jackson
  2013-11-29  5:06             ` Arno Wagner
  0 siblings, 1 reply; 10+ messages in thread
From: anderson jackson @ 2013-11-29  1:31 UTC (permalink / raw)
  To: dm-crypt, Arno Wagner

On Fri, 29 Nov 2013 02:03:53 +0100 Arno Wagner <arno@wagner.name> wrote

> On Fri, Nov 29, 2013 at 01:49:57 CET, anderson jackson wrote:
> > On Fri, 29 Nov 2013 01:32:51 +0100 Arno Wagner <arno@wagner.name> wrote
> > 
> > > If I understood this right, it is plain(luks(data))
> > 
> > No actually I meant plain(plain(data)). Therefore you won't see the luks
> > header when the attacker finds the correct pass but just random data.
> > 
> 
> That is not really more secure than just plain with the two 
> passphrases concatenated (as long as the entropy does not
> exceed the key length). No reason to do this, except if you 
> mistrust the ciphers and want to use two different ones.

My knowledge about the subject is only skin deep. However I feel as if I am
missing something and in addition to that I must have explained myself poorly.
What I was suggesting is cascading two identical ciphers (both AES) in plain
mode with two independent passphrases one for the first plain block device and
another for the second one. 
/dev/sdx = random data
/dev/mapper/cascade1 = random data
/dev/mapper/cascade2 = file system

Let’s say an attacker is using brute force to find the passphrase and
let’s say the tries he has performed includes the first passphrase. When
that passphrase was tried the decrypted result would have been random data
just as if it were a wrong passphrase. The attacker has no way of knowing that
there is a cascade since there is no header or other identifiable markers. So
even when he finds the correct passphrase it would appear to be a failed
attempt because he only gets random data. He would have to try to brute force
the passphrase for the second plain block device for each of the used phrases
of the first block device. 

Jackson


____________________________________________________________
South Africas premier free email service - www.webmail.co.za 

Cotlands - Shaping tomorrows Heroes http://www.cotlands.org.za/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-29  1:31           ` anderson jackson
@ 2013-11-29  5:06             ` Arno Wagner
  0 siblings, 0 replies; 10+ messages in thread
From: Arno Wagner @ 2013-11-29  5:06 UTC (permalink / raw)
  To: dm-crypt

On Fri, Nov 29, 2013 at 02:31:19 CET, anderson jackson wrote:
> On Fri, 29 Nov 2013 02:03:53 +0100 Arno Wagner <arno@wagner.name> wrote
> 
> > On Fri, Nov 29, 2013 at 01:49:57 CET, anderson jackson wrote:
> > > On Fri, 29 Nov 2013 01:32:51 +0100 Arno Wagner <arno@wagner.name> wrote
> > > 
> > > > If I understood this right, it is plain(luks(data))
> > > 
> > > No actually I meant plain(plain(data)). Therefore you won't see the luks
> > > header when the attacker finds the correct pass but just random data.
> > > 
> > 
> > That is not really more secure than just plain with the two 
> > passphrases concatenated (as long as the entropy does not
> > exceed the key length). No reason to do this, except if you 
> > mistrust the ciphers and want to use two different ones.
> 
> My knowledge about the subject is only skin deep. However I feel as if I
> am missing something and in addition to that I must have explained myself
> poorly.  What I was suggesting is cascading two identical ciphers (both
> AES) in plain mode with two independent passphrases one for the first
> plain block device and another for the second one.
>
> /dev/sdx = random data
> /dev/mapper/cascade1 = random data
> /dev/mapper/cascade2 = file system

Ah, I see. I misread that one, as this approach has zero benefits.

> Let’s say an attacker is using brute force to find the passphrase and
> let’s say the tries he has performed includes the first passphrase.  When
> that passphrase was tried the decrypted result would have been random data
> just as if it were a wrong passphrase.  The attacker has no way of knowing
> that there is a cascade since there is no header or other identifiable
> markers.  So even when he finds the correct passphrase it would appear to
> be a failed attempt because he only gets random data.  He would have to
> try to brute force the passphrase for the second plain block device for
> each of the used phrases of the first block device.

That is not how it works, unfortunately. While your idea is
somewhat intuitive, there is no way to brute-force even 
a 128 bit AES key. Hence such an attacker must know some
weakness in the cipher. But the thing is that possibly
there is a key k3 so that

   aes(k1, aes(k2, data)) = aes(k3, data)

and hence layering the same cipher may completely worthless.
AFAIK this type of approach was abandoned quite a while ago
in the research community.

Just use a single AES layer and pump up the passphrase entropy
by doing 

   aes(k1+k2, data)

which is massively more secure unless k1, k2 have entropy in 
the size of the key-length.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-28 23:32 [dm-crypt] Cascading two plain dm-crypt volumes anderson jackson
       [not found] ` <CAMw1ynShpDpGVNWZGfHNkvApbiMadidiBkVStDsL9AUkbZ+B9w@mail.gmail.com>
  2013-11-29  0:27 ` Arno Wagner
@ 2013-11-29 10:55 ` Matthias Schniedermeyer
  2013-11-29 16:53   ` Arno Wagner
  2 siblings, 1 reply; 10+ messages in thread
From: Matthias Schniedermeyer @ 2013-11-29 10:55 UTC (permalink / raw)
  To: anderson jackson; +Cc: dm-crypt

On 29.11.2013 01:32, anderson jackson wrote:
> Hello, 
> 
> I have a small question regarding luks and plain dm-crypt, and I am unsure
> what to use. 
> 
> I feel that the advantages provided by Luks obviously offers extra security
> compared to plain, however I feel uneasy about the obviousness of the fact
> that the drive is encrypted. Mainly because a disk with just random data could
> have been wiped instead of encrypted. I would like the extra security provided
> by luks without it being obvious that the disk is encrypted. To combat this I
> was thinking about doing a cascade of two identical ciphers in plain mode, in
> this case AES because the AES-NI acceleration will severely limit the
> performance penalty of cascading two ciphers, I had the following setup in
> mind:
> 
> first step: cryptsetup ???-cipher=aes-xts-plain ???-offset=0 ???-key-size=512
> open ???-type=plain /dev/sdx cascade1, with the first independend password.
> Second step: cryptsetup ???-cipher=aes-xts-plain ???-offset=0 ???-key-size=512
> open ???-type=plain /dev/mapper/cascade1 cascade2, with the second independed
> unrelated password.
> Third step: nwipe --rounds=1 --noblank --prng=twister --method=random
> /dev/mapper/cascade2, this will fill the last block device with random data to
> completely fill up the entire disk. 
> Fourth step: format the last block device with ext4.
> 
> My theory then is, that even when an attacker finds the first passwords, he
> will never know he has because the result will be random just as with a wrong
> password. In fact all possible passwords will result in random data. The
> attacker has no way of knowing if there are cascades and how many. Am I right
> to come to this conclusion or should I stick with luks and deal with it being
> an obvious encrypted disk?

There is also loop-aes v3 format, also supported by dm-crypt/cryptsetup.
It doesn't use a header and you need a total of 65 keys to be 
broken, before you could read the whole volume.
But you would need to use a key-file to store the 65 keys, the 
"standard" method is to use gpg for that.
Without the key-file it is pratically impossible to break such an 
encrypted volume. Same as it is pratically impossible to break a simple 
plain encrypted volume with a key that has full entophy.




-- 

Matthias

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] Cascading two plain dm-crypt volumes
  2013-11-29 10:55 ` Matthias Schniedermeyer
@ 2013-11-29 16:53   ` Arno Wagner
  0 siblings, 0 replies; 10+ messages in thread
From: Arno Wagner @ 2013-11-29 16:53 UTC (permalink / raw)
  To: dm-crypt

On Fri, Nov 29, 2013 at 11:55:31 CET, Matthias Schniedermeyer wrote:
> On 29.11.2013 01:32, anderson jackson wrote:
[...] 
> There is also loop-aes v3 format, also supported by dm-crypt/cryptsetup.
> It doesn't use a header and you need a total of 65 keys to be 
> broken, before you could read the whole volume.
> But you would need to use a key-file to store the 65 keys, the 
> "standard" method is to use gpg for that.
> Without the key-file it is pratically impossible to break such an 
> encrypted volume. Same as it is pratically impossible to break a simple 
> plain encrypted volume with a key that has full entophy.

Indeed. From something like 100 bit of effort, brute forcing 
may well become impossible on this planet and for something like
200 bits of effort, it may become impossible in this galaxy.
(Not enough energy and matter available...).

So the primary concern is to have a) good ciphers and 
b) high-entropy passphrases. Concern b) is the responsibility
of the user.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2013-11-29 16:53 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-28 23:32 [dm-crypt] Cascading two plain dm-crypt volumes anderson jackson
     [not found] ` <CAMw1ynShpDpGVNWZGfHNkvApbiMadidiBkVStDsL9AUkbZ+B9w@mail.gmail.com>
2013-11-29  0:08   ` Claudio Moretti
2013-11-29  0:32     ` Arno Wagner
2013-11-29  0:49       ` anderson jackson
2013-11-29  1:03         ` Arno Wagner
2013-11-29  1:31           ` anderson jackson
2013-11-29  5:06             ` Arno Wagner
2013-11-29  0:27 ` Arno Wagner
2013-11-29 10:55 ` Matthias Schniedermeyer
2013-11-29 16:53   ` Arno Wagner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.