<?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: Jungle Disk</title>
	<atom:link href="http://www.jwsecure.com/dan/2008/08/28/jungle-disk/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jwsecure.com/dan/2008/08/28/jungle-disk/</link>
	<description>Security, information technology, business</description>
	<pubDate>Sun, 14 Mar 2010 20:12:42 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>By: JungleDave</title>
		<link>http://www.jwsecure.com/dan/2008/08/28/jungle-disk/#comment-850</link>
		<dc:creator>JungleDave</dc:creator>
		<pubDate>Fri, 29 Aug 2008 00:52:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.jwsecure.com/dan/2008/08/28/jungle-disk/#comment-850</guid>
		<description>The default to standard (SSL, no bucket password) security is simple: The greatest "risk" to most users is that they forget their password. When that happens there is no recovery and all data is lost. For those users who want added security and can take responsibility for remembering their password, that option is available.

Regarding MD5 for key generation - note that it does not simply use a hash of the password (which would limit the key size). Rather, MD5 is used as an input to a PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) key generation function, which allows you to extract as many bits of key data as needed (randomness limited only by the length of your pass phrase). Of course, most users have no where near 256 bits, or even 128 bits of randomness in their pass phrase, but we don't limit your choice in that area.</description>
		<content:encoded><![CDATA[<p>The default to standard (SSL, no bucket password) security is simple: The greatest &#8220;risk&#8221; to most users is that they forget their password. When that happens there is no recovery and all data is lost. For those users who want added security and can take responsibility for remembering their password, that option is available.</p>
<p>Regarding MD5 for key generation - note that it does not simply use a hash of the password (which would limit the key size). Rather, MD5 is used as an input to a PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) key generation function, which allows you to extract as many bits of key data as needed (randomness limited only by the length of your pass phrase). Of course, most users have no where near 256 bits, or even 128 bits of randomness in their pass phrase, but we don&#8217;t limit your choice in that area.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dan</title>
		<link>http://www.jwsecure.com/dan/2008/08/28/jungle-disk/#comment-849</link>
		<dc:creator>dan</dc:creator>
		<pubDate>Thu, 28 Aug 2008 18:55:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.jwsecure.com/dan/2008/08/28/jungle-disk/#comment-849</guid>
		<description>Well, the default lack of a user password is definitely the weakest link. If the user provides a password, it's still probably the weakest link, depending.

I'm uncomfortable with calling MD5 "excellent" or "a good choice" in any situation, cryptographic or otherwise, based on what's published, except as a compromise for backward-compatibility.

Also, when Jungle Disk switched to AES (I saw an early reference to RC4), MD5 became a bad choice even assuming its best-case collision space. That is, there's a 128-bit (at least) key space cipher with a 64-bit (effective) key space hash.

Most would agree that SHA-256 is currently the proper choice for supporting 128-bit keys. And it's supported by both .NET and OpenSSL.</description>
		<content:encoded><![CDATA[<p>Well, the default lack of a user password is definitely the weakest link. If the user provides a password, it&#8217;s still probably the weakest link, depending.</p>
<p>I&#8217;m uncomfortable with calling MD5 &#8220;excellent&#8221; or &#8220;a good choice&#8221; in any situation, cryptographic or otherwise, based on what&#8217;s published, except as a compromise for backward-compatibility.</p>
<p>Also, when Jungle Disk switched to AES (I saw an early reference to RC4), MD5 became a bad choice even assuming its best-case collision space. That is, there&#8217;s a 128-bit (at least) key space cipher with a 64-bit (effective) key space hash.</p>
<p>Most would agree that SHA-256 is currently the proper choice for supporting 128-bit keys. And it&#8217;s supported by both .NET and OpenSSL.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JungleDave</title>
		<link>http://www.jwsecure.com/dan/2008/08/28/jungle-disk/#comment-848</link>
		<dc:creator>JungleDave</dc:creator>
		<pubDate>Thu, 28 Aug 2008 18:14:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.jwsecure.com/dan/2008/08/28/jungle-disk/#comment-848</guid>
		<description>Thanks for the review! A note on the use of MD5 for key generation - MD5 has been shown to have collisions, which makes it bad for use as a cryptographic signing hash. However, as a hash algorithm it is still considered excellent, which makes it a good choice for key generation.</description>
		<content:encoded><![CDATA[<p>Thanks for the review! A note on the use of MD5 for key generation - MD5 has been shown to have collisions, which makes it bad for use as a cryptographic signing hash. However, as a hash algorithm it is still considered excellent, which makes it a good choice for key generation.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
