<?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>Thu, 17 Apr 2008 02:01:05 -0600</pubDate>
    <lastBuildDate>Thu, 17 Apr 2008 02:01:05 -0600</lastBuildDate>
    <category>Cryptology ePrint Archive Forum</category>
    <generator>Phorum 5.1.22</generator>
    <ttl>600</ttl>
    <item>
      <title>[2008 Reports] Re: 2008/128:  A Chosen IV Attack Using Phase Shifting Equivalent Keys against DECIM v2</title>
      <link>http://eprint.iacr.org/forum/read.php?8,48,53#msg-53</link>
      <author>Tib</author>
      <description><![CDATA[The note http://eprint.iacr.org/2008/169 has been updated to reflect the changes in Report 2008/128.
Namely:
- after taking into account the behavior of the ABSG in the right manner, the authors claim 2^79.90 time complexity,
- the same problems remain in essence:
* the complexity of the algorithm is at least 2^79.90 multiplied by (768 rounds + some keystream generation + more keystream generation in the case of phase-shifted keys),
* despite the comments above, the revised version of Report 2008/128 does not detail the algorithm more than the previous version; this prevents computing the real complexity of the algorithm to verify the claim precisely,
- all the comments and conclusions from the previous version of the note on phase-shifting-based attacks remain valid; the update encompasses only the description of Report 2008/128, which has been modified to take the revision into account.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,48,53#msg-53</guid>
      <pubDate>Thu, 17 Apr 2008 02:01:05 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: 2008/128:  A Chosen IV Attack Using Phase Shifting Equivalent Keys against DECIM v2</title>
      <link>http://eprint.iacr.org/forum/read.php?8,48,52#msg-52</link>
      <author>Tib</author>
      <description><![CDATA[The note is available here: http://eprint.iacr.org/2008/169.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,48,52#msg-52</guid>
      <pubDate>Tue, 15 Apr 2008 14:58:43 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: 2008/128:  A Chosen IV Attack Using Phase Shifting Equivalent Keys against DECIM v2</title>
      <link>http://eprint.iacr.org/forum/read.php?8,48,51#msg-51</link>
      <author>Merlin.7</author>
      <description><![CDATA[Regarding the alleged attack in the paper &quot;A Chosen IV Attack Using Phase Shifting Equivalent Keys against DECIM v2&quot;, we have just submitted a note called &quot;Understanding Phase Shifting Equivalent Keys and Exhaustive Search&quot; to the eprint archive.

The note shows that this type of attack, from a general perspective, always has a time complexity at least $2^n$ updates of the cipher state, with $n$ being the length of the key. The erroneous result in the paper above stems from the fact that the authors forgot to include the initialization time in their computation, so one should read that their attack has complexity $O(2^{79.56})$, not $2^{79.56}$.

In a nutshell, what we prove in our note is that, considering a single operation to be one update of the cipher state, the constant in the $O(2^{m})$ attack complexity is always at least $2^{n-m}$. This type of attack can be used to speed up exhaustive search by &quot;parallelizing&quot; partly the search for multiple keys at once. However, there is an overhead for each parallelized key, which is always at least the computational cost of one additional update of the internal state, hence the result that such &quot;attacks&quot; always require at least the computation of $2^n$ updates of the internal state.

Please note that our result also invalidates the claims made by the authors in the introduction about the fact that another eSTREAM algorithm, Grain, fails under a similar attack better of complexity $2^{78.4}$ or $2^{78.7}$. Here again, the authors did not include the computational cost per tested key.

As a result, these attacks against both Decim v2 and Grain have a complexity that remains well over $2^80$, as these complexities shall be multiplied by a bit more than the complexity of one initialization of the cipher. Even in the case of a cipher with 80-bits keys to which these attacks would apply ideally (e.g. where the initialization and keystream generation steps are the same), these attacks could not reach less than $2^{80}$.

At last, please note that the authors of the paper &quot;A Chosen IV Attack Using Phase Shifting Equivalent Keys against DECIM v2&quot; are currently reconsidering their attack and the evaluation of the time complexity of their attack after the authors of this note pointed out (in the post above) a misunderstanding of the Decim v2 scheme. We thus expect a revised version to take into account this note and the comments above.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,48,51#msg-51</guid>
      <pubDate>Tue, 15 Apr 2008 10:13:54 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: A general suggestion</title>
      <link>http://eprint.iacr.org/forum/read.php?8,47,49#msg-49</link>
      <author>eprint-forum-admin</author>
      <description><![CDATA[We are aware of this, but have not taken any steps
to further integration because the forum and the
archive run on different database systems.

Thank you for the suggestion.

  Christian Cachin]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,47,49#msg-49</guid>
      <pubDate>Sun, 13 Apr 2008 02:04:08 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] 2008/128:  A Chosen IV Attack Using Phase Shifting Equivalent Keys against DECIM v2</title>
      <link>http://eprint.iacr.org/forum/read.php?8,48,48#msg-48</link>
      <author>Merlin.7</author>
      <description><![CDATA[We have been looking at eprint paper &quot;A chosen IV attack using phase shifting equivalent keys against Decim v2&quot; by Hidehiko Nakagami, Ryoichi Teramura, Toshihiro Ohigashi, Hidenori Kuwakado and Masakatu Morii and we have some concerns about the validity of the results because of two main points:
 
- the first point is that the claim on p.7 that, if a phase shifting equivalent key $\hat{K}$ exists for $K$, then the resulting keystream $Z$ and $\hat{Z}$ will synchronize eventually and thus enable the attacker to check that $K$ and $\hat{K}$ are phase shifting equivalent by using only keystream $Z$, is wrong. Indeed, two 1-bit Phase Shifting Equivalent Keys $K$ and $\hat{K}$ yield sequences output from the filter generator that are shifted from one bit. Thus, the two sequences that are input to the ABSG mechanism are shifted from one bit. As shown in the article &quot;The Bit-Search Generator&quot;, published at SASC2004, the BSG and the ABSG outputs can be seen as the result of an action of the input sequence on a set of three elements. Two input sequences will yield shifted outputs iff the input sequences are shifted by a sequence of full BSG words, i.e. words of the form $b \bar{b}^k b$. Therefore, two input sequences that are shifted by only one bit do not yield shifted outputs and the outputs of $Z$ and $\hat{Z}$ never synchronize.
 
As a consequence, $Z$ and $\hat{Z}$ keystreams arising from phase shifting equivalent keys cannot be detected. Thus, in the attack algorithm from Section 5.2, testing whether an element of $E$ is $\hat{K}$ by generating the corresponding keystream $\hat{Z}$ and comparing it to the original keystream to detect phase shifting equivalent keys is not possible.
 
- the second point is the time complexity computation in the final attack.
 
It is usual to consider the time complexity of a key recovery algorithm as the overall expected number of keys tested in the algorithm to recover the key with probability close to 1, which means considering the total serial computational time. Otherwise, it would be sufficient to run 2 processes in parallel performing exhaustive search in two disjoint halves of the key space in order to claim a time complexity of $2^{n-1}$ to recover the key with probability 1.
A variant for time complexity is the average time complexity, where you compute the average expected number of keys tested. In the case of average time complexity, as even a single machine doing brute force will perform $2^{n-1}$ tests on average, the relevance of an average complexity of more than $2^{n-1}$ is questionable.
In this paper, the time complexity appears to be a mix of the two definitions above. The authors should precise the meaning of the result and provide a more precise description of the attack algorithm in order to support the complexity analysis.
 
If we have understood well the algorithm, there seems to be other flaws in the computation. Indeed, in the description of the attack algorithm in Section 5.2, it is mentioned that a subset $E$ of $2^{78}$ keys is first parsed, and for each element $x$ in this subset, the algorithm tests whether $x$ is suitable as the key $K$, and whether $x$ is suitable as a shifted key $\hat{K}$, thus requiring two key tests each time (and generation of one $Z$ keystream and one $\hat{Z}$ keystream). This doubles the time complexity of the algorithm steps carried out in $E$, as for each element in $E$, two candidates keys are tested. This is not taken into account in the time complexity. For instance, for case 4, the time complexity is $\frac{21}{32} (2\times 2^{78} + (2^{80} - 2^{78})$, as first $E$ is parsed unsuccessfully for $K$ and $\hat{K}$, and then $\bar{E}$ is parsed for $K$. This yields an increase in the average time complexity of the exhaustive key search that needs to be taken into account.
 
To summarize, we believe that there may be flaws in the time complexity computation of the attack algorithm in Section 5.2, and, most importantly, that a misunderstanding of the ABSG in the reasoning may invalidate this algorithm.
 

We will appreciate feedback and comments on these remarks. 
 
 
 
Best regards,
 
Come Berbain, Aline Gouget, Herve Sibert]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,48,48#msg-48</guid>
      <pubDate>Tue, 01 Apr 2008 04:15:47 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] A general suggestion</title>
      <link>http://eprint.iacr.org/forum/read.php?8,47,47#msg-47</link>
      <author>sultan</author>
      <description><![CDATA[This discussion forum looks nice. I wonder whether it is possible to modify the system such that each discussion is attached to the paper itself. If this is done, it will be easier to use and more discussion can occur.]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,47,47#msg-47</guid>
      <pubDate>Mon, 31 Mar 2008 20:05:11 -0600</pubDate>
    </item>
    <item>
      <title>[2008 Reports] Re: 2008/034 and 2007/145</title>
      <link>http://eprint.iacr.org/forum/read.php?8,45,46#msg-46</link>
      <author>CryptoNovice</author>
      <description><![CDATA[I'm a novice to this field and I'm not able to judge if your comment is really genuine or sarcastic. Could you elaborate? 

Thanks in advance
Novice]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,45,46#msg-46</guid>
      <pubDate>Tue, 05 Feb 2008 13:53:14 -0700</pubDate>
    </item>
    <item>
      <title>[2008 Reports] 2008/034 and 2007/145</title>
      <link>http://eprint.iacr.org/forum/read.php?8,45,45#msg-45</link>
      <author>trustedThirdParty</author>
      <description><![CDATA[These reports, taken together, prove that the theory of cryptography is inconsistent. This is a really great new result!]]></description>
      <category>2008 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?8,45,45#msg-45</guid>
      <pubDate>Mon, 28 Jan 2008 11:16:06 -0700</pubDate>
    </item>
    <item>
      <title>[2005 Reports] 2005/422 Is ACJT group signature fully anonymous?</title>
      <link>http://eprint.iacr.org/forum/read.php?5,44,44#msg-44</link>
      <author>qlq</author>
      <description><![CDATA[''On Anonymity of Group Signatures ''
http://eprint.iacr.org/2005/422
this paper answers the question, and the result is that ACJT is fully anonymous (CCA2-secure) in ROM.
Is it right?
Since I couldn't totally agree with the proof.]]></description>
      <category>2005 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?5,44,44#msg-44</guid>
      <pubDate>Fri, 18 Jan 2008 00:20:58 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] 2007/440</title>
      <link>http://eprint.iacr.org/forum/read.php?7,43,43#msg-43</link>
      <author>thulasi</author>
      <description><![CDATA[The weakness pointed out in this paper seems to be very weak. 

Authors mentioned of Giri and Srivasta's improvement of a remote user authentication scheme[2006/274] and it's weakness because of the readability of the data in the smartcard. By the general implication, when we say we are storing something in the smartcard, we lock it and make it inaccessible from outside. Only the smartcard can read this data in its processing logic. 

Even if we agree with the authors, their scheme is also subjected to the same attack as follows. 

If only we can retrieve the RegID and SPi from the smartcard we can calculate A = RegID-SPi and can frame many acceptable login requests with random r and varying timestamps T. 

This paper seems to be not a bit of innovative work but just mere copying of Giri and Srivastav's work. Please consider my comments positively.

I am always ready for the discussions.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,43,43#msg-43</guid>
      <pubDate>Thu, 03 Jan 2008 04:47:47 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/476:  Dynamic  SHA has weak expansion ME2</title>
      <link>http://eprint.iacr.org/forum/read.php?7,39,42#msg-42</link>
      <author>xuzijie</author>
      <description><![CDATA[hi.
   The reason i need ME2 is i want to bring a real nonlinear function and the ANFs have many monomials. Someone may think that functions like ME1 is nonlinear function. but i do not think so, bijection is not dependable.  And in the paper,  the equations (2) keep the size of equations (3) and (4), and equations (2) is a restriction for the solutions for the equations (3) and (4),  At last the message expansion is a element that we can use to divide the message space. why not use &quot;Dynamic function&quot; to divide the message space.

   I need partner. I wellcome anyone join me. :) ^_^]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,39,42#msg-42</guid>
      <pubDate>Sat, 29 Dec 2007 09:40:28 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/476:  Dynamic  SHA has weak expansion ME2</title>
      <link>http://eprint.iacr.org/forum/read.php?7,39,41#msg-41</link>
      <author>Vlastimil Klima</author>
      <description><![CDATA[The main questions are, IF you NEED variables W32,..., W47 and WHY?

(i) If you don´t need W32, ..., W47:
Easily you can set directly W32 = ... = W47 = 0 without calculation ME2 and your algorithm will be faster (in Table 6 you can avoid using W32 = ... = W47 = 0 from calculations in step 3).

(ii) If you really need W32, ..., W47:
You can (for instance) redesign ME2 with the same complexity and speed,but cryptographically stronger. But, you should know WHY. Then you would better know HOW.

IMHO, it isn´t easy to answer those questions.

Vlastimil Klima]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,39,41#msg-41</guid>
      <pubDate>Fri, 28 Dec 2007 09:16:18 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/476:  Dynamic  SHA has weak expansion ME2</title>
      <link>http://eprint.iacr.org/forum/read.php?7,39,40#msg-40</link>
      <author>xuzijie</author>
      <description><![CDATA[when i write the paper, i know this. 
1, i get the idea at september, complete it at october. i had not think over all thing.
2, even we can find &quot;collide&quot; for ME2, but the system has function G, R. our target is the last hash value. when we get &quot;collide&quot; for ME2, the different in {M[0], ..., M[31]} will will change the last hash value. 
3,if we design a &quot;hard&quot; ME2, the workload of system will be increased.
4, give me some time. :).

the function G,R,ME2 divide message space into many parts. in differnt part, the hash value is calculated with different formula. the &quot;collides&quot; will be divide into different part too. so in a part, the &quot;collides&quot; is lesser. if someone choice a part,it is harder to find &quot;collide&quot;.

(my english is not good, i hope you know what mean, thank you for your suggestion)]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,39,40#msg-40</guid>
      <pubDate>Fri, 28 Dec 2007 04:12:51 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] 2007/476:  Dynamic  SHA has weak expansion ME2</title>
      <link>http://eprint.iacr.org/forum/read.php?7,39,39#msg-39</link>
      <author>Vlastimil Klima</author>
      <description><![CDATA[2007/476:  Dynamic  SHA has weak expansion ME2
Note that the expansion ME2 is weak.

(i) Dynamic SHA-224/256:
For every message block M = M[0], ..., M[15], where (M[0] xor M[1]...xor M[7] = 0xfedcba98) and (M[8] xor M[9]...xor M[15] = 0x76543210) the expansion ME2(M) ''expands'' M to 16 32-bit zero words

(ii) Dynamic SHA-384/512:
For every message block M = M[0], ..., M[15], where M[0] xor M[1]... xor M[15] = 0x76543210fedcba98, the expansion ME2(M) ''expands'' M to 16 64-bit zero words

Vlastimil Klima]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,39,39#msg-39</guid>
      <pubDate>Wed, 26 Dec 2007 04:09:26 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/378</title>
      <link>http://eprint.iacr.org/forum/read.php?7,17,38#msg-38</link>
      <author>Sean O'Neil</author>
      <description><![CDATA[I have just noticed this thread. Although the situation was quite upsetting to me, I must agree with the above comments. I have changed the note. I should have done it earlier. The whole thing has since been directed up the right channels anyway. I sincerely apologize if I have upset or offended anyone personally.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,17,38#msg-38</guid>
      <pubDate>Wed, 12 Dec 2007 12:49:24 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Report 2007/414, Optimizing double-base elliptic-curve single-scalar multiplication</title>
      <link>http://eprint.iacr.org/forum/read.php?7,37,37#msg-37</link>
      <author>jamuir</author>
      <description><![CDATA[Report 2007/414 is &quot;Optimizing double-base elliptic-curve single-scalar multiplication&quot; by Bernstein, Birkner, Lange and Peters.  I think it is a very nice paper, but I wondered if someone might be able to help me track down the origins of one of the ideas mentioned in it.

In the discussion in the section &quot;Computing a chain&quot;, which starts at the bottom of page 8, the first two paragraphs mention what I call closest-choice decompositions of the integer 314159.  It is mentioned that these decompositions correspond to an addition chain method by Thurber.  Specifically, &quot;Thurber's base-2 sliding window chain&quot; is mentioned.  I assume that this a reference to Thurber's DMJ paper (cited as [22]).

When I look through [22] I don't find any discussion there about closest-choice decompositions.  Moreover, Thurber treats only addition chains rather than addition-subtraction chains.  Does anyone know if there is some other work by Thurber where this can be found?

In [22], Thurber does, however, present an example (page 912) where he uses the binary representation of n to identify what he calls critical numbers.  His strategy seems to differ from the close-choice strategy because he selects the first critical number to be larger than the others.

Can anyone help me track down the origins of closest choice representations?

-James]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,37,37#msg-37</guid>
      <pubDate>Fri, 23 Nov 2007 12:08:17 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Misleading title for Report 2007/408</title>
      <link>http://eprint.iacr.org/forum/read.php?7,36,36#msg-36</link>
      <author>pbarreto</author>
      <description><![CDATA[The title of this paper (&quot;Differential Cryptanalysis of PRESENT&quot;) is misleading, as it suggests that the PRESENT block cipher is broken. The author does not cryptanalyze PRESENT itself, but a simplified version with half the number of rounds (specifically, 16 rather than 31). A title like &quot;Differential Cryptanalysis of Reduced-Round PRESENT&quot; or so would be much more appropriate and true to the contents.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,36,36#msg-36</guid>
      <pubDate>Fri, 16 Nov 2007 06:46:30 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/401: Deus ex Machina?</title>
      <link>http://eprint.iacr.org/forum/read.php?7,27,35#msg-35</link>
      <author>nigel</author>
      <description><![CDATA[Actually it is the VERIFICATION of the current Intel floating point unit, which was done as a result of the pentium bug which I would claim shows that formal methods have a place.

Talk to a chip designer. Almost all their effort is now spent in verifying the design.

The same should be true of crypto. Coming up with a new scheme should be the easy bit, we should be spending our time on the tools and effort needed to verify it is secure.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,27,35#msg-35</guid>
      <pubDate>Wed, 07 Nov 2007 13:34:41 -0700</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/401: Deus ex Machina?</title>
      <link>http://eprint.iacr.org/forum/read.php?7,27,34#msg-34</link>
      <author>Vielhaber</author>
      <description><![CDATA[Observing that Koblitz cites Sokal, I was essentially sure I would like this report. Not disappointed.

@jkatz:
So, what is Nowak showing then? 
Since ElGamal is unsecure for certain q's, the &quot;proof&quot; should mention this (apparently impossible, the prime factorisation of q is outside the focus) or then what does it *really* prove?
So, game-five is *not* true after all, if q is special??

@nigel:
Comparing VLSI design with cryptography leads us to the very point:
VLSI design is a check of some (maybe huge, but) *finite* set of rules (electrical design rule check, Boolean transformations etc.) that have to be satisfied, and if they do, the chip is considered to be OK (including the famous Pentium division bug, the Pentium was OK according to the rules).

Cryptographic security, in particular *provable security* is open-ended. So, the (necessarily) finitely many checks an automated prover can make, never can assure 100% security (and how would a proof system distinguish P=NP from P \neq NP?, with its obviously different implications). 

Of course, computers aid. I think the main point is the exageration of claiming to achieve &quot;provable security&quot;, when there is no such thing outside the OneTimePad and QuantumBitTransmission realm. And then, what is &quot;some&quot; security worth?]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,27,34#msg-34</guid>
      <pubDate>Fri, 02 Nov 2007 18:31:14 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] RE Paper #2007/389: Similar results have been independently discovered by Iordanis Kerenidis and André Chailloux.</title>
      <link>http://eprint.iacr.org/forum/read.php?7,33,33#msg-33</link>
      <author>Florin Ciocan</author>
      <description><![CDATA[Similar results have been independently discovered by Iordanis Kerenidis and André Chailloux.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,33,33#msg-33</guid>
      <pubDate>Fri, 02 Nov 2007 03:48:48 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2000/394 Garay and Ostrovsky technical report on &quot;almost everywhere secure computation&quot;</title>
      <link>http://eprint.iacr.org/forum/read.php?7,31,32#msg-32</link>
      <author>cryptography</author>
      <description><![CDATA[Also, check the recent versions of the technical report on &quot;Secure computation on incomplete networks&quot;

Which has elaborate explainations and enhanced acknowledgements on your reports.


cheers,
cryptographer.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,31,32#msg-32</guid>
      <pubDate>Fri, 26 Oct 2007 09:19:25 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] 2000/394 Garay and Ostrovsky technical report on &quot;almost everywhere secure computation&quot;</title>
      <link>http://eprint.iacr.org/forum/read.php?7,31,31#msg-31</link>
      <author>cryptography</author>
      <description><![CDATA[Hi, I just happened to look at your report on almost everywhere secure computation on ePrint. Interesting, work...

(1) I looked at your remarks about simulation based definition and KKMO definition and I think you are not understanding that a simulator is just an &quot;abstract mental construct&quot; which does not have to be possessed by the adversary or for the adversary to be even aware that such a simulator at all exists.

It is just a way (or can be a way) of proving/bounding the amount of knowledge/information that an adversary learns about the inputs/outputs of other parties but other then that it is &quot;hypothetical mental construct&quot;. Your problem seems to be arising from the fact that you are seeing &quot;simulator&quot; as a tangible entity - who is provided inputs from somewhere and who is providing outputs to someone. This is not the case!! There is no simulator out there that is working and producing results - just like there is no ideal case. Its just a way of modelling and proving certain properties of MPC protocols.

Remember when you show that there exists a simulator (which is given inputs/outputs etc. etc.) by which the entire logs of the adversary could be created, then the claim is that adversary has this much knowledge /information about the I/O of some parties - which essentially conveys that adversary has learnt not one more bit of information about the inputs and outputs of the parties then this! Thats it.

Its only a way of proving things - that you have to understand [Don't always start looking out for a real simulator which is given inputs about different variables and parties on the network!]

My students also initially faced some difficulties in understanding this at first - but now they are understanding that a simulator is just an &quot;abstract mental construct&quot;.

(2) I find it a little funny that you like to claim that you understand the definitions of your co-author. The previous version that you sent to ICALP - without the permission of your third co-author - and without infact the approval of the third co-author - to send a paper with his name on it [And he has logs of these emails] you mention that you do not understand those definitions [namely you mention that they are too complex], then he sent some draft to Canetti who seem told you inputs are not handled satisfactorially - it seems that too was fixed by the fellow in the new version and in a still new version Canetti seems to have given you an example - but as I tell you - the problem is in your misunderstanding the whole &quot;simulation&quot; thing for which you actually go out looking for real inputs from real life!

3) all your faulty claims about the contributions in technical report on &quot;secure computation on incomplete networks&quot; have been addressed in the recent version of the report posted on ePrint Archive.

4) Lastly, you also seem to mention you presented the work of the third author at several rump sessions at TCC'07 etc. You do not even understand his work - how did you present his work to these conferences? Your actions seem to be in the same &quot;subterfuginous&quot; manner as before where you do not take any approval about submitting something to a conference without the permission or approval of your co-author..?

Your actions have no integrity or professional of any kind?

5) Lastly, writting a dozen papers on a topic or even hundred does not help or even understand a topic necessarily. How else would Ran Canetti, you both be making such remarks about the definitions of the other paper?

cheers,
Cryptographer]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,31,31#msg-31</guid>
      <pubDate>Fri, 26 Oct 2007 09:17:48 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/401: Deus ex Machina?</title>
      <link>http://eprint.iacr.org/forum/read.php?7,27,30#msg-30</link>
      <author>nigel</author>
      <description><![CDATA[I think there is a major misunderstanding in the article as to why these works are interesting.

In chip design, automated verification via computer assisted, or directed, proofs is crucial; otherwise we cannot get the complex microprocessors we now have. Once upon a time, academic papers were published which did these things on small examples. At the time it would have been clear that the human could have done better. Now however we reap the benefits of such early research as we can purchase fast computers etc.

Would it not be nice if in the future we could verify, in the complexity theoretic/cryptographic model, a very very complicated security protocol ? For example a protocol to implement an electronic election, or run a part of national critical infrastructure. To do this we need to develop tools, clearly at first these tools will only be applied to smallish protocols, which may have easier hand based proofs; but eventually these tools will allow us to do things a human cannot.
  - Going back to my earlier analogy; would anyone try and verify the Intel Core 2 design by hand ?
 
To criticise such papers, as Koblitz does, is in my view showing that one does not appreciate where this research may take us. 

Indeed I would say that this merging of the cryptographic and the symbolic (computer assisted proof) methods has been one of the more important things in crypto in the last few years. For too long have the two communities moved apart.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,27,30#msg-30</guid>
      <pubDate>Thu, 25 Oct 2007 06:49:33 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] 2007/401</title>
      <link>http://eprint.iacr.org/forum/read.php?7,27,29#msg-29</link>
      <author>jkatz</author>
      <description><![CDATA[I just wanted to note that the criticism given at the end of Section 4 (page 16) is incorrect: if q (the order of the group) has small factors, then indeed El Gamal is insecure. But in that case the DDH assumption does not hold (as you  mention), so this does not in any way contradict the theorem that was proved.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,27,29#msg-29</guid>
      <pubDate>Wed, 24 Oct 2007 17:57:26 -0600</pubDate>
    </item>
    <item>
      <title>[General] Re: Welcome to the discussion forum</title>
      <link>http://eprint.iacr.org/forum/read.php?2,2,28#msg-28</link>
      <author>contini</author>
      <description><![CDATA[Hi, it seems that the website likes to put &quot;New&quot; in red text for every thread that I haven't read, even though the thread really isn't new (the last reply has not happened since I last visited).  Is there a reason for this?  To me it seems like a distraction....]]></description>
      <category>General</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?2,2,28#msg-28</guid>
      <pubDate>Tue, 23 Oct 2007 22:04:59 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] 2007/401: Deus ex Machina?</title>
      <link>http://eprint.iacr.org/forum/read.php?7,27,27#msg-27</link>
      <author>ShaiHalevi</author>
      <description><![CDATA[In his latest article, Koblitz decries those naive cryptographers who &quot;hope that a suitably designed device --- some cleverly written computer code --- will make unpleasant natural phenomena go away.&quot; 

Call me naive, but I think that the main use of computers is to eliminate unpleasantnesses: Whenever you are faced with a task that requires keeping track of many simple details, it is only natural to consider &quot;some cleverly written computer code&quot; to do this work for you. I am guessing that Koblitz wrote this article using a word processor, a &quot;cleverly written computer code&quot; that helps eliminating the unpleasantness of manual typesetting. 

Let me begin with a small comment: Koblitz quotes out of context a partial sentence from my ePrint note from a few years ago, regarding the reason that some published proofs have errors in them. The entire quote reads as follows:

  &quot;Some of the reasons for this problem are social (e.g., we mostly
   publish in conferences rather than journals), but the true cause of
   it is that our proofs are truly complex. After all, the objects that
   we deal with are non-trivial algorithms, and what we try to prove
   are some properties of an intricate interaction between a few of
   these algorithms.&quot;

Koblitz omitted the part about &quot;the true cause&quot;. Indeed, the part that was omitted is more important than what was quoted: cryptographic proofs are complex mostly because they involve keeping track of an enormous number of details (most of them rather boring). I may be naive, but I would really want &quot;some cleverly written computer code&quot; to help me keep track of them.

On a more technical level, Koblitz completely missed the point of the work that is done in automated/computer-aided cryptographic proofs. Specifically, he writes that

  &quot;the hope of authors of recent papers on automated theorem proving
   is to take the uncertainties, flaws, and human foibles out of the
   process of deriving reductionist security arguments.&quot;

I seriously doubt that there is anyone working on automated proofs that has this view. We cannot even &quot;take the uncertainties, flaws, and human foibles out of the process&quot; of writing an essay (even with our clever word-editors), certainly we cannot hope to do so with mathematical proofs.

Instead, the hope is that computer programs can help with the task of checking the &quot;obvious details&quot; of a proof, making sure that there are no errors there. Errors in published proofs are often contained in exactly these &quot;obvious details&quot; (see the OAEP case for example), and computer software may help avoiding such errors. As I wrote in that ePrint note:

  &quot;cryptographic proofs have a creative part (e.g., describing the
   simulator or the reduction) and a mundane part (e.g., checking that
   the reduction actually goes through). It often happens that the
   mundane parts are much harder to write and verify, and it is with
   these parts that we can hope to have automated help.&quot;

Koblitz'es article consists of a few examples from the literature, where he demonstrates that proofs that can be checked by computers are all &quot;obvious&quot;. However, contrary to his claim, this does not show that they have no value. Quite the contrary, they demonstrate that these &quot;obvious&quot; steps are simple enough to be checked by a computer, thus lending support to the hope that we may one day have a computer program that can actually be helpful in writing/verifying our proofs.

To be sure, none of the code written so far can really be used by cryptographers when writing their proofs. But the recent work of Blanchet and Pointcheval clearly demonstrates that a &quot;truly useful&quot; program is technically doable. Most of the arguments, transformations, and tools that we use in our proofs are re-used over and over again in many different analyses, and Blanchet and Pointcheval demonstrated that these can indeed be formally expressed and used by a computer program. The challenge in creating a &quot;truly useful&quot; program lies essentially in assembling enough of them and devising a suitable user interface.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,27,27#msg-27</guid>
      <pubDate>Mon, 22 Oct 2007 14:05:52 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/378</title>
      <link>http://eprint.iacr.org/forum/read.php?7,17,26#msg-26</link>
      <author>dbrown</author>
      <description><![CDATA[mscott, if you were referring to a statement that the chair published the same results under his name (see the 2nd version 20070927:155650), then this could be defamatory.  eprint is not a good place to allege plagiarism, its function should mainly be to distribute research quickly.  a ban on such allegations, however, might be too much of a nuissance for the eprint editors to enforce?]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,17,26#msg-26</guid>
      <pubDate>Fri, 19 Oct 2007 14:12:28 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] your report on ePrint</title>
      <link>http://eprint.iacr.org/forum/read.php?7,25,25#msg-25</link>
      <author>cryptography</author>
      <description><![CDATA[Hi, I just happened to look at your report on almost everywhere secure computation on ePrint. Interesting, work...

(1) I looked at your remarks about simulation based definition and KKMO definition and I think you are not understanding that a simulator is just an &quot;abstract mental construct&quot; which does not have to be possessed by the adversary or for the adversary to be even aware that such a simulator at all exists.

  It is just a way (or can be a way) of proving/bounding the amount of knowledge/information that an adversary learns about the inputs/outputs of other parties but other then that it is &quot;hypothetical mental construct&quot;. Your problem seems to be arising from the fact that you are seeing &quot;simulator&quot; as a tangible entity - who is provided inputs from somewhere and who is providing outputs to someone. This is not the case!! There is no simulator out there that is working and producing results - just like there is no ideal case. Its just a way of modelling and proving certain properties of MPC protocols.

  Remember when you show that there exists a simulator (which is given inputs/outputs etc. etc.) by which the entire logs of the adversary could be created, then the claim is that adversary has this much knowledge /information about the I/O of some parties - which essentially conveys that adversary has learnt not one more bit of information about the inputs and outputs of the parties then this! Thats it.

  Its only a way of proving things - that you have understand [Don't start looking out for a real simulator which is given inputs about different variables and parties on the network!]

  My students also initially faced some difficulties in understanding this at first - but now they are understanding that a simulator is just an &quot;abstract mental construct&quot;.

(2) I find it a little funny that you like to claim that you understand the definitions of your co-author. The previous version that you sent to ICALP - without his permission and without infact his approval to send a paper with his name on it [And he has logs of these emails] you mention that you do not understand those definitions [namely you mention that they are too complex], then he sent some draft to Canetti who seem told you inputs are not handled satisfactorially - it seems that too was fixed by the fellow in the new version and in a still new version Canetti seems to have given you an example - but as I tell you - the problem is in your misunderstanding the whole &quot;simulation&quot; thing for which you actually go out looking for real inputs from real life!!

  Have fun doing cryptography!

cheers,
Cryptographer]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,25,25#msg-25</guid>
      <pubDate>Fri, 19 Oct 2007 09:06:42 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/378</title>
      <link>http://eprint.iacr.org/forum/read.php?7,17,24#msg-24</link>
      <author>ciphergoth</author>
      <description><![CDATA[O'Neil has also been very rude to me through a sockpuppet account on Wikipedia.  See also his behaviour in the SASC forums.]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,17,24#msg-24</guid>
      <pubDate>Sun, 14 Oct 2007 16:03:56 -0600</pubDate>
    </item>
    <item>
      <title>[2007 Reports] Re: 2007/377 (Extended Jacobi curves)</title>
      <link>http://eprint.iacr.org/forum/read.php?7,22,23#msg-23</link>
      <author>evilcry</author>
      <description><![CDATA[Truly intersting paper :)]]></description>
      <category>2007 Reports</category>
      <guid isPermaLink="true">http://eprint.iacr.org/forum/read.php?7,22,23#msg-23</guid>
      <pubDate>Sat, 13 Oct 2007 11:21:14 -0600</pubDate>
    </item>
  </channel>
</rss>
