<?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/"
		>
<channel>
	<title>Comments for Cryptosophy</title>
	<atom:link href="http://crypto.cs.uiuc.edu/blog/?feed=comments-rss2" rel="self" type="application/rss+xml" />
	<link>http://crypto.cs.uiuc.edu/blog</link>
	<description>The sophter side of Cryptography</description>
	<lastBuildDate>Tue, 29 Sep 2009 03:38:33 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Course objective by David Morrison</title>
		<link>http://crypto.cs.uiuc.edu/blog/?p=56&#038;cpage=1#comment-21518</link>
		<dc:creator>David Morrison</dc:creator>
		<pubDate>Tue, 29 Sep 2009 03:38:33 +0000</pubDate>
		<guid isPermaLink="false">http://crypto.cs.uiuc.edu/blog/?p=56#comment-21518</guid>
		<description>Speaking of &quot;primitives&quot;... Here&#039;s the stick figure guide to AES:

http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html</description>
		<content:encoded><![CDATA[<p>Speaking of &#8220;primitives&#8221;&#8230; Here&#8217;s the stick figure guide to AES:</p>
<p><a href="http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html" rel="nofollow">http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Course objective by mikero</title>
		<link>http://crypto.cs.uiuc.edu/blog/?p=56&#038;cpage=1#comment-21505</link>
		<dc:creator>mikero</dc:creator>
		<pubDate>Tue, 22 Sep 2009 16:23:23 +0000</pubDate>
		<guid isPermaLink="false">http://crypto.cs.uiuc.edu/blog/?p=56#comment-21505</guid>
		<description>&lt;i&gt;just too many of them resemble each other (for e.g., those which take an input and a key, and produce an output that looks like gibberish)&lt;/i&gt;

So cryptography is essentially about appreciating the fine subtleties among the myriad of ways of producing gibberish... which I guess makes us gibberish connoisseurs.

I think next time someone asks me what I do, I will tell them I&#039;m a connoisseur of gibberish.</description>
		<content:encoded><![CDATA[<p><i>just too many of them resemble each other (for e.g., those which take an input and a key, and produce an output that looks like gibberish)</i></p>
<p>So cryptography is essentially about appreciating the fine subtleties among the myriad of ways of producing gibberish&#8230; which I guess makes us gibberish connoisseurs.</p>
<p>I think next time someone asks me what I do, I will tell them I&#8217;m a connoisseur of gibberish.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Defining Security (again) by Manoj</title>
		<link>http://crypto.cs.uiuc.edu/blog/?p=33&#038;cpage=1#comment-21504</link>
		<dc:creator>Manoj</dc:creator>
		<pubDate>Mon, 21 Sep 2009 18:44:01 +0000</pubDate>
		<guid isPermaLink="false">http://crypto.cs.uiuc.edu/blog/?p=33#comment-21504</guid>
		<description>Hi David, 

(Sorry for the delay in replying here, but hopefully your question was answered by now.)

SIM-* definitions are not the &quot;traditional&quot; definitions used for encryption. We introduced them as a way to &lt;em&gt;justify&lt;/em&gt; the traditional IND-* definitions.  In the case of CCA and CPA secure encryptions (SKE or PKE), yes, you can omit saying IND/SIM, because they are equivalent. As mentioned in the class, IND-* definitions are more technical/low-level. When you &lt;em&gt;build&lt;/em&gt; an encryption scheme and want to show that it is secure, go with the IND definition. But, if you are &lt;em&gt;using&lt;/em&gt; an encryption scheme, sometimes you&#039;d want to go with the SIM definition as it gives a more high-level guarantee, that is easy to use. So both definitions are still very much useful.

Later on, when we move beyond simple encryption, often SIM definitions are all that we will have. Or, when you do come up with a natural looking IND definition, it may turn out not to capture all the security requirements.</description>
		<content:encoded><![CDATA[<p>Hi David, </p>
<p>(Sorry for the delay in replying here, but hopefully your question was answered by now.)</p>
<p>SIM-* definitions are not the &#8220;traditional&#8221; definitions used for encryption. We introduced them as a way to <em>justify</em> the traditional IND-* definitions.  In the case of CCA and CPA secure encryptions (SKE or PKE), yes, you can omit saying IND/SIM, because they are equivalent. As mentioned in the class, IND-* definitions are more technical/low-level. When you <em>build</em> an encryption scheme and want to show that it is secure, go with the IND definition. But, if you are <em>using</em> an encryption scheme, sometimes you&#8217;d want to go with the SIM definition as it gives a more high-level guarantee, that is easy to use. So both definitions are still very much useful.</p>
<p>Later on, when we move beyond simple encryption, often SIM definitions are all that we will have. Or, when you do come up with a natural looking IND definition, it may turn out not to capture all the security requirements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Defining Security (again) by David Morrison</title>
		<link>http://crypto.cs.uiuc.edu/blog/?p=33&#038;cpage=1#comment-21487</link>
		<dc:creator>David Morrison</dc:creator>
		<pubDate>Wed, 09 Sep 2009 02:45:19 +0000</pubDate>
		<guid isPermaLink="false">http://crypto.cs.uiuc.edu/blog/?p=33#comment-21487</guid>
		<description>One thing that has been confusing to me in the last couple of lectures is the distinction between the IND-* definitions and the SIM-* definitions.  As I understand it, we&#039;re basically approaching the same notion of security from two different viewpoints: the real/ideal framework, and this sort of &quot;experiment&quot; framework.  But fundamentally you can show that these are the same notion of security (that is, IND-CPA and SIM-CPA make the same security guarantees -- at least, that was what I&#039;d understood from lecture), so why the distinction between the two?  Why not just say that we&#039;ve achieved CPA security?</description>
		<content:encoded><![CDATA[<p>One thing that has been confusing to me in the last couple of lectures is the distinction between the IND-* definitions and the SIM-* definitions.  As I understand it, we&#8217;re basically approaching the same notion of security from two different viewpoints: the real/ideal framework, and this sort of &#8220;experiment&#8221; framework.  But fundamentally you can show that these are the same notion of security (that is, IND-CPA and SIM-CPA make the same security guarantees &#8212; at least, that was what I&#8217;d understood from lecture), so why the distinction between the two?  Why not just say that we&#8217;ve achieved CPA security?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Coin flips by Cryptosophy &#183; What is cryptography?</title>
		<link>http://crypto.cs.uiuc.edu/blog/?p=5&#038;cpage=1#comment-21483</link>
		<dc:creator>Cryptosophy &#183; What is cryptography?</dc:creator>
		<pubDate>Fri, 28 Aug 2009 00:07:07 +0000</pubDate>
		<guid isPermaLink="false">http://crypto.cs.uiuc.edu/blog/?p=5#comment-21483</guid>
		<description>[...] point we briefly touched up on in the introductory lecture, especially if it lets me recycle an old blog post. The very notion of information (from which stems the notion of secrecy) is based on a [...]</description>
		<content:encoded><![CDATA[<p>[...] point we briefly touched up on in the introductory lecture, especially if it lets me recycle an old blog post. The very notion of information (from which stems the notion of secrecy) is based on a [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on On defining security &#8211; I by David Molnar</title>
		<link>http://crypto.cs.uiuc.edu/blog/?p=6&#038;cpage=1#comment-3</link>
		<dc:creator>David Molnar</dc:creator>
		<pubDate>Mon, 25 Dec 2006 08:28:37 +0000</pubDate>
		<guid isPermaLink="false">http://crypto.cs.uiuc.edu/blog/?p=6#comment-3</guid>
		<description>Good to see your weblog!

There&#039;s an interesting parallel between what you say at the end, regarding knowing what can go wrong, and cryptographic research into database privacy. A lot of the work from our community comes at it from the perspective of secure multi-party computation -- that is, we will promise you that a specification will be fulfilled as if we had access to a trusted third party, but we make no guarantees that the spec is correct. So for example, we&#039;ll do secure set intersection, but our protocols don&#039;t stop Alice from playing with a set of size 1 to see if a particular name is in Bob&#039;s database...</description>
		<content:encoded><![CDATA[<p>Good to see your weblog!</p>
<p>There&#8217;s an interesting parallel between what you say at the end, regarding knowing what can go wrong, and cryptographic research into database privacy. A lot of the work from our community comes at it from the perspective of secure multi-party computation &#8212; that is, we will promise you that a specification will be fulfilled as if we had access to a trusted third party, but we make no guarantees that the spec is correct. So for example, we&#8217;ll do secure set intersection, but our protocols don&#8217;t stop Alice from playing with a set of size 1 to see if a particular name is in Bob&#8217;s database&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Coin flips by Sariel Har-Peled</title>
		<link>http://crypto.cs.uiuc.edu/blog/?p=5&#038;cpage=1#comment-2</link>
		<dc:creator>Sariel Har-Peled</dc:creator>
		<pubDate>Sat, 02 Sep 2006 21:08:52 +0000</pubDate>
		<guid isPermaLink="false">http://crypto.cs.uiuc.edu/blog/?p=5#comment-2</guid>
		<description>And for a really nice discussion of randomness, see teh beginning of the movie/play Rosenkrantz and Gilderstein are Dead.</description>
		<content:encoded><![CDATA[<p>And for a really nice discussion of randomness, see teh beginning of the movie/play Rosenkrantz and Gilderstein are Dead.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
