<?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 on: Cryptanalysis vs. Bughunting</title>
	<atom:link href="http://spiresecurity.com/?feed=rss2&#038;p=489" rel="self" type="application/rss+xml" />
	<link>http://spiresecurity.com/?p=489</link>
	<description>Risk and Cybersecurity Analysis</description>
	<lastBuildDate>Wed, 21 Aug 2013 23:28:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Andrew Donofrio</title>
		<link>http://spiresecurity.com/?p=489&#038;cpage=1#comment-771</link>
		<dc:creator>Andrew Donofrio</dc:creator>
		<pubDate>Sat, 24 Dec 2005 16:30:14 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=489#comment-771</guid>
		<description><![CDATA[&quot;My assessment of the risk suggests that the imminent threat and corresponding risk from successful cryptanalysis is much lower than with bughunting&quot;

In general, I agree with this statement, but probably in a different way than implied by the post. There seems to be some implication that these types of research should not be published (even conducted?) and that seems naive. How can one attempt to build things without first understanding how to break things? And, how can one fix something they do not know is broken in the first place?

As far as the imminent threats, cryptanalytic results are often academic in nature, while &quot;bughunting&quot; results are often practical in nature. A cryptographic mechanism can be broken in theory while the break remains totally useless in the realworld due to, say, its computational requirements or weaker security notions being enough for the uses of the mechanism, but a bug in a particular implementation exposes some sort of flaw or problem in that immediate implementation and often these issues can be leveraged for practical attacks. So, the impact of cryptanalytic results may be big in terms of future crypto designs, but small in terms of current realworld attacks on implementations, while the impact of &quot;bughunting&quot; may be big in terms of current realword attacks on implementations, but small to medium in terms of influencing design and development of future implementations (they do, however, result in fixes/workarounds for the buggy implementation and its direct relatives, as long as the research is disclosed). I think part of the variation in impacts is caused by the fact the crypto community is small, open, and homogeneous in a way that it generally uses cryptanalytic results to eliminate weaker crypto from the ballgame quite early on before its widespread adoption and use, while &quot;bughunting&quot; in implementations covers a large, both closed and open, and heterogeneous community and is, well, after implementation. (Also, this does not mean that practical attacks from cryptanalytic results do not occur, but these are diluted across the vast number of research breaks, which can be some years away from being extended to the realworld if ever, and, even when practical attacks in current systems are possible due to cryptanalytic results, the attacks themselves are often much more difficult to get to generate useful results by themselves than attacks stemming from &quot;bughunting.&quot;  As we have all heard before, crypto is often not the weakest link in the security chain of realworld systems.)

However, things like poor implementation and improper usage of crypto blur the line between cryptanalysis and &quot;bughunting.&quot; These two arenas are by no means mutally exclusive in my view and combinations of the two can be used to devastating effect. In recent days, watermarking attacks on older versions of loop-aes, depending on your threat model for disk encryption, total crushing of WEP, according the its own design goals, and AES cache timing analysis, depending on your predictions for next year, have been in some of the discussions people are having around me.

In all of these cases (&quot;bughunting,&quot; cryptanalyzing, or blur), the publishing of security research leads to the ability to improve what is out there, whether by designing and building better primitives, protocols, and systems, or just fixing flaws in current deployments. And, in general, third party audits often play an important part in the review process.
]]></description>
		<content:encoded><![CDATA[<p>&#8220;My assessment of the risk suggests that the imminent threat and corresponding risk from successful cryptanalysis is much lower than with bughunting&#8221;</p>
<p>In general, I agree with this statement, but probably in a different way than implied by the post. There seems to be some implication that these types of research should not be published (even conducted?) and that seems naive. How can one attempt to build things without first understanding how to break things? And, how can one fix something they do not know is broken in the first place?</p>
<p>As far as the imminent threats, cryptanalytic results are often academic in nature, while &#8220;bughunting&#8221; results are often practical in nature. A cryptographic mechanism can be broken in theory while the break remains totally useless in the realworld due to, say, its computational requirements or weaker security notions being enough for the uses of the mechanism, but a bug in a particular implementation exposes some sort of flaw or problem in that immediate implementation and often these issues can be leveraged for practical attacks. So, the impact of cryptanalytic results may be big in terms of future crypto designs, but small in terms of current realworld attacks on implementations, while the impact of &#8220;bughunting&#8221; may be big in terms of current realword attacks on implementations, but small to medium in terms of influencing design and development of future implementations (they do, however, result in fixes/workarounds for the buggy implementation and its direct relatives, as long as the research is disclosed). I think part of the variation in impacts is caused by the fact the crypto community is small, open, and homogeneous in a way that it generally uses cryptanalytic results to eliminate weaker crypto from the ballgame quite early on before its widespread adoption and use, while &#8220;bughunting&#8221; in implementations covers a large, both closed and open, and heterogeneous community and is, well, after implementation. (Also, this does not mean that practical attacks from cryptanalytic results do not occur, but these are diluted across the vast number of research breaks, which can be some years away from being extended to the realworld if ever, and, even when practical attacks in current systems are possible due to cryptanalytic results, the attacks themselves are often much more difficult to get to generate useful results by themselves than attacks stemming from &#8220;bughunting.&#8221;  As we have all heard before, crypto is often not the weakest link in the security chain of realworld systems.)</p>
<p>However, things like poor implementation and improper usage of crypto blur the line between cryptanalysis and &#8220;bughunting.&#8221; These two arenas are by no means mutally exclusive in my view and combinations of the two can be used to devastating effect. In recent days, watermarking attacks on older versions of loop-aes, depending on your threat model for disk encryption, total crushing of WEP, according the its own design goals, and AES cache timing analysis, depending on your predictions for next year, have been in some of the discussions people are having around me.</p>
<p>In all of these cases (&#8220;bughunting,&#8221; cryptanalyzing, or blur), the publishing of security research leads to the ability to improve what is out there, whether by designing and building better primitives, protocols, and systems, or just fixing flaws in current deployments. And, in general, third party audits often play an important part in the review process.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
