[dm-crypt] The future of disk encryption with LUKS2

[dm-crypt] The future of disk encryption with LUKS2

[.. ink ..]

I am curious about what problems luks1 current has and how luks2 is
going to fix them but there
seem to be no documentation about luks2 anywhere.

I just came across this link here[1] and i am very much interested in
this presentation.Will it be
recorded and posted online?

Will any of the materials used in the presented posted online
somewhere for the rest of us to see?


[1] https://devconfcz2016.sched.org/event/5nsA/the-future-of-disk-encryption-with-luks2

Re: [dm-crypt] The future of disk encryption with LUKS2

[Yves-Alexis Perez]

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

On mer., 2016-02-03 at 16:13 +0300, .. ink .. wrote:
> I am curious about what problems luks1 current has and how luks2 is
> going to fix them but there
> seem to be no documentation about luks2 anywhere.

Looking at the list archive I found <55DAB73F.2080002@gmail.com> and followup
<20150824115418.GA20268@tansi.org>

There's also the wip-luks2 branch at https://gitlab.com/cryptsetup/cryptsetup/
tree/wip-luks2

Regards,
-- 
Yves-Alexis


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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/03/2016 02:13 PM, .. ink .. wrote:
> I am curious about what problems luks1 current has and how luks2 is
> going to fix them but there
> seem to be no documentation about luks2 anywhere.

Yes, and it is just because I am completely out of time (I have planned
to send some information week ago :-)

> I just came across this link here[1] and i am very much interested in
> this presentation.Will it be
> recorded and posted online?

Yes, but this is just high level talk, do not expect anything useful for developers.
(It should be recorded.)

Anyway, please give me few weeks, I expect the design discussion will happen here
(I have a lot of to say why I am trying to do it this way.)
I just prefer to discuss existing proof-of-concept code that theoretic discussions.

For now, LUKS2 is experiment (partially proof-of-concept of some ideas
of configurable keyslots, partially as testbed for my university work
as implementing Argon 2 as PBKDF2 replacement etc).

(You already found one serious mistake in code, so do not use it yet :)

> Will any of the materials used in the presented posted online
> somewhere for the rest of us to see?

yes 

Milan

> 
> 
> [1] https://devconfcz2016.sched.org/event/5nsA/the-future-of-disk-encryption-with-luks2
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Wed, Feb 03, 2016 at 15:17:41 CET, Milan Broz wrote:
> On 02/03/2016 02:13 PM, .. ink .. wrote:
> > I am curious about what problems luks1 current has and how luks2 is
> > going to fix them but there
> > seem to be no documentation about luks2 anywhere.
> 
> Yes, and it is just because I am completely out of time (I have planned
> to send some information week ago :-)

The curse of the wicked...aehm, I mean "of those that do good work" ;-)
 
> > I just came across this link here[1] and i am very much interested in
> > this presentation.Will it be
> > recorded and posted online?
> 
> Yes, but this is just high level talk, do not expect anything useful for
> developers.  (It should be recorded.)
> 
> Anyway, please give me few weeks, I expect the design discussion will
> happen here (I have a lot of to say why I am trying to do it this way.) 
> I just prefer to discuss existing proof-of-concept code that theoretic
> discussions.

Excellent, I like that approach very much.
 
> For now, LUKS2 is experiment (partially proof-of-concept of some ideas
> of configurable keyslots, partially as testbed for my university work
> as implementing Argon 2 as PBKDF2 replacement etc).

Part of your research work? Even better. Then it has to be good! 

> (You already found one serious mistake in code, so do not use it yet :)
> 
> > Will any of the materials used in the presented posted online
> > somewhere for the rest of us to see?
> 
> yes 

Looking forward to that.

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Really looking forward to the discussion, Milan.

Personally I'd love to see FEC extensions in a v2 on-disk-format.

Regards

-Sven


Am 03.02.2016 um 15:17 schrieb Milan Broz:
> On 02/03/2016 02:13 PM, .. ink .. wrote:
>
> Anyway, please give me few weeks, I expect the design discussion will happen here
> (I have a lot of to say why I am trying to do it this way.)
> I just prefer to discuss existing proof-of-concept code that theoretic discussions.
>
> For now, LUKS2 is experiment (partially proof-of-concept of some ideas
> of configurable keyslots, partially as testbed for my university work
> as implementing Argon 2 as PBKDF2 replacement etc).
>
> (You already found one serious mistake in code, so do not use it yet :)
>
>> Will any of the materials used in the presented posted online
>> somewhere for the rest of us to see?
>
> yes
>
> Milan
>
>>
>>
>> [1] https://devconfcz2016.sched.org/event/5nsA/the-future-of-disk-encryption-with-luks2
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/03/2016 08:46 PM, Sven Eschenberg wrote:
> Really looking forward to the discussion, Milan.
> 
> Personally I'd love to see FEC extensions in a v2 on-disk-format.

Hi Sven,

If you mean FEC (forward error correction, using Reed-Solomon code)
support for dm-verity, that's not directly related to LUKS2. In fact
it is kernel feature (and it will be supported in next major veritysetup version,
just the FEC branch need a lot of cleanup before I can merge it).

Anyway, I do not like much the way how it implemented but it is already
in mainline kernel so it is just waste of time to complain again :)

(Read dm-devel if you are interested, thread
"dm verity: add support for error correction" from November last year.)

I have never thought of using FEC for dm-crypt, anyway, if it is implemented
as a separate layer below dmcrypt, it could work (not the case today,
FEC is integral part of dm-verity).

Anyway, if you have some real use cases for FEC (and specifically some
real-world examples of data corruption it can fix), please share it, I am
very interested to see that. (I know the problem exist and that FEC could
be useful but seems nobody is able provide any hard data...)

Milan

Re: [dm-crypt] The future of disk encryption with LUKS2

[Michael Kjörling]

On 4 Feb 2016 09:38 +0100, from gmazyland@gmail.com (Milan Broz):
> On 02/03/2016 08:46 PM, Sven Eschenberg wrote:
>> Personally I'd love to see FEC extensions in a v2 on-disk-format.
> 
> Anyway, if you have some real use cases for FEC (and specifically some
> real-world examples of data corruption it can fix), please share it, I am
> very interested to see that. (I know the problem exist and that FEC could
> be useful but seems nobody is able provide any hard data...)

Plain data duplication seems both easier to implement and likely to
allow recovery from the same as well as other classes of errors.
Reed-Solomon and similar FEC is useful when a read is marginal, but
useless when a read fails completely, which I believe is a far more
common failure mode in the layers of storage that we are interested
in.

Storing the LUKS header in two separate locations on disk could
probably do the trick. For example, right at the start *and* right at
the end of the LUKS container, which would avoid any issues with
having to remap a location in the middle of the container. Put a
counter in the header, ensure that all copies are in sync when the
header is read or written to, and if they are out of sync, use the one
with the highest counter value that works and rewrite the other. Add a
checksum (could be something really simple even, like CRC32, but it
would be good to make this extensible without needing to change the
on-disk format) to protect against any corruption that somehow manages
to slip past the FEC in the storage layer.

In fact, that would be similar to how ZFS and Btrfs already solves
pretty much the same problem.

I would discourage complex features; in cryptography, simple and easy
to validate should be the name of the game, and simply storing the
same data in two distinct locations is _far_ easier to understand than
code to calculate and use FEC data.

-- 
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] The future of disk encryption with LUKS2

[Sumaya1960]

Hi agian,

I am very sorry for bothering all of you!
BUT I lost all my Data once and I will make sure that this time it will 
not going to happen again!

So 2 short questions:

1. external USB-Disk with as raw block device as 'external backup 
device'? ( FAQ 2.2 (2))
Is that OK?

2. Can I use a Hardware Raid 10 with 4 SSD's?
I will use raw disks as well with no other format and no other 
partition. I will configure the virtual drive on the host (adapter) 
side. Is this possible or would you recommend another setup on the 
hardware raid?

Thank you so much and again, I am very sorry for my stupid questions!
I just want to make sure, that everything is considered!
I will use ASCII character Set to setup the pass-phrase, that is clear.

Thanks a lot to everyone!

Best wishes!!!
Susu

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/04/2016 10:20 AM, Michael Kjörling wrote:
> On 4 Feb 2016 09:38 +0100, from gmazyland@gmail.com (Milan Broz):
>> On 02/03/2016 08:46 PM, Sven Eschenberg wrote:

> Storing the LUKS header in two separate locations on disk could
> probably do the trick. For example, right at the start *and* right at
> the end of the LUKS container, which would avoid any issues with
> having to remap a location in the middle of the container. Put a
> counter in the header, ensure that all copies are in sync when the
> header is read or written to, and if they are out of sync, use the one
> with the highest counter value that works and rewrite the other. Add a
> checksum (could be something really simple even, like CRC32, but it
> would be good to make this extensible without needing to change the
> on-disk format) to protect against any corruption that somehow manages
> to slip past the FEC in the storage layer.

That is really for design documentation I would like to write and send here,
but that's almost exactly I already have in LUKS2 branch

- two headers with checksum (configurable algorithm, for now just plain sha256)
  (there is different salt for headers and small binary header to be parsed by blkid)

- counter (epoch) and automatic recovery (in fact trivial journal)
 (this does not apply for raw slot key material)

FEC is not needed for header resilience, above works pretty well and it is simple.

The most "fancy" feature is that metadata are in JSON, so I can work even
with "unknown" future type keyslots/segments types and keep its metadata intact.

 
> In fact, that would be similar to how ZFS and Btrfs already solves
> pretty much the same problem.

If you mention these, I would like to have integrity protection (either authenticated
mode or additional integrity data) on block layer encryption level.

And LUKS2 header will allow to add this in future without on-disk header change,
just by defining new segment type.

For now, cryptography algorithms are the same as LUKS1 (except experimental
Argon2 KDF support that need a lot of engineering work for libargon2 library...)
but the format allows upgrade in future without on-disk change.


> I would discourage complex features; in cryptography, simple and easy
> to validate should be the name of the game, and simply storing the
> same data in two distinct locations is _far_ easier to understand than
> code to calculate and use FEC data.

YES, 100% agree with that.

Milan

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Thu, Feb 04, 2016 at 10:35:57 CET, Sumaya1960@gmx.de wrote:
> Hi agian,
> 
> I am very sorry for bothering all of you!
> BUT I lost all my Data once and I will make sure that this time it
> will not going to happen again!
> 
> So 2 short questions:
> 
> 1. external USB-Disk with as raw block device as 'external backup
> device'? ( FAQ 2.2 (2))
> Is that OK?

If you have a header backup, that already covers some problems.
If you add a full backup of the raw LUKS device, that protects
you justr as much as a regular fullbackup does. You just cannot
compress that backup compared to a regular one.
 
> 2. Can I use a Hardware Raid 10 with 4 SSD's?
> I will use raw disks as well with no other format and no other
> partition. I will configure the virtual drive on the host (adapter)
> side. Is this possible or would you recommend another setup on the
> hardware raid?

RAID10 is something pretty obsolete and it has worse reliability
than RAID1 and the speed-advantage does not matter much today. 
Better use RAID1 with larger SSDs or RAID 6. 

BTW, you can meaningfully mix normal HDDS and SSDs in a Linux 
software RAID1 and you can use more than 2 drives in a RAID1 
under Linux software RAID. I have a page on how to do that here:

    http://www.arnowagner.info/hybrid/

What I currently uses is one SSD and two notebook HDDs for 
important data in a 3-way RAID1 (on partition level, but 
works the same for full disks). Unless all three fail, the
data is good. Of course, I have backup. LUKS goes on-top
of that RAID. 

For reading, this is as fast as the SSD. Writes are buffered
in memory anyways. Unless you need high write-performance for
writes larger than the free memory, this is the ideal set-up.
 
> Thank you so much and again, I am very sorry for my stupid questions!

Don't worry. The only propblems are lazy questions where
people have not bothered to find things out. You obviously 
have. 

Regards,
Arno

> I just want to make sure, that everything is considered!
> I will use ASCII character Set to setup the pass-phrase, that is clear.
> 
> Thanks a lot to everyone!
> 
> Best wishes!!!
> Susu
> 
> 
> 
> 
> 
> _______________________________________________
> 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] The future of disk encryption with LUKS2

[Arno Wagner]

On Thu, Feb 04, 2016 at 11:02:36 CET, Milan Broz wrote:
[...] 
> FEC is not needed for header resilience, above works pretty 
> well and it is simple.

For smaller things (and on disk the LUKS header qualifies), 
replication and checksumming is always preferrable. 

One problem with FEC on top of HDDs is that you will  
almost always not get bit errors, but full defective 
sectors. The disk already corrects most bit-errors and 
the user only sees errors when the disk has given up. 
That would mean you would need to be able to correct 
4096 missing _bytes_, and that will cause massive FEC 
block sizes, which kills performance. Or alternatively, 
you can distribute all blocks in smaller slices (so 
each REED-SOLOMONS block gets smaller), which also 
kills performance.

For SSDs, the situation would be much, much worse.

This is the reason why FEC is not used in storage
above what the disk itself already does.

In storage, if you really need it, you do RAID1/5/6
and for large installations, RAID5/6 does not have 
much cost overhead. For small ones, adding a second disk
to get a RAID1 is also not going to affetc the overall
cost much.

FEC does have its primary use when you cannot have 
RAID-type redundancy or when you have lots of small 
burst-type errors. That is the case in wireless 
communication or raw HDD reads. It is also the case 
on optical media. It is not the case on disk reads 
on (S)ATA level.

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] The future of disk encryption with LUKS2

[Yves-Alexis Perez]

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

On mer., 2016-02-03 at 15:17 +0100, Milan Broz wrote:
> Anyway, please give me few weeks, I expect the design discussion will happen here
> (I have a lot of to say why I am trying to do it this way.)
> I just prefer to discuss existing proof-of-concept code that theoretic discussions.
> 
> For now, LUKS2 is experiment (partially proof-of-concept of some ideas
> of configurable keyslots, partially as testbed for my university work
> as implementing Argon 2 as PBKDF2 replacement etc).

I know it's a recurring subject, and maybe it's more dm-crypt2 than LUKS2 or
something, but in that context, is there people working on authenticated
encryption and anti-replay?

Regards,
-- 
Yves-Alexis


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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Hi all,

Yes data duplication (a secondary shadow copy of the header) together 
with checksumming for integrity checking is of course easier and more 
straight forward. I thought about FEC (not necessarily Reeed-S.) as an 
alternative that covers both issues without introducing an extra 
location of header data. Then again, if the (primary) header is 
overwritten completely, FECs won't help you that much.

The problem with an extra header at the end of the device is, that it 
makes growing/shrinking a more difficult task. Currently the mapping 
always covers the whole size of the backing device.

Regards

-Sven

Am 04.02.2016 um 10:20 schrieb Michael Kjörling:
> On 4 Feb 2016 09:38 +0100, from gmazyland@gmail.com (Milan Broz):
>> On 02/03/2016 08:46 PM, Sven Eschenberg wrote:
>>> Personally I'd love to see FEC extensions in a v2 on-disk-format.
>>
>> Anyway, if you have some real use cases for FEC (and specifically some
>> real-world examples of data corruption it can fix), please share it, I am
>> very interested to see that. (I know the problem exist and that FEC could
>> be useful but seems nobody is able provide any hard data...)
>
> Plain data duplication seems both easier to implement and likely to
> allow recovery from the same as well as other classes of errors.
> Reed-Solomon and similar FEC is useful when a read is marginal, but
> useless when a read fails completely, which I believe is a far more
> common failure mode in the layers of storage that we are interested
> in.
>
> Storing the LUKS header in two separate locations on disk could
> probably do the trick. For example, right at the start *and* right at
> the end of the LUKS container, which would avoid any issues with
> having to remap a location in the middle of the container. Put a
> counter in the header, ensure that all copies are in sync when the
> header is read or written to, and if they are out of sync, use the one
> with the highest counter value that works and rewrite the other. Add a
> checksum (could be something really simple even, like CRC32, but it
> would be good to make this extensible without needing to change the
> on-disk format) to protect against any corruption that somehow manages
> to slip past the FEC in the storage layer.
>
> In fact, that would be similar to how ZFS and Btrfs already solves
> pretty much the same problem.
>
> I would discourage complex features; in cryptography, simple and easy
> to validate should be the name of the game, and simply storing the
> same data in two distinct locations is _far_ easier to understand than
> code to calculate and use FEC data.
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Thu, Feb 04, 2016 at 17:29:36 CET, Yves-Alexis Perez wrote:
> On mer., 2016-02-03 at 15:17 +0100, Milan Broz wrote:
> > Anyway, please give me few weeks, I expect the design discussion will happen here
> > (I have a lot of to say why I am trying to do it this way.)
> > I just prefer to discuss existing proof-of-concept code that theoretic discussions.
> > 
> > For now, LUKS2 is experiment (partially proof-of-concept of some ideas
> > of configurable keyslots, partially as testbed for my university work
> > as implementing Argon 2 as PBKDF2 replacement etc).
> 
> I know it's a recurring subject, and maybe it's more dm-crypt2 than LUKS2 or
> something, but in that context, is there people working on authenticated
> encryption and anti-replay?

Maybe my crypto-knowledge deserts me here, but how is that
relevant for storage encryption? 

If somebody can replay old storage blocks, they have already 
compromised your machine and can do what they want, unless 
you have an unsecured Network Block Device or iSCSI device. 
That would already be a problem on a different level.

And authenticated encryption seems to not even apply to storage,
unless you are thinking about integrity. If so, wrong project,
as integrity always requires additional bits and LUKS/DM-cryopt
does not have them bu design.

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] The future of disk encryption with LUKS2

[Arno Wagner]

Hi Sven,

if you place a copy of the header at the end, you already
need some way to know where the end is and to reserve space
at it. A resize could then be as simple as an additional
"luksUpdateHeaderCopy" afterwards (whith all other 
header-changing operations doing that implicitely already).

For completeness and security (preventing an old copy
of the header from lingering), a "luksNukeHeaderCopy"
would also be required.

On the other hand, resizing a Luks container with a 
filesystem in there without killing that filesystem is
already complicated enough that I usually just recomend 
a backup and recreation instead of a resize.

Regards,
Arno

On Thu, Feb 04, 2016 at 17:34:26 CET, Sven Eschenberg wrote:
> Hi all,
> 
> Yes data duplication (a secondary shadow copy of the header)
> together with checksumming for integrity checking is of course
> easier and more straight forward. I thought about FEC (not
> necessarily Reeed-S.) as an alternative that covers both issues
> without introducing an extra location of header data. Then again, if
> the (primary) header is overwritten completely, FECs won't help you
> that much.
> 
> The problem with an extra header at the end of the device is, that
> it makes growing/shrinking a more difficult task. Currently the
> mapping always covers the whole size of the backing device.
> 
> Regards
> 
> -Sven
> 
> Am 04.02.2016 um 10:20 schrieb Michael Kjörling:
> >On 4 Feb 2016 09:38 +0100, from gmazyland@gmail.com (Milan Broz):
> >>On 02/03/2016 08:46 PM, Sven Eschenberg wrote:
> >>>Personally I'd love to see FEC extensions in a v2 on-disk-format.
> >>
> >>Anyway, if you have some real use cases for FEC (and specifically some
> >>real-world examples of data corruption it can fix), please share it, I am
> >>very interested to see that. (I know the problem exist and that FEC could
> >>be useful but seems nobody is able provide any hard data...)
> >
> >Plain data duplication seems both easier to implement and likely to
> >allow recovery from the same as well as other classes of errors.
> >Reed-Solomon and similar FEC is useful when a read is marginal, but
> >useless when a read fails completely, which I believe is a far more
> >common failure mode in the layers of storage that we are interested
> >in.
> >
> >Storing the LUKS header in two separate locations on disk could
> >probably do the trick. For example, right at the start *and* right at
> >the end of the LUKS container, which would avoid any issues with
> >having to remap a location in the middle of the container. Put a
> >counter in the header, ensure that all copies are in sync when the
> >header is read or written to, and if they are out of sync, use the one
> >with the highest counter value that works and rewrite the other. Add a
> >checksum (could be something really simple even, like CRC32, but it
> >would be good to make this extensible without needing to change the
> >on-disk format) to protect against any corruption that somehow manages
> >to slip past the FEC in the storage layer.
> >
> >In fact, that would be similar to how ZFS and Btrfs already solves
> >pretty much the same problem.
> >
> >I would discourage complex features; in cryptography, simple and easy
> >to validate should be the name of the game, and simply storing the
> >same data in two distinct locations is _far_ easier to understand than
> >code to calculate and use FEC data.
> >
> _______________________________________________
> 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] The future of disk encryption with LUKS2

