Consider increasing LUKS_STRIPES because of 4096 byte sector hds

[GoogleCodeExporter]

Currently LUKS_STRIPES is set to 4000 in luks/luks.h and afaik there is no
user interface to change it. Since afaik the stripes are meant to protect
against forensic attacks. E.g. if a hardware sector of the harddisk cannot
be accessed anymore because it has been remapped, it is not possible to
delete the master key completely. Since there now hard drives with a sector
size that is 8 times bigger than the sector size luks assumes to be, imho
the LUKS_STRIPES should also be increased to address this.

Original issue reported on code.google.com by opensource@till.name on 19 Mar 2010 at 2:22

[GoogleCodeExporter]

The AF splitted material is (key) length * LUKS_STRIPES, and this is stored in 
keyslot.

It will need some analysis but it should be still enough, 128bit key splits to 
32 *
4k sectors (on normal drives).

(And SSDs use even larger write block, so yes, it should be analysed. But I 
would
prefer not change these parameters for LUKS1 header, anyway, disk topology 
should by
one of new things to think about for the new header version.)

Original comment by gmazyl...@gmail.com on 19 Mar 2010 at 3:05

[GoogleCodeExporter]

I think the biggest threat is SSD. They can have very large effective sector 
sizes
and typically do not overwrite data on writes to the same area. For 4K sector 
HDDs, I do not see a problem. In fact, I do not see a problem for HDDs as long 
as it is unlikely that a complete key-slot goes undeletable due to defect 
management. 

For SSDs, that is different as overwrites may not overwrite at all but go to a 
different sector. This requires more study, but my intuition is that for SSDs, 
one would have to use huge key-slots, i.e. larger than the reserved space, to 
be sure. To give an example: A 240GB SSD tupically has 256GB of FLASH. To be 
sure key-slots get destroyed on overwrite, they would need to be >16GB in size, 
as only in this case the SSD _has_ _to_ overwrite sectors from the spare pool, 
as it does not have enough space to do otherwise. Even that works only if the 
whole SSD is filled with data before.

That said, doing a secure erase (via ATA command) of a current SSD should be 
enough for LUKS as well and the anti-forensic splitting does help. Simply 
changing key-slots is a problem on SSD though. As is erasing data in the first 
place.

For the moment, I think we simply have to advise users that with SSDs, LUKS 
security properties are not as good as with HDDs for some operations. 

I may add a dedicated SSD section to the FAQ at some time to deal with this.

Original comment by wagner.a...@gmail.com on 27 Apr 2012 at 1:13