<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: RSA public keys are not private (implementation)</title>
	<atom:link href="http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/</link>
	<description>Embedded security, crypto, software protection</description>
	<lastBuildDate>Mon, 06 Feb 2012 20:16:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/comment-page-1/#comment-4852</link>
		<dc:creator><![CDATA[Nate Lawson]]></dc:creator>
		<pubDate>Tue, 16 Dec 2008 22:07:00 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/#comment-4852</guid>
		<description><![CDATA[Alan, thanks for the comment. You are right in the general case, but I am discussing a specific case where that does not apply. If the system designer chose &lt;em&gt;e&lt;/em&gt; randomly, then it would indeed be safe from brute-force guessing. But as you point out, such a system would be quite slow for both encryption and decryption, and a symmetric key would have been more appropriate.

The system I am describing chose &lt;em&gt;e&lt;/em&gt; to be fast for signature verification (i.e., much smaller than &lt;em&gt;d&lt;/em&gt;). (I think you get this, based on your last sentence.)This was because RSA was originally only used for signatures. Then the engineers later tried to add encryption by keeping (&lt;em&gt;e&lt;/em&gt;, &lt;em&gt;n&lt;/em&gt;) secret. In any case where &lt;em&gt;e&lt;/em&gt; is not chosen randomly but is much smaller than &lt;em&gt;d&lt;/em&gt;, it is subject to brute-force guessing and thus you can calculate &lt;em&gt;n&lt;/em&gt;. The engineers&#039; mistake was in thinking that &lt;em&gt;n&lt;/em&gt; can be kept secret in this case.

The &lt;a href=&quot;http://rdist.root.org/2007/05/01/rsa-public-keys-are-not-private/&quot; rel=&quot;nofollow&quot;&gt;first article&lt;/a&gt; in this series explained this in more detail.]]></description>
		<content:encoded><![CDATA[<p>Alan, thanks for the comment. You are right in the general case, but I am discussing a specific case where that does not apply. If the system designer chose <em>e</em> randomly, then it would indeed be safe from brute-force guessing. But as you point out, such a system would be quite slow for both encryption and decryption, and a symmetric key would have been more appropriate.</p>
<p>The system I am describing chose <em>e</em> to be fast for signature verification (i.e., much smaller than <em>d</em>). (I think you get this, based on your last sentence.)This was because RSA was originally only used for signatures. Then the engineers later tried to add encryption by keeping (<em>e</em>, <em>n</em>) secret. In any case where <em>e</em> is not chosen randomly but is much smaller than <em>d</em>, it is subject to brute-force guessing and thus you can calculate <em>n</em>. The engineers&#8217; mistake was in thinking that <em>n</em> can be kept secret in this case.</p>
<p>The <a href="http://rdist.root.org/2007/05/01/rsa-public-keys-are-not-private/" rel="nofollow">first article</a> in this series explained this in more detail.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan Braggins</title>
		<link>http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/comment-page-1/#comment-4847</link>
		<dc:creator><![CDATA[Alan Braggins]]></dc:creator>
		<pubDate>Fri, 05 Dec 2008 09:49:32 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/#comment-4847</guid>
		<description><![CDATA[&gt; It only expands the search time by 2^17

No, if you are going to try and keep the &quot;public&quot; exponent a secret, you make it the same sort of size as the private exponent and modulus, 2^1024 or larger.

This is unreasonable for normal usage, since it just makes verification pointlessly slow. And if you have to keep both halves secret at both ends of communication, why not just use a symmetric key? (In the example given, because they were trying to reuse an existing key intended only for signature, which is why it almost certainly does have a small public exponent.)]]></description>
		<content:encoded><![CDATA[<p>&gt; It only expands the search time by 2^17</p>
<p>No, if you are going to try and keep the &#8220;public&#8221; exponent a secret, you make it the same sort of size as the private exponent and modulus, 2^1024 or larger.</p>
<p>This is unreasonable for normal usage, since it just makes verification pointlessly slow. And if you have to keep both halves secret at both ends of communication, why not just use a symmetric key? (In the example given, because they were trying to reuse an existing key intended only for signature, which is why it almost certainly does have a small public exponent.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/comment-page-1/#comment-1201</link>
		<dc:creator><![CDATA[Nate Lawson]]></dc:creator>
		<pubDate>Fri, 04 May 2007 17:35:56 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/#comment-1201</guid>
		<description><![CDATA[Re: values of e -- doesn&#039;t matter for the attack if someone tried to choose a &quot;secret&quot; e that wasn&#039;t one of those 3 values.  It only expands the search time by 2^17 at most, even if you had to search every single reasonable value of e.  And those 3 values are the highest by far in use in both software and hardware.

I agree there is no need for n to be secret.  In fact, you&#039;re missing the whole point of these articles -- when using n with signatures, it NEVER CAN be kept secret, even if you wanted to.  Perhaps you missed the previous article where the vendor was expecting to keep n secret and use (e, n) for encryption as well as signature verification.  Here&#039;s the link again:

http://rdist.root.org/2007/05/01/rsa-public-keys-are-not-private/]]></description>
		<content:encoded><![CDATA[<p>Re: values of e &#8212; doesn&#8217;t matter for the attack if someone tried to choose a &#8220;secret&#8221; e that wasn&#8217;t one of those 3 values.  It only expands the search time by 2^17 at most, even if you had to search every single reasonable value of e.  And those 3 values are the highest by far in use in both software and hardware.</p>
<p>I agree there is no need for n to be secret.  In fact, you&#8217;re missing the whole point of these articles &#8212; when using n with signatures, it NEVER CAN be kept secret, even if you wanted to.  Perhaps you missed the previous article where the vendor was expecting to keep n secret and use (e, n) for encryption as well as signature verification.  Here&#8217;s the link again:</p>
<p><a href="http://rdist.root.org/2007/05/01/rsa-public-keys-are-not-private/" rel="nofollow">http://rdist.root.org/2007/05/01/rsa-public-keys-are-not-private/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: LibX</title>
		<link>http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/comment-page-1/#comment-1193</link>
		<dc:creator><![CDATA[LibX]]></dc:creator>
		<pubDate>Fri, 04 May 2007 09:33:28 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/#comment-1193</guid>
		<description><![CDATA[&quot;e is almost always 3, 17, or 65537&quot; -&gt; based on who&#039;s experience?
there is not need to use this value u can use other values also.

&quot;only d and n are actually secrets&quot;  -&gt; there is not need for N to be secret at all its a public value as long as it big enough there isn&#039;t a single problem.]]></description>
		<content:encoded><![CDATA[<p>&#8220;e is almost always 3, 17, or 65537&#8243; -&gt; based on who&#8217;s experience?<br />
there is not need to use this value u can use other values also.</p>
<p>&#8220;only d and n are actually secrets&#8221;  -&gt; there is not need for N to be secret at all its a public value as long as it big enough there isn&#8217;t a single problem.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