[Michael Kjörling]

On 4 Feb 2016 18:23 +0100, from arno@wagner.name (Arno Wagner):
> if you place a copy of the header at the end,

It doesn't need to be at the end of the container either; that's just
a convenient spot, particularly because the size of the device backing
the container is already known and it's far away from the beginning of
the container. The most important aspect would likely be that the two
locations are unlikely to be affected by any single error, which is
trivial to show to be the case on HDDs with far-removed LBA addresses,
and is easy to argue is highly likely on SSDs in the same case.

> you already
> need some way to know where the end is and to reserve space
> at it. A resize could then be as simple as an additional
> "luksUpdateHeaderCopy" afterwards (whith all other 
> header-changing operations doing that implicitely already).

I don't know anything about what hooks are available or practical, but
an alternative might be to hook into the "resize" control flow and
move the header through there. That would be a much cleaner approach
from a user point of view.

As a user, I would want a usable encrypted container; I don't really
care where on the disk the metadata to implement this is stored, and I
certainly wouldn't want the documentation to say "oh, and after you
run this, you MUST run this other command" just to keep the container
in a consistent state. That would feel very amateurish. It would be a
bit like if I store a file on a RAID 1, I then have to resilver the
array to make sure that the file is on all constituent devices.


> For completeness and security (preventing an old copy
> of the header from lingering), a "luksNukeHeaderCopy"
> would also be required.

This should be handled transparently by luksErase and/or resize, for
the same reason cited above; all commands that use or affect the LUKS
header should strive to keep the container in a consistent state,
including ensuring that both copies of the metadata are synchronized.

If absolutely necessary, a command-line switch could be added to
disable that behavior, with clear warnings about the potential
implications.

-- 
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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Hi all,

Am 04.02.2016 um 19:42 schrieb Michael Kjörling:
> On 4 Feb 2016 18:23 +0100, from arno@wagner.name (Arno Wagner):
>> if you place a copy of the header at the end,
>
> It doesn't need to be at the end of the container either; that's just
> a convenient spot, particularly because the size of the device backing
> the container is already known and it's far away from the beginning of
> the container. The most important aspect would likely be that the two
> locations are unlikely to be affected by any single error, which is
> trivial to show to be the case on HDDs with far-removed LBA addresses,
> and is easy to argue is highly likely on SSDs in the same case.

Well there's only two ways, storing it based on the device's size, or at 
a fixed offset (which would imply a minimum size of offset+headersize). 
The latter seems plain wrong. So yes, in contrast to the current 
situation the logic to determine device size, placing the header and so 
on needs to be added.

>
>> you already
>> need some way to know where the end is and to reserve space
>> at it. A resize could then be as simple as an additional
>> "luksUpdateHeaderCopy" afterwards (whith all other
>> header-changing operations doing that implicitely already).
>
> I don't know anything about what hooks are available or practical, but
> an alternative might be to hook into the "resize" control flow and
> move the header through there. That would be a much cleaner approach
> from a user point of view.
>
> As a user, I would want a usable encrypted container; I don't really
> care where on the disk the metadata to implement this is stored, and I
> certainly wouldn't want the documentation to say "oh, and after you
> run this, you MUST run this other command" just to keep the container
> in a consistent state. That would feel very amateurish. It would be a
> bit like if I store a file on a RAID 1, I then have to resilver the
> array to make sure that the file is on all constituent devices.

Keeping consistency is of course not the user's job. But when we look at 
v2 design changes, these things need to be addressed and evaluated. 
While an ACID-Transaction to move the header is no magic, things need to 
be crafted carefully. Milan already said there's some sort of replay log 
planned or WIP.

>
>
>> For completeness and security (preventing an old copy
>> of the header from lingering), a "luksNukeHeaderCopy"
>> would also be required.
>
> This should be handled transparently by luksErase and/or resize, for
> the same reason cited above; all commands that use or affect the LUKS
> header should strive to keep the container in a consistent state,
> including ensuring that both copies of the metadata are synchronized.
>
> If absolutely necessary, a command-line switch could be added to
> disable that behavior, with clear warnings about the potential
> implications.
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Yves-Alexis Perez]

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

On jeu., 2016-02-04 at 18:17 +0100, Arno Wagner wrote:
> Maybe my crypto-knowledge deserts me here, but how is that
> relevant for storage encryption? 
> 
> If somebody can replay old storage blocks, they have already 
> compromised your machine and can do what they want, 

Think external drives / removable storage?
> 
> And authenticated encryption seems to not even apply to storage,
> unless you are thinking about integrity. 

Indeed.

> If so, wrong project,
> as integrity always requires additional bits and LUKS/DM-cryopt
> does not have them bu design.

I am well aware of the need to store the integrity patterns, that's why I'm
asking this in context of LUKS2. Thanks for the reply though.

Regards,
-- 
Yves-Alexis


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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

I think you are asking for a lot more "magic" than is safe
here. If you are a mrer "user", you have no business resizing
a LUKS container in the first place. You need to know what you
are doing to do so safely.

Arno

On Thu, Feb 04, 2016 at 19:42:43 CET, Michael Kjörling wrote:
> On 4 Feb 2016 18:23 +0100, from arno@wagner.name (Arno Wagner):
> > if you place a copy of the header at the end,
> 
> It doesn't need to be at the end of the container either; that's just
> a convenient spot, particularly because the size of the device backing
> the container is already known and it's far away from the beginning of
> the container. The most important aspect would likely be that the two
> locations are unlikely to be affected by any single error, which is
> trivial to show to be the case on HDDs with far-removed LBA addresses,
> and is easy to argue is highly likely on SSDs in the same case.
> 
> > you already
> > need some way to know where the end is and to reserve space
> > at it. A resize could then be as simple as an additional
> > "luksUpdateHeaderCopy" afterwards (whith all other 
> > header-changing operations doing that implicitely already).
> 
> I don't know anything about what hooks are available or practical, but
> an alternative might be to hook into the "resize" control flow and
> move the header through there. That would be a much cleaner approach
> from a user point of view.
> 
> As a user, I would want a usable encrypted container; I don't really
> care where on the disk the metadata to implement this is stored, and I
> certainly wouldn't want the documentation to say "oh, and after you
> run this, you MUST run this other command" just to keep the container
> in a consistent state. That would feel very amateurish. It would be a
> bit like if I store a file on a RAID 1, I then have to resilver the
> array to make sure that the file is on all constituent devices.
> 
> 
> > For completeness and security (preventing an old copy
> > of the header from lingering), a "luksNukeHeaderCopy"
> > would also be required.
> 
> This should be handled transparently by luksErase and/or resize, for
> the same reason cited above; all commands that use or affect the LUKS
> header should strive to keep the container in a consistent state,
> including ensuring that both copies of the metadata are synchronized.
> 
> If absolutely necessary, a command-line switch could be added to
> disable that behavior, with clear warnings about the potential
> implications.
> 
> -- 
> 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)
> _______________________________________________
> 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] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 07:30:50 CET, Yves-Alexis Perez wrote:
> On jeu., 2016-02-04 at 18:17 +0100, Arno Wagner wrote:
> > Maybe my crypto-knowledge deserts me here, but how is that
> > relevant for storage encryption? 
> > 
> > If somebody can replay old storage blocks, they have already 
> > compromised your machine and can do what they want, 
> 
> Think external drives / removable storage?

An attacker with physical access that you do not notice has 
won. Storage encryption does not protect here. Think, for 
example, "evil maid" type attacks. Storage encryption
is only for theft of the device (which you notice) or 
attacker access which you notice in other ways.

Regards,
Arno


> > 
> > And authenticated encryption seems to not even apply to storage,
> > unless you are thinking about integrity. 
> 
> Indeed.
> 
> > If so, wrong project,
> > as integrity always requires additional bits and LUKS/DM-cryopt
> > does not have them bu design.
> 
> I am well aware of the need to store the integrity patterns, that's why I'm
> asking this in context of LUKS2. Thanks for the reply though.
> 
> Regards,
> -- 
> Yves-Alexis
> 



> _______________________________________________
> 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] The future of disk encryption with LUKS2

[Yves-Alexis Perez]

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

On ven., 2016-02-05 at 12:02 +0100, Arno Wagner wrote:
> > Think external drives / removable storage?
> 
> An attacker with physical access that you do not notice has 
> won. Storage encryption does not protect here. Think, for 
> example, "evil maid" type attacks. Storage encryption
> is only for theft of the device (which you notice) or 
> attacker access which you notice in other ways.

This is exactly why integrity matters? The point is to have an usb drive /
external disk *fully* encrypted. The decryption is done by the host (which is
trusted). In that case, confidentiality and integrity are both important.

Regards,
-- 
Yves-Alexis


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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 14:13:21 CET, Yves-Alexis Perez wrote:
> On ven., 2016-02-05 at 12:02 +0100, Arno Wagner wrote:
> > > Think external drives / removable storage?
> > 
> > An attacker with physical access that you do not notice has 
> > won. Storage encryption does not protect here. Think, for 
> > example, "evil maid" type attacks. Storage encryption
> > is only for theft of the device (which you notice) or 
> > attacker access which you notice in other ways.
> 
> This is exactly why integrity matters? The point is to have an usb drive /
> external disk *fully* encrypted.  The decryption is done by the host
> (which is trusted).  In that case, confidentiality and integrity are both
> important.

No. You are trying to solve the wrong problem. First, disk 
encryption with 1:1 mapping will never give you integrity 
protection and the other variants kill performance.

And second, who says anything abot the "evil maid" changing
things in the encrypted container?

Seriosuly, what you want you do not do with disk encryption, 
but with PGP/GnuPG on file-level.

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] The future of disk encryption with LUKS2

[Zaolin]

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

Hi,

> On Fri, Feb 05, 2016 at 14:13:21 CET, Yves-Alexis Perez wrote:
> > On ven., 2016-02-05 at 12:02 +0100, Arno Wagner wrote:
> > > > Think external drives / removable storage?
> > > 
> > > An attacker with physical access that you do not notice has 
> > > won. Storage encryption does not protect here. Think, for 
> > > example, "evil maid" type attacks. Storage encryption
> > > is only for theft of the device (which you notice) or 
> > > attacker access which you notice in other ways.
> > 
> > This is exactly why integrity matters? The point is to have an usb
> > drive /
> > external disk *fully* encrypted.  The decryption is done by the
> > host
> > (which is trusted).  In that case, confidentiality and integrity
> > are both
> > important.
> 
> No. You are trying to solve the wrong problem. First, disk 
> encryption with 1:1 mapping will never give you integrity 
> protection and the other variants kill performance.
I partially agree. What's about using GCM or CCM mode of operation for
disk encryption ? ;) In order to solve the evil maid issue you need
hardware security and a secure boot process.
> 
> And second, who says anything abot the "evil maid" changing
> things in the encrypted container?
That's correct.
> 
> Seriosuly, what you want you do not do with disk encryption, 
> but with PGP/GnuPG on file-level.
> 
> Regards,
> Arno 

Regards Zaolin

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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Yves-Alexis Perez]

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

On ven., 2016-02-05 at 14:31 +0100, Arno Wagner wrote:
> No. You are trying to solve the wrong problem. First, disk 
> encryption with 1:1 mapping will never give you integrity 
> protection and the other variants kill performance.

I perfectly understand that, thank you. Again, I'm *well aware* of the need to
store integrity patterns somewhere. I'm *not* asking for 1:1 mapping.

Can I sincerely ask that you not consider at first (and second, and third)
that I didn't think first about what I was asking on the list?
> 
> And second, who says anything abot the "evil maid" changing
> things in the encrypted container?

I'm not following you here.
> 
> Seriosuly, what you want you do not do with disk encryption, 
> but with PGP/GnuPG on file-level.

Because encrypting whole disk with GnuPG doesn't really scale, for example? I
have to admit I'm a bit puzzled by the question on this list, to be honest.

Regards,
-- 
Yves-Alexis


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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Robert Nichols]

On 02/04/2016 11:23 AM, Arno Wagner wrote:
> On the other hand, resizing a Luks container with a
> filesystem in there without killing that filesystem is
> already complicated enough that I usually just recomend
> a backup and recreation instead of a resize.

Making an already difficult process more complex isn't going to
win many friends.  Sounds like what you need is a "--resizefs"
option like the one LVM's lvresize uses to invoke fsadm(8).

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 14:49:38 CET, Zaolin wrote:
> Hi,
> 
> > On Fri, Feb 05, 2016 at 14:13:21 CET, Yves-Alexis Perez wrote:
> > > On ven., 2016-02-05 at 12:02 +0100, Arno Wagner wrote:
> > > > > Think external drives / removable storage?
> > > > 
> > > > An attacker with physical access that you do not notice has 
> > > > won. Storage encryption does not protect here. Think, for 
> > > > example, "evil maid" type attacks. Storage encryption
> > > > is only for theft of the device (which you notice) or 
> > > > attacker access which you notice in other ways.
> > > 
> > > This is exactly why integrity matters? The point is to have an usb
> > > drive /
> > > external disk *fully* encrypted.  The decryption is done by the
> > > host
> > > (which is trusted).  In that case, confidentiality and integrity
> > > are both
> > > important.
> > 
> > No. You are trying to solve the wrong problem. First, disk 
> > encryption with 1:1 mapping will never give you integrity 
> > protection and the other variants kill performance.
> I partially agree. What's about using GCM or CCM mode of operation for
> disk encryption ? ;) In order to solve the evil maid issue you need
> hardware security and a secure boot process.

GCM needs extra storage and so does CCM. The problem is that
a simple entropy-argument shows that integrity protection is
infeasible in the general case without extra storage.

The effect is that unless you want to mess with effective
disk block size (not a good idea), you do not get integrity
protection in block-level disk encryption. On the other hand,
there is a file-level alternative: eCryptFS. It serves somewhat
different needs and has different performance characteristics.
It basically does automated per-file PGP-like encryption. (The 
format is even derived from PGP.) It does have some drawbacks 
though, for example filenames, the filesystem (think evil maid) 
and some metadata and information about file changes are not 
protected.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 16:01:14 CET, Yves-Alexis Perez wrote:
> On ven., 2016-02-05 at 14:31 +0100, Arno Wagner wrote:
> > No. You are trying to solve the wrong problem. First, disk 
> > encryption with 1:1 mapping will never give you integrity 
> > protection and the other variants kill performance.
> 
> I perfectly understand that, thank you. Again, I'm *well aware* of the need to
> store integrity patterns somewhere. I'm *not* asking for 1:1 mapping.
> 
> Can I sincerely ask that you not consider at first (and second, and third)
> that I didn't think first about what I was asking on the list?

Then why are you asking about integrity protection on a list
dedicated to a block-layer encryption system? That does not make
any sense. If you state things that do not make sense then I
will point that out, because there is a real possibility that
your reasoning process (I am not implying there was none) was 
flawed. 

> > And second, who says anything abot the "evil maid" changing
> > things in the encrypted container?
> 
> I'm not following you here.

Attacks on hardware, replacement of the disk with something that
attacks the boot process, Firewire, USB, etc. vulnerabilities, 
changes in non-encrypted areas, etc. 

> > 
> > Seriosuly, what you want you do not do with disk encryption, 
> > but with PGP/GnuPG on file-level.
> 
> Because encrypting whole disk with GnuPG doesn't really scale, for
> example?  I have to admit I'm a bit puzzled by the question on this list,
> to be honest.

Use eCryptFS for a scalable implementation of that idea.
In fact, eCryptFS uses a file-format derived from PGP, 
and that is no accident.

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] The future of disk encryption with LUKS2

[Milan Broz]

On 02/05/2016 04:24 PM, Arno Wagner wrote:
> On Fri, Feb 05, 2016 at 16:01:14 CET, Yves-Alexis Perez wrote:
>> On ven., 2016-02-05 at 14:31 +0100, Arno Wagner wrote:
>>> No. You are trying to solve the wrong problem. First, disk 
>>> encryption with 1:1 mapping will never give you integrity 
>>> protection and the other variants kill performance.
>>
>> I perfectly understand that, thank you. Again, I'm *well aware* of the need to
>> store integrity patterns somewhere. I'm *not* asking for 1:1 mapping.
>>
>> Can I sincerely ask that you not consider at first (and second, and third)
>> that I didn't think first about what I was asking on the list?
> 
> Then why are you asking about integrity protection on a list
> dedicated to a block-layer encryption system? That does not make
> any sense. If you state things that do not make sense then I
> will point that out, because there is a real possibility that
> your reasoning process (I am not implying there was none) was 
> flawed. 

I think it is perfectly fine to ask there (please do not forget
we are still closely cooperating with storage guys).

And by the way, we have a experimental plan to test authenticated encryption
on this level (obviously part of that is to solve additional metadata space).
(Even if it is not usable in the end I would like to try that.)

The reply/revert attack possibility without support of specific hw will
be still there but I would say even if we can provide method how to detect
random corruption of sectors it could be useful.

Milan

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 16:08:28 CET, Robert Nichols wrote:
> On 02/04/2016 11:23 AM, Arno Wagner wrote:
> >On the other hand, resizing a Luks container with a
> >filesystem in there without killing that filesystem is
> >already complicated enough that I usually just recomend
> >a backup and recreation instead of a resize.
> 
> Making an already difficult process more complex isn't going to
> win many friends.  Sounds like what you need is a "--resizefs"
> option like the one LVM's lvresize uses to invoke fsadm(8).

And thereby limit what filesystem can be in there? That is
a rather gross layering-violation and not a good idea.

Do not forget that backup and restore need to be tested
and the backup done regularly anyways if the data has any 
worth. I an not asking people to do anything new. (Well, 
except for those with only throwaway-data in their encrypted 
containers....)

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] The future of disk encryption with LUKS2

[Yves-Alexis Perez]

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

On ven., 2016-02-05 at 16:24 +0100, Arno Wagner wrote:
> Then why are you asking about integrity protection on a list
> dedicated to a block-layer encryption system? That does not make
> any sense. If you state things that do not make sense then I
> will point that out, because there is a real possibility that
> your reasoning process (I am not implying there was none) was 
> flawed. 

Because integrity protection *does* make sense on block layer encryption? The
fact that you don't have a 1:1 mapping is indeed an issue, and that's why I
was asking in the context of the LUKS2 thread (where supposedly new ideas
could be thrown), because solving the involved challenges would be useful in
the context of dm-crypt. I think. You could store all ICV in a specific place
in the block device, or have one block of ICVs every once in a while, or
something else. It'd involve some clever calculation indeed but it might be
doable.

But I can perfectly understand if it's not something which interest developers
here, and I can perfectly take “no” as an answer :)
> 
> > > And second, who says anything abot the "evil maid" changing
> > > things in the encrypted container?
> > 
> > I'm not following you here.
> 
> Attacks on hardware, replacement of the disk with something that
> attacks the boot process, Firewire, USB, etc. vulnerabilities, 
> changes in non-encrypted areas, etc.

This is about your external disk drive or usb where you put data on it. This
is not about boot integrity or something, really.

