<?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"
	>
<channel>
	<title>Comments on: You can never rely on encryption</title>
	<atom:link href="http://www.tomrafteryit.net/you-can-never-rely-on-encryption/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/</link>
	<description>Tom Raftery, social media consultant, speaker, blogger and podcaster</description>
	<pubDate>Sat, 05 Jul 2008 03:37:49 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Cagey</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114900</link>
		<dc:creator>Cagey</dc:creator>
		<pubDate>Mon, 03 Mar 2008 14:49:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114900</guid>
		<description>If the file was encrypted on the laptop then it was unencrypted at some stage.  That would imply there would be info left over in the swapfile or somewhere else that may not be encrypted.

Alternatively, maybe they are saying that file is not specifically encrypted but the laptop hard disk is protected with 256 AES.

In either scenario, the encryption is as weak as the password.  The letter says that "the code on this laptop is thirty five characters".  Is that potentially or in reality?  If the actual password is 5 or 6 characters then it can be easily brute-force cracked.  If it is longer it may be vulnerable to a dictionary attack. If it is a random 35 alphanumeric characters then it is presumably written down somewhere.

Unless the user has a very good memory for random alphas the only hope would be an obfuscated passphrase like "Shou1dnt 68 5hare-tHis_*&#38;$ing_data!"</description>
		<content:encoded><![CDATA[<p>If the file was encrypted on the laptop then it was unencrypted at some stage.  That would imply there would be info left over in the swapfile or somewhere else that may not be encrypted.</p>
<p>Alternatively, maybe they are saying that file is not specifically encrypted but the laptop hard disk is protected with 256 AES.</p>
<p>In either scenario, the encryption is as weak as the password.  The letter says that &#8220;the code on this laptop is thirty five characters&#8221;.  Is that potentially or in reality?  If the actual password is 5 or 6 characters then it can be easily brute-force cracked.  If it is longer it may be vulnerable to a dictionary attack. If it is a random 35 alphanumeric characters then it is presumably written down somewhere.</p>
<p>Unless the user has a very good memory for random alphas the only hope would be an obfuscated passphrase like &#8220;Shou1dnt 68 5hare-tHis_*&amp;$ing_data!&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fitz</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114803</link>
		<dc:creator>Fitz</dc:creator>
		<pubDate>Wed, 27 Feb 2008 13:09:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114803</guid>
		<description>I've written a letter to the Chief Executive of the IBTS with a number of questions. One of the questions asks specifically if the password was stored anywhere else.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve written a letter to the Chief Executive of the IBTS with a number of questions. One of the questions asks specifically if the password was stored anywhere else.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114801</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Wed, 27 Feb 2008 12:12:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114801</guid>
		<description>i.e. if faced with a 2^255 operation Bank Vault Door, look for the doorbell</description>
		<content:encoded><![CDATA[<p>i.e. if faced with a 2^255 operation Bank Vault Door, look for the doorbell</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114800</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Wed, 27 Feb 2008 12:07:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114800</guid>
		<description>the AES-type 256 bit encryption is a red herring; if Mitnick were confronted with this he'd look for the post-it with the password - probably in the laptop case.</description>
		<content:encoded><![CDATA[<p>the AES-type 256 bit encryption is a red herring; if Mitnick were confronted with this he&#8217;d look for the post-it with the password - probably in the laptop case.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fitz</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114771</link>
		<dc:creator>Fitz</dc:creator>
		<pubDate>Mon, 25 Feb 2008 23:33:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114771</guid>
		<description>I'm very very angry. I received a letter from the IBTS today telling me that my information was on that laptop.

I did not give permission to IBTS to use my personal details in any way. 

I am also concerned that although the details are supposedly encrypted there is clearly such lax protection of this data that the passwords are probably stored in email on the damn laptop.</description>
		<content:encoded><![CDATA[<p>I&#8217;m very very angry. I received a letter from the IBTS today telling me that my information was on that laptop.</p>
<p>I did not give permission to IBTS to use my personal details in any way. </p>
<p>I am also concerned that although the details are supposedly encrypted there is clearly such lax protection of this data that the passwords are probably stored in email on the damn laptop.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous Coward</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114763</link>
		<dc:creator>Anonymous Coward</dc:creator>
		<pubDate>Mon, 25 Feb 2008 18:21:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114763</guid>
		<description>Ip Address - It was simple. They didn't need a lab or any fancy equipment.  The cooling was done using a simply canister you can buy at any electronics or many other stores (they used the same spray canisters you use to blow dust out of your computer or keyboard).  They lowered the temp to -50 degrees centigrade, not -192.  

Once cooled, they could then remove the memory chip and simply drop it into another system.  Nothing complex here.  After that they could use any of a number of freely available utilities to do a memory dump and then look for an area of high entropy - basically a memory segment that looked like a series of random numbers. Not very difficult considering that you could easily eliminate all the areas that the computer instructions (program) use because instructions aren't random.  Program data is also usually not random (unless generated for games (to vary game play) or for some other program related purpose).  Data is otherwise very structured.

Anyone skilled enough to understand assembly and hardware savvy enough to take a machine apart enough to access the ram would be able to pull this off.  Which boils down to almost any computer science grad or half-baked hacker.

However, since this is a recent exploit, it's likely that the blood donor data was safe from attack.  Ultimately, this wasn't an attack on any of the encryption algorithms but is a "side-channel" attack.  You can't break the encryption, so you just go around it.  Kind of like recording a blue-ray dvd to an analog device.  But in this case, you don't really get any signal degredation.</description>
		<content:encoded><![CDATA[<p>Ip Address - It was simple. They didn&#8217;t need a lab or any fancy equipment.  The cooling was done using a simply canister you can buy at any electronics or many other stores (they used the same spray canisters you use to blow dust out of your computer or keyboard).  They lowered the temp to -50 degrees centigrade, not -192.  </p>
<p>Once cooled, they could then remove the memory chip and simply drop it into another system.  Nothing complex here.  After that they could use any of a number of freely available utilities to do a memory dump and then look for an area of high entropy - basically a memory segment that looked like a series of random numbers. Not very difficult considering that you could easily eliminate all the areas that the computer instructions (program) use because instructions aren&#8217;t random.  Program data is also usually not random (unless generated for games (to vary game play) or for some other program related purpose).  Data is otherwise very structured.</p>
<p>Anyone skilled enough to understand assembly and hardware savvy enough to take a machine apart enough to access the ram would be able to pull this off.  Which boils down to almost any computer science grad or half-baked hacker.</p>
<p>However, since this is a recent exploit, it&#8217;s likely that the blood donor data was safe from attack.  Ultimately, this wasn&#8217;t an attack on any of the encryption algorithms but is a &#8220;side-channel&#8221; attack.  You can&#8217;t break the encryption, so you just go around it.  Kind of like recording a blue-ray dvd to an analog device.  But in this case, you don&#8217;t really get any signal degredation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ip Address</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114719</link>
		<dc:creator>Ip Address</dc:creator>
		<pubDate>Sun, 24 Feb 2008 06:48:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114719</guid>
		<description>What concert me is that a group from Princeton University call it "simple method" to steal encrypted information stored on computer hard disks.
I do not think that it is simple method to cool the chips in liquid nitrogen (-196 Â°C) and then put the chips back into a machine to read out their contents. But... it is good to know that increased the security of modern personal computers, does not appear to stop the potential attacks and that computer security experts are now on the move to make things better and more secure.</description>
		<content:encoded><![CDATA[<p>What concert me is that a group from Princeton University call it &#8220;simple method&#8221; to steal encrypted information stored on computer hard disks.<br />
I do not think that it is simple method to cool the chips in liquid nitrogen (-196 Â°C) and then put the chips back into a machine to read out their contents. But&#8230; it is good to know that increased the security of modern personal computers, does not appear to stop the potential attacks and that computer security experts are now on the move to make things better and more secure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hunter</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114711</link>
		<dc:creator>John Hunter</dc:creator>
		<pubDate>Sat, 23 Feb 2008 18:18:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114711</guid>
		<description>Very true.  I don't understand why simple common sense measures are not taken.  I get the same feeling as when a character in a movie is obviously setting themselves up for disaster.  They would never to that in real life...  Hmm., then again maybe they would :-(</description>
		<content:encoded><![CDATA[<p>Very true.  I don&#8217;t understand why simple common sense measures are not taken.  I get the same feeling as when a character in a movie is obviously setting themselves up for disaster.  They would never to that in real life&#8230;  Hmm., then again maybe they would <img src='http://www.tomrafteryit.net/wp-includes/images/smilies/icon_sad.gif' alt=':-(' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anon</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114707</link>
		<dc:creator>Anon</dc:creator>
		<pubDate>Sat, 23 Feb 2008 17:00:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114707</guid>
		<description>You're being totally alarmist here. The reported vulnerability really has nothing to do with the loss of donor data in this case.

Look at the details of the attack - the window in which it has to occur is tiny. Somehow I doubt the thief chilled the DRAM and extracted the data within a few minutes. 

Now you might have reason to be concerned if the laptop was switched on, unlocked and the crypto keys had been entered when it was taken. Some casual snooping could lead to the data.</description>
		<content:encoded><![CDATA[<p>You&#8217;re being totally alarmist here. The reported vulnerability really has nothing to do with the loss of donor data in this case.</p>
<p>Look at the details of the attack - the window in which it has to occur is tiny. Somehow I doubt the thief chilled the DRAM and extracted the data within a few minutes. </p>
<p>Now you might have reason to be concerned if the laptop was switched on, unlocked and the crypto keys had been entered when it was taken. Some casual snooping could lead to the data.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven</title>
		<link>http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114691</link>
		<dc:creator>Steven</dc:creator>
		<pubDate>Fri, 22 Feb 2008 20:50:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.tomrafteryit.net/you-can-never-rely-on-encryption/#comment-114691</guid>
		<description>That data should never have left the building, nevermind the State, encrypted or otherwise. I'm curious to know whether the terms under which it was acquired from donors permits its use in software testing by third parties..

In the UK, at least, this is &lt;em&gt;streng verboten&lt;/em&gt;: http://www.theregister.co.uk/2006/03/14/unknown_data_protection_breach/</description>
		<content:encoded><![CDATA[<p>That data should never have left the building, nevermind the State, encrypted or otherwise. I&#8217;m curious to know whether the terms under which it was acquired from donors permits its use in software testing by third parties..</p>
<p>In the UK, at least, this is <em>streng verboten</em>: <a href="http://www.theregister.co.uk/2006/03/14/unknown_data_protection_breach/">http://www.theregister.co.uk/2006/03/14/unknown_data_protection_breach/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
