News for hackers. Stuff that matters.
Re:When Full-Disk Encryption Goes Wrong by cmurf on Friday May 20, 2016 @02:09PM (#11740097)
OK recently my recovery volume's HFSJ file system became corrupted in a way that prevented booting, similar to this story. Nothing could repair it, not Apple's fsck_hfs (Disk Utility) nor Disk Warrior. I used dd to backup the recovery partition because I wasn't sure if it contained anything vital for unlocking the encrypted volume. And then I proceeded to nuke that partition (I actually formatted the volume from a Fedora live image, and that issues a trim command prior to the format; and I followed that up with removing the partition with gdisk, so for sure there is no recovery HD volume data at all on this SSD)

Using a separate OS X boot volume I created a USB installer of El Capitan, booted that, went to Disk Utility, asked it to unlock the encrypted primary volume, using just the normal passphrase, and it worked. I then went back to the main menu to reinstall the OS; i.e. installing over the existing (newer) El Capitan installation. The installer took forever but it reinstalled the (older) OS version of El Capitan, created a new Recovery HD volume, and did not erase any of my data. And I could boot afterward.

So too bad this guy's blog doesn't accept comments or I'd tell him this directly and there's a pretty good chance his data can be recovered intact.

Re:When Full-Disk Encryption Goes Wrong by cmurf on Friday May 20, 2016 @02:15PM (#11740137)
What I think is the Core Storage metadata on the primary volume contains an encrypted copy of the DEK. I mean, why put the only copy on another file system and partition? That's risky. I'm willing to bet how Apple does it is similar to a combined LVM+LUKS header, except they appear to duplicate the metadata at each end of the partition. In between that plaintext metadata is a (huge) pile of ciphertext which is the actual primary volume, OS + apps + user data.