Regards,
-- 
Yves-Alexis


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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 16:44:02 CET, Milan Broz wrote:
> On 02/05/2016 04:24 PM, Arno Wagner wrote:
> > On Fri, Feb 05, 2016 at 16:01:14 CET, Yves-Alexis Perez wrote:
> >> On ven., 2016-02-05 at 14:31 +0100, Arno Wagner wrote:
> >>> No. You are trying to solve the wrong problem. First, disk 
> >>> encryption with 1:1 mapping will never give you integrity 
> >>> protection and the other variants kill performance.
> >>
> >> I perfectly understand that, thank you. Again, I'm *well aware* of the need to
> >> store integrity patterns somewhere. I'm *not* asking for 1:1 mapping.
> >>
> >> Can I sincerely ask that you not consider at first (and second, and third)
> >> that I didn't think first about what I was asking on the list?
> > 
> > Then why are you asking about integrity protection on a list
> > dedicated to a block-layer encryption system? That does not make
> > any sense. If you state things that do not make sense then I
> > will point that out, because there is a real possibility that
> > your reasoning process (I am not implying there was none) was 
> > flawed. 
> 
> I think it is perfectly fine to ask there (please do not forget
> we are still closely cooperating with storage guys).

It is fine to ask. But if you get your hackles up when being
told "not really", that is something else.
 
> And by the way, we have a experimental plan to test authenticated
> encryption on this level (obviously part of that is to solve additional
> metadata space).  (Even if it is not usable in the end I would like to try
> that.)

Sure, it would be interesting to see how badly this impacts
performance, for example. 
 
> The reply/revert attack possibility without support of specific hw will
> be still there but I would say even if we can provide method how to detect
> random corruption of sectors it could be useful.

From my experience with larger storage systems, I doubt that.
The disks do an excellent job of detecting sector corruption 
themselves these days. And even before, a defective CPU or RAM
was much more likely the cause of data corruption than an
undetected read error on disk.

As it is basically free with authenticated encryption, it may
still have some use though.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 17:50:14 CET, Yves-Alexis Perez wrote:
> On ven., 2016-02-05 at 16:24 +0100, Arno Wagner wrote:
> > Then why are you asking about integrity protection on a list
> > dedicated to a block-layer encryption system? That does not make
> > any sense. If you state things that do not make sense then I
> > will point that out, because there is a real possibility that
> > your reasoning process (I am not implying there was none) was 
> > flawed. 
> 

> Because integrity protection *does* make sense on block layer encryption?
> The fact that you don't have a 1:1 mapping is indeed an issue, and that's
> why I was asking in the context of the LUKS2 thread (where supposedly new
> ideas could be thrown), because solving the involved challenges would be
> useful in the context of dm-crypt.  I think.  You could store all ICV in a
> specific place in the block device, or have one block of ICVs every once
> in a while, or something else.  It'd involve some clever calculation
> indeed but it might be doable.
> 
> But I can perfectly understand if it's not something which interest
> developers here, and I can perfectly take “no” as an answer :)

Well, as they plan to *experiment* with it anyways (and I assume
"they" will be the dm-crypt people), we will see how viable it is.	

> > > > And second, who says anything abot the "evil maid" changing
> > > > things in the encrypted container?
> > > 
> > > I'm not following you here.
> > 
> > Attacks on hardware, replacement of the disk with something that
> > attacks the boot process, Firewire, USB, etc. vulnerabilities, 
> > changes in non-encrypted areas, etc.
> 

> This is about your external disk drive or usb where you put data on it.
> This is not about boot integrity or something, really.

I am well aware of that. Have a look at what types of "evil maid"
attacks are possible today. If somebody competent had access to 
your storage device, chances are they will be able to successfully 
attack the next machine you plug it into. Sure, may be expensive,
may take hardware modification, but do not think just because it 
is "only" a storage device it is always safe to plug it into a 
computer.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 20:53:44 CET, Arno Wagner wrote:
> On Fri, Feb 05, 2016 at 17:50:14 CET, Yves-Alexis Perez wrote:
> > On ven., 2016-02-05 at 16:24 +0100, Arno Wagner wrote:
> > > Then why are you asking about integrity protection on a list
> > > dedicated to a block-layer encryption system? That does not make
> > > any sense. If you state things that do not make sense then I
> > > will point that out, because there is a real possibility that
> > > your reasoning process (I am not implying there was none) was 
> > > flawed. 
> > 
> 
> > Because integrity protection *does* make sense on block layer encryption?
> > The fact that you don't have a 1:1 mapping is indeed an issue, and that's
> > why I was asking in the context of the LUKS2 thread (where supposedly new
> > ideas could be thrown), because solving the involved challenges would be
> > useful in the context of dm-crypt.  I think.  You could store all ICV in a
> > specific place in the block device, or have one block of ICVs every once
> > in a while, or something else.  It'd involve some clever calculation
> > indeed but it might be doable.
> > 
> > But I can perfectly understand if it's not something which interest
> > developers here, and I can perfectly take “no” as an answer :)
> 
> Well, as they plan to *experiment* with it anyways (and I assume
> "they" will be the dm-crypt people), we will see how viable it is.	
> 
> > > > > And second, who says anything abot the "evil maid" changing
> > > > > things in the encrypted container?
> > > > 
> > > > I'm not following you here.
> > > 
> > > Attacks on hardware, replacement of the disk with something that
> > > attacks the boot process, Firewire, USB, etc. vulnerabilities, 
> > > changes in non-encrypted areas, etc.
> > 
> 
> > This is about your external disk drive or usb where you put data on it.
> > This is not about boot integrity or something, really.
> 
> I am well aware of that. Have a look at what types of "evil maid"
> attacks are possible today. If somebody competent had access to 
> your storage device, chances are they will be able to successfully 
> attack the next machine you plug it into. Sure, may be expensive,
> may take hardware modification, but do not think just because it 
> is "only" a storage device it is always safe to plug it into a 
> computer.
> 
> Regards,
> Arno

P.S. Also, I apologize, I think I over-reacted.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Fri, Feb 05, 2016 at 20:45:35 CET, Arno Wagner wrote:
> On Fri, Feb 05, 2016 at 16:44:02 CET, Milan Broz wrote:
[...]
>  
> > The reply/revert attack possibility without support of specific hw will
> > be still there but I would say even if we can provide method how to detect
> > random corruption of sectors it could be useful.
> 
> From my experience with larger storage systems, I doubt that.
> The disks do an excellent job of detecting sector corruption 
> themselves these days. And even before, a defective CPU or RAM
> was much more likely the cause of data corruption than an
> undetected read error on disk.
> 
> As it is basically free with authenticated encryption, it may
> still have some use though.

Come to think of it, with iSCSI and Network Block Devices,
detecting corruption if the dm-crypt layer does not run
on the machine the disks are in makes quite a bit of sense,
even if it ends up detecting bus, controller and memory
problems and not disk problems. 

One application of iSCSI is exporting a volume from a 
slow-CPU NAS and then doing LUKS/dm-crypt on a machine 
with good CPU power but little space for disks.

Will in any case be interesting to see how much this does
cost in terms of performance in the real world.

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

It should be noted here, that LVM is incapable to resize when there'S 
multiple metadata areas (and that is certainly not a coincidence).

Arno, remember, that type of resizing usually only refers to filesystems 
that can be resized online and which is done by the FS itself (as in 
intriniscly). This is of course a limitation, but then again, who'd want 
to resize a dmcrypt container instead of recreating it, when using a 
filesystem that cannot be resized? That does not make too much sense too 
me, cause recreating the dm-crypt container is merely a single minor 
extra step when you recreate the filesystem anyway.

Regards

-Sven

Am 05.02.2016 um 16:57 schrieb Arno Wagner:
> On Fri, Feb 05, 2016 at 16:08:28 CET, Robert Nichols wrote:
>> On 02/04/2016 11:23 AM, Arno Wagner wrote:
>>> On the other hand, resizing a Luks container with a
>>> filesystem in there without killing that filesystem is
>>> already complicated enough that I usually just recomend
>>> a backup and recreation instead of a resize.
>>
>> Making an already difficult process more complex isn't going to
>> win many friends.  Sounds like what you need is a "--resizefs"
>> option like the one LVM's lvresize uses to invoke fsadm(8).
>
> And thereby limit what filesystem can be in there? That is
> a rather gross layering-violation and not a good idea.
>
> Do not forget that backup and restore need to be tested
> and the backup done regularly anyways if the data has any
> worth. I an not asking people to do anything new. (Well,
> except for those with only throwaway-data in their encrypted
> containers....)
>
> Regards,
> Arno
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

It might be the time of night, but I have no idea what you are 
trying to say....

Regards,
Arno

On Sat, Feb 06, 2016 at 00:51:07 CET, Sven Eschenberg wrote:
> It should be noted here, that LVM is incapable to resize when
> there'S multiple metadata areas (and that is certainly not a
> coincidence).
> 
> Arno, remember, that type of resizing usually only refers to
> filesystems that can be resized online and which is done by the FS
> itself (as in intriniscly). This is of course a limitation, but then
> again, who'd want to resize a dmcrypt container instead of
> recreating it, when using a filesystem that cannot be resized? That
> does not make too much sense too me, cause recreating the dm-crypt
> container is merely a single minor extra step when you recreate the
> filesystem anyway.
> 
> Regards
> 
> -Sven
> 
> Am 05.02.2016 um 16:57 schrieb Arno Wagner:
> >On Fri, Feb 05, 2016 at 16:08:28 CET, Robert Nichols wrote:
> >>On 02/04/2016 11:23 AM, Arno Wagner wrote:
> >>>On the other hand, resizing a Luks container with a
> >>>filesystem in there without killing that filesystem is
> >>>already complicated enough that I usually just recomend
> >>>a backup and recreation instead of a resize.
> >>
> >>Making an already difficult process more complex isn't going to
> >>win many friends.  Sounds like what you need is a "--resizefs"
> >>option like the one LVM's lvresize uses to invoke fsadm(8).
> >
> >And thereby limit what filesystem can be in there? That is
> >a rather gross layering-violation and not a good idea.
> >
> >Do not forget that backup and restore need to be tested
> >and the backup done regularly anyways if the data has any
> >worth. I an not asking people to do anything new. (Well,
> >except for those with only throwaway-data in their encrypted
> >containers....)
> >
> >Regards,
> >Arno
> >
> _______________________________________________
> 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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Might be, or I was just unable to communicate my thoughst properly.

The first paragraph rather commented on Robert's post. He talked about 
LVM and I wanted to point out that LVM is not a good example of how to 
properly handle resizing, as it fails to properly resize for multiple 
metadata locations. (A secondary header implies that all changes on both 
headers need to be atomic and in sync. While this is doable, LVM clearly 
shows, that it is not trivial, otherwise it would certainly be available 
as feature by now).

The second paragraph commented on your statement regarding filesystem 
resizing the way LVM handles it (lvm --resize). You stated this would 
limit the possible filesystems in the dm-crypt container where a resize 
could be done. I agreed that it is limited to those supporting online 
resizing. LVM uses fsadm which in turn uses the filesystem's API to do 
the resize operation. The operation is then commenced by the fs driver. 
You already said before, that you rather recommend to recreate the 
filesystem. If one goes this path, then there is no need for a resize 
operation on dm-crypt's side either. If you recreate the fs, then you 
can aswell just recreate the dm-crypt container instead of resizing it.

IMHO a dm-crypt resize operation only makes sense, if you plan to resize 
the filesystem aswell. Otherwise just backup and recreate.

Regards

-Sven


Am 06.02.2016 um 03:58 schrieb Arno Wagner:
> It might be the time of night, but I have no idea what you are
> trying to say....
>
> Regards,
> Arno
>
> On Sat, Feb 06, 2016 at 00:51:07 CET, Sven Eschenberg wrote:
>> It should be noted here, that LVM is incapable to resize when
>> there'S multiple metadata areas (and that is certainly not a
>> coincidence).
>>
>> Arno, remember, that type of resizing usually only refers to
>> filesystems that can be resized online and which is done by the FS
>> itself (as in intriniscly). This is of course a limitation, but then
>> again, who'd want to resize a dmcrypt container instead of
>> recreating it, when using a filesystem that cannot be resized? That
>> does not make too much sense too me, cause recreating the dm-crypt
>> container is merely a single minor extra step when you recreate the
>> filesystem anyway.
>>
>> Regards
>>
>> -Sven
>>
>> Am 05.02.2016 um 16:57 schrieb Arno Wagner:
>>> On Fri, Feb 05, 2016 at 16:08:28 CET, Robert Nichols wrote:
>>>> On 02/04/2016 11:23 AM, Arno Wagner wrote:
>>>>> On the other hand, resizing a Luks container with a
>>>>> filesystem in there without killing that filesystem is
>>>>> already complicated enough that I usually just recomend
>>>>> a backup and recreation instead of a resize.
>>>>
>>>> Making an already difficult process more complex isn't going to
>>>> win many friends.  Sounds like what you need is a "--resizefs"
>>>> option like the one LVM's lvresize uses to invoke fsadm(8).
>>>
>>> And thereby limit what filesystem can be in there? That is
>>> a rather gross layering-violation and not a good idea.
>>>
>>> Do not forget that backup and restore need to be tested
>>> and the backup done regularly anyways if the data has any
>>> worth. I an not asking people to do anything new. (Well,
>>> except for those with only throwaway-data in their encrypted
>>> containers....)
>>>
>>> Regards,
>>> Arno
>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Michael Kjörling]

On 6 Feb 2016 04:18 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
> (A secondary header implies that
> all changes on both headers need to be atomic and in sync. While
> this is doable, LVM clearly shows, that it is not trivial, otherwise
> it would certainly be available as feature by now).

I'm not so sure it does imply that. It does certainly imply the need
to know that a, and which one out of the lot, header is most up to
date, but that does not necessarily require writes to both to be done
atomically and in sync. (In fact, truly atomic, in-sync writes to
multiple distinct locations seems a physical impossibility at least in
the case of a single spinning disk, since the write head can only be
in one location at any one time.)

This is where the "update counter" and a checksum that I mentioned
earlier comes in. An example of how to actually do this might be to
first discard (or perhaps rather, remove from consideration) any
header which doesn't match its checksum (for integrity purposes), then
use the one with the highest update counter value (taking care to
allow for wraparound) as a starting point for the operation at hand,
then rewrite any previously discarded headers (ideally writing the
checksum last, such that the header remains considered invalid until
it has been fully rewritten).

Or maybe even better, rewrite a previously considered invalid header
(if any) first; that should ensure that as long as the storage itself
works properly, if any header is ever valid at the beginning of an
operation, there exists at all times at least one header which is
valid.

By placing the headers far apart from each other, this forces at least
spinning disks to seek, which naturally introduces a sequence point
into the write process; even if the two write requests were to be put
onto the I/O bus at the same instant, one write must complete before
the other can physically begin. (Finally, a good use for the seek
delay in rotational storage!)

This should work equally well for any number of header copies.

-- 
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] The future of disk encryption with LUKS2

[Arno Wagner]

Thanks, clearer now.

On Sat, Feb 06, 2016 at 04:18:29 CET, Sven Eschenberg wrote:
> Might be, or I was just unable to communicate my thoughst properly.
> 
> The first paragraph rather commented on Robert's post. He talked
> about LVM and I wanted to point out that LVM is not a good example
> of how to properly handle resizing, as it fails to properly resize
> for multiple metadata locations. (A secondary header implies that
> all changes on both headers need to be atomic and in sync. While
> this is doable, LVM clearly shows, that it is not trivial, otherwise
> it would certainly be available as feature by now).
> 
> The second paragraph commented on your statement regarding
> filesystem resizing the way LVM handles it (lvm --resize). You
> stated this would limit the possible filesystems in the dm-crypt
> container where a resize could be done. I agreed that it is limited
> to those supporting online resizing. LVM uses fsadm which in turn
> uses the filesystem's API to do the resize operation. The operation
> is then commenced by the fs driver. You already said before, that
> you rather recommend to recreate the filesystem. If one goes this
> path, then there is no need for a resize operation on dm-crypt's
> side either. If you recreate the fs, then you can aswell just
> recreate the dm-crypt container instead of resizing it.

I think I did recommend that. At least that was the idea:

1. Do backup
2. Resize partition 
3. Recreate LUKS container and restore backup

Far less ways for this to go wrong. And unless 1. is broken,
you can try again.

> IMHO a dm-crypt resize operation only makes sense, if you plan to
> resize the filesystem aswell. Otherwise just backup and recreate.

I agree to that. So maybe to satisfy KISS, it would be preferrable
to not even have container resize, even when the container becomes
aware of its size, unlike now. 

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Sat, Feb 06, 2016 at 11:01:40 CET, Michael Kjörling wrote:
> On 6 Feb 2016 04:18 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
> > (A secondary header implies that
> > all changes on both headers need to be atomic and in sync. While
> > this is doable, LVM clearly shows, that it is not trivial, otherwise
> > it would certainly be available as feature by now).
> 
> I'm not so sure it does imply that. It does certainly imply the need
> to know that a, and which one out of the lot, header is most up to
> date, but that does not necessarily require writes to both to be done
> atomically and in sync. (In fact, truly atomic, in-sync writes to
> multiple distinct locations seems a physical impossibility at least in
> the case of a single spinning disk, since the write head can only be
> in one location at any one time.)

You do not need it atomic on low level. Some soft real-time 
way to do it is quite enough (with a big error if it fails)
as there should not be any competing cryptsetup invocations
changing the header. If there are, you are doing it wrong.
 
But you do need the update to all headers or the key-management 
becomes broken. A simple example is that a key has been 
compromised and you change it. Unless this removes the old one 
from all headers, your container becomes insecure.

Incidentally, the same applies to a header backup or an image
backup including the header. I do warn of this in the FAQ.
Here you also need some (usually manual) soft real-time 
way to fix that.

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Hi Michael,


Am 06.02.2016 um 11:01 schrieb Michael Kjörling:
> On 6 Feb 2016 04:18 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
>> (A secondary header implies that
>> all changes on both headers need to be atomic and in sync. While
>> this is doable, LVM clearly shows, that it is not trivial, otherwise
>> it would certainly be available as feature by now).
>
> I'm not so sure it does imply that. It does certainly imply the need
> to know that a, and which one out of the lot, header is most up to
> date, but that does not necessarily require writes to both to be done
> atomically and in sync. (In fact, truly atomic, in-sync writes to
> multiple distinct locations seems a physical impossibility at least in
> the case of a single spinning disk, since the write head can only be
> in one location at any one time.)

Of course atomicity applies to the transaction as whole. Here atomicity 
implies that before starting and afterwards the state is consistent and 
that if something goes wrong inbetween, you'll be able to cleanly roll 
back or conclude the operation.
>
> This is where the "update counter" and a checksum that I mentioned
> earlier comes in. An example of how to actually do this might be to
> first discard (or perhaps rather, remove from consideration) any
> header which doesn't match its checksum (for integrity purposes), then
> use the one with the highest update counter value (taking care to
> allow for wraparound) as a starting point for the operation at hand,
> then rewrite any previously discarded headers (ideally writing the
> checksum last, such that the header remains considered invalid until
> it has been fully rewritten).

An update counter+checksum will not do the trick. Let's see (This is has 
not been completely thought over and checked) a resize operation that 
grows the container:
The backing device grows, possibly without any warning -> We'll need to 
keep the secondary header location in the primary header.
Check that both headers are consistent, otherwise fix them first.
Add old location and new planned location of the header into the WAL.
Read secondary header, write secondary header (note in WAL, note the 
secondary header at old location will be removed)
safely wipe old header (note in WAL)
Note that primary header's location info on secondary header is about to 
be updated, update and note success in WAL.

Check for consistency & clear WAL.

Hopefully I did not miss any step and yes, it is not THAT complicated as 
there is no concurrency involved, but the transactions for resizing need 
to be crafted carefully.

With a single metadatacopy 90% of the issues don't even exist ;-).

>
> Or maybe even better, rewrite a previously considered invalid header
> (if any) first; that should ensure that as long as the storage itself
> works properly, if any header is ever valid at the beginning of an
> operation, there exists at all times at least one header which is
> valid.
>
> By placing the headers far apart from each other, this forces at least
> spinning disks to seek, which naturally introduces a sequence point
> into the write process; even if the two write requests were to be put
> onto the I/O bus at the same instant, one write must complete before
> the other can physically begin. (Finally, a good use for the seek
> delay in rotational storage!)
>
> This should work equally well for any number of header copies.
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Michael Kjörling]

