Encryption seems to be the new bone of contention

This entry was originally at http://www.whitehawksoftware.com and then moved here.

It has been a discussion item for a long time. The FBI wants to limit encryption, the president now agrees with scientists, encryption should not be limited. (Why an agency can push against the president beats me.)

Within hours after the Paris terror attack it was mentioned that encryption was a big element of enabling these attacks. I don’t know how anybody could analyze such a complex attack in such short time. In my opinion the arguments must have been long prepared and the attack been the awaited opportunity to present the arguments.

The current discussion about encryption has been going on for quite a long time. But in actuality, the discussion was even going on much longer. Since ‘prehistoric’ times, even before the internet (late 70s, early 80s). Already then there was had a big flare about requiring back doors and special hardware chips providing encryption with back doors. With no warning and no explanation known to me, that discussion simply ceased. Maybe nobody was able to develop such chips which actually would work and have a safe backdoor. Could anybody really believe that if such a thing could have been build, not 200 startup companies would try to market it today?

And even before prehistoric times, in internet times about when humans were climbing down from the trees and learned walking, there were US export restrictions, just as today, against cryptography and encryption hardware. The result was very simple: such chips were build outside of the US borders and used everywhere, even imported to the US.

An iceberg represents visible and invisible use of encryption.

Lets be more precise: Today, it is not about controlling and forbidding encryption but about providing backdoors. The obvious, popular, and I think very true argument is: When we build in backdoors for the “good” guys, the “bad” guys will find and use them.

Anyway, so we are supposed to limit encryption. The “good” guys can’t use it anymore. Do you really think the “bad” guys will follow and not use unlimited encryption for their communication? The genie is out of the bottle and entropy prevents it from crawling back into the bottle!

Now lets think a little bit more about what happened between ice ages and when the Titanic was sinking. In particular, what is the percentage of an ice-berg above the waterline? That matches the fraction of encryption that is used for human communication. But there is more outside to obvious human communication area. Cyber crooks can eves-drop on all communication. It’s not clear to me whether there will be a way left to detect tampering with communication. I think somebody went througho a lot of effort to build a division line between hash codes and encryption.

Also: No more credit cards. No more ATM machines. No more safe backups… By the way: No more White Hawk Software.

What if safe backdoors would really exist? Some applications might still work. But some of them wouldn’t. Consider the White Hawk Software user-interface advantage: “One way to direct the strength of a protection is to trade performance for protection strength”. That shows that already now without backdoors performance-limits are painful. Something companies like White Hawk Software need is called “white box” cryptography. (White box cryptography means: Even with an attacker single-stepping the decoding, the passwords (and maybe also) the user data can not be uncovered.) Ok, so fantasy and genies could manage back doors in cryptography. What do you think about managing back doors in “white-box” cryptography? Can I give you a lollypop?

Experience has proven again and again in computer science that: The whole is more than the sum of the parts; sometime to its advantage, about equally often to its disadvantage. So you find an algorithm to do “A”. You also find an algorithm to do “B”. What can we say about an single algorithm to do “A+B”? Yes, cases exist where “A+B” is easier to do. This is cool, and when it happens we are very happy. More often however, an algorithm for “A+B” is about as complex as an algorithm for “A” times and an algorithm for “B’. Of course occasionally it is much worse and exponential functions need to be used. Can you imagine what performance costs would occur if the “decryption-of-code” part in tamper-proofing would require a backdoor?

Not many people will care about White Hawk Software, right? But what about all the critical infrastructure that needs software protection and other stuff protected with White Hawk Software? i.e. the smart grid, the connected car or automated manufacturing? A totally different story…

Advertisement

Programming style

See here: http://cjacobi.com/misc/csharp_style.pdf

I have spent the last years writing substantial amounts of C# code for White Hawk Software.  I found it rather important that my code can be maintained; more precisely: that I myself will be able to understand my own code when I need to read it again.

It would be nice if I could pick up some other style guide.  However, I found that most code is written for people with huge memory capacities.  I had to write in a style which makes “code in the large” readable; I don’t care about small examples with lots of text explaining what it does.  If my memory needs lots of help and style-guided support to understand my programs, I guess other people might consider my code too easy to read.  That is however not something I have experienced.

These features have been paramount for this style guide

• The C# language construct, a “using alias directive” is prominently used.  In fact, this feature was the main reason wich caused me to choose C# for programming-in-the-large.
• From Xerox Parc I took the idea that “values” are key, and the difference between variables, constants and macros is irrelevant.  The one thing different, are Types.
• From C++ I picked the habit of using small capitalization for methods.
• Monitor size matters.
• Programmers read source code.  Try reading this, putting stress on different parts of the sentence…

I found writing a style guide difficult. A style guide isn’t a beginner text in programming, nor should it be a straight jacket for experts. Writing a style guide isn’t a goal, it is a means to programming.   Writing a book-sized style-guide may be very interesting, but it doesn’t leave time for actual programming.

If you would like to discuss this style, my bulletin board has reserved some space.

Chris

Hello world!

This is my first post to this blog.   For the longest time there wasn’t much I wanted to say.  Today is five years later, much has changed, and I’m editing that old “hello world” post to keep its original date:  Now, I plan on occasionally telling some facts about my new startup company which might not exactly fit into the category of “glossy paper”.

White Hawk Software

My company can protect your software from being hacked…