<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Analysis of FileVault 2 (Apple&#8217;s full disk encryption)</title>
	<atom:link href="http://www.lightbluetouchpaper.org/2012/08/06/analysis-of-filevault-2-apples-full-disk-encryption/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.lightbluetouchpaper.org/2012/08/06/analysis-of-filevault-2-apples-full-disk-encryption/</link>
	<description>Security Research, Computer Laboratory, University of Cambridge</description>
	<lastBuildDate>Wed, 19 Jun 2013 22:09:39 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: muondude</title>
		<link>http://www.lightbluetouchpaper.org/2012/08/06/analysis-of-filevault-2-apples-full-disk-encryption/comment-page-1/#comment-353681</link>
		<dc:creator>muondude</dc:creator>
		<pubDate>Thu, 18 Oct 2012 05:36:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/?p=4305#comment-353681</guid>
		<description>Have you performed a similar analysis on the  McAfee Endpoint Encryption for Mac?</description>
		<content:encoded><![CDATA[<p>Have you performed a similar analysis on the  McAfee Endpoint Encryption for Mac?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nick P</title>
		<link>http://www.lightbluetouchpaper.org/2012/08/06/analysis-of-filevault-2-apples-full-disk-encryption/comment-page-1/#comment-331354</link>
		<dc:creator>Nick P</dc:creator>
		<pubDate>Thu, 23 Aug 2012 18:29:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/?p=4305#comment-331354</guid>
		<description>&quot;assuming true overwrites are possible on the media, and that attackers have not previously had access to the media to copy the key&quot;

Not a safe assumption. Besides, the best way to erase an encrypted volume is to forget the key. That trick let&#039;s you erase TB of data in under a second. ;)</description>
		<content:encoded><![CDATA[<p>&#8220;assuming true overwrites are possible on the media, and that attackers have not previously had access to the media to copy the key&#8221;</p>
<p>Not a safe assumption. Besides, the best way to erase an encrypted volume is to forget the key. That trick let&#8217;s you erase TB of data in under a second. <img src='http://www.lightbluetouchpaper.org/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Owen</title>
		<link>http://www.lightbluetouchpaper.org/2012/08/06/analysis-of-filevault-2-apples-full-disk-encryption/comment-page-1/#comment-329233</link>
		<dc:creator>Owen</dc:creator>
		<pubDate>Fri, 17 Aug 2012 07:35:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/?p=4305#comment-329233</guid>
		<description>From the paper:

&gt; We are not sure of the real advantage introduced by encrypting the
&gt; EncryptedRoot.plist ﬁle. This ﬁle contains the keys in an encrypted
&gt; blob (therefore security measures have already been taken), but the
&gt; key to decrypt the ﬁle is available as plain text in the header of the
&gt; CoreStorage volume (so any attacker can do that; for a  dictionary
&gt; attack, as detailed earlier, an attacker only needs to decrypt this
&gt; ﬁle once).

The purpose of encrypting this file is obvious given that its name is EncryptedRoot.plist.wipekey -- clearly it is encrypted with the &quot;wipekey&quot; from the header such that overwriting the sector(s) containing that wipekey will cryptographically wipe the volume (assuming true overwrites are possible on the media, and that attackers have not previously had access to the media to copy the key).</description>
		<content:encoded><![CDATA[<p>From the paper:</p>
<p>&gt; We are not sure of the real advantage introduced by encrypting the<br />
&gt; EncryptedRoot.plist ﬁle. This ﬁle contains the keys in an encrypted<br />
&gt; blob (therefore security measures have already been taken), but the<br />
&gt; key to decrypt the ﬁle is available as plain text in the header of the<br />
&gt; CoreStorage volume (so any attacker can do that; for a  dictionary<br />
&gt; attack, as detailed earlier, an attacker only needs to decrypt this<br />
&gt; ﬁle once).</p>
<p>The purpose of encrypting this file is obvious given that its name is EncryptedRoot.plist.wipekey &#8212; clearly it is encrypted with the &#8220;wipekey&#8221; from the header such that overwriting the sector(s) containing that wipekey will cryptographically wipe the volume (assuming true overwrites are possible on the media, and that attackers have not previously had access to the media to copy the key).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: finid</title>
		<link>http://www.lightbluetouchpaper.org/2012/08/06/analysis-of-filevault-2-apples-full-disk-encryption/comment-page-1/#comment-329078</link>
		<dc:creator>finid</dc:creator>
		<pubDate>Thu, 16 Aug 2012 17:30:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/?p=4305#comment-329078</guid>
		<description>Have you tried something similar for reading a volume encrypted in Linux?</description>
		<content:encoded><![CDATA[<p>Have you tried something similar for reading a volume encrypted in Linux?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