On 6 Feb 2016 19:56 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
> Hopefully I did not miss any step and yes, it is not THAT
> complicated as there is no concurrency involved, but the
> transactions for resizing need to be crafted carefully.

I agree, it gets more complicated when resizing a container. I was
considering primarily the normal use case of a container that isn't in
the process of changing its size.

-- 
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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Hi Arno,

Vou are welcome.

Am 06.02.2016 um 15:20 schrieb Arno Wagner:
> Thanks, clearer now.
>
> On Sat, Feb 06, 2016 at 04:18:29 CET, Sven Eschenberg wrote:
>> Might be, or I was just unable to communicate my thoughst properly.
>>
>> The first paragraph rather commented on Robert's post. He talked
>> about LVM and I wanted to point out that LVM is not a good example
>> of how to properly handle resizing, as it fails to properly resize
>> for multiple metadata locations. (A secondary header implies that
>> all changes on both headers need to be atomic and in sync. While
>> this is doable, LVM clearly shows, that it is not trivial, otherwise
>> it would certainly be available as feature by now).
>>
>> The second paragraph commented on your statement regarding
>> filesystem resizing the way LVM handles it (lvm --resize). You
>> stated this would limit the possible filesystems in the dm-crypt
>> container where a resize could be done. I agreed that it is limited
>> to those supporting online resizing. LVM uses fsadm which in turn
>> uses the filesystem's API to do the resize operation. The operation
>> is then commenced by the fs driver. You already said before, that
>> you rather recommend to recreate the filesystem. If one goes this
>> path, then there is no need for a resize operation on dm-crypt's
>> side either. If you recreate the fs, then you can aswell just
>> recreate the dm-crypt container instead of resizing it.
>
> I think I did recommend that. At least that was the idea:
>
> 1. Do backup
> 2. Resize partition
> 3. Recreate LUKS container and restore backup

You indeed did. Right now the container resizes without any interaction 
as the whole device simply is mapped. This of course has to change in 
one way (or another) if multiple metadatacopies are used. And providing 
a resize needs quite some work (in design and code). I wanted to point 
this out, as I had the impression that some others thought it would be 
trivial to keep the feature.

>
> Far less ways for this to go wrong. And unless 1. is broken,
> you can try again.
>
>> IMHO a dm-crypt resize operation only makes sense, if you plan to
>> resize the filesystem aswell. Otherwise just backup and recreate.
>
> I agree to that. So maybe to satisfy KISS, it would be preferrable
> to not even have container resize, even when the container becomes
> aware of its size, unlike now.
>
> Regards,
> Arno
>

For safety, yes, dumping the resize feature would be smarter. Then 
again, for those not faint at heart, why not give the option to do 
online resizes. For big storage-containers backup+online-resize still 
can safe you a lot of time (and downtime) afterall.

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Okay, I see, for simple updates a counter could indeed be sufficient to 
ensure consistency by bringing the header with lower counter in sync 
with the other one.

Regards

-Sven

Am 06.02.2016 um 20:09 schrieb Michael Kjörling:
> On 6 Feb 2016 19:56 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
>> Hopefully I did not miss any step and yes, it is not THAT
>> complicated as there is no concurrency involved, but the
>> transactions for resizing need to be crafted carefully.
>
> I agree, it gets more complicated when resizing a container. I was
> considering primarily the normal use case of a container that isn't in
> the process of changing its size.
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Lars Winterfeld]

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

On 06.02.2016 20:18, Sven Eschenberg wrote:
> Okay, I see, for simple updates a counter could indeed be sufficient to
> ensure consistency by bringing the header with lower counter in sync
> with the other one.

If one is afraid of, e.g., power loss in the middle of rewriting the
header, there could also be a "changing header" flag that is set to 1
first, then header data is changed, then the flag is reset to 0. If you
later find a flag set to 1, you should restore the other "backup"
header. Maybe this is useful in very rare cases, but also very easy to
implement, so one could still do it?



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

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

This discussion of multiple headers wrt resizing seems to be
overcomplicating the issue, while potentially breaking LUKS
for my use case.

First, overcomplicating:

Putting a backup header at the very end of the device, as we've seen,
requires all sorts of gymnastics to ensure that the right things
happen with updates and resizes.  But what are we really trying to
fix here?  Accidental header smashes?  In that case, might I suggest
something much simpler:

(a) If the underlying container is smaller than some figure (100 meg?),
just use a single header.  You could back up -the whole container-
in seconds, much less the header.

(b) If it's bigger, put a second header maybe 1 meg after the first
header, and start the encrypted container after that second header.

The idea here is to allow tiny containers for those cases which make
sense (if there are any), without chewing up several extra meg for a
backup header.  But if the container is larger than (say) 100 meg, the
extra space rapidly becomes completely negligible.  We don't have to
put the header at the end of the device---just keeping it several meg
away from things that are likely to smash it is fine.  (Something that
decides to eat 10's of meg into your filesystem is rare and will turn
the FS to swiss cheese anyway and you're going to have to go back to
your backups at that point, most likely.)

This doesn't solve the how-to-update-correctly problem (since we're
still talking two or more headers), but it -does- mean that enlarging
the partition -does not- require relocating a backup header!  This,
in turn, means no pressure to remove the ability to resize (most
especially, to -grow-) the container, which is very important to my
use case.

My use case:

I crucially depend on LUKS being able to grow to a larger container
-without having to throw away the existing filesystem-.  Why?  Because
one of my most-important use cases is a giant encrypted filesystem
which holds dirvish vaults.  These vaults are -very- extensively
hardlinked, not only forwards and backwards in time, but also sideways
across vaults, because I run faster-dupemerge across them to squeeze
out identical copies of files from similar hosts and from movement of
files from one host to another.

For example, I'm looking at one FS right now with 8 TB in it,
consisting of about 845 million inodes, with a huge number of
those reflecting files with tens of hardlinks or more.

This FS is built on top of LUKS, on top of LVM, on top of RAID.
I have enlarged it by either migrating to larger disks, or by
adding disks and adding LV's, then growing LUKS to cover them
(which it does automatically, since it resizes itself to the
size of the underlying device), and then growing the filesystem.
[I can do this online, since the filesystem is ext4.]

Because there are so many hardlinks and the filesystem is so large, it
is NOT POSSIBLE to copy this filesystem at the file level to another
device.  I can point at previous discussions from years ago on other
lists detailing the difficulties, but here's an outline:  Neither
rsync nor tar nor cpio can walk the entire filesystem without eating
enormous quantities of RAM, which cannot physically fit in the
machine, which means enormous paging, which means runtime of months
if not years.  It is also infeasible to move the filesystem in slices,
because that would break all the hardlinks between the shards, and
recomputing them is both computationally expensive -and- would alter
directory write times in undesireable ways.

When I have migrated this FS to different hardware in the past, I've
either done a block-level copy with dd (after dismounting it, of
course), or swapped RAID devices underneath it, And then, if I'm going
to larger disks (the primary reason for moving it, especially before
it was also a RAID), I've resized, including resizing the LUKS layer,
of course.

If LUKS lost the ability to resize in place, LUKS would become useless
to me for this workload.  "You should copy it elsewhere and redo LUKS
and then copy back" is simply a nonstarter.  At the very best, that
would mean a block-level copy of the whole thing, recreation of LUKS,
and copy back, using either dd or playing RAID games, while the entire
FS was down.  That's several days.  But the current scheme, where LUKS
can resize in place, means I can (if I have to) back up the filesystem
via RAID (e.g., add disks, sync, remove) while it's still up, then
resize, and see no downtime at all.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

Incidentally, this is the way Linux md-RAID checks whether
elements are in sync on RAID assembly. I don't know how 
reliable and often md-RAID updates the counters, but I 
have not run into problems so far.

For the LUKS header, a classic 2-phase commit would
not be a problem. Disks do lie about having flushed
buffers to disk (this world being pretty imperfect, in
particular with regards to its inhabitants), but
with some sensible delays that any header updates need 
anyways, this should be pretty reliable.

Regards,
Arno

On Sat, Feb 06, 2016 at 20:18:02 CET, Sven Eschenberg wrote:
> Okay, I see, for simple updates a counter could indeed be sufficient
> to ensure consistency by bringing the header with lower counter in
> sync with the other one.
> 
> Regards
> 
> -Sven
> 
> Am 06.02.2016 um 20:09 schrieb Michael Kjörling:
> >On 6 Feb 2016 19:56 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
> >>Hopefully I did not miss any step and yes, it is not THAT
> >>complicated as there is no concurrency involved, but the
> >>transactions for resizing need to be crafted carefully.
> >
> >I agree, it gets more complicated when resizing a container. I was
> >considering primarily the normal use case of a container that isn't in
> >the process of changing its size.
> >
> _______________________________________________
> 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] The future of disk encryption with LUKS2

[Arno Wagner]

I see your problem. The more simple solution would be to
default to a header copy at the end (people being careless),
but to allow to explicitely disable/endable it on creation 
and later. In fact, I am very much for adding these options.

You and (likely) I would run with single headers, but looking 
at the history of this list, that default backup header would 
have helped quite a few people.

Would be a single flag in the header and a check for the
second header if the first one is damaged. Use of that
second header should require answering a safety question with 
YES or giving a --force option or the like. Would also need
an option to update container size to the size of the underlying
block-device (as it does now automatically on mapping).

Regards,
Arno


On Sun, Feb 07, 2016 at 08:09:58 CET, f-dm-c@media.mit.edu wrote:
> This discussion of multiple headers wrt resizing seems to be
> overcomplicating the issue, while potentially breaking LUKS
> for my use case.
> 
> First, overcomplicating:
> 
> Putting a backup header at the very end of the device, as we've seen,
> requires all sorts of gymnastics to ensure that the right things
> happen with updates and resizes.  But what are we really trying to
> fix here?  Accidental header smashes?  In that case, might I suggest
> something much simpler:
> 
> (a) If the underlying container is smaller than some figure (100 meg?),
> just use a single header.  You could back up -the whole container-
> in seconds, much less the header.
> 
> (b) If it's bigger, put a second header maybe 1 meg after the first
> header, and start the encrypted container after that second header.
> 
> The idea here is to allow tiny containers for those cases which make
> sense (if there are any), without chewing up several extra meg for a
> backup header.  But if the container is larger than (say) 100 meg, the
> extra space rapidly becomes completely negligible.  We don't have to
> put the header at the end of the device---just keeping it several meg
> away from things that are likely to smash it is fine.  (Something that
> decides to eat 10's of meg into your filesystem is rare and will turn
> the FS to swiss cheese anyway and you're going to have to go back to
> your backups at that point, most likely.)
> 
> This doesn't solve the how-to-update-correctly problem (since we're
> still talking two or more headers), but it -does- mean that enlarging
> the partition -does not- require relocating a backup header!  This,
> in turn, means no pressure to remove the ability to resize (most
> especially, to -grow-) the container, which is very important to my
> use case.
> 
> My use case:
> 
> I crucially depend on LUKS being able to grow to a larger container
> -without having to throw away the existing filesystem-.  Why?  Because
> one of my most-important use cases is a giant encrypted filesystem
> which holds dirvish vaults.  These vaults are -very- extensively
> hardlinked, not only forwards and backwards in time, but also sideways
> across vaults, because I run faster-dupemerge across them to squeeze
> out identical copies of files from similar hosts and from movement of
> files from one host to another.
> 
> For example, I'm looking at one FS right now with 8 TB in it,
> consisting of about 845 million inodes, with a huge number of
> those reflecting files with tens of hardlinks or more.
> 
> This FS is built on top of LUKS, on top of LVM, on top of RAID.
> I have enlarged it by either migrating to larger disks, or by
> adding disks and adding LV's, then growing LUKS to cover them
> (which it does automatically, since it resizes itself to the
> size of the underlying device), and then growing the filesystem.
> [I can do this online, since the filesystem is ext4.]
> 
> Because there are so many hardlinks and the filesystem is so large, it
> is NOT POSSIBLE to copy this filesystem at the file level to another
> device.  I can point at previous discussions from years ago on other
> lists detailing the difficulties, but here's an outline:  Neither
> rsync nor tar nor cpio can walk the entire filesystem without eating
> enormous quantities of RAM, which cannot physically fit in the
> machine, which means enormous paging, which means runtime of months
> if not years.  It is also infeasible to move the filesystem in slices,
> because that would break all the hardlinks between the shards, and
> recomputing them is both computationally expensive -and- would alter
> directory write times in undesireable ways.
> 
> When I have migrated this FS to different hardware in the past, I've
> either done a block-level copy with dd (after dismounting it, of
> course), or swapped RAID devices underneath it, And then, if I'm going
> to larger disks (the primary reason for moving it, especially before
> it was also a RAID), I've resized, including resizing the LUKS layer,
> of course.
> 
> If LUKS lost the ability to resize in place, LUKS would become useless
> to me for this workload.  "You should copy it elsewhere and redo LUKS
> and then copy back" is simply a nonstarter.  At the very best, that
> would mean a block-level copy of the whole thing, recreation of LUKS,
> and copy back, using either dd or playing RAID games, while the entire
> FS was down.  That's several days.  But the current scheme, where LUKS
> can resize in place, means I can (if I have to) back up the filesystem
> via RAID (e.g., add disks, sync, remove) while it's still up, then
> resize, and see no downtime at all.
> _______________________________________________
> 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] The future of disk encryption with LUKS2

[Sven Eschenberg]

I know that mdraid uses an events counter and checksum, probably Neil 
Brown could clarify on the amount of updates. Never had problems either, 
then again I think that mdraid signatures are by a magnitute smaller 
than a LUKS header (mdadm signature/header is 1 sector). The checksum of 
course is a good idea, to detect if the 'newer' header is corrupted or 
partially written.

Concerning disks, I thought with ACS2/ATA-8 real write barriers were 
introduced. On the other hand I've seen disks returning successfull 
reads with long zero-burst-errors undetected - no fun. I always wondered 
how a HDD exactly behaves when power fails, while a sector is in 
transit. My best hope is, that the CRC at the end of the sector does not 
match and an error is returned on the next read?

Regards

-Sven


Am 08.02.2016 um 00:05 schrieb Arno Wagner:
> Incidentally, this is the way Linux md-RAID checks whether
> elements are in sync on RAID assembly. I don't know how
> reliable and often md-RAID updates the counters, but I
> have not run into problems so far.
>
> For the LUKS header, a classic 2-phase commit would
> not be a problem. Disks do lie about having flushed
> buffers to disk (this world being pretty imperfect, in
> particular with regards to its inhabitants), but
> with some sensible delays that any header updates need
> anyways, this should be pretty reliable.
>
> Regards,
> Arno
>
> On Sat, Feb 06, 2016 at 20:18:02 CET, Sven Eschenberg wrote:
>> Okay, I see, for simple updates a counter could indeed be sufficient
>> to ensure consistency by bringing the header with lower counter in
>> sync with the other one.
>>
>> Regards
>>
>> -Sven
>>
>> Am 06.02.2016 um 20:09 schrieb Michael Kjörling:
>>> On 6 Feb 2016 19:56 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
>>>> Hopefully I did not miss any step and yes, it is not THAT
>>>> complicated as there is no concurrency involved, but the
>>>> transactions for resizing need to be crafted carefully.
>>>
>>> I agree, it gets more complicated when resizing a container. I was
>>> considering primarily the normal use case of a container that isn't in
>>> the process of changing its size.
>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

A simple grow/shrink could be done by dumping the secondary header, 
changing size and recreating the header. Of course the indermediate 
phase will not 'forgive' any errors or severe failures, the resize would 
be quite simplistic though.

With a single header all partial writes whil be disastrous (which is the 
status quo) and a secondary header helps recovering from such type of 
failures.

How about a '--resize --drop-secondary-header --yes-i-am-bold' variant 
for resize operations? (*scnr*)

Regards

-Sven


Am 08.02.2016 um 00:17 schrieb Arno Wagner:
> I see your problem. The more simple solution would be to
> default to a header copy at the end (people being careless),
> but to allow to explicitely disable/endable it on creation
> and later. In fact, I am very much for adding these options.
>
> You and (likely) I would run with single headers, but looking
> at the history of this list, that default backup header would
> have helped quite a few people.
>
> Would be a single flag in the header and a check for the
> second header if the first one is damaged. Use of that
> second header should require answering a safety question with
> YES or giving a --force option or the like. Would also need
> an option to update container size to the size of the underlying
> block-device (as it does now automatically on mapping).
>
> Regards,
> Arno
>
>
> On Sun, Feb 07, 2016 at 08:09:58 CET, f-dm-c@media.mit.edu wrote:
>> This discussion of multiple headers wrt resizing seems to be
>> overcomplicating the issue, while potentially breaking LUKS
>> for my use case.
>>
>> First, overcomplicating:
>>
>> Putting a backup header at the very end of the device, as we've seen,
>> requires all sorts of gymnastics to ensure that the right things
>> happen with updates and resizes.  But what are we really trying to
>> fix here?  Accidental header smashes?  In that case, might I suggest
>> something much simpler:
>>
>> (a) If the underlying container is smaller than some figure (100 meg?),
>> just use a single header.  You could back up -the whole container-
>> in seconds, much less the header.
>>
>> (b) If it's bigger, put a second header maybe 1 meg after the first
>> header, and start the encrypted container after that second header.
>>
>> The idea here is to allow tiny containers for those cases which make
>> sense (if there are any), without chewing up several extra meg for a
>> backup header.  But if the container is larger than (say) 100 meg, the
>> extra space rapidly becomes completely negligible.  We don't have to
>> put the header at the end of the device---just keeping it several meg
>> away from things that are likely to smash it is fine.  (Something that
>> decides to eat 10's of meg into your filesystem is rare and will turn
>> the FS to swiss cheese anyway and you're going to have to go back to
>> your backups at that point, most likely.)
>>
>> This doesn't solve the how-to-update-correctly problem (since we're
>> still talking two or more headers), but it -does- mean that enlarging
>> the partition -does not- require relocating a backup header!  This,
>> in turn, means no pressure to remove the ability to resize (most
>> especially, to -grow-) the container, which is very important to my
>> use case.
>>
>> My use case:
>>
>> I crucially depend on LUKS being able to grow to a larger container
>> -without having to throw away the existing filesystem-.  Why?  Because
>> one of my most-important use cases is a giant encrypted filesystem
>> which holds dirvish vaults.  These vaults are -very- extensively
>> hardlinked, not only forwards and backwards in time, but also sideways
>> across vaults, because I run faster-dupemerge across them to squeeze
>> out identical copies of files from similar hosts and from movement of
>> files from one host to another.
>>
>> For example, I'm looking at one FS right now with 8 TB in it,
>> consisting of about 845 million inodes, with a huge number of
>> those reflecting files with tens of hardlinks or more.
>>
>> This FS is built on top of LUKS, on top of LVM, on top of RAID.
>> I have enlarged it by either migrating to larger disks, or by
>> adding disks and adding LV's, then growing LUKS to cover them
>> (which it does automatically, since it resizes itself to the
>> size of the underlying device), and then growing the filesystem.
>> [I can do this online, since the filesystem is ext4.]
>>
>> Because there are so many hardlinks and the filesystem is so large, it
>> is NOT POSSIBLE to copy this filesystem at the file level to another
>> device.  I can point at previous discussions from years ago on other
>> lists detailing the difficulties, but here's an outline:  Neither
>> rsync nor tar nor cpio can walk the entire filesystem without eating
>> enormous quantities of RAM, which cannot physically fit in the
>> machine, which means enormous paging, which means runtime of months
>> if not years.  It is also infeasible to move the filesystem in slices,
>> because that would break all the hardlinks between the shards, and
>> recomputing them is both computationally expensive -and- would alter
>> directory write times in undesireable ways.
>>
>> When I have migrated this FS to different hardware in the past, I've
>> either done a block-level copy with dd (after dismounting it, of
>> course), or swapped RAID devices underneath it, And then, if I'm going
>> to larger disks (the primary reason for moving it, especially before
>> it was also a RAID), I've resized, including resizing the LUKS layer,
>> of course.
>>
>> If LUKS lost the ability to resize in place, LUKS would become useless
>> to me for this workload.  "You should copy it elsewhere and redo LUKS
>> and then copy back" is simply a nonstarter.  At the very best, that
>> would mean a block-level copy of the whole thing, recreation of LUKS,
>> and copy back, using either dd or playing RAID games, while the entire
>> FS was down.  That's several days.  But the current scheme, where LUKS
>> can resize in place, means I can (if I have to) back up the filesystem
>> via RAID (e.g., add disks, sync, remove) while it's still up, then
>> resize, and see no downtime at all.
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 00:17:50 +0100
    > From: Arno Wagner <arno@wagner.name>

    > I see your problem. The more simple solution would be to
    > default to a header copy at the end (people being careless),
    > but to allow to explicitely disable/endable it on creation 
    > and later. In fact, I am very much for adding these options.

