<?xml version="1.0" encoding="iso-8859-1"?><!-- generator="b2evolution/2.4.0-rc2" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>EnRUPT &#8211; The Simpler The Better - Latest comments on &#239;rRUPT64x2/H</title>
		<link>http://www.enrupt.com/index.php?disp=comments</link>
		<description></description>
		<language>en-AU</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=2.4.0-rc2"/>
		<ttl>60</ttl>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Fri, 12 Dec 2008 13:29:31 +0000</pubDate>
			<dc:creator>Sean O&#8217;Neil [Member]</dc:creator>
			<guid isPermaLink="false">c87@http://www.enrupt.com/</guid>
			<description>&gt; It is instructive to compare your and Greg Rose's responses to having your hash broken.&lt;br /&gt;
&lt;br /&gt;
Yes it is. It is also very instructive to compare the two hashes and the attacks. Greg Rose&amp;#8217;s hash has no tunable parameter and requires major structural changes to protect against the attack. Contrary to that, EnRUPT was submitted with a security parameter &lt;em&gt;s&lt;/em&gt;, requiring only a few extra rounds to defend against such class of attacks. In that light, EnRUPT cannot even be considered or called broken, only 8 rounds of it are broken. 5 rounds of Rijndael are broken, and nobody is complaining about Rijndael with 10.&lt;br /&gt;
&lt;br /&gt;
Naturally, Greg Rose does not want people to waste any more time on his hash since it cannot be easily fixed, while I insist that it is premature to declare EnRUPT broken trying to dismiss it, no matter how much you hate it as one of your competitors. EnRUPT simply does not need any fixing, only tuning the tunable parameter requested by NIST to increase its security. All the attacks must take all the parameters into consideration before claiming EnRUPT to be broken.&lt;br /&gt;</description>
			<content:encoded><![CDATA[> It is instructive to compare your and Greg Rose's responses to having your hash broken.<br />
<br />
Yes it is. It is also very instructive to compare the two hashes and the attacks. Greg Rose&#8217;s hash has no tunable parameter and requires major structural changes to protect against the attack. Contrary to that, EnRUPT was submitted with a security parameter <em>s</em>, requiring only a few extra rounds to defend against such class of attacks. In that light, EnRUPT cannot even be considered or called broken, only 8 rounds of it are broken. 5 rounds of Rijndael are broken, and nobody is complaining about Rijndael with 10.<br />
<br />
Naturally, Greg Rose does not want people to waste any more time on his hash since it cannot be easily fixed, while I insist that it is premature to declare EnRUPT broken trying to dismiss it, no matter how much you hate it as one of your competitors. EnRUPT simply does not need any fixing, only tuning the tunable parameter requested by NIST to increase its security. All the attacks must take all the parameters into consideration before claiming EnRUPT to be broken.<br />]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c87</link>
		</item>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Fri, 12 Dec 2008 08:04:06 +0000</pubDate>
			<dc:creator>A non a mouse [Visitor]</dc:creator>
			<guid isPermaLink="false">c86@http://www.enrupt.com/</guid>
			<description>&gt; Are we looking for a good algorithm or are we &lt;br /&gt;
&gt; looking to get rid of all the most competitive &lt;br /&gt;
&gt; algorithms as quickly as possible?&lt;br /&gt;
&lt;br /&gt;
It is instructive to compare your and Greg Rose's responses to having your hash broken.</description>
			<content:encoded><![CDATA[> Are we looking for a good algorithm or are we <br />
> looking to get rid of all the most competitive <br />
> algorithms as quickly as possible?<br />
<br />
It is instructive to compare your and Greg Rose's responses to having your hash broken.]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c86</link>
		</item>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Tue, 25 Nov 2008 15:07:07 +0000</pubDate>
			<dc:creator>Sean O&#8217;Neil [Member]</dc:creator>
			<guid isPermaLink="false">c85@http://www.enrupt.com/</guid>
			<description>Dear anonymous coward,&lt;br /&gt;
&lt;br /&gt;
&quot;algorithms that specify the number of rounds as a parameter&quot; makes no sense. It is either a specific number or a variable parameter. In case of EnRUPT it is a parameter, not a specified constant.&lt;br /&gt;
&lt;br /&gt;
The measurements of complexity of linearization were incorrectly transferred from block hashing to stream hashing. We do not say that &lt;em&gt;s&lt;/em&gt; has to be at least 8, even for stream hashing. It is still at least 2 for block hashing and for stream ciphers. For collision resistance it probably has to be at least 5 for &lt;em&gt;w&lt;/em&gt;=32 and at least 7 for &lt;em&gt;w&lt;/em&gt;=64. We recommend a slightly higher value for &lt;em&gt;s&lt;/em&gt; to guarantee a sufficiently high change in the state between the inputs.&lt;br /&gt;
&lt;br /&gt;
No matter how much you want to see EnRUPT removed from the competition, it is still incorrect to call the entire EnRUPT family, its &amp;#239;rRUPT mode and even more specifically &amp;#239;rRUPT64x2-256/s broken. No one has pointed out a structural weakness in any of them, merely an attack against 8 rounds of &amp;#239;rRUPT64x2 (&lt;em&gt;s&lt;/em&gt;=4). The future versions of its specification will be updated accordingly. It is not even known if EnRUPT is going to be accepted in the competition yet, so your verbal attacks are premature.&lt;br /&gt;</description>
			<content:encoded><![CDATA[Dear anonymous coward,<br />
<br />
"algorithms that specify the number of rounds as a parameter" makes no sense. It is either a specific number or a variable parameter. In case of EnRUPT it is a parameter, not a specified constant.<br />
<br />
The measurements of complexity of linearization were incorrectly transferred from block hashing to stream hashing. We do not say that <em>s</em> has to be at least 8, even for stream hashing. It is still at least 2 for block hashing and for stream ciphers. For collision resistance it probably has to be at least 5 for <em>w</em>=32 and at least 7 for <em>w</em>=64. We recommend a slightly higher value for <em>s</em> to guarantee a sufficiently high change in the state between the inputs.<br />
<br />
No matter how much you want to see EnRUPT removed from the competition, it is still incorrect to call the entire EnRUPT family, its &#239;rRUPT mode and even more specifically &#239;rRUPT64x2-256/s broken. No one has pointed out a structural weakness in any of them, merely an attack against 8 rounds of &#239;rRUPT64x2 (<em>s</em>=4). The future versions of its specification will be updated accordingly. It is not even known if EnRUPT is going to be accepted in the competition yet, so your verbal attacks are premature.<br />]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c85</link>
		</item>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Tue, 25 Nov 2008 14:15:48 +0000</pubDate>
			<dc:creator>Anonymous Coward [Visitor]</dc:creator>
			<guid isPermaLink="false">c84@http://www.enrupt.com/</guid>
			<description>So algorithms that specify the number of rounds as a parameter are not broken? Even if they recommond wrong parameters?&lt;br /&gt;
&lt;br /&gt;
It is up to the designer of the algorithm to pick the correct parameters (tradeoff between security and performance). You made a wrong choice.&lt;br /&gt;
&lt;br /&gt;
In your specification you wrote: &quot;Therefore, in order to be able to break &amp;#239;rRUPT faster than 2^h, the attacker must be able to approximate each arithmetic adder at a cost of less than w/4&amp;#8901;(s&amp;#8211;1) bits, which is highly unlikely even for s=2.&quot; Now it turns out s has to be at least 8...</description>
			<content:encoded><![CDATA[So algorithms that specify the number of rounds as a parameter are not broken? Even if they recommond wrong parameters?<br />
<br />
It is up to the designer of the algorithm to pick the correct parameters (tradeoff between security and performance). You made a wrong choice.<br />
<br />
In your specification you wrote: "Therefore, in order to be able to break &#239;rRUPT faster than 2^h, the attacker must be able to approximate each arithmetic adder at a cost of less than w/4&#8901;(s&#8211;1) bits, which is highly unlikely even for s=2." Now it turns out s has to be at least 8...]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c84</link>
		</item>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Tue, 25 Nov 2008 10:13:13 +0000</pubDate>
			<dc:creator>Sean O&#8217;Neil [Member]</dc:creator>
			<guid isPermaLink="false">c83@http://www.enrupt.com/</guid>
			<description>Dear anonymous coward,&lt;br /&gt;
&lt;br /&gt;
1. No changes need to be made to EnRUPT submitted as EnRUPT[&lt;em&gt;w&lt;/em&gt;]x[P]/[&lt;em&gt;s&lt;/em&gt;] and so far not broken as such.&lt;br /&gt;
&lt;br /&gt;
2. Whether EnRUPT is in or out of the competition, it is up to NIST to decide, NOT you. However, your bitterness is understandable. EnRUPT is too competitive. Many submitters are eager to see it out of their way.&lt;br /&gt;
&lt;br /&gt;
3. You are shooting in the dark obviously without any knowledge of Boole structure or the attack. Boole has no tunable parameters, it is submitted fixed at 16 mixing rounds. The Boole attack also exploits a structural flaw that cannot be fixed with extra rounds. So, yes, I am sure.&lt;br /&gt;</description>
			<content:encoded><![CDATA[Dear anonymous coward,<br />
<br />
1. No changes need to be made to EnRUPT submitted as EnRUPT[<em>w</em>]x[P]/[<em>s</em>] and so far not broken as such.<br />
<br />
2. Whether EnRUPT is in or out of the competition, it is up to NIST to decide, NOT you. However, your bitterness is understandable. EnRUPT is too competitive. Many submitters are eager to see it out of their way.<br />
<br />
3. You are shooting in the dark obviously without any knowledge of Boole structure or the attack. Boole has no tunable parameters, it is submitted fixed at 16 mixing rounds. The Boole attack also exploits a structural flaw that cannot be fixed with extra rounds. So, yes, I am sure.<br />]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c83</link>
		</item>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Tue, 25 Nov 2008 09:18:14 +0000</pubDate>
			<dc:creator>Anonymous Coward [Visitor]</dc:creator>
			<guid isPermaLink="false">c82@http://www.enrupt.com/</guid>
			<description>NIST is quite clear: &quot;NIST will refuse to accept changes that seem to be responses to attacks, even if an attack can be blocked by a very simple change, unless there is a convincing argument that the attack is only the result of a typo in the first place.&quot;&lt;br /&gt;
&lt;br /&gt;
Face it. You are out of the competition!&lt;br /&gt;
&lt;br /&gt;
Are you sure Boole can not be patched by doubling the amount of rounds?</description>
			<content:encoded><![CDATA[NIST is quite clear: "NIST will refuse to accept changes that seem to be responses to attacks, even if an attack can be blocked by a very simple change, unless there is a convincing argument that the attack is only the result of a typo in the first place."<br />
<br />
Face it. You are out of the competition!<br />
<br />
Are you sure Boole can not be patched by doubling the amount of rounds?]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c82</link>
		</item>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Tue, 25 Nov 2008 07:58:51 +0000</pubDate>
			<dc:creator>Ilya [Visitor]</dc:creator>
			<guid isPermaLink="false">c81@http://www.enrupt.com/</guid>
			<description>Hope so. Let see a NIST verdict first anyway.</description>
			<content:encoded><![CDATA[Hope so. Let see a NIST verdict first anyway.]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c81</link>
		</item>
				<item>
			<title>In response to: &#239;rRUPT64x2/H</title>
			<pubDate>Tue, 25 Nov 2008 06:55:55 +0000</pubDate>
			<dc:creator>Sean O&#8217;Neil [Member]</dc:creator>
			<guid isPermaLink="false">c80@http://www.enrupt.com/</guid>
			<description>The SHA-3 organizers have improved the competition since the AES. They do differentiate that for NIST purposes now, which is why they have requested a tunable security/performance parameter. EnRUPT submission is not broken. What is broken is only the initially recommended s=4 variant. It is not yet broken even for s=5 or s=8, what to talk about the currently recommended s=H. That is contrary to Boole, Sg&amp;#224;il, HASH 2X, NKS2D or WaMM, which are broken exploiting structural flaws and cannot be cured with a few extra rounds or simply do not have a tunable security/performance parameter at all.</description>
			<content:encoded><![CDATA[The SHA-3 organizers have improved the competition since the AES. They do differentiate that for NIST purposes now, which is why they have requested a tunable security/performance parameter. EnRUPT submission is not broken. What is broken is only the initially recommended s=4 variant. It is not yet broken even for s=5 or s=8, what to talk about the currently recommended s=H. That is contrary to Boole, Sg&#224;il, HASH 2X, NKS2D or WaMM, which are broken exploiting structural flaws and cannot be cured with a few extra rounds or simply do not have a tunable security/performance parameter at all.]]></content:encoded>
			<link>http://www.enrupt.com/index.php/2008/11/23/irrupt64x2-h#c80</link>
		</item>
			</channel>
</rss>
