<?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: Password Entropy</title>
	<atom:link href="http://spiresecurity.com/?feed=rss2&#038;p=669" rel="self" type="application/rss+xml" />
	<link>http://spiresecurity.com/?p=669</link>
	<description>Risk and Cybersecurity Analysis</description>
	<lastBuildDate>Wed, 21 Aug 2013 23:28:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Scott Wright</title>
		<link>http://spiresecurity.com/?p=669&#038;cpage=1#comment-906</link>
		<dc:creator>Scott Wright</dc:creator>
		<pubDate>Tue, 30 Jan 2007 03:41:57 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=669#comment-906</guid>
		<description><![CDATA[Just a comment on the problem of converting a password to a cryptographic key.  I have some experience with the Entrust Public Key Infrastructure product.  It&#039;s a bit more complex in terms of the process of going from a password to a crypto key.

First, you have to realize that Entrust uses something they call an Entrust Profile, which is a file that contains some plaintext data and some encrypted data.  In order to use a cryptographic key pair for encrypting or decrypting a symmetric key (which is randomly generated using strictly governed algorithms certified by the government), you have to decrypt the private (or secret) part of the public key pair (also generated in a similar random fashion).

The interesting and relevant part of the process (to this blog post anyway) is that the password you choose is hashed something like 10,000 times, every time it is used to decrypt the profile to access the private key.  It makes for a pretty good random distribution of bits witin a fixed hash size.  Certainly, not all products go to this extreme to ensure that passwords are not subject to attack due to the problem you describe above.

Entrust does enforce strong passwords with a configurable policy; with more settings than you&#039;ll probably ever need (eg. percent of password that can be repeated in substrings, etc.).

I don&#039;t know if that adds value or not, but at least some of us care!
]]></description>
		<content:encoded><![CDATA[<p>Just a comment on the problem of converting a password to a cryptographic key.  I have some experience with the Entrust Public Key Infrastructure product.  It&#8217;s a bit more complex in terms of the process of going from a password to a crypto key.</p>
<p>First, you have to realize that Entrust uses something they call an Entrust Profile, which is a file that contains some plaintext data and some encrypted data.  In order to use a cryptographic key pair for encrypting or decrypting a symmetric key (which is randomly generated using strictly governed algorithms certified by the government), you have to decrypt the private (or secret) part of the public key pair (also generated in a similar random fashion).</p>
<p>The interesting and relevant part of the process (to this blog post anyway) is that the password you choose is hashed something like 10,000 times, every time it is used to decrypt the profile to access the private key.  It makes for a pretty good random distribution of bits witin a fixed hash size.  Certainly, not all products go to this extreme to ensure that passwords are not subject to attack due to the problem you describe above.</p>
<p>Entrust does enforce strong passwords with a configurable policy; with more settings than you&#8217;ll probably ever need (eg. percent of password that can be repeated in substrings, etc.).</p>
<p>I don&#8217;t know if that adds value or not, but at least some of us care!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
