* [dm-crypt] Data recovery @ 2011-10-08 12:28 Nico Gevers 2011-10-08 16:22 ` Arno Wagner 0 siblings, 1 reply; 8+ messages in thread From: Nico Gevers @ 2011-10-08 12:28 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 804 bytes --] Hi I've recently decided to encrypt all my drives using luks, running on ubuntu 11.10. I encrypted my external drive, and loaded all my backups onto the drive. One morning, I tried accessing the drive, and it wouldn't accept my key phrase. I tried a couple of times, even tried some variations, but no avail. Then I stupidly thought of running fsck on the drive. I fixed a couple of innodes, but then stopped, realising that I was probably doing more harm than good. When I run luksDump on that drive, I get all the expected information. My question is: is the header still intact. Is there any chance I can recover my data, owing to the fact that luksDump displays, what seems to me, a valid header? (I'm assuming that if luksDump shows the information, the header is intact). thanks in advance Nico [-- Attachment #2: Type: text/html, Size: 904 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Data recovery 2011-10-08 12:28 [dm-crypt] Data recovery Nico Gevers @ 2011-10-08 16:22 ` Arno Wagner 2011-10-08 17:42 ` Nico Gevers 0 siblings, 1 reply; 8+ messages in thread From: Arno Wagner @ 2011-10-08 16:22 UTC (permalink / raw) To: dm-crypt On Sat, Oct 08, 2011 at 02:28:28PM +0200, Nico Gevers wrote: > Hi > > I've recently decided to encrypt all my drives using luks, running on ubuntu > 11.10. I encrypted my external drive, and loaded all my backups onto the > drive. One morning, I tried accessing the drive, and it wouldn't accept my > key phrase. I tried a couple of times, even tried some variations, but no > avail. Then I stupidly thought of running fsck on the drive. I fixed a > couple of innodes, but then stopped, realising that I was probably doing > more harm than good. > > When I run luksDump on that drive, I get all the expected information. My > question is: is the header still intact. Is there any chance I can recover > my data, owing to the fact that luksDump displays, what seems to me, a valid > header? (I'm assuming that if luksDump shows the information, the header is > intact). The header itself may be intact. But the problem here is the keyslots. If they are damaged, the only thing that can save your data is a header backup. What I wonder is why fsck was even willing to run. Due to the encryption, it will have seen absolutely nothing that looks like a filesystem. It also is quite possible that it 'fixed' things in the keyslot area. In addition, there is the question for the reason fo the initial fail. So, what you do now is make a header backup (procedure is in the FAQ) und analyse that. First, find out in which keyslot your key is (likely the first), then look at the FAQ section on on-disk format and look at the encrypted keyslot with a hex-dump tool, e.g. hd. If there is anything looking regular in the keyslot area, apply procedure for dealing with permanent data loss, also described in the FAQ. You can of course ask for further advice here, but it is impossible to answer your question without looking at that keyslot data. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Data recovery 2011-10-08 16:22 ` Arno Wagner @ 2011-10-08 17:42 ` Nico Gevers 2011-10-08 20:02 ` Arno Wagner 0 siblings, 1 reply; 8+ messages in thread From: Nico Gevers @ 2011-10-08 17:42 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 4659 bytes --] Hi Arno Thanks for your reply. I made a header backup and had a look at the hex dump. Its about 1.4M so haven't attached it, but can if its useful. The drive was using aes-xts-plain with a 512 bit key. According to the FAQ this means that 1st keyslot starts at 0x1000 and runs until 0x3f800. Having had a look at the dump, I noticed 0x1000 - 0x13300 was fairly regular, and from 0x14000 the dump looked quite random until the end of the keyspace. I guess that means I've lost some of the key. Excuse my ignorance here, but wouldn't it be possible (in my case) to reverse engineer the data in the keyslot, since I know the original key as well as the iterations and salt value. Could I not regenerate the key hash and insert it back into the header. I could even check the correctness of the key my matching the last half of the bits to the ones in the existing keyslot. As for how it happened, I wish I knew. All I remember is one morning starting my machine up and being surprised that the external drive wouldn't accept my password. I do remember getting semaphore errors for the first time, and since I'm running ubuntu 11.10 beta, perhaps I did an update that might have caused a hassle some where (perhaps a kernel update or an update to cryptsetup). I wasn't really paying attention since I didn't anticipate anything like this. Oh, and here's a dump of the luksDump command. I can attach the header if its useful to anyone. Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha1 Payload offset: 4040 MK bits: 512 MK digest: 1e 01 d1 96 ba 79 cd 9f d1 cd 7f ee 1c e5 e7 51 ed a7 61 06 MK salt: 60 32 3e 38 42 1f 5c 05 ce 21 d6 27 ad 23 bf 1e a7 18 13 a7 75 8f 33 f0 f6 f8 25 da 0c e0 af 60 MK iterations: 9125 UUID: 5048085d-d798-4b4f-902b-88eb2e71fd88 Key Slot 0: ENABLED Iterations: 36805 Salt: 25 4b 79 50 a4 0b 26 40 85 48 5c d0 28 1b 42 73 7b 59 a7 e6 17 81 94 22 c8 45 de 96 b7 bd 8f f1 Key material offset: 8 AF stripes: 4000 <the rest of the keyslots are empty> thanks again Nico On Sat, Oct 8, 2011 at 6:22 PM, Arno Wagner <arno@wagner.name> wrote: > On Sat, Oct 08, 2011 at 02:28:28PM +0200, Nico Gevers wrote: > > Hi > > > > I've recently decided to encrypt all my drives using luks, running on > ubuntu > > 11.10. I encrypted my external drive, and loaded all my backups onto the > > drive. One morning, I tried accessing the drive, and it wouldn't accept > my > > key phrase. I tried a couple of times, even tried some variations, but no > > avail. Then I stupidly thought of running fsck on the drive. I fixed a > > couple of innodes, but then stopped, realising that I was probably doing > > more harm than good. > > > > When I run luksDump on that drive, I get all the expected information. My > > question is: is the header still intact. Is there any chance I can > recover > > my data, owing to the fact that luksDump displays, what seems to me, a > valid > > header? (I'm assuming that if luksDump shows the information, the header > is > > intact). > > The header itself may be intact. But the problem here is the keyslots. > If they are damaged, the only thing that can save your data is a header > backup. > > What I wonder is why fsck was even willing to run. Due to the encryption, > it will have seen absolutely nothing that looks like a filesystem. > It also is quite possible that it 'fixed' things in the keyslot area. > > In addition, there is the question for the reason fo the initial > fail. > > So, what you do now is make a header backup (procedure is in the > FAQ) und analyse that. First, find out in which keyslot your key > is (likely the first), then look at the FAQ section on on-disk > format and look at the encrypted keyslot with a hex-dump > tool, e.g. hd. If there is anything looking regular in the > keyslot area, apply procedure for dealing with permanent data > loss, also described in the FAQ. > > You can of course ask for further advice here, but it is impossible > to answer your question without looking at that keyslot data. > > Arno > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > arno@wagner.name > 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 > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > [-- Attachment #2: Type: text/html, Size: 7059 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Data recovery 2011-10-08 17:42 ` Nico Gevers @ 2011-10-08 20:02 ` Arno Wagner 2011-10-09 17:17 ` Nico Gevers 0 siblings, 1 reply; 8+ messages in thread From: Arno Wagner @ 2011-10-08 20:02 UTC (permalink / raw) To: dm-crypt On Sat, Oct 08, 2011 at 07:42:09PM +0200, Nico Gevers wrote: > Hi Arno > > Thanks for your reply. I made a header backup and had a look at the hex > dump. Its about 1.4M so haven't attached it, but can if its useful. The > drive was using aes-xts-plain with a 512 bit key. According to the FAQ this > means that 1st keyslot starts at 0x1000 and runs until 0x3f800. Having had a > look at the dump, I noticed 0x1000 - 0x13300 was fairly regular, and from > 0x14000 the dump looked quite random until the end of the keyspace. I guess > that means I've lost some of the key. Actually, you lost the full key, due to the anti-forensic properties of LUKS key storage. Hanginf a few bits anywhere in the keyslot is enough to make the master-key irrecoverable. This is by design. No idea what overwrites 0x1000-0x13300, except possibly the fdisk-run... > Excuse my ignorance here, but wouldn't it be possible (in my case) to > reverse engineer the data in the keyslot, since I know the original key as > well as the iterations and salt value. Could I not regenerate the key hash > and insert it back into the header. I could even check the correctness of > the key my matching the last half of the bits to the ones in the existing > keyslot. No. The key that was lost is the master key, encrypted with your passphrase and "streched" to the full keyslot size. If a reconstruction as you suggest were possible, disabling old passphrases would be impossible. > As for how it happened, I wish I knew. All I remember is one morning > starting my machine up and being surprised that the external drive wouldn't > accept my password. I do remember getting semaphore errors for the first > time, and since I'm running ubuntu 11.10 beta, perhaps I did an update that > might have caused a hassle some where (perhaps a kernel update or an update > to cryptsetup). I wasn't really paying attention since I didn't anticipate > anything like this. Should not cause this. Some versions of Ubuntu have a problem that they offer to create new LUKS partitions during install in unclear language, leading people to belive their existing LUKS containers would be activated, but that is about it AFAIK. So what you see should not happen. Read errors from the disk would also show up differently. Has maybe somebody else had access to that disk? Since you ran fdisk, it is likely impossible to find out anything from the change-pattern now. Arno > Oh, and here's a dump of the luksDump command. I can attach the header if > its useful to anyone. > > Version: 1 > Cipher name: aes > Cipher mode: xts-plain > Hash spec: sha1 > Payload offset: 4040 > MK bits: 512 > MK digest: 1e 01 d1 96 ba 79 cd 9f d1 cd 7f ee 1c e5 e7 51 ed a7 61 06 > MK salt: 60 32 3e 38 42 1f 5c 05 ce 21 d6 27 ad 23 bf 1e > a7 18 13 a7 75 8f 33 f0 f6 f8 25 da 0c e0 af 60 > MK iterations: 9125 > UUID: 5048085d-d798-4b4f-902b-88eb2e71fd88 > > Key Slot 0: ENABLED > Iterations: 36805 > Salt: 25 4b 79 50 a4 0b 26 40 85 48 5c d0 28 1b 42 73 > 7b 59 a7 e6 17 81 94 22 c8 45 de 96 b7 bd 8f f1 > Key material offset: 8 > AF stripes: 4000 > > <the rest of the keyslots are empty> > > thanks again > Nico > > On Sat, Oct 8, 2011 at 6:22 PM, Arno Wagner <arno@wagner.name> wrote: > > > On Sat, Oct 08, 2011 at 02:28:28PM +0200, Nico Gevers wrote: > > > Hi > > > > > > I've recently decided to encrypt all my drives using luks, running on > > ubuntu > > > 11.10. I encrypted my external drive, and loaded all my backups onto the > > > drive. One morning, I tried accessing the drive, and it wouldn't accept > > my > > > key phrase. I tried a couple of times, even tried some variations, but no > > > avail. Then I stupidly thought of running fsck on the drive. I fixed a > > > couple of innodes, but then stopped, realising that I was probably doing > > > more harm than good. > > > > > > When I run luksDump on that drive, I get all the expected information. My > > > question is: is the header still intact. Is there any chance I can > > recover > > > my data, owing to the fact that luksDump displays, what seems to me, a > > valid > > > header? (I'm assuming that if luksDump shows the information, the header > > is > > > intact). > > > > The header itself may be intact. But the problem here is the keyslots. > > If they are damaged, the only thing that can save your data is a header > > backup. > > > > What I wonder is why fsck was even willing to run. Due to the encryption, > > it will have seen absolutely nothing that looks like a filesystem. > > It also is quite possible that it 'fixed' things in the keyslot area. > > > > In addition, there is the question for the reason fo the initial > > fail. > > > > So, what you do now is make a header backup (procedure is in the > > FAQ) und analyse that. First, find out in which keyslot your key > > is (likely the first), then look at the FAQ section on on-disk > > format and look at the encrypted keyslot with a hex-dump > > tool, e.g. hd. If there is anything looking regular in the > > keyslot area, apply procedure for dealing with permanent data > > loss, also described in the FAQ. > > > > You can of course ask for further advice here, but it is impossible > > to answer your question without looking at that keyslot data. > > > > Arno > > -- > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > > arno@wagner.name > > 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 > > 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Data recovery 2011-10-08 20:02 ` Arno Wagner @ 2011-10-09 17:17 ` Nico Gevers 2011-10-09 17:51 ` Arno Wagner 0 siblings, 1 reply; 8+ messages in thread From: Nico Gevers @ 2011-10-09 17:17 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 7403 bytes --] Hi Arno Thanks for the help. I'll consider the data lost and move on. Incidentally, is there any way to recover deleted files from an encrypted drive. eg, you delete some files (and empty the trash), and then recover them afterwards. I know there are tools available, but I'm not sure i they would work on an encrypted drive (while mounted of course). Will encrypting a drive remove all possibilities of undelete? On Sat, Oct 8, 2011 at 10:02 PM, Arno Wagner <arno@wagner.name> wrote: > On Sat, Oct 08, 2011 at 07:42:09PM +0200, Nico Gevers wrote: > > Hi Arno > > > > Thanks for your reply. I made a header backup and had a look at the hex > > dump. Its about 1.4M so haven't attached it, but can if its useful. The > > drive was using aes-xts-plain with a 512 bit key. According to the FAQ > this > > means that 1st keyslot starts at 0x1000 and runs until 0x3f800. Having > had a > > look at the dump, I noticed 0x1000 - 0x13300 was fairly regular, and from > > 0x14000 the dump looked quite random until the end of the keyspace. I > guess > > that means I've lost some of the key. > > Actually, you lost the full key, due to the anti-forensic properties > of LUKS key storage. Hanginf a few bits anywhere in the keyslot is > enough to make the master-key irrecoverable. This is by design. > > No idea what overwrites 0x1000-0x13300, except possibly the > fdisk-run... > > > Excuse my ignorance here, but wouldn't it be possible (in my case) to > > reverse engineer the data in the keyslot, since I know the original key > as > > well as the iterations and salt value. Could I not regenerate the key > hash > > and insert it back into the header. I could even check the correctness of > > the key my matching the last half of the bits to the ones in the existing > > keyslot. > > No. The key that was lost is the master key, encrypted with > your passphrase and "streched" to the full keyslot size. > If a reconstruction as you suggest were possible, disabling > old passphrases would be impossible. > > > As for how it happened, I wish I knew. All I remember is one morning > > starting my machine up and being surprised that the external drive > wouldn't > > accept my password. I do remember getting semaphore errors for the first > > time, and since I'm running ubuntu 11.10 beta, perhaps I did an update > that > > might have caused a hassle some where (perhaps a kernel update or an > update > > to cryptsetup). I wasn't really paying attention since I didn't > anticipate > > anything like this. > > Should not cause this. Some versions of Ubuntu have a problem that > they offer to create new LUKS partitions during install in unclear > language, leading people to belive their existing LUKS containers > would be activated, but that is about it AFAIK. > > So what you see should not happen. Read errors from the disk > would also show up differently. Has maybe somebody else had > access to that disk? > > Since you ran fdisk, it is likely impossible to find out anything from > the change-pattern now. > > Arno > > > Oh, and here's a dump of the luksDump command. I can attach the header if > > its useful to anyone. > > > > Version: 1 > > Cipher name: aes > > Cipher mode: xts-plain > > Hash spec: sha1 > > Payload offset: 4040 > > MK bits: 512 > > MK digest: 1e 01 d1 96 ba 79 cd 9f d1 cd 7f ee 1c e5 e7 51 ed a7 61 > 06 > > MK salt: 60 32 3e 38 42 1f 5c 05 ce 21 d6 27 ad 23 bf 1e > > a7 18 13 a7 75 8f 33 f0 f6 f8 25 da 0c e0 af 60 > > MK iterations: 9125 > > UUID: 5048085d-d798-4b4f-902b-88eb2e71fd88 > > > > Key Slot 0: ENABLED > > Iterations: 36805 > > Salt: 25 4b 79 50 a4 0b 26 40 85 48 5c d0 28 1b 42 73 > > 7b 59 a7 e6 17 81 94 22 c8 45 de 96 b7 bd 8f f1 > > Key material offset: 8 > > AF stripes: 4000 > > > > <the rest of the keyslots are empty> > > > > thanks again > > Nico > > > > On Sat, Oct 8, 2011 at 6:22 PM, Arno Wagner <arno@wagner.name> wrote: > > > > > On Sat, Oct 08, 2011 at 02:28:28PM +0200, Nico Gevers wrote: > > > > Hi > > > > > > > > I've recently decided to encrypt all my drives using luks, running on > > > ubuntu > > > > 11.10. I encrypted my external drive, and loaded all my backups onto > the > > > > drive. One morning, I tried accessing the drive, and it wouldn't > accept > > > my > > > > key phrase. I tried a couple of times, even tried some variations, > but no > > > > avail. Then I stupidly thought of running fsck on the drive. I fixed > a > > > > couple of innodes, but then stopped, realising that I was probably > doing > > > > more harm than good. > > > > > > > > When I run luksDump on that drive, I get all the expected > information. My > > > > question is: is the header still intact. Is there any chance I can > > > recover > > > > my data, owing to the fact that luksDump displays, what seems to me, > a > > > valid > > > > header? (I'm assuming that if luksDump shows the information, the > header > > > is > > > > intact). > > > > > > The header itself may be intact. But the problem here is the keyslots. > > > If they are damaged, the only thing that can save your data is a header > > > backup. > > > > > > What I wonder is why fsck was even willing to run. Due to the > encryption, > > > it will have seen absolutely nothing that looks like a filesystem. > > > It also is quite possible that it 'fixed' things in the keyslot area. > > > > > > In addition, there is the question for the reason fo the initial > > > fail. > > > > > > So, what you do now is make a header backup (procedure is in the > > > FAQ) und analyse that. First, find out in which keyslot your key > > > is (likely the first), then look at the FAQ section on on-disk > > > format and look at the encrypted keyslot with a hex-dump > > > tool, e.g. hd. If there is anything looking regular in the > > > keyslot area, apply procedure for dealing with permanent data > > > loss, also described in the FAQ. > > > > > > You can of course ask for further advice here, but it is impossible > > > to answer your question without looking at that keyslot data. > > > > > > Arno > > > -- > > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > > > arno@wagner.name > > > 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 > > > 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 > > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > arno@wagner.name > 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 > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > [-- Attachment #2: Type: text/html, Size: 9448 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Data recovery 2011-10-09 17:17 ` Nico Gevers @ 2011-10-09 17:51 ` Arno Wagner 2011-10-09 18:54 ` Nico Gevers 2011-10-23 22:03 ` Anna 0 siblings, 2 replies; 8+ messages in thread From: Arno Wagner @ 2011-10-09 17:51 UTC (permalink / raw) To: dm-crypt Hi Nico, On Sun, Oct 09, 2011 at 07:17:31PM +0200, Nico Gevers wrote: > Hi Arno > > Thanks for the help. I'll consider the data lost and move on. > > Incidentally, is there any way to recover deleted files from an encrypted > drive. eg, you delete some files (and empty the trash), and then recover > them afterwards. I know there are tools available, but I'm not sure i they > would work on an encrypted drive (while mounted of course). Will encrypting > a drive remove all possibilities of undelete? This will behave exactly the same as with a non-encrypted device. The encryption layer just translates the raw encrypted device into a raw non-encrypted device, which for all intents and purposes (except performance) can be treated the same as a non-encrypted device. The filesystem sits on top of that and difficulty-level of recovering deleted files depends on the filesystem used. For example, with ext2/3 it is pretty difficult, but you may find fragments easily if you know what you are looking for. With FAT is is generally easy. BTRFS, XFS, ZFS, etc. I have no idea. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Data recovery 2011-10-09 17:51 ` Arno Wagner @ 2011-10-09 18:54 ` Nico Gevers 2011-10-23 22:03 ` Anna 1 sibling, 0 replies; 8+ messages in thread From: Nico Gevers @ 2011-10-09 18:54 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 1858 bytes --] Thanks for all your help, Arno. I've learned a lot in the last few days, and am grateful for your time in helping me. On Sun, Oct 9, 2011 at 7:51 PM, Arno Wagner <arno@wagner.name> wrote: > Hi Nico, > > On Sun, Oct 09, 2011 at 07:17:31PM +0200, Nico Gevers wrote: > > Hi Arno > > > > Thanks for the help. I'll consider the data lost and move on. > > > > Incidentally, is there any way to recover deleted files from an encrypted > > drive. eg, you delete some files (and empty the trash), and then recover > > them afterwards. I know there are tools available, but I'm not sure i > they > > would work on an encrypted drive (while mounted of course). Will > encrypting > > a drive remove all possibilities of undelete? > > This will behave exactly the same as with a non-encrypted device. > The encryption layer just translates the raw encrypted device into > a raw non-encrypted device, which for all intents and purposes > (except performance) can be treated the same as a non-encrypted > device. > > The filesystem sits on top of that and difficulty-level of > recovering deleted files depends on the filesystem used. > For example, with ext2/3 it is pretty difficult, but you > may find fragments easily if you know what you are looking > for. With FAT is is generally easy. BTRFS, XFS, ZFS, etc. > I have no idea. > > Arno > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > arno@wagner.name > 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 > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > [-- Attachment #2: Type: text/html, Size: 2512 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Data recovery 2011-10-09 17:51 ` Arno Wagner 2011-10-09 18:54 ` Nico Gevers @ 2011-10-23 22:03 ` Anna 1 sibling, 0 replies; 8+ messages in thread From: Anna @ 2011-10-23 22:03 UTC (permalink / raw) To: dm-crypt > > > > Incidentally, is there any way to recover deleted files from an encrypted > > drive. > Arno Well, i guess you can try this free program: http://undeletedeletedfiles.com/ it helps to restore all missing info ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-10-23 22:05 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-10-08 12:28 [dm-crypt] Data recovery Nico Gevers 2011-10-08 16:22 ` Arno Wagner 2011-10-08 17:42 ` Nico Gevers 2011-10-08 20:02 ` Arno Wagner 2011-10-09 17:17 ` Nico Gevers 2011-10-09 17:51 ` Arno Wagner 2011-10-09 18:54 ` Nico Gevers 2011-10-23 22:03 ` Anna
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.