<?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"
	>
<channel>
	<title>Comments on: Security through Obscurity</title>
	<atom:link href="http://voipsa.org/blog/2006/12/08/security-through-obscurity/feed/" rel="self" type="application/rss+xml" />
	<link>http://voipsa.org/blog/2006/12/08/security-through-obscurity/</link>
	<description>Collective thoughts and musings on the state of VoIP security today.</description>
	<pubDate>Thu, 03 Jul 2008 22:45:35 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Martyn Davies</title>
		<link>http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-44689</link>
		<dc:creator>Martyn Davies</dc:creator>
		<pubDate>Fri, 13 Apr 2007 10:13:45 +0000</pubDate>
		<guid isPermaLink="false">http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-44689</guid>
		<description>Good to see the 'long tail' effect of the blogosphere at work.  Thanks for commenting, Steve, it's good to hear the argument in your own words.</description>
		<content:encoded><![CDATA[<p>Good to see the &#8216;long tail&#8217; effect of the blogosphere at work.  Thanks for commenting, Steve, it&#8217;s good to hear the argument in your own words.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Babbage</title>
		<link>http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-44573</link>
		<dc:creator>Steve Babbage</dc:creator>
		<pubDate>Thu, 12 Apr 2007 15:27:58 +0000</pubDate>
		<guid isPermaLink="false">http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-44573</guid>
		<description>I only just discovered this blog ....

I certainly agree with Dustin that meddling with a well-trusted algorithm is not something to be done lightly.  But a competent cryptographer can add something on top of a well-proven algorithm in such a way that it's intuitively obvious, or even provable, that all the strength of the well-trusted algorithm is retained (i.e. if you can break the overall system, then you can break the underlying well-trusted algorithm).

I'm a competent cryptographer.  I would trust myself to design a cryptosystem based on AES but with some additional secret components, in such a way that all the strength of AES is retained.  I wouldn't trust myself to design a brand new secret algorithm, alone, that no one could break - and I don't think any other wise cryptographer would trust herself to do so either.  To build a strong fundamental algorithm needs the collective analysis of many experts, over a long period of time; to build a strong hybrid algorithm from an EXISTING strong fundamental algorithm needs fewer eyes and less time.

So I do believe you can have the best of both worlds: all the benefits of the well-trusted algorithm to protect you against mathematical cryptanalysis, plus some additional obscurity to help protect against (for instance) side channel attacks.</description>
		<content:encoded><![CDATA[<p>I only just discovered this blog &#8230;.</p>
<p>I certainly agree with Dustin that meddling with a well-trusted algorithm is not something to be done lightly.  But a competent cryptographer can add something on top of a well-proven algorithm in such a way that it&#8217;s intuitively obvious, or even provable, that all the strength of the well-trusted algorithm is retained (i.e. if you can break the overall system, then you can break the underlying well-trusted algorithm).</p>
<p>I&#8217;m a competent cryptographer.  I would trust myself to design a cryptosystem based on AES but with some additional secret components, in such a way that all the strength of AES is retained.  I wouldn&#8217;t trust myself to design a brand new secret algorithm, alone, that no one could break - and I don&#8217;t think any other wise cryptographer would trust herself to do so either.  To build a strong fundamental algorithm needs the collective analysis of many experts, over a long period of time; to build a strong hybrid algorithm from an EXISTING strong fundamental algorithm needs fewer eyes and less time.</p>
<p>So I do believe you can have the best of both worlds: all the benefits of the well-trusted algorithm to protect you against mathematical cryptanalysis, plus some additional obscurity to help protect against (for instance) side channel attacks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vulnerability Disclosure, Cryptography Research, and Open Source &#171; Dustin D. Trammell</title>
		<link>http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-42014</link>
		<dc:creator>Vulnerability Disclosure, Cryptography Research, and Open Source &#171; Dustin D. Trammell</dc:creator>
		<pubDate>Mon, 02 Apr 2007 22:07:06 +0000</pubDate>
		<guid isPermaLink="false">http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-42014</guid>
		<description>[...] To hear me make the case for some secrecy, or rather, obscurity, you can find some similar commentary to the above regarding cryptosystems in my response to a post by Martin Davies over at the Voice of VoIPSA Blog entitled Security Through Obscurity. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] To hear me make the case for some secrecy, or rather, obscurity, you can find some similar commentary to the above regarding cryptosystems in my response to a post by Martin Davies over at the Voice of VoIPSA Blog entitled Security Through Obscurity. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dustin D. Trammell</title>
		<link>http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-7652</link>
		<dc:creator>Dustin D. Trammell</dc:creator>
		<pubDate>Fri, 08 Dec 2006 22:55:33 +0000</pubDate>
		<guid isPermaLink="false">http://voipsa.org/blog/2006/12/08/security-through-obscurity/#comment-7652</guid>
		<description>Unfortunately, adding anything to a cryptosystem after the intellectual rigour has been done by the crypto community to prove the cryptosystem can potentially weaken or create vulnerabilities in the system.  At the end of the day, you would still have a component of your cryptosystem that lacks the peer-review and testing that the rest of the system had attained, thus making it potentially less secure.  Quite often, differences in implementation of the same algorithm or even different utilizations of the same implementation can introduce vulnerabilities that were nonexistant in the original vetted algorithm.

Essentially it comes down to balancing how much of your cryptosystem as a whole is public and has been extensively reviewed and tested and how much of it is not.  It may be worth the potential insecurity for a component of your cryptosystem to be private if perhaps it's a very small part of the system as a whole, however the more of your system that is not public and has not recieved extensive review increases the potential for insecurity.  As it usually is with security it's a trade-off and becomes a question of how comfortable you are with the risk that that trade-off creates.

In my opinion, the hurdle that you're throwing in front of an attacker via obscurity probably isn't worth as much as the real security that you would achieve by having the entire cryptosystem publicly peer-reviewed.  Keep in mind that my opinion here is very specific to cryptosystems;  There are cases with other technologies where I believe you can successfully create a hurdle of obscurity without impacting the actual security of the technology itself.  In such cases as those, it's a no-brainer to add the obscurity as well.</description>
		<content:encoded><![CDATA[<p>Unfortunately, adding anything to a cryptosystem after the intellectual rigour has been done by the crypto community to prove the cryptosystem can potentially weaken or create vulnerabilities in the system.  At the end of the day, you would still have a component of your cryptosystem that lacks the peer-review and testing that the rest of the system had attained, thus making it potentially less secure.  Quite often, differences in implementation of the same algorithm or even different utilizations of the same implementation can introduce vulnerabilities that were nonexistant in the original vetted algorithm.</p>
<p>Essentially it comes down to balancing how much of your cryptosystem as a whole is public and has been extensively reviewed and tested and how much of it is not.  It may be worth the potential insecurity for a component of your cryptosystem to be private if perhaps it&#8217;s a very small part of the system as a whole, however the more of your system that is not public and has not recieved extensive review increases the potential for insecurity.  As it usually is with security it&#8217;s a trade-off and becomes a question of how comfortable you are with the risk that that trade-off creates.</p>
<p>In my opinion, the hurdle that you&#8217;re throwing in front of an attacker via obscurity probably isn&#8217;t worth as much as the real security that you would achieve by having the entire cryptosystem publicly peer-reviewed.  Keep in mind that my opinion here is very specific to cryptosystems;  There are cases with other technologies where I believe you can successfully create a hurdle of obscurity without impacting the actual security of the technology itself.  In such cases as those, it&#8217;s a no-brainer to add the obscurity as well.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
