<?xml version="1.0" encoding="iso-8859-1" ?>
<rss version="2.0">
  <channel>
    <title>2010 Reports</title>
    <link>http://eprint.iacr.org/forum/list.php?10</link>
    <description><![CDATA[Discussion forum for Cryptology ePrint Archive reports posted in 2010.
Please put the report number in the subject.

]]></description>
    <language>EN</language>
    <pubDate>Fri, 13 Aug 2010 07:59:31 -0600</pubDate>
    <lastBuildDate>Fri, 13 Aug 2010 07:59:31 -0600</lastBuildDate>
    <category>2010 Reports</category>
    <generator>Phorum 5.1.22</generator>
    <ttl>600</ttl>
    <item>
      <title>Re: 2010/430 is right but so wrong</title>
      <link>http://eprint.iacr.org/forum/read.php?10,287,293#msg-293</link>
      <author>Orr</author>
      <description><![CDATA[Danilo,

Your are entitled to your opinion. But narrow pipe designs are more efficient, and their security is clearly defined (the discussion on the hash function mailing list can probably explain why the paper is technically right, but so wrong, for example, the security proofs assume less than birthday-paradox number of queries to the _compression function_, your attack makes more than that queries).]]></description>
      <category>2010 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?10,287,293#msg-293</guid>
      <pubDate>Fri, 13 Aug 2010 07:59:31 -0600</pubDate>
    </item>
    <item>
      <title>Re: 2010/430 is right but so wrong</title>
      <link>http://eprint.iacr.org/forum/read.php?10,287,291#msg-291</link>
      <author>gligoroski</author>
      <description><![CDATA[Designers of narrow-pipe hash functions can ignore the facts that those designs are inferior to wide-pipe designs. Its their choice.

“Know the enemy and know yourself; in a hundred battles you will never be in peril. When you are ignorant of the enemy, but know yourself, your chances of winning or losing are equal. If ignorant both of your enemy and yourself, you are certain in every battle to be in peril.&quot;, Sun Tzu.

Regards,
Danilo!]]></description>
      <category>2010 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?10,287,291#msg-291</guid>
      <pubDate>Sun, 08 Aug 2010 23:38:24 -0600</pubDate>
    </item>
    <item>
      <title>Re: 2010/430 is right but so wrong</title>
      <link>http://eprint.iacr.org/forum/read.php?10,287,289#msg-289</link>
      <author>Vlastimil Klima</author>
      <description><![CDATA[Orr, 
you mix theory and practice, hash function 
and compression functions together. 
We even underlined the difference between 
hash function calls and compression 
function calls in the paper. 

You wrote: &quot;I explain why the results of 
this paper are right but not interesting.&quot; 
Well, so here is an interesting game for you.

Let us have a SHA3 winner.

Let there are two casinos. In both casinos 
they play the same game: the players are 
buying cards for one cent 
(the card has a 256bit number) until they 
find two cards with the same number. 
Once a player present such a collision, 
he/she win all the money from both casinos. 

In the first/second casino, 
the cards are numbered using SHA3/SHA2 
and the method and the messages, 
described in our eprint paper. 

Even if I don't know how long messages 
they used for producing the cards, 
even if I don't know what is SHA3 winner, 
even if I don't know its compression function,...
I would go to the first casino.

Vlastimil Klima]]></description>
      <category>2010 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?10,287,289#msg-289</guid>
      <pubDate>Thu, 05 Aug 2010 17:01:25 -0600</pubDate>
    </item>
    <item>
      <title>2010/430 is right but so wrong</title>
      <link>http://eprint.iacr.org/forum/read.php?10,287,287#msg-287</link>
      <author>Orr</author>
      <description><![CDATA[The authors of 2010/430 claim that finding collisions in a narrow-pipe takes 2^{n/2-k/2} calls for the _hash function_, which is lower than 2^n/2 expected by the birthday bound.

However, the colliding messages are 2^k long, meaning that the amount of work is 2^{n/2+k/2} _compression function_ calls.

As finding a collision in any of the discussed hash functions can be easily done once a collision in the compression function is found, then using the results of the paper is not only wrong, but misleading, as one can easily find a collision in the above mentioned hash functions using only 2^n/2 compression function calls.]]></description>
      <category>2010 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?10,287,287#msg-287</guid>
      <pubDate>Thu, 05 Aug 2010 13:28:35 -0600</pubDate>
    </item>
  </channel>
</rss>