That still seems to be more complicated than it needs to be.

    > You and (likely) I would run with single headers, but looking 
    > at the history of this list, that default backup header would 
    > have helped quite a few people.

Even a second header right after the first---or with an empty gap of a
meg or something---would solve the overwritten-by-OS problem, and even
the bad-disk-sector-in-an-unfortunate-place problem, or the power-
failure-exactly-when-modifying-a-keyslot problem.  It takes up so
little space that just always doing it (unless it's a truly tiny
container) would make sense, assuming you're going to change the
format at all from only one header.  And it's way easier to do than to
rely on correctly knowing the end of the container when that end might
move.  That also means you don't need all kinds of fancy switches and
options to control the behavior, -especially- switches and options
that both installers and gparted etc must now learn to use whenever
the container is being resized.  Either leave things with a single
header, or just write a second one with a one meg empty gap between
it and the first one, and call it a day already.

[Putting the backup right at the end of the partition only solves some
problems anyway---anything which moves a potential later partition
backwards could overwrite it, and I've occasionally seen mistakes like
that when repartitioning, depending on the tool.  Certain RAID formats
put data near the end of the partition as well, and they often suffer
obscure failures modes because of that as well.]

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Placing the secondary (backup) header closely to the first one is not a 
good idea. While this does resolve a power failure induced broken 
header, all other problems persist.

If a sector fails, it is not that uncommon that a whole chunk of 
consecutive sectors fail (for rotating disks that is). While a recovery 
from such a severe failure poses further problems on higher levels, the 
risk both headers get damaged is not that small, if they are too close 
to each other.

Same holds true when structured data is written over the header 
accidently. Depending on the FS and other things both headers could 
easily be damaged. Well, if the headers are far apart (start/end) this 
could still happen ... true.

The LUKS-header (including key material, which indeed is vital and needs 
to be replicated as well) is not as small as you might think, as the 
size strongly depends on various parameters.

IMHO a small 1 MB gap is not really an option, as most problems won't be 
really solved by this.

It would be possible to place the header at floor(dev_sectors/2) or 
something, but this would be pretty complicated, as you'd have to add a 
dm-layer to tie together the backing device split by the header or 
modify dm-crypt in ther kernel to skip over the gap properly. This seems 
a little too nasty for me.

Regards

-Sven

Am 08.02.2016 um 03:06 schrieb f-dm-c@media.mit.edu:
>      > Date: Mon, 8 Feb 2016 00:17:50 +0100
>      > From: Arno Wagner <arno@wagner.name>
>
>      > I see your problem. The more simple solution would be to
>      > default to a header copy at the end (people being careless),
>      > but to allow to explicitely disable/endable it on creation
>      > and later. In fact, I am very much for adding these options.
>
> That still seems to be more complicated than it needs to be.
>
>      > You and (likely) I would run with single headers, but looking
>      > at the history of this list, that default backup header would
>      > have helped quite a few people.
>
> Even a second header right after the first---or with an empty gap of a
> meg or something---would solve the overwritten-by-OS problem, and even
> the bad-disk-sector-in-an-unfortunate-place problem, or the power-
> failure-exactly-when-modifying-a-keyslot problem.  It takes up so
> little space that just always doing it (unless it's a truly tiny
> container) would make sense, assuming you're going to change the
> format at all from only one header.  And it's way easier to do than to
> rely on correctly knowing the end of the container when that end might
> move.  That also means you don't need all kinds of fancy switches and
> options to control the behavior, -especially- switches and options
> that both installers and gparted etc must now learn to use whenever
> the container is being resized.  Either leave things with a single
> header, or just write a second one with a one meg empty gap between
> it and the first one, and call it a day already.
>
> [Putting the backup right at the end of the partition only solves some
> problems anyway---anything which moves a potential later partition
> backwards could overwrite it, and I've occasionally seen mistakes like
> that when repartitioning, depending on the tool.  Certain RAID formats
> put data near the end of the partition as well, and they often suffer
> obscure failures modes because of that as well.]
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 03:46:27 +0100
    > From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>

    > If a sector fails, it is not that uncommon that a whole chunk of 
    > consecutive sectors fail (for rotating disks that is).

Oh, come on.  A one-meg gap is 256 4K sectors and 1024 1K sectors.

I've never seen anything take out more than a handful of sectors
adjacent to each other unless the disk has completely failed.
Anything that's chewing up multiple megs or tens of megs at the start
of your FS is likely to destroy any other random parts of it as well.

Okay, how about a -10- meg gap?  That enough?

If you need resiliency from massive corruption like that, use a header
backup -on other media-, and -also- an actual backup of the FS.

Complicating LUKS to the point where resizing becomes fraught and
difficult to handle and other tools need all kinds of special
instructions to solve a problem where the disk is already in severe
distress or something's written tens of megs of garbage all over it
seems pointless.

The (potentially solvable) problem we've seen most on this list is not
massive disk failure, but OS's that decide to overwrite a sector or
two near the front.  So maybe we'll be extravagent and use 10 megs of
clear space between the two copies---that's still absolutely in the
noise on any reasonable disk, while being dead simple to implement,
does not require any knowledge of the ultimate container size, does
not require motion if the size changes, and will withstand almost any
conceivable failure except someone doing "dd if=/dev/zero of=part" and
then not noticing until a minute later---at which point, it's time to
go to the backups anyway.  And it doesn't involve hairing up the
options to enable/disable/move around/dance a jig with where the
backup header is stored.  Keep it simple.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Am 08.02.2016 um 04:43 schrieb f-dm-c@media.mit.edu:
>      > Date: Mon, 8 Feb 2016 03:46:27 +0100
>      > From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
>
>      > If a sector fails, it is not that uncommon that a whole chunk of
>      > consecutive sectors fail (for rotating disks that is).
>
> Oh, come on.  A one-meg gap is 256 4K sectors and 1024 1K sectors.
>
> I've never seen anything take out more than a handful of sectors
> adjacent to each other unless the disk has completely failed.
> Anything that's chewing up multiple megs or tens of megs at the start
> of your FS is likely to destroy any other random parts of it as well.
>
> Okay, how about a -10- meg gap?  That enough?

Well, I've seen several thoundand adjacent sectors going down. And not 
just once.

As I pointed out creating a filesystem can easily destroy both headers, 
even though many FSes have a rather thin metadata structure. Another 
neat example mdadm - default is header at 4k (primary header will be 
damaged) followed by a bad block list and and intent bitmap. The size of 
those can vary afaik.

To be honest, I am not completely sure what a good offset would be.

>
> If you need resiliency from massive corruption like that, use a header
> backup -on other media-, and -also- an actual backup of the FS.

Of course, that's what I usually do anyway. But we'll have to at least 
consider an average user aswell, having a normal desktop, using a magic 
mumbo jumbo installer with LVM on top of dm-crypt setup. It's not about 
covering your or my use case, but rather those of as many users as 
possible, without sacrificing i.e. security though.

>
> Complicating LUKS to the point where resizing becomes fraught and
> difficult to handle and other tools need all kinds of special
> instructions to solve a problem where the disk is already in severe
> distress or something's written tens of megs of garbage all over it
> seems pointless.

Of course overcomplicating things is not an option. But you should 
always remember: A damaged header is a total loss, a damaged fs can 
quite often be recovered easily enough. And other tools need 'special 
instructions' for every fs, dm-layer and task. There's no generic 
resize() IOCTL for all your block layers.

>
> The (potentially solvable) problem we've seen most on this list is not
> massive disk failure, but OS's that decide to overwrite a sector or
> two near the front.  So maybe we'll be extravagent and use 10 megs of
> clear space between the two copies---that's still absolutely in the
> noise on any reasonable disk, while being dead simple to implement,
> does not require any knowledge of the ultimate container size, does
> not require motion if the size changes, and will withstand almost any
> conceivable failure except someone doing "dd if=/dev/zero of=part" and
> then not noticing until a minute later---at which point, it's time to
> go to the backups anyway.  And it doesn't involve hairing up the
> options to enable/disable/move around/dance a jig with where the
> backup header is stored.  Keep it simple.

I don't mind keeping it simple. Really simple and secure was already 
mentioned: You do have a backup anyway, just recreate the container and 
pull back the backup and you are done ;-). Resizing (growing) is just a 
convenient thing to do.

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 05:32:14 +0100
    > From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>

    > Of course, that's what I usually do anyway. But we'll have to at least 
    > consider an average user aswell, having a normal desktop, using a magic 
    > mumbo jumbo installer with LVM on top of dm-crypt setup. It's not about 
    > covering your or my use case, but rather those of as many users as 
    > possible, without sacrificing i.e. security though.

Right.  And the average user is using an installer that might want to
expand a partition.  If that doesn't work, LUKS is a nonstarter there.
Even if it -could- work, but installers suddenly have to be aware of
which version of LUKS they're talking so they can supply magic random
options, then that's a situation where it's very likely that installers
will screw it up.  And installers screwing it up is -precisely- why
we're talking about having header redundancy in the first place.
Let's please not -encourage- screwups of rare-and-not-well-tested
actions that can lose data.

Also, the -average- user is not experiencing multiple megabytes of
corruption at the beginning of partitions.  C'mon.  The -average-
user is experiencing a bad Ubuntu installer deciding to put a
partition table on top of a LUKS header or some other handful-
of-sectors corruption.  Not a megabyte, much less ten or more.

    > Of course overcomplicating things is not an option. But you should 
    > always remember: A damaged header is a total loss, a damaged fs can 
    > quite often be recovered easily enough. And other tools need 'special 
    > instructions' for every fs, dm-layer and task. There's no generic 
    > resize() IOCTL for all your block layers.

But all the rest of them do assume that they can use the entire
container unless you say not to, and that expansion works.

Every single layer of what -I- do -is- resizeable---I can resize
partitions, and LVM, and LUKS, and ext4.  Any solution in which LUKS
can no longer be resized (especially grown) means that LUKS will be
instantly heaved overboard in favor of something else that can,
because it's the only thing in the stack which would fail that test.

    > I don't mind keeping it simple. Really simple and secure was already 
    > mentioned: You do have a backup anyway, just recreate the container and 
    > pull back the backup and you are done ;-). Resizing (growing) is just a 
    > convenient thing to do.

Did you actually read my original message?  As I said, in my use case,
it is simply not an option to "back up, blow away, resize, and put
back," because having to do that offline means multiple days of
downtime to do two entirely-pointless block-level copies, one in each
direction, on a -dismounted- FS.  Those multiple days are clearly not
required if LUKS can grow---I've done it before without downtime,
precisely because all layers can grow.

Let me try to summarize:  The reason we are having this conversation
at all is because proposals to increase the robustness of LUKS headers
almost immediately allowed the perfect to become the enemy of the good
---to the point where increasing their robustness lead to comments like
"well, let's just kill the ability of LUKS to grow because it's too
hard to figure out how to preserve the multiple headers in that case."
That is a big warning sign that the proposal is too complex.

One other thing:  One problem with putting a redundant header at the
end is that something which resizes the container out from under LUKS
(prime candidate for "something just corrupted the container") means
that LUKS (and any user trying to find that header by hand) has no
idea where to look for it, short of scanning every single block on
the disk for something that looks like a header.  Putting it near the
front means that LUKS either has only one option, or at the very least
only a very small number of blocks to scan, before it concludes that
it's either found the header or there isn't one.

[For example, and to take into account "OMG but what if massive giant
corruptions and/or mislayered tables at start," have these as defaults:
(a) FS < 10 meg --> no extra header
(b) 10 meg < FS < 100 meg --> extra header after 1 meg gap
(c) 100 meg < FS < 10 gig --> extra header after 10 meg gap
(d) fs > 10 gig --> extra header after 100 meg gap
(where "gap" means "really unused---don't give it to the FS" or maybe
even "put a backup header every n megabytes all through the gap"), and
have --redundant-header-at=[none|offset-in-meg] option for those who
insist on putting it somewhere magic.  Now LUKS has at most 3 places
to look even if it doesn't know how big the FS was, or a scan if the
user used --redundant-header-at.  But the code is still very simple,
online resizing works the way it always did, and people who are super-
paranoid about corrupting a gig at the start of their partition can
throw away an entire gig by pushing it farther in or something.  Or
putting it at the end, but then LUKS has to treat the gap as actual FS
storage area, which is again more complicated, so I don't recommend it.]

Re: [dm-crypt] The future of disk encryption with LUKS2

[Michael Kjörling]

On 8 Feb 2016 01:25 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
> I always
> wondered how a HDD exactly behaves when power fails, while a sector
> is in transit. My best hope is, that the CRC at the end of the
> sector does not match and an error is returned on the next read?

That's the theory; if a sector write is interrupted half way through
(regardless of the reason), then the FEC data doesn't match the sector
payload data. In this case, the difference is very likely large enough
that the error cannot be corrected using the FEC data, so you get a
read error back instead.

_Unfortunately_, theory and practice don't always agree. I think it
was Google that did a study on storage errors not all that long ago,
and one conclusion was that silent read errors (where you do get data
back from the drive, but that data is not the same as was originally
written), while rare, happens with a high enough probability to
warrant consideration in large storage systems.

-- 
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] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 01:25:31 CET, Sven Eschenberg wrote:
[...]
> Concerning disks, I thought with ACS2/ATA-8 real write barriers were
> introduced. On the other hand I've seen disks returning successfull
> reads with long zero-burst-errors undetected - no fun. I always
> wondered how a HDD exactly behaves when power fails, while a sector
> is in transit. My best hope is, that the CRC at the end of the
> sector does not match and an error is returned on the next read?

For these you should have intact data on disk, but
your data never made it there. If data after the zeros
did get written fine, there is a simple explanation:
Modern disks may reorder sectors in order to be able
to begin writing as soon as the heads are stable in 
the track.

Behavior on power failure used to be that the disk will 
notice the power failing early enough that it has enough 
time left with hood power to finish a sector-write in 
progress. I think that still applies. The zeros would 
then be sector-aligned and/or the data that was in 
those sectors before, hence the checksums are fine.

The thing is that in a typical PC, power drops relatively 
slowly and disks work non-seeking for a lower voltage
that the thresholds. Add to that that a single sector
write takes less than 1ms (probably much less), and
you get ample time to finish a write in progress.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 05:32:14 CET, Sven Eschenberg wrote:
> 
> 
> Am 08.02.2016 um 04:43 schrieb f-dm-c@media.mit.edu:
> >     > Date: Mon, 8 Feb 2016 03:46:27 +0100
> >     > From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
> >
> >     > If a sector fails, it is not that uncommon that a whole chunk of
> >     > consecutive sectors fail (for rotating disks that is).
> >
> >Oh, come on.  A one-meg gap is 256 4K sectors and 1024 1K sectors.
> >
> >I've never seen anything take out more than a handful of sectors
> >adjacent to each other unless the disk has completely failed.
> >Anything that's chewing up multiple megs or tens of megs at the start
> >of your FS is likely to destroy any other random parts of it as well.
> >
> >Okay, how about a -10- meg gap?  That enough?
> 
> Well, I've seen several thoundand adjacent sectors going down. And
> not just once.

Same here.
 
> As I pointed out creating a filesystem can easily destroy both
> headers, even though many FSes have a rather thin metadata
> structure. Another neat example mdadm - default is header at 4k
> (primary header will be damaged) followed by a bad block list and
> and intent bitmap. The size of those can vary afaik.
> 
> To be honest, I am not completely sure what a good offset would be.

I like the end, because it is clear and far away. It is also what
md-RAID for superblock 0.90 does.

Non-redudancy during resize is not an issue, as anybody sane will 
only resize with a header-backup done before. Insane people will 
manage to screw up anyways, nothing we can do about that. Resize
is a dangerous operation, no way around that. We can prevent
people from hosing their LUKS container when creating filesysems
on it though, or partition sectors or the like.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 07:09:24 CET, f-dm-c@media.mit.edu wrote:
[...]

