<?xml version="1.0" encoding="iso-8859-1" ?>
<rss version="2.0">
  <channel>
    <title>Cryptology ePrint Archive Forum</title>
    <link>http://eprint.iacr.org/forum/index.php</link>
    <description><![CDATA[]]></description>
    <language>EN</language>
    <pubDate>Wed, 01 Jul 2009 06:22:04 -0600</pubDate>
    <lastBuildDate>Wed, 01 Jul 2009 06:22:04 -0600</lastBuildDate>
    <category>Cryptology ePrint Archive Forum</category>
    <generator>Phorum 5.1.22</generator>
    <ttl>600</ttl>
    <item>
      <title>[2009 Reports] 134</title>
      <link>http://eprint.iacr.org/forum/read.php?9,134,134#msg-134</link>
      <author>Krause</author>
      <description><![CDATA[Dear Authors of report 2009/134,

I think that in the proof of your main theorem (Theorem 1, section 3, p.7,8 there is a bug. Equation (6) at page 8 has to be g=g_1 and not g=(1+x_k)g_1 as putting g_1=g_2 into Equation (5) yields g=g_1.

But then deg(g)=deg(g_1) and your inductive argument fails.

Can you repair this?

Best regards

Matthias]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,134,134#msg-134</guid>
      <pubDate>Wed, 01 Jul 2009 06:22:04 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] Re: 2009/049</title>
      <link>http://eprint.iacr.org/forum/read.php?9,73,133#msg-133</link>
      <author>Khoongming</author>
      <description><![CDATA[Hi Joe,

Thanks for your question. 

There was an error in a previous version of our paper. The number of keystream needed in the attack on Toyocrypt should be 128 bits from each of 4 (or 8) re-synchronizations, that is 512 (or 1024) bits in total.

This has been corrected in our latest version.

Thanks,
Khoongming.]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,73,133#msg-133</guid>
      <pubDate>Thu, 18 Jun 2009 19:51:44 -0600</pubDate>
    </item>
    <item>
      <title>[General] Re: RSS feeds</title>
      <link>http://eprint.iacr.org/forum/read.php?2,130,132#msg-132</link>
      <author>Rafik</author>
      <description><![CDATA[Never mind, it's just that the service is unpredictable...]]></description>
      <category>General</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?2,130,132#msg-132</guid>
      <pubDate>Fri, 12 Jun 2009 22:10:36 -0600</pubDate>
    </item>
    <item>
      <title>[General] RSS feeds</title>
      <link>http://eprint.iacr.org/forum/read.php?2,130,130#msg-130</link>
      <author>Rafik</author>
      <description><![CDATA[Hello,

Who is in charge of the RSS feeds? All of them (1.0/2.0/atom1.0) seem broken :-( IS there something wrong with the server or am I just doing something wrong?]]></description>
      <category>General</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?2,130,130#msg-130</guid>
      <pubDate>Thu, 04 Jun 2009 02:16:13 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] Re: 2009/127</title>
      <link>http://eprint.iacr.org/forum/read.php?9,76,90#msg-90</link>
      <author>Orr</author>
      <description><![CDATA[Dear Cramer_vs_Cramer,

Most call for papers for IACR venues allow this line of fast dissemination of knowledge.

It is a shame that someone accuses &quot;famous cryptographers&quot; in trying to bias the review process, without taking into consideration the importance of fast dissemination (and to some extent also the time stamping feature eprint offers)!!!]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,76,90#msg-90</guid>
      <pubDate>Wed, 13 May 2009 14:41:51 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] Re: 2009/033</title>
      <link>http://eprint.iacr.org/forum/read.php?9,72,89#msg-89</link>
      <author>Orr</author>
      <description><![CDATA[A difference in the MSB, affects only other MSBs.

(in other words - the MSBs do not affect any other bit but the MSBs).

And for a given message (just fix the 31 LSBs of each message word and the entire chaining value), the MSBs of the eight output chaining value are a linear combination of the 16 message MSBs.

Because this is the case, it is easy to find collisions (just solve the required linear equations), second preimages (given a specific input to the compression function, flip the correct MSBs to obtain the same output).

Also, using the De Canniere and Rechberger attack from Crypto 2006, it is possible to find preimages of the compression function in time complexity of about 32*2^8.

(some of these observations were verified by Tor).]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,72,89#msg-89</guid>
      <pubDate>Wed, 13 May 2009 14:36:18 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] Re: 2009/033</title>
      <link>http://eprint.iacr.org/forum/read.php?9,72,88#msg-88</link>
      <author>yesmaeili</author>
      <description><![CDATA[I got from the point claimed by Orr that collision attack or/and a second preimage attack can be easily done. I would be appreciate Orr if he explains more.
Is your points related to the weaknesses properties of T-Functions?]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,72,88#msg-88</guid>
      <pubDate>Thu, 30 Apr 2009 03:10:59 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/177</title>
      <link>http://eprint.iacr.org/forum/read.php?9,87,87#msg-87</link>
      <author>gligoroski</author>
      <description><![CDATA[I am wondering what is the relation between &quot;H being preimage aware&quot; and &quot;H being second-preimage resistant&quot;?
Which one is more general and which one induce the other?
In the paper I can not find this issues addressed, and I think these questions are important since the term &quot;second-preimage resistance&quot; has been known for a long time.]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,87,87#msg-87</guid>
      <pubDate>Sun, 26 Apr 2009 00:52:24 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Shamir's Cube attack == My AIDA attack ! !!!</title>
      <link>http://eprint.iacr.org/forum/read.php?8,59,86#msg-86</link>
      <author>Vielhaber</author>
      <description><![CDATA[@Skeptic:
Maybe, we should continue by eMail: vielhaber At gmail.com

First, the forms are *always* sparse, when linear
(see my forthcoming paper)

Anyway, you will identify ANY linear form in 81+ simulations:
You may use any random key and get the hypercube sum, 0 or 1. Repeat this 81+ times, and you get a system of 81 equations in 81 unknowns c_0,c_1..c_80 in {0,1}.

You pretend \sum_i=0..80 c_i k_i = hypercube sum (with &quot;k_0&quot;=1, the constant term), where the k_i of each simulation fill one row of the matrix (A), the result is the corresponding right hand side (b).

So, you can resolve Ac=b -&gt; c=A^(-1)b (Gauss) and obtain the c_i, hence the precise linear form (which you should certainly check against more keys),
else you get a contradiction, ergo not linear.

See you in Cologne?]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,59,86#msg-86</guid>
      <pubDate>Tue, 21 Apr 2009 09:34:47 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Shamir's Cube attack == My AIDA attack ! !!!</title>
      <link>http://eprint.iacr.org/forum/read.php?8,59,85#msg-85</link>
      <author>Skeptic</author>
      <description><![CDATA[OK, for sparse equations but in a more general way, if a particular unique non sparse linear form exist for random coefficients,the AIDA dont find it.

For what I understood AIDA is:
-choose IV set
-make the summing
-test for K_i= 1 to 80 if Ki=form
While Cube attack is
-chooseIV set
-make the summing
-test the linearity
-if OK identify implied variables
-identify linear form


For example if there is a unique  linear form of 40 non null coefficients of the key, you have Binomial(80,40) linear forms to test exhaustively with AIDA, while with cube attack its only 40. This is not linear gain.

But in Trivium, Forms are sparse so AIDA~Cube in this case.

This is an example where AIDA fails, and Cube attack succeeds :

-take the original trivium specification
-replace the key/iv copy by a linear introduction with some LFSR  to mix the key terms a large number of times.

Now the forms in ANF are non sparse.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,59,85#msg-85</guid>
      <pubDate>Tue, 21 Apr 2009 03:22:08 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Shamir's Cube attack == My AIDA attack ! !!!</title>
      <link>http://eprint.iacr.org/forum/read.php?8,59,84#msg-84</link>
      <author>Vielhaber</author>
      <description><![CDATA[@Skeptic:

You certainly may do linear algebra and get away with 80+\varepsilon, on average 81, simulations (given that Trivium has 80 key bits).

BLR, as described by D&amp;S, requires 4 simulations per 1 BLR test, and with 2 BLR tests on average, you need 8 simulations instead of 81.

This accelerates the SAME attack by a factor of 10.
This is nice, CPU-time-wise.

This does not constitute a novel attack though.

Had they called the paper &quot;Fast implementation of AIDA&quot;, my heartfelt congratulations. 
As it is, it is plagiarism.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,59,84#msg-84</guid>
      <pubDate>Mon, 20 Apr 2009 14:08:19 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Shamir's Cube attack == My AIDA attack ! !!!</title>
      <link>http://eprint.iacr.org/forum/read.php?8,59,83#msg-83</link>
      <author>Skeptic</author>
      <description><![CDATA[I read your article before the introduction of the cube attack by Shamir. It is very interesting, but it lacks one thing.

The main difference is that your article doesn't clearly state how to check the linearity of the function obtained after applying the summing. 

At the other side,the &quot;momomial degree test&quot; introduced by Khazaei, tests the linearity without identifying the linear form.

Shamir made the synthesis.

After reading your article I was able to check exhaustively by testing each key bit for a given summing set if k_i= \sum_IV Cipher(X). The cube attack is more effective, first find a linear form, then identify it. Maybe was it trivial for you, not for the reader.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,59,83#msg-83</guid>
      <pubDate>Thu, 16 Apr 2009 08:10:29 -0600</pubDate>
    </item>
    <item>
      <title>[2006 Reports] 2006/468</title>
      <link>http://eprint.iacr.org/forum/read.php?6,82,82#msg-82</link>
      <author>Skeptic</author>
      <description><![CDATA[The subject and the methods introduce in the article are of high interest. I'm still currently working on it and I have a question about the perturbation polynomial. 

1) Perturbation polynomial :

The construction implies the use of a multivariate polynomial. However in the AES system (part S), the equations for one round are multivariate but with univariate monomials. So if some multivariate monomials are used in the construction of Qf (as stated in the previous article[5]), the equation implied by Qf are founded by inspection,ie the permutation pi_1 of M_1 is ineffective. Or do I miss something?]]></description>
      <category>2006 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?6,82,82#msg-82</guid>
      <pubDate>Thu, 16 Apr 2009 07:57:46 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] A Stream C without IV</title>
      <link>http://eprint.iacr.org/forum/read.php?9,80,81#msg-81</link>
      <author>Skeptic</author>
      <description><![CDATA[PS: article 2009/29]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,80,81#msg-81</guid>
      <pubDate>Thu, 16 Apr 2009 05:40:58 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/29</title>
      <link>http://eprint.iacr.org/forum/read.php?9,80,80#msg-80</link>
      <author>Skeptic</author>
      <description><![CDATA[The proposed cipher is an 'enhancement' of the previous Henkos cipher which is broken by a resynchronization attack.

This cipher doesn't have an IV, thus cannot be subject to differential attacks.

In a cipher without IV, the key may only be used once.

Please don't waste time and don't add noise to the server by posting a cryptanalysis.]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,80,80#msg-80</guid>
      <pubDate>Thu, 16 Apr 2009 05:39:26 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/081</title>
      <link>http://eprint.iacr.org/forum/read.php?9,79,79#msg-79</link>
      <author>alpkup</author>
      <description><![CDATA[The paper uses many techniques from previous work of Ateniese et al. without properly acknowledging it. Furthermore, there are no cryptographic security proofs. Lastly, even though the blocks of the file can be updated within the scheme, the use of error-correcting codes make any updates on the file change (almost) the whole encoding, thus rendering an updateable scheme useless.

The application to cloud storage scenario is good, but there is not enough comparison with previous work. More specifically, there is not a satisfactory discussion of why previous POR and PDP schemes cannot be applied straightforwardly to the cloud storage setting (instead of a single-server setting).

I suggest humbly that the authors should address such concerns.]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,79,79#msg-79</guid>
      <pubDate>Thu, 02 Apr 2009 20:19:10 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] Re: 2009/137 (Kiev card, par. 4.4)</title>
      <link>http://eprint.iacr.org/forum/read.php?9,77,78#msg-78</link>
      <author>roel</author>
      <description><![CDATA[Hey Nicolas,

Interesting attack you describe. I'll try to look more carefully at the details soon.

The cards that always respond are probably not manufactured by NXP. They seem to be cheap unlicensed MIFARE Classic clones. In this post you will find an overview of the 5 available clones that I was able to track down. http://www.proxmark.org/forum/topic/169/mifare-classic-clones/
Personally I have some Fudan FM11RF08 tags (which have this &quot;always-answer-on-auth-failure&quot; problem).

Maybe it is useful to know that MIFARE Classic cards only support the ISO14443A standard up to level 3 (not 4, where the ATS/ATR is described). This means that tools often simulate a (dummy) ATS for cards that do not support this. Original and clone cards are distinguishable though, let me sum up some ways.

- A genuine card will answer to a 7bits frame 0x0E (like the REQA/WUPA message), don't ask me why, but clones will not.
- You can authenticate and communicate to a clone card with incorrect parities, as long as you keep the CRC ok, you can send any parities you want. A genuine card will not accept this.
- The timing is different. The MIFARE Clones seem to be more vulnerable to timing side-channel attacks, while genuine cards are more constant in answering.
- The random number generator seems to be iterating different (slower?) on clones.
...
I've found more differences, let me know if you are interested in them, so I can dig them up for ya ;).

Kind regards,

  Roel Verdult
  Radboud University Nijmegen]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,77,78#msg-78</guid>
      <pubDate>Mon, 30 Mar 2009 15:56:43 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/137 (Kiev card, par. 4.4)</title>
      <link>http://eprint.iacr.org/forum/read.php?9,77,77#msg-77</link>
      <author>tomas_rosa</author>
      <description><![CDATA[First of all – nice work!

Having read the paper, I have a note on the identifier of the Kiev cards. It’s stated that these cards are indistinguishable from any other card. However, to support that, the ATR string is presented. It is worth noting that ATR is by no means a precise description of a contactless card, as this is a “synthetic” value compiled especially for the purpose of PC/SC interface layer to allow the contactless card appear as an ordinary (contact) smartcard for the rest of the operating system.

Considerably more precise description would be the values of ATQA and SAK strings that are transmitted during the mandatory anti-collision procedure of ISO 14443A. If it was a contactless *smartcard* then the ATS (‘S’ not ‘R’ at the end) string would also be important (btw. ATR is a certain loose translation of those values here). Knowing ATQA and SAK, it could be easier to determine what the Kiev card is. Perhaps, it can be a MIFARE Classic emulation embedded into some contactless smartcard (i.e. a more sophisticated card emulating MF Classic for a backward compatibility), etc.

It’s a bit difficult to describe how to obtain ATQA/SAK in a nutshell here, but basing on what I have just read, I am sure that the author or his supporting technicians will know how to do that.

Kind regards,
Tomas Rosa]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,77,77#msg-77</guid>
      <pubDate>Fri, 27 Mar 2009 05:16:19 -0600</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/127</title>
      <link>http://eprint.iacr.org/forum/read.php?9,76,76#msg-76</link>
      <author>Cramer_vs_Cramer</author>
      <description><![CDATA[Side Channel Cube Attacks on Block Ciphers
Itai Dinur and Adi Shamir

Publication Info: Submitted to CHES 2009
Date: received 18 Mar 2009

It is a shame what some famous cryptographers are
doing to avoid anonymous review process!!!]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,76,76#msg-76</guid>
      <pubDate>Fri, 20 Mar 2009 14:20:40 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Shamir's Cube attack == My AIDA attack !!!!!!!!!!!!</title>
      <link>http://eprint.iacr.org/forum/read.php?8,59,75#msg-75</link>
      <author>Vielhaber</author>
      <description><![CDATA[Shamir's &quot;cube attack&quot;: A plagiarism of AIDA

has been submitted to (*this) (pr)eprint server and is available at 
http://www.hs-bremerhaven.de/Michael_Vielhaber.html



@Luo Lan: I agree.

@ ciphergoth: This is Orwellian Newspeak. By induction the first N papers on anything do not matter, just anticipating the N+1st, \forall N in N]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,59,75#msg-75</guid>
      <pubDate>Sat, 28 Feb 2009 13:08:43 -0700</pubDate>
    </item>
    <item>
      <title>[General] G schreiber</title>
      <link>http://eprint.iacr.org/forum/read.php?2,74,74#msg-74</link>
      <author>aisha</author>
      <description><![CDATA[hi any one know abt G schreiber]]></description>
      <category>General</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?2,74,74#msg-74</guid>
      <pubDate>Thu, 05 Feb 2009 13:02:10 -0700</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/049</title>
      <link>http://eprint.iacr.org/forum/read.php?9,73,73#msg-73</link>
      <author>Joe</author>
      <description><![CDATA[For the Toyocrypt complexities, how is it possible to recover a 128-bit state given 4 (or 8) bits of keystream without brute-forcing the last 124 (or 120) bits?]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,73,73#msg-73</guid>
      <pubDate>Fri, 30 Jan 2009 05:20:41 -0700</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/033</title>
      <link>http://eprint.iacr.org/forum/read.php?9,72,72#msg-72</link>
      <author>Orr</author>
      <description><![CDATA[The MSBs are treated in a linear manner.

Thus, a collision attack and a second preimage attack on the hash function are easily done.]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,72,72#msg-72</guid>
      <pubDate>Fri, 23 Jan 2009 10:52:50 -0700</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Padding</title>
      <link>http://eprint.iacr.org/forum/read.php?8,71,71#msg-71</link>
      <author>jungk</author>
      <description><![CDATA[I found this interesting paper (http://eprint.iacr.org/2008/529.pdf), while trying to implement one of the SHA-3 candidates. In contrast to the presented implementation, my implementation will have the padding ability.

While I tried to figure out the workings of the described hardware interface, I came to the conclusion, that it's not possible to implement a working padding function.

Consider the following example:

- The world length is set to 32 bits
- The input to the hashing algorithm is of arbitrary length

There are two possibilites:

- The input is a multiple of 32 bits long
- The input is _not_ a multiple of 32 bits long

The padding function can work with input lengths, which are a multiple of 32 bits. If this is not the case, however, the padding function has no way of detecting the exact message length with the data provided by the proposed interface. Therefore the implementation is unable to pad the message.

Have I missed anything?]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,71,71#msg-71</guid>
      <pubDate>Wed, 21 Jan 2009 12:28:24 -0700</pubDate>
    </item>
    <item>
      <title>[2009 Reports] 2009/034 - Attacks on NaSHA</title>
      <link>http://eprint.iacr.org/forum/read.php?9,70,70#msg-70</link>
      <author>Dmitry Khovratovich</author>
      <description><![CDATA[The core of the paper is that the attack would imply a solution to a system of form

f_1(x_1,..,x_5)*g_1(x_1,..x_5) = a(x_1);
f_2(x_1,..,x_5)*g_2(x_1,..x_5) = a(x_1);
f_3(x_1,..,x_5)*g_3(x_1,..x_5) = a(x_1);

(proposition 1, page 6).

The NaSHA authors claim that since there might be no solution, a check for all possible values of x_1,...,x_5 (2^320 tuples) might be required. 

I would disagree with this observation. Let us consider the  set of tuples L ={(f_1(X)*g_1(X); f_2(X)*g_2(X); f_3(X)*g_3(X)) | X is a 5-tuple} and the set R = {a(x_1) | all possible x_1}.

If all functions are assumed to be random, then the sets L and R intersect and give many solutions (on average 2^192 trials are enough). If the functions are so far from random that this observation is invalid, this may imply many dangerous properties for NaSHA.

Summarizing, the claim that the attack does not work requires details on why the system pointed above does not behave as a random system.

The examples that are provided by the NaSHA authors are examples of toy systems which intuitively may not have a solution. Furthermore, the right part of systems in the examples has variables that are not involved in the left part - which is not the case for the attack.]]></description>
      <category>2009 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?9,70,70#msg-70</guid>
      <pubDate>Sun, 18 Jan 2009 07:48:22 -0700</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Happy New Year</title>
      <link>http://eprint.iacr.org/forum/read.php?8,68,69#msg-69</link>
      <author>annisa</author>
      <description><![CDATA[hoppefully, this year will be better than last year...]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,68,69#msg-69</guid>
      <pubDate>Thu, 15 Jan 2009 02:21:51 -0700</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Happy New Year</title>
      <link>http://eprint.iacr.org/forum/read.php?8,68,68#msg-68</link>
      <author>luolan</author>
      <description><![CDATA[Happy New Year.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,68,68#msg-68</guid>
      <pubDate>Thu, 01 Jan 2009 05:50:51 -0700</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Shamir's Cube attack == My AIDA attack ! (?)</title>
      <link>http://eprint.iacr.org/forum/read.php?8,59,67#msg-67</link>
      <author>luolan</author>
      <description><![CDATA[It's hot. In Chinese ºÃÈÈÄÖ¡£]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,59,67#msg-67</guid>
      <pubDate>Sat, 06 Dec 2008 01:56:39 -0700</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: Shamir's Cube attack == My AIDA attack ! (?)</title>
      <link>http://eprint.iacr.org/forum/read.php?8,59,66#msg-66</link>
      <author>ciphergoth</author>
      <description><![CDATA[The Cube attack authors acknowlege your anticipation of the attack in the linked paper:

&quot;Vielhaber [27] recovered 47 key bits of Trivium with 576 initialization rounds in negligible time. The  key bits were recovered after some small IV special subsets were found, each one with the following property: The result of summing on some keystream bit produced by assigning a special subset all possible IV values, while keeping the other IV bits fixed, is equal to some key bit or to the sum of two key bits. Note that this is a very special case of our cube attack, and it is not clear why the author imposed this unnecessary restriction.&quot;

Could you clarify more on what remains unsolved?  The linked paper describes a variety of &quot;black-box&quot; techniques for finding those linear parts in section 4.2.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,59,66#msg-66</guid>
      <pubDate>Thu, 04 Dec 2008 08:08:37 -0700</pubDate>
    </item>
    <item>
      <title>[2008 Reports] 2008/443 &quot;how to break TRIVIUM&quot;: does this attack work?</title>
      <link>http://eprint.iacr.org/forum/read.php?8,65,65#msg-65</link>
      <author>ciphergoth</author>
      <description><![CDATA[I've had a quick flick through this paper but I can't quite grasp the attack.  In particular I can't see whether the attack is asserted to work no matter how many initialization rounds Trivium uses or whether it is shown to use too few.  Can anyone shed any light?  Cheers!]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,65,65#msg-65</guid>
      <pubDate>Fri, 28 Nov 2008 04:29:11 -0700</pubDate>
    </item>
  </channel>
</rss>
