[Cryptography] On the Impending Crypto Monoculture

[Andrew Donoho]

> On Mar 27, 2016, at 19:42 , Nemo <nemo at self-evident.org> wrote:
> 
> Andrew Donoho <awd at ddg.com> writes:
> 
>> 	Thank you for correcting me.
> 
> Thank you for being gracious even though I was not. I just get tired of
> software engineers trying to design their own cryptography. How many
> breaks do we have to endure because of this arrogance? The answer
> appears to be "infinity”.



Nemo,



	One learns from many people in many ways. I am always enriched by folks who try to help.

	If you mean by cryptography, am I creating crypto algorithms, then I am not doing cryptography. I am building a system that stores data at rest in a cryptographically private fashion using standard crypto algorithms on commodity MBaaS services. Such a thing does not currently appear to be available for my platform, iOS nor Android. Hence, if I want one, I have to build it.



>> 	Your advice then would be to calculate the HMAC and then
>> 	sign(h(m||hmac))? (Sign the SHA-256 hash of the encrypted
>> 	AES-256-CBC message concatenated with the HMAC.) I can do that.
> 
> My advice is more fundamental, which is "leave the cryptography to the
> cryptographers". I am not one of them. I am not even sure there are any
> on this list.



	I do leave cryptography to the cryptographers. Some of whom have been gracious enough to advise me privately on my designs and architecture. They concur that I need to build my system from scratch using standard crypto algorithms. These are the kinds systems specifically covered in “Cryptography Engineering” by Ferguson, Schneier, and Kohno.

	For example, since your comment, I have also had other private communications that are opposite to your advice about EtM vs. EtS. These systems are subtle and need careful thought. Both yours and these other comments are being factored into my design. Hence, without burdening this group, I read and learn. I occasionally add what I hope are useful facts from my own experience being an iOS developer. 



> If your cryptographic protocol does not come with a security proof, then
> you are doing it wrong. Note that a "security proof" is not really a
> proof of security, because there is no such thing. Rather, it is a
> collection of provable statements of the form "if an attacker could do
> Y, they could also do X", where X is something everyone agrees looks
> hard, like "violate IND-CPA for AES”.



	In my experience, very little code, even crypto code, is proven. Typically, it is engineered to death by multiple reviews and by attacks from hostile players. Could things be different? Yes. Are the tools mature enough for me to apply them to my code as if they were unit tests? Unlikely.

	But your point is taken. I am addressing it by asking reviewers to engage in my design process early. I intend to pay for security reviews. Proofs? Perhaps, but you are the first person to try and impose that requirement on me. More thought and study are needed about what is meant by a secure system.



> If you are not comfortable reading and creating such proofs, then my
> advice is to obtain your protocol (and preferably your code) from
> someone who is.



	I’m a big believer in using other people’s code, OPC. It is much more valuable than OPM. My code is not available from someone else. I’ve looked. It would be way cheaper to buy than build.



> Or, more briefly: The first rule of cryptography is to use someone
> else's design. The second rule of cryptography is to use someone else's
> implementation.



	When I can use OPC, I do. 



> Unfortunately, in my experience, there are only two kinds of software
> engineers in the world: Those who do not need to be told any of this,
> and those who will not listen when told.



	While I’m pretty sure you are going to lump me in your second category, what would you have me do? I cannot buy it. Not build it? I have customers who use the first generation of my system today. It is well received by them. They have new requirements they wish me to meet. The “Top Men” who have heretofore advised me on my crypto system design think I’ve done a good job. Could I get better? Yes. Will I? Yes. Will I adopt new methodologies as needed? Over the last 30+ years of my professional career I have done so. I suspect I’ll continue learning and growing.

	Regardless, thank you for sharing your insight and spending your precious time educating me.



Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
awd at DDG.com, +1 (512) 750-7596, twitter.com/adonoho

New: Spot marks the taX™ App, <http://SpotMarksTheTaX.com>
Retweever Family: <http://Image.Retweever.com>, <http://Retweever.com>

“… things will change in ways that are unimaginable."
	Bruce Sterling, January 02, 2009