> [For example, and to take into account "OMG but what if massive giant
> corruptions and/or mislayered tables at start," have these as defaults:
> (a) FS < 10 meg --> no extra header
> (b) 10 meg < FS < 100 meg --> extra header after 1 meg gap
> (c) 100 meg < FS < 10 gig --> extra header after 10 meg gap
> (d) fs > 10 gig --> extra header after 100 meg gap

That strikes me as an exceedingly bad idea as it will be 
unpredictable to those users that need it. And I do not like
different places for md-RAID 1.x format superblocks one bit.
We should pick one thing, make it otional (but on by default)
and stick with it, so users do know where it is, regardless 
of other parameters.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 12:34:04 CET, Michael Kjörling wrote:
> On 8 Feb 2016 01:25 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
> > I always
> > wondered how a HDD exactly behaves when power fails, while a sector
> > is in transit. My best hope is, that the CRC at the end of the
> > sector does not match and an error is returned on the next read?
> 
> That's the theory; if a sector write is interrupted half way through
> (regardless of the reason), then the FEC data doesn't match the sector
> payload data. In this case, the difference is very likely large enough
> that the error cannot be corrected using the FEC data, so you get a
> read error back instead.
> 
> _Unfortunately_, theory and practice don't always agree. I think it
> was Google that did a study on storage errors not all that long ago,
> and one conclusion was that silent read errors (where you do get data
> back from the drive, but that data is not the same as was originally
> written), while rare, happens with a high enough probability to
> warrant consideration in large storage systems.

I think I read that paper (if so, it was pretty bad) and if I
remember correctly, they did not diagnose what the issues were,
just that they had bad data at the end in main memory.

From my experience shoveling a few hundred TBs of research data
around when 200GB disks where standard, the only undetected errors
I ever found were due to memory corruption due to a weak RAM bit 
in one server that did not have ECC memory. Those amounted to 
3 errors in 30TBs of recorded data. I never had undetected read
errors from disk (and since all data was bzip2 compressed, 
errors would have been found), so I tend to view these as not
a disk problem, but likely happening someplace after the data
leaves the disk.  

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Indeed usually a disk should be able to finish the sector write with 
remaining power. Actually most modern disks do have voltage shifters and 
most parts operate on lower voltage. Thus a drop on the changer's input 
does not immediately lead to a drop on the output of the voltage 
shifter. If's theres enough power left for the physical layer scrambler 
and the head to write, then everything should be fine. I was rather 
wondering if there's definite sources on that?

BTW. The burst errors I mentioned did not happen on a power loss, but 
rather during operation. Reading twice, one time with burst errors, one 
time without. I checked the RAM for ages - no failures. That was really 
weird.

Regards

-Sven


Am 08.02.2016 um 17:41 schrieb Arno Wagner:
> On Mon, Feb 08, 2016 at 01:25:31 CET, Sven Eschenberg wrote:
> [...]
>> Concerning disks, I thought with ACS2/ATA-8 real write barriers were
>> introduced. On the other hand I've seen disks returning successfull
>> reads with long zero-burst-errors undetected - no fun. I always
>> wondered how a HDD exactly behaves when power fails, while a sector
>> is in transit. My best hope is, that the CRC at the end of the
>> sector does not match and an error is returned on the next read?
>
> For these you should have intact data on disk, but
> your data never made it there. If data after the zeros
> did get written fine, there is a simple explanation:
> Modern disks may reorder sectors in order to be able
> to begin writing as soon as the heads are stable in
> the track.
>
> Behavior on power failure used to be that the disk will
> notice the power failing early enough that it has enough
> time left with hood power to finish a sector-write in
> progress. I think that still applies. The zeros would
> then be sector-aligned and/or the data that was in
> those sectors before, hence the checksums are fine.
>
> The thing is that in a typical PC, power drops relatively
> slowly and disks work non-seeking for a lower voltage
> that the thresholds. Add to that that a single sector
> write takes less than 1ms (probably much less), and
> you get ample time to finish a write in progress.
>
> Regards,
> Arno
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Am 08.02.2016 um 07:09 schrieb f-dm-c@media.mit.edu:
>      > Date: Mon, 8 Feb 2016 05:32:14 +0100
>      > From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
>
>      > Of course, that's what I usually do anyway. But we'll have to at least
>      > consider an average user aswell, having a normal desktop, using a magic
>      > mumbo jumbo installer with LVM on top of dm-crypt setup. It's not about
>      > covering your or my use case, but rather those of as many users as
>      > possible, without sacrificing i.e. security though.
>
> Right.  And the average user is using an installer that might want to
> expand a partition.  If that doesn't work, LUKS is a nonstarter there.

Honestly, I am just imagining the average user, starting its installer 
for the first time and going like: Darn, there's that LUKS-partition 
from my last install - It's a pitty it cannot be resized.

Seriously, the task of resizing ANY partition during installation is far 
from being average user's standard task and ALWAYS imposes immediate 
threat to the data, no matter if we talk about LUKS, a plain filesystem, 
lvm+fs or whatsoever.

> Even if it -could- work, but installers suddenly have to be aware of
> which version of LUKS they're talking so they can supply magic random
> options, then that's a situation where it's very likely that installers
> will screw it up.  And installers screwing it up is -precisely- why
> we're talking about having header redundancy in the first place.
> Let's please not -encourage- screwups of rare-and-not-well-tested
> actions that can lose data.

But the same holds true for all non-LUKS cases too. Replace partition 
holding LUKS-container by device holding disklabel. There's a complete 
zoo of disklabels. Take GPTs for instance - either the installer does 
update both copies and can handle displaced secondary copies by itself, 
or it will at least need to talk to one of the many partitioning tools 
that does this job. And it will need to know how to 'instruct' the tool 
to do the job. And an installer does not talk to LUKS nor is it aware of 
what version of LUKS is used, it 'gently asks' the tools responsible for 
handling the operation to do it.

>
> Also, the -average- user is not experiencing multiple megabytes of
> corruption at the beginning of partitions.  C'mon.  The -average-
> user is experiencing a bad Ubuntu installer deciding to put a
> partition table on top of a LUKS header or some other handful-
> of-sectors corruption.  Not a megabyte, much less ten or more.

Possibly, but maybe the ubuntu installer puts LVM metadata there, 
creates a LV and a filesystem, and all the sudden we talk about 1+ MByte 
of corrupted data. (Unfortunately some distributions consider LVM the 
default)

>
>      > Of course overcomplicating things is not an option. But you should
>      > always remember: A damaged header is a total loss, a damaged fs can
>      > quite often be recovered easily enough. And other tools need 'special
>      > instructions' for every fs, dm-layer and task. There's no generic
>      > resize() IOCTL for all your block layers.
>
> But all the rest of them do assume that they can use the entire
> container unless you say not to, and that expansion works.

Maybe I am not getting your point here, but for dm-crypt this does hold 
true. A filesystem tool that operates on the partition container will 
happily trash mdadm headers on the partition, if it is not aware of the 
presence of the metadata.

Anyhow for resizing each layer and each corresponding tool needs to be 
able to resize, agreeed. But there's no difference to cryptsetup then. 
Resizing with two metadatacopies can be done, it just needs extra work. 
Same holds true for other layers, if you thing about it:
GPT, backing store scales up -> secondary metadata is displaced. Move 
secondary metadata, update primary metadata. Doing this right and 
resilient needs caution. On a scale down the secondary metadata is lost 
altogether (and can be recreated from the primary metadata). Better 
first scale down the contents of the container.
mdadm: only one array metadata copy on each device and a per device 
metadata section. What happens if all backing devices grow? In the cases 
where metadata is at device's end you'll certainly run into trouble.
LVM - resize is a non worker for multiple metadata copies.


>
> Every single layer of what -I- do -is- resizeable---I can resize
> partitions, and LVM, and LUKS, and ext4.  Any solution in which LUKS
> can no longer be resized (especially grown) means that LUKS will be
> instantly heaved overboard in favor of something else that can,
> because it's the only thing in the stack which would fail that test.
>
>      > I don't mind keeping it simple. Really simple and secure was already
>      > mentioned: You do have a backup anyway, just recreate the container and
>      > pull back the backup and you are done ;-). Resizing (growing) is just a
>      > convenient thing to do.
>
> Did you actually read my original message?  As I said, in my use case,
> it is simply not an option to "back up, blow away, resize, and put
> back," because having to do that offline means multiple days of
> downtime to do two entirely-pointless block-level copies, one in each
> direction, on a -dismounted- FS.  Those multiple days are clearly not
> required if LUKS can grow---I've done it before without downtime,
> precisely because all layers can grow.

I did read your mail and yes I do see your use case and yes, I do have 
this use case too. As I stated in another mail, it is also possible to 
ditch a secondary header, recreate at the new location and update the 
mapping. There's no magic in there, except it is not completely safe. Or 
rather, it is as unsafe as now.

By the way, do you really think it is safe to update a disklabel to grow 
a partition? While it is only one sector for MBR, a failure during 
update is fatal. On GPT you do have a secondary copy. But if the device 
grows updating the GPT properly needs complicated extra work aswell.

>
> Let me try to summarize:  The reason we are having this conversation
> at all is because proposals to increase the robustness of LUKS headers
> almost immediately allowed the perfect to become the enemy of the good
> ---to the point where increasing their robustness lead to comments like
> "well, let's just kill the ability of LUKS to grow because it's too
> hard to figure out how to preserve the multiple headers in that case."
> That is a big warning sign that the proposal is too complex.

It is always hard to solve problems which consist of opposing design 
goals. Unfortunately...

>
> One other thing:  One problem with putting a redundant header at the
> end is that something which resizes the container out from under LUKS
> (prime candidate for "something just corrupted the container") means
> that LUKS (and any user trying to find that header by hand) has no
> idea where to look for it, short of scanning every single block on
> the disk for something that looks like a header.  Putting it near the
> front means that LUKS either has only one option, or at the very least
> only a very small number of blocks to scan, before it concludes that
> it's either found the header or there isn't one.

mdadm suffers from this problem by the way, at least for metadata 
versions 0.9 and 1.0. Anyhow, desaster recovery is not LUKS' intrinsic 
task. If you need to recover from such a failure, you know the old size 
of the container (approx) and instruct the recovery process to scan at 
the whereabouts of that place.

A similiar issue arises at the front of the container, it is just less 
common. Growing the preceeding partition imposes exactly this type of 
threat.

