Re: [Bug-ddrescue] fill-mode vs luks encryption

[Atom Smasher]

On Fri, 6 Jun 2014, Marian Csontos wrote:

> Hi, first, have you checked the LUKS headers were unaffected? (Or you 
> have backups) Otherwise an attempt to rescue the data may be futile.
==========

first error is at 0x4B5293D000, so the header should be fine. i do have a 
backup header, just in case.


> Second, // My terminology may be bit unorthodox...
>
> Hypothetically:
> If you wanted markers in the files you would better run ddrescue on the 
> cleartext mapping instead of encrypted device. (However, that may slow 
> things down, and may be unfeasible for some drives holding on just for 
> short periods of time.)
===========

oh yeah... /dev/mapper/udisks-luks-uuid-xxxxx

i hadn't thought of that... maybe i'll give that a shot...

the downside though, IIUC, is that the luks partition uses 4k sectors... 
so in theory i could lose up to 8x more data than i have errors, if some 
sectors of the physical drive don't get recovered sequentially. by running 
ddrescue on the physical disk, i can recover more (encrypted) data (with 
multiple runs of ddrescue), because it doesn't matter if the 512B sectors 
are recovered sequentially or not sequentially. in practice, that probably 
doesn't matter much.

so i think... doing it the way you suggest would have the advantage of 
being able to identify bad data with fill-mode... but the disadvantage of 
not recovering as much data. it's a trade-off.

anyway... it's worth a shot while the drive is on my desk, before i RMA 
it.


> Also similarly to keep data encrypted you should write to cleartext 
> mapping on top of another LUKS-encrypted (loop)device.
===========

most of my external drives are encrypted, anyway, so just writing a 
"normal" image on one of them would be "safe", as it's on an encrypted 
drive.


> Now, with the encrypted data you have...
>
> I am not sure there is a binary grep tool to find sequences of the 
> marker string in the encrypted device (if not it would not be that 
> difficult to write one) - when identified list of offset and span 
> tuples, you would have to dd over the corresponding parts of your 
> cleartext device.
===========

another part of the problem is that block-ciphers don't necessarily have a 
1:1 mapping of bits on the drive to bits in a file. 1 bad bit on the drive 
could easily result in 64 bits of unrecoverable data.


--
        ...atom

 ________________________
 http://atom.smasher.org/
 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
 -------------------------------------------------

        "In every respect, vegans appear to enjoy equal
         or better health in comparison to both vegetarians
         and non-vegetarians."
                -- T. Colin Campbell,
                PhD Professor of Nutrition, Cornell University