On Sun, Feb 22, 2009 at 04:48:07PM +0100, orinoco wrote: > On Wed, 18 Feb 2009 16:23:30 +0100 > Arno Wagner <arno@xxxxxxxxxxx> wrote: > > On Wed, Feb 18, 2009 at 03:15:32PM +0100, orinoco wrote: > > [...] > > So the header looks good but open fails. Most likely > > is a defective key block. No way to repair that. > > Too bad! > I guess dm-crypt did overwrite the luks header with a random key for a > swap partition, but I'd like to know what did actually happen, and if > there is a chance to brute-force-attack single bytes in case the key in > the header were not overwritten completely. Single bytes are definitely possible. However the key-setup (making the key from the header data) is done in a way that requires significant time. This servers to make brute-forcing more difficult, by increasing the time it takes to verify a guess. Also, you need to take into account that change location is also missing bits, e.g. if you know exactly one byte was overwritten in a 2MB key block (if I remember this correctly, LUKS uses this size), you have 8 bits of data to guess and 21 bits of position, i.e. 29 bits overall. > > > > There may be other fields you absolutely need, but > > > > 32-64 bits or so can be brute-forced today without too > > > > much hassle, depending on what actually need to be done > > > > for a try. This still costs significant effort and > > > > may cause significant cost. > > > > > > > > The other thing is to think about how much your data is > > > > worth. It may be cheaptest to regard this as a lost > > > > cause from the beginning. > > > I would consider it "nice to have it back" and worth some effort. > > > It isn't (or wasn't) vital information. > > Good to know. I think you have done all the easy steps. > > My advice is to cut your losses and start over with a new > > encrypted partition. > > I guess I will keep it as-is-as as a memorial. And maybe quantum > computers in the future will be able to decrypt the information again > =:-} I think Quantum Computing is a scam conducted to get research money. Somebody I know in Quantum Computing agrees ;-) > > > > Although I would recomment at least > > > > one in-detail look at the header. It may basically still > > > > be there. > > > There is a "complete" header information I get from luksDump (see > > > above), but it does not seem to work with luksOpen and the original > > > passphrase. > > > BTW I noticed that my system keeps mixing the sdXX device order. > > > After a reboot it changed again. > > That is really bad, expecially with automated swap creation. > > I turned it off completely although there shouldn't be any partition > left to mix with it. I'm fed up with encrypted swap. Understandable. I have run Linux without swap (4GB main memory) for a long time on my desktop, precisely because on-the-fly generated encrypted swap struck me as risky. No issues so far. Wouldn't do that on a machine with higher uptimes though. > > What I would advise is that you delegate the swap creation > > to a script, that at least checks partition size before > > trashing it. You may also want to, e.g., not use the first > > kB of the partition and put a magic number in there that you > > also check. > > Come to think of it, you could also put your swap on an > > one-partition RAID1 and then access it by its /dev/md<number> > > (set partition type to autodetection). That should be stable > > and circumvent your problem. > > I will consider that. > In the sidux form they advised me to label the swap partition. Might be > another solution to kick off all /dev/sdXX entries in the fstab and > crypttab files and make mounting unique. Indeed. > Thanks for your help. You are welcome. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