>
> [For example, and to take into account "OMG but what if massive giant
> corruptions and/or mislayered tables at start," have these as defaults:
> (a) FS < 10 meg --> no extra header
> (b) 10 meg < FS < 100 meg --> extra header after 1 meg gap
> (c) 100 meg < FS < 10 gig --> extra header after 10 meg gap
> (d) fs > 10 gig --> extra header after 100 meg gap
> (where "gap" means "really unused---don't give it to the FS" or maybe
> even "put a backup header every n megabytes all through the gap"), and
> have --redundant-header-at=[none|offset-in-meg] option for those who
> insist on putting it somewhere magic.  Now LUKS has at most 3 places
> to look even if it doesn't know how big the FS was, or a scan if the
> user used --redundant-header-at.  But the code is still very simple,
> online resizing works the way it always did, and people who are super-
> paranoid about corrupting a gig at the start of their partition can
> throw away an entire gig by pushing it farther in or something.  Or
> putting it at the end, but then LUKS has to treat the gap as actual FS
> storage area, which is again more complicated, so I don't recommend it.]

I do see a chance of Joe Average complaining about the 'lost' (unsused) 
space. Another problem with configureable offset is, that you'd again 
have to store the location information in the primary header. If that 
gets corrupted, the secondary header would be dangling and you'd have to 
scan for that.

Anyhow, as I see it, this discussion is about the choice of sane 
defaults. Question, do more people value the safety of an extra header, 
without any extra params or do more people value online resizing without 
extra parameters and effort.

Variants:
--no-secondary - during format. No extra safety, easy online resizing
--scratch secondary - first trashes secondary header, updates the 
secondary header, remaps, recreate secondary header. Gives you the 
safety of the backup header, while having the exact same online resizing 
ability as single header and same dangers of course during the resize phase.
Have secondary header and do onlinze resizing, implementation needs 
extra effort.

And last but not least, I am not sure if it is a good idea to base 
behavior on FS size. So (a) is probably a really bad idea as it behaves 
differently from the others. (b) could be a close call for LVM (metadata 
size 1Mbyte + whatever the next, upper, layer would additionally 
destroy) and possibly mdadm.

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 18:26:49 CET, Sven Eschenberg wrote:
> Indeed usually a disk should be able to finish the sector write with
> remaining power. Actually most modern disks do have voltage shifters
> and most parts operate on lower voltage. 

At least for the R/W logic. The heads do not need to be
moved during a started write and the platters will keep 
spinning far longer than needed. 

> Thus a drop on the
> changer's input does not immediately lead to a drop on the output of
> the voltage shifter. If's theres enough power left for the physical
> layer scrambler and the head to write, then everything should be
> fine. 

As this depends on the buffer-capacitors, you can design how
long they keep the lower voltage (typically 3.3V or 2.5V) up
after the input has gone below, say 4.5V. With a low-drop
3.3V regulator you get about 1V of drop, before 3.3V drops.
That is plenty.

Maybe I will have a look into an older 2.5" hdd and check
when it stops spinngin and what voltage the R/W amplifier is
fed.

> I was rather wondering if there's definite sources on that?

There is not even a definite source on what error-correcting 
codes are used today or what the actual rate of non-correctable 
errors is. Disk manufacturers like to keep the user in the
dark about potential problems...

I used to look at technical manuals of disks, but in the last
10 years or so they were impossible to get, at least from public 
sources.
 
> BTW. The burst errors I mentioned did not happen on a power loss,
> but rather during operation. Reading twice, one time with burst
> errors, one time without. I checked the RAM for ages - no failures.
> That was really weird.

Indeed. Maybe you did run into a firmware error or some
PC-side controller problem that was not properly caught 
in the driver. Maybe also a DMA error or the like that
failed to move all the data into RAM. I found that 
checking alignment on such errors often gives good 
clues.

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Am 08.02.2016 um 19:49 schrieb Arno Wagner:
> On Mon, Feb 08, 2016 at 18:26:49 CET, Sven Eschenberg wrote:
>> Indeed usually a disk should be able to finish the sector write with
>> remaining power. Actually most modern disks do have voltage shifters
>> and most parts operate on lower voltage.
>
> At least for the R/W logic. The heads do not need to be
> moved during a started write and the platters will keep
> spinning far longer than needed.
>
>> Thus a drop on the
>> changer's input does not immediately lead to a drop on the output of
>> the voltage shifter. If's theres enough power left for the physical
>> layer scrambler and the head to write, then everything should be
>> fine.
>
> As this depends on the buffer-capacitors, you can design how
> long they keep the lower voltage (typically 3.3V or 2.5V) up
> after the input has gone below, say 4.5V. With a low-drop
> 3.3V regulator you get about 1V of drop, before 3.3V drops.
> That is plenty.
>
> Maybe I will have a look into an older 2.5" hdd and check
> when it stops spinngin and what voltage the R/W amplifier is
> fed.
>
>> I was rather wondering if there's definite sources on that?
>
> There is not even a definite source on what error-correcting
> codes are used today or what the actual rate of non-correctable
> errors is. Disk manufacturers like to keep the user in the
> dark about potential problems...

So true, let me rephrase, can we trust on manufacturers handling these 
cases the way we assume they do? Or do we need to assume the worst case 
we can even imagine?

>
> I used to look at technical manuals of disks, but in the last
> 10 years or so they were impossible to get, at least from public
> sources.
>
>> BTW. The burst errors I mentioned did not happen on a power loss,
>> but rather during operation. Reading twice, one time with burst
>> errors, one time without. I checked the RAM for ages - no failures.
>> That was really weird.
>
> Indeed. Maybe you did run into a firmware error or some
> PC-side controller problem that was not properly caught
> in the driver. Maybe also a DMA error or the like that
> failed to move all the data into RAM. I found that
> checking alignment on such errors often gives good
> clues.

The errors seemed sector aligned, if I remember correctly, that's why I 
thought the cause is probably the disk (or it's firmware). I remember, 
it only happened when a lot of data was moved. I tried various things 
like putting load on the chipset, the CPU, just to see if I can trigger 
the problem and reproduce it. Then again, could still have been a 
problem in the PCIe root hub or whatsoever *shrugs*. Too many variables 
to know for sure.

>
> Regards,
> Arno
>

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 17:48:22 +0100
    > From: Arno Wagner <arno@wagner.name>

    > I like the end, because it is clear and far away. It is also what
    > md-RAID for superblock 0.90 does.

Doesn't that increase the chances of mdraid 0.90 stepping on your own
"far away" header?

    > Non-redudancy during resize is not an issue, as anybody sane will 
    > only resize with a header-backup done before. Insane people will 
    > manage to screw up anyways, nothing we can do about that. Resize
    > is a dangerous operation, no way around that. We can prevent
    > people from hosing their LUKS container when creating filesysems
    > on it though, or partition sectors or the like.

As long as whatever redundancy gets added doesn't eliminate the
ability to do an -online- grow, I don't care.  It's when people
start saying "disallow online resize -because of- the redudancy"
that I start questioning the wisdom of the entire concept, and
that's why I spoke up at all.

(Note that I don't care so much re online -shrink-, because ext4
at least can't do that either.)

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 20:49:59 CET, f-dm-c@media.mit.edu wrote:
>     > Date: Mon, 8 Feb 2016 17:48:22 +0100
>     > From: Arno Wagner <arno@wagner.name>
> 
>     > I like the end, because it is clear and far away. It is also what
>     > md-RAID for superblock 0.90 does.
> 
> Doesn't that increase the chances of mdraid 0.90 stepping on your own
> "far away" header?

Not really. Or rather the 1.x formats also do beginning 
and 4k from beginning, so there is no way avoiding the 
risk anyways.

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Am 08.02.2016 um 20:49 schrieb f-dm-c@media.mit.edu:
>      > Date: Mon, 8 Feb 2016 17:48:22 +0100
>      > From: Arno Wagner <arno@wagner.name>
>
>      > I like the end, because it is clear and far away. It is also what
>      > md-RAID for superblock 0.90 does.
>
> Doesn't that increase the chances of mdraid 0.90 stepping on your own
> "far away" header?

If mdadm doesn't recognize the presence of that header, yes it would 
potentially trash that backup header (and possibly some data right at 
the end of the device), That would not be desastrous though, as the 
primary header would still be valid. Same holds true the other way 
round. Anyway, this is a generic problem, i.e. a new filesystem 
signature at the beginning would be trashed by mdadm with 1.1 or 1.2 
metadata and a whole bunch of other tools. That's why most filesystems 
do have redundancy in their superblocks and parts of their 
metadata-structures, I guess.

>
>      > Non-redudancy during resize is not an issue, as anybody sane will
>      > only resize with a header-backup done before. Insane people will
>      > manage to screw up anyways, nothing we can do about that. Resize
>      > is a dangerous operation, no way around that. We can prevent
>      > people from hosing their LUKS container when creating filesysems
>      > on it though, or partition sectors or the like.
>
> As long as whatever redundancy gets added doesn't eliminate the
> ability to do an -online- grow, I don't care.  It's when people
> start saying "disallow online resize -because of- the redudancy"
> that I start questioning the wisdom of the entire concept, and
> that's why I spoke up at all.
>
> (Note that I don't care so much re online -shrink-, because ext4
> at least can't do that either.)

Is there any filesystem right now, that does support online shrinking? 
Most bits in the blocklayer support (online) shrinking though.

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 17:51:24 +0100
    > From: Arno Wagner <arno@wagner.name>

    > On Mon, Feb 08, 2016 at 07:09:24 CET, f-dm-c@media.mit.edu wrote:
    > [...]

    > > [For example, and to take into account "OMG but what if massive giant
    > > corruptions and/or mislayered tables at start," have these as defaults:
    > > (a) FS < 10 meg --> no extra header
    > > (b) 10 meg < FS < 100 meg --> extra header after 1 meg gap
    > > (c) 100 meg < FS < 10 gig --> extra header after 10 meg gap
    > > (d) fs > 10 gig --> extra header after 100 meg gap

    > That strikes me as an exceedingly bad idea as it will be 
    > unpredictable to those users that need it. And I do not like
    > different places for md-RAID 1.x format superblocks one bit.
    > We should pick one thing, make it otional (but on by default)
    > and stick with it, so users do know where it is, regardless 
    > of other parameters.

I only said that to try to quell the "but it's -not enough- of an
offset," because someone can always spin an even-worse-case where
whatever you do just isn't enough.  As I originally said, the least
complicated thing seems to be to just repeat the header right after
the original header, perhaps with a megabyte or so of padding between
them.  (But even if you had these extra headers at varied offsets,
you only have 3 different places to look, and if it's not a header,
it will look all wrong, including failing a checksum.)

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

[This is in a separate message because it could be a distraction.
I'm just tossing this stuff as food for thought, but don't want
to derail.]

Given all the complexity about "how do we do this atomically,"
there's also the really simple idea of just writing several copies
of the header, perhaps one right after the other, and just -voting-.
(The ITS operating system, which ran on PDP-10's back in the 70's
and 80's, did precisely this with its directories---it replicated
its directory structure onto every disk pack in parallel, and when
the machine came up, it simply did a majority vote amongst the packs.)

This gives LUKS lots of redundancy and a mechanism to pick the right
header that's really easy to analyze for correctness.  I have nothing
against generation counts---they would help win a tie from an
unfortunate corruption that leads to an even number of survivors
---but voting may help with the whole "how do we know when disks do
their writes" issue by encouraging lots of redundant copies.

P.S.  My other worry with "header at the end" concerns deliberate
overwrite.  If I have a LUKS container and I want to be absolutely
sure that I've wiped all keys before I discard the device,* writing
a few meg, or even a gig, to the front of it guarantees this.  With a
header at the end, I need to be able to figure out where that header
is.  (I can't count on always having the luxury of using LUKS itself
to wipe every keyslot when discarding a disk.)  Sure, I can do the
math and issue the correct dd into the container at the right offset,
but it encourages mistakes.

* (I can think of several scenarios whereby someone may have had
  access, authorized or not, to a pasphrase, so I want to ensure
  that such knowledge can't do them any good once I let the disk
  out of my physical possession.)

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 17:57:48 +0100
    > From: Arno Wagner <arno@wagner.name>

    > From my experience shoveling a few hundred TBs of research data
    > around when 200GB disks where standard, the only undetected errors
    > I ever found were due to memory corruption due to a weak RAM bit 
    > in one server that did not have ECC memory. Those amounted to 
    > 3 errors in 30TBs of recorded data. I never had undetected read
    > errors from disk (and since all data was bzip2 compressed, 
    > errors would have been found), so I tend to view these as not
    > a disk problem, but likely happening someplace after the data
    > leaves the disk.  

I can confirm scenarios like this.  Some years ago, I moved a couple
TB from one machine to another and was paranoid enought to individually
checksum the files and discovered a few that weren't right.  Since
both the source and destination disks were LUKS, I could immediately
rule out large swaths of the disk subsystems, since that would have
lead to entire blocks of corruption due to the operation of the
cipher, whereas the errors I found were a handful of incorrect bits
in each case.

I narrowed this down reasonably quickly to the source machine getting
rare and data-dependent read errors from its RAM, but -only- when the
machine had automatically reduced its CPU clock rate because it was
unloaded.  If I nailed the CPU at 100% in some other process, the RAM
errors went away, as they did if I simply disabled CPU clock rate
adjustment at all.

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 17:41:43 +0100
    > From: Arno Wagner <arno@wagner.name>

    > The thing is that in a typical PC, power drops relatively 
    > slowly and disks work non-seeking for a lower voltage
    > that the thresholds. Add to that that a single sector
    > write takes less than 1ms (probably much less), and
    > you get ample time to finish a write in progress.

If the data has already made it all the way into the drive itself,
that may be valid, but it's very dangerous to make such assumptions
in general, and you can't necessarily know the timing of the power
failure vs when the data makes it to the disk, much less the platters.

http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc

And new technologies may change this---not just SSDs, but modern
high-capacity drives that must rewrite many, many sectors to write
one.  (Yes, I know this also argues that those headers should be
far away from each other.  So be it.  If such scattered headers
don't prevent resizing, I don't care.  Except maybe for secure wipe.)

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Humm, well, I think a backup copy of the header would be right at the 
end. Question remains, keep the ordering of the primary header, or let 
it grow down like a stack, i.e. last sector has the luks signature, key 
material in front of that.

Anyhow, as dd itself does not support negative values (for offsets), you 
could still easily use blockdev and substract a secure value of sectors 
from that and pass it to dd in case you do not have cryptsetup at hand. 
If that takes too much time, a single line script can save you some time.

Regards

-Sven

Am 08.02.2016 um 21:11 schrieb f-dm-c@media.mit.edu:
> [This is in a separate message because it could be a distraction.
> I'm just tossing this stuff as food for thought, but don't want
> to derail.]
>
> Given all the complexity about "how do we do this atomically,"
> there's also the really simple idea of just writing several copies
> of the header, perhaps one right after the other, and just -voting-.
> (The ITS operating system, which ran on PDP-10's back in the 70's
> and 80's, did precisely this with its directories---it replicated
> its directory structure onto every disk pack in parallel, and when
> the machine came up, it simply did a majority vote amongst the packs.)
>
> This gives LUKS lots of redundancy and a mechanism to pick the right
> header that's really easy to analyze for correctness.  I have nothing
> against generation counts---they would help win a tie from an
> unfortunate corruption that leads to an even number of survivors
> ---but voting may help with the whole "how do we know when disks do
> their writes" issue by encouraging lots of redundant copies.
>
> P.S.  My other worry with "header at the end" concerns deliberate
> overwrite.  If I have a LUKS container and I want to be absolutely
> sure that I've wiped all keys before I discard the device,* writing
> a few meg, or even a gig, to the front of it guarantees this.  With a
> header at the end, I need to be able to figure out where that header
> is.  (I can't count on always having the luxury of using LUKS itself
> to wipe every keyslot when discarding a disk.)  Sure, I can do the
> math and issue the correct dd into the container at the right offset,
> but it encourages mistakes.
>
> * (I can think of several scenarios whereby someone may have had
>    access, authorized or not, to a pasphrase, so I want to ensure
>    that such knowledge can't do them any good once I let the disk
>    out of my physical possession.)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Am 08.02.2016 um 21:31 schrieb f-dm-c@media.mit.edu:
>      > Date: Mon, 8 Feb 2016 17:41:43 +0100
>      > From: Arno Wagner <arno@wagner.name>
>
>      > The thing is that in a typical PC, power drops relatively
>      > slowly and disks work non-seeking for a lower voltage
>      > that the thresholds. Add to that that a single sector
>      > write takes less than 1ms (probably much less), and
>      > you get ample time to finish a write in progress.
>
> If the data has already made it all the way into the drive itself,
> that may be valid, but it's very dangerous to make such assumptions
> in general, and you can't necessarily know the timing of the power
> failure vs when the data makes it to the disk, much less the platters.

If the data hasn't made it to the drive (or rather is not in transit) 
then the change is just discarded leaving us in a stable state.
>
> http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
>
> And new technologies may change this---not just SSDs, but modern
> high-capacity drives that must rewrite many, many sectors to write
> one.  (Yes, I know this also argues that those headers should be
> far away from each other.  So be it.  If such scattered headers
> don't prevent resizing, I don't care.  Except maybe for secure wipe.)

Well, if we talk about SMR, small changes will be written to the random 
IO section of the drive and merged later. With those drives you'll 
probably never know if there's parts of the old header lingering around 
someplace else.

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 21:31:05 CET, f-dm-c@media.mit.edu wrote:
>     > Date: Mon, 8 Feb 2016 17:41:43 +0100
>     > From: Arno Wagner <arno@wagner.name>
> 
>     > The thing is that in a typical PC, power drops relatively 
>     > slowly and disks work non-seeking for a lower voltage
>     > that the thresholds. Add to that that a single sector
>     > write takes less than 1ms (probably much less), and
>     > you get ample time to finish a write in progress.
> 
> If the data has already made it all the way into the drive itself,
> that may be valid, but it's very dangerous to make such assumptions
> in general, and you can't necessarily know the timing of the power
> failure vs when the data makes it to the disk, much less the platters.
> 
> http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
> 
> And new technologies may change this---not just SSDs, but modern
> high-capacity drives that must rewrite many, many sectors to write
> one.  (Yes, I know this also argues that those headers should be
> far away from each other.  So be it.  If such scattered headers
> don't prevent resizing, I don't care.  Except maybe for secure wipe.)

My argument only relates to sectors getting corrupted by
power failure, not other things. For that, the drive must
become unable to write in mid-sector.

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] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 21:51:34 CET, Sven Eschenberg wrote:
[...]
> >http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
> >
> >And new technologies may change this---not just SSDs, but modern
> >high-capacity drives that must rewrite many, many sectors to write
> >one.  (Yes, I know this also argues that those headers should be
> >far away from each other.  So be it.  If such scattered headers
> >don't prevent resizing, I don't care.  Except maybe for secure wipe.)
> 
> Well, if we talk about SMR, small changes will be written to the
> random IO section of the drive and merged later. With those drives
> you'll probably never know if there's parts of the old header
> lingering around someplace else.

Just as with SSDs and hybrid drives. On these, the LUKS 
key-management features potentially lose the secure 
key-slot deletion property.
 
We cannot really fix that, we can only warn of it.

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] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 21:51:34 +0100
    > From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>

    > If the data hasn't made it to the drive (or rather is not in transit) 
    > then the change is just discarded leaving us in a stable state.

Please read the first part of discussion below---in particular, Ted's
description of the difference between SGI hardware of the day and
typical PC-class hardware of the day.  If we're analyzing the
consistency of the various headers in the event that power is failing
as we write them, it's not just about whether the write happened or
not or whether the hardware sector is corrupted from the drive's
perspective---it's also whether we can trust a sector the drive
thinks is okay but turns out not to be from our standpoint.

    > > http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc

It is entirely possible that you could ask the drive to write garbage
and it would succeed.  It really isn't safe to make any assumptions
about how an entire machine -might- work as power is failing; in
general, the manufacturer (of any piece, much less the whole) has
not guaranteed you anything about its behavior, and it could do
anything.  Just because -your- machine does something doesn't mean
all users' machines out there will do the same thing.

Re: [dm-crypt] The future of disk encryption with LUKS2

[f-dm-c]

    > Date: Mon, 8 Feb 2016 22:08:31 +0100
    > From: Arno Wagner <arno@wagner.name>

    > My argument only relates to sectors getting corrupted by
    > power failure, not other things. For that, the drive must
    > become unable to write in mid-sector.

Ah, just hardware sector corruption.  I thought the discussion had
drifted into how to properly manage redundant writes in general in
LUKS, given the discussion of generation numbers and so forth.  (If
it's just corrupted disk sectors, those will either be unreadable,
or the entire header will presumably fail a checksum.)

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/03/2016 03:17 PM, Milan Broz wrote:

>> Will any of the materials used in the presented posted online
>> somewhere for the rest of us to see?

Slides are here, but it is really just overview talk
https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf
(The talk name was a kind of joke because conference hashtag is #definefuture:)

TL;DR; we have to provide extensible interface for different keyslot types.

[Just note to already crazy discussion here - there will be NO LUKS header
at the end of device. Been there with another storage project and
just no - it is not worth problems it causes.]

[And second note - wiping of encrypted keyslot data is with current
storage devices impossible to do reliably.]

Anyway, the first goal here is to just redefine current on-disk format
to allow keyslot extensions. All possible changes in algorithms can
follow because it becomes "easily" configurable.

Milan
p.s.
There are also live stream recordings on youtube.

But better than watching our LUKS2 overview talk see follow-up talk
  "New Cryptography for Binding Data to Third Parties" 
https://www.youtube.com/watch?v=Ixo8iOpQsNQ
(Note you need to switch camera in stream, there is no official recording
videos yet, this is recording of a live stream from multiple rooms.)

My intention with LUKS2 is to provide interface for this but
keep responsibility for these protocols in separate projects.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

In the discussion a completely different situation is described.

I pointed out, that if no data made it to the drive (not even in it's 
internal cache) the transaction never started and we are at the old 
state. Failure or garbled write leaves us with an inconsistent/damaged 
header, we can easily recover from this by using the secondary header. 
If the primary header was written successfully, we are done.

And yes, we ask the drive to flush dirty pages before the header update, 
do the update, ask to flush dirty pages again, reread and check 
consistency, at this point if the header is consistent we should be 
okay. That is, if the drive is not purposefully lying to us.

Additionally I pointed out, that transactional semantics better be 
used...which in turn leads to more complexity in header updating and 
especially online resizing.

But, afterall, you can only die one way ....

Reagrds

-Sven


Am 08.02.2016 um 22:43 schrieb f-dm-c@media.mit.edu:
>      > Date: Mon, 8 Feb 2016 21:51:34 +0100
>      > From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
>
>      > If the data hasn't made it to the drive (or rather is not in transit)
>      > then the change is just discarded leaving us in a stable state.
>
> Please read the first part of discussion below---in particular, Ted's
> description of the difference between SGI hardware of the day and
> typical PC-class hardware of the day.  If we're analyzing the
> consistency of the various headers in the event that power is failing
> as we write them, it's not just about whether the write happened or
> not or whether the hardware sector is corrupted from the drive's
> perspective---it's also whether we can trust a sector the drive
> thinks is okay but turns out not to be from our standpoint.
>
>      > > http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
>
> It is entirely possible that you could ask the drive to write garbage
> and it would succeed.  It really isn't safe to make any assumptions
> about how an entire machine -might- work as power is failing; in
> general, the manufacturer (of any piece, much less the whole) has
> not guaranteed you anything about its behavior, and it could do
> anything.  Just because -your- machine does something doesn't mean
> all users' machines out there will do the same thing.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Hi Milan,

Are you serious about using JSON on disk level?

Regards,

-Sven

Am 08.02.2016 um 22:51 schrieb Milan Broz:
> On 02/03/2016 03:17 PM, Milan Broz wrote:
>
>>> Will any of the materials used in the presented posted online
>>> somewhere for the rest of us to see?
>
> Slides are here, but it is really just overview talk
> https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf
> (The talk name was a kind of joke because conference hashtag is #definefuture:)
>
> TL;DR; we have to provide extensible interface for different keyslot types.
>
> [Just note to already crazy discussion here - there will be NO LUKS header
> at the end of device. Been there with another storage project and
> just no - it is not worth problems it causes.]
>
> [And second note - wiping of encrypted keyslot data is with current
> storage devices impossible to do reliably.]
>
> Anyway, the first goal here is to just redefine current on-disk format
> to allow keyslot extensions. All possible changes in algorithms can
> follow because it becomes "easily" configurable.
>
> Milan
> p.s.
> There are also live stream recordings on youtube.
>
> But better than watching our LUKS2 overview talk see follow-up talk
>    "New Cryptography for Binding Data to Third Parties"
> https://www.youtube.com/watch?v=Ixo8iOpQsNQ
> (Note you need to switch camera in stream, there is no official recording
> videos yet, this is recording of a live stream from multiple rooms.)
>
> My intention with LUKS2 is to provide interface for this but
> keep responsibility for these protocols in separate projects.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/08/2016 11:36 PM, Sven Eschenberg wrote:
> Are you serious about using JSON on disk level?

yes.

Actually using text format for metadata works pretty
well even for on-disk metadata (it was one of good ideas
in lvm2, just there it was non-standard text format).

I want to use something easily readable by common
simple library (libjson-c is the only dependence we use).
JSON is very simple format for representation of data we need
(with exception of storing uint64 and small binary data
that need some easy common tricks).

The reason for this universal format is that you can manipulate
with unknown objects (keyslot metadata for slot you do not understand
in core code).
(Note it is used only for metadata not the raw key material
for luks1 keyslot.)

We can probably easily use binary representation of JSON
(like ubjson) or one of the many such formats but in principle
it is the same.

m.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Mon, Feb 08, 2016 at 22:51:25 CET, Milan Broz wrote:
> [Just note to already crazy discussion here - there will be NO LUKS header
> at the end of device. Been there with another storage project and
> just no - it is not worth problems it causes.]

Good to know. So we can drop that discussion.
 
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] The future of disk encryption with LUKS2

[Lars Winterfeld]

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

On 08.02.2016 22:51, Milan Broz wrote:
> [Just note to already crazy discussion here - there will be NO LUKS header
> at the end of device. Been there with another storage project and
> just no - it is not worth problems it causes.]

Out of curiosity: what were those problems?



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

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Tue, Feb 09, 2016 at 23:08:19 CET, Lars Winterfeld wrote:
> On 08.02.2016 22:51, Milan Broz wrote:
> > [Just note to already crazy discussion here - there will be NO LUKS header
> > at the end of device. Been there with another storage project and
> > just no - it is not worth problems it causes.]
> 
> Out of curiosity: what were those problems?

Same here. Not asking for a justification (if you feel
it is a mess or other problem, that is quite enough for 
me), just want to understand the issue.

For proper layering, it should of course allways be

   [header, payload]

with the payload having potentially the same format 
if there are more layers below. That is the tradidional 
way to do it. This even has a name, but I do not remember 
it at the moment.

Was the problem confusion/complexity because this 
layering-sheme was violated?

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Am 10.02.2016 um 00:35 schrieb Arno Wagner:
> On Tue, Feb 09, 2016 at 23:08:19 CET, Lars Winterfeld wrote:
>> On 08.02.2016 22:51, Milan Broz wrote:
>>> [Just note to already crazy discussion here - there will be NO LUKS header
>>> at the end of device. Been there with another storage project and
>>> just no - it is not worth problems it causes.]
>>
>> Out of curiosity: what were those problems?
>
> Same here. Not asking for a justification (if you feel
> it is a mess or other problem, that is quite enough for
> me), just want to understand the issue.
>
> For proper layering, it should of course allways be
>
>     [header, payload]
>
> with the payload having potentially the same format
> if there are more layers below. That is the tradidional
> way to do it. This even has a name, but I do not remember
> it at the moment.

Question is, who defines 'proper' I wonder, what the traditional way of 
doing this would be, if you'ask right-to-left readers ;-).

BTW: RAID signatures have mostly been at the end for ages (not just for 
mdadm), I guess because for mirroring you can use each disk easily 
outside of the mirror and calculation of the layout is simplified for 
RAID 5/6 with a zero offset.

Another possible reason why disklabels always resided at the beginning 
of the disk is: It's easier to access the first sectors of a disk in 
16-Bit asm.


>
> Was the problem confusion/complexity because this
> layering-sheme was violated?
>
> Regards,
> Arno
>

Unfortunately I have no idea what name you are looking for.

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/10/2016 12:35 AM, Arno Wagner wrote:
> On Tue, Feb 09, 2016 at 23:08:19 CET, Lars Winterfeld wrote:
>> On 08.02.2016 22:51, Milan Broz wrote:
>>> [Just note to already crazy discussion here - there will be NO LUKS header
>>> at the end of device. Been there with another storage project and
>>> just no - it is not worth problems it causes.]
>>
>> Out of curiosity: what were those problems?

I think the real problem was mentioning here several times -
the device size sometimes changes and you have no real control over it.

People resize partition tables, logical volumes, use dd from
smaller disk to bigger (and vice versa but that's another story ;-)

Then you have not always chance to properly wipe out old header, and
in the LUKS case it is additional security risk.

(If you do not wipe additional space it is not so big problem.)

Also note that GPT stores backup header near the end of device,
I can imagine various semi-destroyed headers by that as well.

In case of a "forensic" recovery (you are trying to recover some
partially wiped disk) it complicates thinks even more (should
we expect that a second header somewhere on the device has correct device
size in it or it is just old header and the real one was destroyed?)
(If we have sequence if or epoch in such metadata - what to do
if there is more recent version - because some people tried to recover
with wrong device size (common mistake to try recovery before thinking
of the real problem)? What if it is an older metadata from some
previous install - can we expect always different UUID?)

From the LUKS POV it means that there is no need to change logic
of backup and recovery of header (just replace header, no need to
play magic with writing to device end).

With external scripts (and even programs compiled without proper flags)
you have even bigger chance to screw it up for large devices
when calculating header position because of limited integers handling
(note getsize/getsize64 in blockdev command for example).

The implementation is more complicated but that's not the reason
to reject it (despite I prefer simpler code).

IIRC for lvm2 the resize with redundant metadata (located near the end of PV)
was disabled for some time (code was not complete to handle it)
but today it should work (just FYI).

...
> Was the problem confusion/complexity because this 
> layering-sheme was violated?

That is another problem - during storage stack resize you require user
to do various complicated steps. If a layer just takes current device size
without any complicated steps it effectively limits area for error.
(Well, it can be exact opposite in some situations but I expect people are
more extending devices than shrinking it.)

(In current LUKS2 metadata we can store segment size, so we can limit
device size in header but this is meant for some internal segment handling
like reencryption which requires several segments of sliding window
with limited size. Default is still "use current device size".)

So my reason to not use header near the end of the device is mainly
that security risk of possibly old keyslot material on device.

Milan

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Wed, Feb 10, 2016 at 09:37:09 CET, Milan Broz wrote:
> On 02/10/2016 12:35 AM, Arno Wagner wrote:
[...]
> So my reason to not use header near the end of the device is mainly
> that security risk of possibly old keyslot material on device.

Hmm. I do agree to that. It is pretty convincing and security
has to be the first priority. 

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Hi Milan,

While I understand your arguments, many of these issues can be addressed 
more or less easily. If we talk about really complex setups, we 
hopefully consider these not average user cases and non average users 
are always on their own, at least to some extent.

Concerning GPT, it already collides with mdadm metadata, while mdadm 
metadata at the start of device does have it's own serious issues aswell.

And to be honest, there is no way around the user knowing the layering 
anyway and letting him/her do the necessary steps in the correct ordering.

The current LVM man pages still suggests that resizing with multiple 
metacopies is not working, if it does work nowadays, the man page needs 
fixing ;-).

BTW: Personally I think that one thing in the blockdevice stack was 
screwed up severely: Always have information on the upper layer in the 
lower layer - That would eliminate most issues. On the lowest layer we 
do have that information (PARTUUID/PARTTYPE), it is just mostly ignored.

Regards

-Sven

Am 10.02.2016 um 09:37 schrieb Milan Broz:
> On 02/10/2016 12:35 AM, Arno Wagner wrote:
>> On Tue, Feb 09, 2016 at 23:08:19 CET, Lars Winterfeld wrote:
>>> On 08.02.2016 22:51, Milan Broz wrote:
>>>> [Just note to already crazy discussion here - there will be NO LUKS header
>>>> at the end of device. Been there with another storage project and
>>>> just no - it is not worth problems it causes.]
>>>
>>> Out of curiosity: what were those problems?
>
> I think the real problem was mentioning here several times -
> the device size sometimes changes and you have no real control over it.
>
> People resize partition tables, logical volumes, use dd from
> smaller disk to bigger (and vice versa but that's another story ;-)
>
> Then you have not always chance to properly wipe out old header, and
> in the LUKS case it is additional security risk.
>
> (If you do not wipe additional space it is not so big problem.)
>
> Also note that GPT stores backup header near the end of device,
> I can imagine various semi-destroyed headers by that as well.
>
> In case of a "forensic" recovery (you are trying to recover some
> partially wiped disk) it complicates thinks even more (should
> we expect that a second header somewhere on the device has correct device
> size in it or it is just old header and the real one was destroyed?)
> (If we have sequence if or epoch in such metadata - what to do
> if there is more recent version - because some people tried to recover
> with wrong device size (common mistake to try recovery before thinking
> of the real problem)? What if it is an older metadata from some
> previous install - can we expect always different UUID?)
>
>  From the LUKS POV it means that there is no need to change logic
> of backup and recovery of header (just replace header, no need to
> play magic with writing to device end).
>
> With external scripts (and even programs compiled without proper flags)
> you have even bigger chance to screw it up for large devices
> when calculating header position because of limited integers handling
> (note getsize/getsize64 in blockdev command for example).
>
> The implementation is more complicated but that's not the reason
> to reject it (despite I prefer simpler code).
>
> IIRC for lvm2 the resize with redundant metadata (located near the end of PV)
> was disabled for some time (code was not complete to handle it)
> but today it should work (just FYI).
>
> ...
>> Was the problem confusion/complexity because this
>> layering-sheme was violated?
>
> That is another problem - during storage stack resize you require user
> to do various complicated steps. If a layer just takes current device size
> without any complicated steps it effectively limits area for error.
> (Well, it can be exact opposite in some situations but I expect people are
> more extending devices than shrinking it.)
>
> (In current LUKS2 metadata we can store segment size, so we can limit
> device size in header but this is meant for some internal segment handling
> like reencryption which requires several segments of sliding window
> with limited size. Default is still "use current device size".)
>
> So my reason to not use header near the end of the device is mainly
> that security risk of possibly old keyslot material on device.
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Robert Nichols]

On 02/10/2016 07:48 AM, Sven Eschenberg wrote:
> BTW: Personally I think that one thing in the blockdevice stack was
> screwed up severely: Always have information on the upper layer in the
> lower layer - That would eliminate most issues. On the lowest layer we
> do have that information (PARTUUID/PARTTYPE), it is just mostly ignored.

It's good that it's ignored.  If anything stopped working just because
I moved a LUKS container to a different partition or device, I would
get rid of LUKS immediately and just use plain dm-crypt.  Adding
unnecessary inter-relationships is a _bad_ thing.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Actually PARTUUID should have read PARTTYPE-GUID - So there's no reason 
why moving it to a different partition should not work, updating the 
PARTTYPE is a trivial step and part of a proper moving operation anyway.

Just imagine the network's linklayer had no idea which upper layer to 
call, because there's no information on that. TCP/IP again does not have 
that type of information.

So either the layering order is fixed and determined, or you actually 
will need intra-layer relationships for proper operation. As an 
alternative, leave it to the user's knowledge and handling. But then we 
don't need partition tables, LUKS-headers or anything else either, 
afterall you can tell each layer the geometry and parameters manually 
and use dmsetup for all your tasks.

Regards

-Sven

Am 10.02.2016 um 15:35 schrieb Robert Nichols:
> On 02/10/2016 07:48 AM, Sven Eschenberg wrote:
>> BTW: Personally I think that one thing in the blockdevice stack was
>> screwed up severely: Always have information on the upper layer in the
>> lower layer - That would eliminate most issues. On the lowest layer we
>> do have that information (PARTUUID/PARTTYPE), it is just mostly ignored.
>
> It's good that it's ignored.  If anything stopped working just because
> I moved a LUKS container to a different partition or device, I would
> get rid of LUKS immediately and just use plain dm-crypt.  Adding
> unnecessary inter-relationships is a _bad_ thing.
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/10/2016 04:09 PM, Sven Eschenberg wrote:
> Actually PARTUUID should have read PARTTYPE-GUID - So there's no reason 
> why moving it to a different partition should not work, updating the 
> PARTTYPE is a trivial step and part of a proper moving operation anyway.

PARTTYPE GUID does not work properly for determining device type and never will.

Hint: check what systemd does with it. There is a "home" GUID. What it says
about device type?
https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html

And that's just one example because the reality is not what you would like to see...

For checking device type we have to use blkid (IOW the real device scan).

I know it is not nice academic design but it is reality and, surprise, it works.

> Just imagine the network's linklayer had no idea which upper layer to 
> call, because there's no information on that. TCP/IP again does not have 
> that type of information.
> 
> So either the layering order is fixed and determined, or you actually 
> will need intra-layer relationships for proper operation. As an 
> alternative, leave it to the user's knowledge and handling. But then we 
> don't need partition tables, LUKS-headers or anything else either, 
> afterall you can tell each layer the geometry and parameters manually 
> and use dmsetup for all your tasks.

It is not just black and white.
(Could we avoid these logical fallacies here please?)

Milan

Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner]

On Wed, Feb 10, 2016 at 16:39:03 CET, Milan Broz wrote:
> 
> On 02/10/2016 04:09 PM, Sven Eschenberg wrote:
[...]
> > So either the layering order is fixed and determined, or you actually 
> > will need intra-layer relationships for proper operation. As an 
> > alternative, leave it to the user's knowledge and handling. But then we 
> > don't need partition tables, LUKS-headers or anything else either, 
> > afterall you can tell each layer the geometry and parameters manually 
> > and use dmsetup for all your tasks.
> 
> It is not just black and white.
> (Could we avoid these logical fallacies here please?)
> 
> Milan

I very much agree. Reality is that sometimes exceptions need to
be made and sometimes you need to deviate from "clean" design
to get good design. The trick is to keep the right balance
and to keep the overall goal firmly in mind and keep the exceptions
and added features down to those really needed, otherwise the 
increased complexity kills you (see also "The second system 
effect" by Brooks). 

Systems were everything is designed "correctly" and "clean" have
a tendency to a) never get finished and b) not work very well.
Reality requires compromises. The trick is to make it good 
compromises.

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] The future of disk encryption with LUKS2

[Sven Eschenberg]

Am 10.02.2016 um 16:39 schrieb Milan Broz:
>
> On 02/10/2016 04:09 PM, Sven Eschenberg wrote:
>> Actually PARTUUID should have read PARTTYPE-GUID - So there's no reason
>> why moving it to a different partition should not work, updating the
>> PARTTYPE is a trivial step and part of a proper moving operation anyway.
>
> PARTTYPE GUID does not work properly for determining device type and never will.

That's most unfortunate and just shows my point of view, misengineered 
from the very beginning. (Not the GPT, the upper layers I mean)
>
> Hint: check what systemd does with it. There is a "home" GUID. What it says
> about device type?
> https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>
> And that's just one example because the reality is not what you would like to see...
>
> For checking device type we have to use blkid (IOW the real device scan).
>
> I know it is not nice academic design but it is reality and, surprise, it works.

"This generator will only look for root partitions on the same physical 
disk the EFI System Partition (ESP) is located on."

So it does not work if the root fs is on an external array, I presume? 
Which in turn means: it is broken and does not work.

BTW, if there's a RAID signature at the end of the device, the kernel 
complains about a displaced GPT. So, what does systemd make out of this?

Let's keep the example: While the presence of the displaced secondary 
GPT header does indeed indicate the proper layering, replace is with MBR 
and the fun really starts.

Still believe 'it works in reality'?
>
>> Just imagine the network's linklayer had no idea which upper layer to
>> call, because there's no information on that. TCP/IP again does not have
>> that type of information.
>>
>> So either the layering order is fixed and determined, or you actually
>> will need intra-layer relationships for proper operation. As an
>> alternative, leave it to the user's knowledge and handling. But then we
>> don't need partition tables, LUKS-headers or anything else either,
>> afterall you can tell each layer the geometry and parameters manually
>> and use dmsetup for all your tasks.
>
> It is not just black and white.
> (Could we avoid these logical fallacies here please?)
>
> Milan

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

Hi Arno,

While there is truth in what you say, the same holds true looking at it 
from the other side:
If you get everything 'just done', you will endup with a quilt that is 
far from being useable and stable and which will fail more often than it 
works. (And possibly gets you killed too).

So yes, compromises are needed.

Then again, we all know more than enough examples where cuts in 
complexity/security ended in desaster, even though all features 'really 
needed' were in place.

Regards

-Sven


Am 10.02.2016 um 17:22 schrieb Arno Wagner:
> On Wed, Feb 10, 2016 at 16:39:03 CET, Milan Broz wrote:
>>
>> On 02/10/2016 04:09 PM, Sven Eschenberg wrote:
> [...]
>>> So either the layering order is fixed and determined, or you actually
>>> will need intra-layer relationships for proper operation. As an
>>> alternative, leave it to the user's knowledge and handling. But then we
>>> don't need partition tables, LUKS-headers or anything else either,
>>> afterall you can tell each layer the geometry and parameters manually
>>> and use dmsetup for all your tasks.
>>
>> It is not just black and white.
>> (Could we avoid these logical fallacies here please?)
>>
>> Milan
>
> I very much agree. Reality is that sometimes exceptions need to
> be made and sometimes you need to deviate from "clean" design
> to get good design. The trick is to keep the right balance
> and to keep the overall goal firmly in mind and keep the exceptions
> and added features down to those really needed, otherwise the
> increased complexity kills you (see also "The second system
> effect" by Brooks).
>
> Systems were everything is designed "correctly" and "clean" have
> a tendency to a) never get finished and b) not work very well.
> Reality requires compromises. The trick is to make it good
> compromises.
>
> Regards,
> Arno
>

Re: [dm-crypt] The future of disk encryption with LUKS2

[Robert Nichols]

On 02/10/2016 09:09 AM, Sven Eschenberg wrote:
> Actually PARTUUID should have read PARTTYPE-GUID - So there's no reason
> why moving it to a different partition should not work, updating the
> PARTTYPE is a trivial step and part of a proper moving operation anyway.
>
> Just imagine the network's linklayer had no idea which upper layer to
> call, because there's no information on that. TCP/IP again does not have
> that type of information.

So, what is it that I shouldn't (or won't in the future) be able to
do, because I'm used to being able to copy a LUKS container freely
among LVM logical volumes, physical partitions, and image files
using commands like "dd if=/dev/mapper/vg00-lv00 of=/var/tmp/xx.img"
and "dd if=/var/tmp/xx.img of=/dev/sdb2" and being able to luksOpen
the LV, partition, or loop device set up on the file.

Just what constitutes a "proper moving operation"? And just where
is this "PARTTYPE" stored? There doesn't appear to be any such
field in the current LUKS on-disk format.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/11/2016 06:09 AM, Robert Nichols wrote:
> 
> Just what constitutes a "proper moving operation"? And just where
> is this "PARTTYPE" stored? There doesn't appear to be any such
> field in the current LUKS on-disk format.

Please ignore it. PARTTYPE is neither used in lvm2 nor in LUKS.

(You can setup LUKS GUID for GPT partition but it doesn't have any real effect.)

Milan

Re: [dm-crypt] The future of disk encryption with LUKS2

[Milan Broz]

On 02/10/2016 02:48 PM, Sven Eschenberg wrote:
...
> The current LVM man pages still suggests that resizing with multiple 
> metacopies is not working, if it does work nowadays, the man page needs 
> fixing ;-).

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=672deaebc55464015065c2101a3de03e02190e01

Just a reminder, reporting bugs is definitely better than complaining
on unrelated mailing list... (bugzilla.redhat.com in this case,
but apparently IRC works as well :) 

m.

Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg]

No one complained. Usually the documentation is the definite source on 
features and their usage. You claimed functionality that was not 
documented and I merely pointed out, that if you were right, the 
documentation needs fixing. Nothing more, nothing less.

Regards

-Sven



Am 14.02.2016 um 09:20 schrieb Milan Broz:
>
> On 02/10/2016 02:48 PM, Sven Eschenberg wrote:
> ...
>> The current LVM man pages still suggests that resizing with multiple
>> metacopies is not working, if it does work nowadays, the man page needs
>> fixing ;-).
>
> https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=672deaebc55464015065c2101a3de03e02190e01
>
> Just a reminder, reporting bugs is definitely better than complaining
> on unrelated mailing list... (bugzilla.redhat.com in this case,
> but apparently IRC works as well :)
>
> m.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

[dm-crypt] LUKS NVMe M.2 SSD - save disklayout...

[Sumaya1960]

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

Hi,

I just wonder, if anyone knows how to save the complete disklayout/disk 
partititions for restoring the partitions with the same layout and UUIDs 
on another disk.
To establish a disatser recovery plan is the goal of my question.
I am using a NVMe M.2 SSD from Samsung. There you see /dev/nvme0n1 and 
it's partitions....




Any ideas and help would be wonderful!
Thanks to everybody!!!!
Susu




[-- Attachment #2.1: Type: text/html, Size: 747 bytes --]

[-- Attachment #2.2: aideeibf.png --]
[-- Type: image/png, Size: 15029 bytes --]

Re: [dm-crypt] LUKS NVMe M.2 SSD - save disklayout...

[Sven Eschenberg]

While this is off-topic for this list, if you want to include all data 
look at tools like partimage or projects like clonezilla?

If you just want to backup the metadata of all layers in the storage 
stack, I'm not aware of any tool for this task.

Regards

-Sven


Am 01.03.2016 um 13:50 schrieb Sumaya1960@gmx.de:
> Hi,
>
> I just wonder, if anyone knows how to save the complete disklayout/disk
> partititions for restoring the partitions with the same layout and UUIDs
> on another disk.
> To establish a disatser recovery plan is the goal of my question.
> I am using a NVMe M.2 SSD from Samsung. There you see /dev/nvme0n1 and
> it's partitions....
>
>
>
>
> Any ideas and help would be wonderful!
> Thanks to everybody!!!!
> Susu
>
>
>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] LUKS NVMe M.2 SSD - save disklayout...

[doark]

On Tue, 1 Mar 2016 19:18:12 Sven Eschenberg wrote:
> While this is off-topic for this list, if you want to include all data 
> look at tools like partimage or projects like clonezilla?
> 
> If you just want to backup the metadata of all layers in the storage 
> stack, I'm not aware of any tool for this task.
> 
> Am 01.03.2016 um 13:50 schrieb Sumaya1960@gmx.de:
> > Hi,
> >
> > I just wonder, if anyone knows how to save the complete
> > disklayout/disk partititions for restoring the partitions with the
> > same layout and UUIDs on another disk.
> > To establish a disatser recovery plan is the goal of my question.
> > I am using a NVMe M.2 SSD from Samsung. There you see /dev/nvme0n1 and
> > it's partitions....
> >
> > Any ideas and help would be wonderful!
> > Thanks to everybody!!!!
> > Susu

AFAIK UUIDs are unique to the device and to the partition. You can't
back them up or restore them to any device. If I'm wrong on this please
say so, I'm willing to be wrong.
Also, it seems to me that a backup solution for encrypted data should
backup and compress the unencrypted data and then reencrypt it. Your free
to do the backup of the whole encrypted partition though.

Sincerely, David

Re: [dm-crypt] LUKS NVMe M.2 SSD - save disklayout...

[Matthias Schniedermeyer]

On 04.03.2016 17:05, doark@mail.com wrote:
> On Tue, 1 Mar 2016 19:18:12 Sven Eschenberg wrote:
> > While this is off-topic for this list, if you want to include all data 
> > look at tools like partimage or projects like clonezilla?
> > 
> > If you just want to backup the metadata of all layers in the storage 
> > stack, I'm not aware of any tool for this task.
> > 
> > Am 01.03.2016 um 13:50 schrieb Sumaya1960@gmx.de:
> > > Hi,
> > >
> > > I just wonder, if anyone knows how to save the complete
> > > disklayout/disk partititions for restoring the partitions with the
> > > same layout and UUIDs on another disk.
> > > To establish a disatser recovery plan is the goal of my question.
> > > I am using a NVMe M.2 SSD from Samsung. There you see /dev/nvme0n1 and
> > > it's partitions....
> > >
> > > Any ideas and help would be wonderful!
> > > Thanks to everybody!!!!
> > > Susu
> 
> AFAIK UUIDs are unique to the device and to the partition. You can't
> back them up or restore them to any device. If I'm wrong on this please
> say so, I'm willing to be wrong.
> Also, it seems to me that a backup solution for encrypted data should
> backup and compress the unencrypted data and then reencrypt it. Your free
> to do the backup of the whole encrypted partition though.

I answer in general. UUIDs are things that are stored. So it's usually 
possible to set them to an arbitrary value, for e.g. a previously used 
value.

Altough it doesn't necessarily mean that it is easy to do.
For e.g. for both xfs & ext? filesystems you can change the UUID of the 
filesystem by using the appropriate cli-tool (xfs_admin/tune2fs). So 
it's easy to change the UUIDs for said filesystems.

Or in other words:
Everything in this directory can be manipulated to be how you want them 
to be:
ls -l /dev/disk/by-uuid/

Whereas most things in this directory are derived from things that 
change when you switch devices:
ls -l /dev/disk/by-id/



-- 

Matthias

Re: [dm-crypt] LUKS NVMe M.2 SSD - save disklayout...

[Sven Eschenberg]

Am 04.03.2016 um 23:05 schrieb doark@mail.com:
> On Tue, 1 Mar 2016 19:18:12 Sven Eschenberg wrote:
>> While this is off-topic for this list, if you want to include all data
>> look at tools like partimage or projects like clonezilla?
>>
>> If you just want to backup the metadata of all layers in the storage
>> stack, I'm not aware of any tool for this task.
>>
>> Am 01.03.2016 um 13:50 schrieb Sumaya1960@gmx.de:
>>> Hi,
>>>
>>> I just wonder, if anyone knows how to save the complete
>>> disklayout/disk partititions for restoring the partitions with the
>>> same layout and UUIDs on another disk.
>>> To establish a disatser recovery plan is the goal of my question.
>>> I am using a NVMe M.2 SSD from Samsung. There you see /dev/nvme0n1 and
>>> it's partitions....
>>>
>>> Any ideas and help would be wonderful!
>>> Thanks to everybody!!!!
>>> Susu
>
> AFAIK UUIDs are unique to the device and to the partition. You can't
> back them up or restore them to any device. If I'm wrong on this please
> say so, I'm willing to be wrong.
> Also, it seems to me that a backup solution for encrypted data should
> backup and compress the unencrypted data and then reencrypt it. Your free
> to do the backup of the whole encrypted partition though.

The very purpose of UUIDs is to be UNIQUE in every respect. It is 
however no problem to i.e. backup metadata including UUIDs and use it 
for another disk at a later time, i.e. on a replacement disk after a 
failure. (Depends of the setup used to a certain extent)

A mirror (i.e.) will have the very same FS UUID on both legs 
(obviously). If the mirror falls apart, then the fs driver will usually 
prevent you from mounting both copies of the FS, as the UUIDs are 
identical and a double mounts ask for major wreckage. But, as you can 
observe, the context defines uniqueness.

>
> Sincerely, David
>

Regards

-Sven

Re: [dm-crypt] The future of disk encryption with LUKS2

[David Niklas]

On Wed, 16 Mar 2016 07:36:38 <okozina@redhat.com> wrote:
> On 03/12/2016 10:20 PM, David Niklas wrote:
> > I've been watching this thread and I tried to access the materials on
> > this page
> > https://devconfcz2016.sched.org/event/5nsA/the-future-of-disk-encryption-with-luks2
> > but I'm not seeing any materials to view. What am I missing?  
> 
> Hi,
> 
> try this link for slides: http://bit.ly/241krO5
> 

Got it!
Thanks, David

Re: [dm-crypt] The future of disk encryption with LUKS2

[Ondrej Kozina]

On 03/12/2016 10:20 PM, David Niklas wrote:
> I've been watching this thread and I tried to access the materials on
> this page
> https://devconfcz2016.sched.org/event/5nsA/the-future-of-disk-encryption-with-luks2
> but I'm not seeing any materials to view. What am I missing?

Hi,

try this link for slides: http://bit.ly/241krO5

O.

Re: [dm-crypt] The future of disk encryption with LUKS2

[David Niklas]

I've been watching this thread and I tried to access the materials on
this page
https://devconfcz2016.sched.org/event/5nsA/the-future-of-disk-encryption-with-luks2
but I'm not seeing any materials to view. What am I missing?

Thanks, David