[Cryptography] The paranoid approach to crypto-plumbing

Bill Frantz frantz at pwpconsult.com
Tue Sep 17 17:46:29 EDT 2013

On 9/17/13 at 2:48 AM, iang at iang.org (ianG) wrote:

>The problem with adding multiple algorithms is that you are also adding complexity. ...

Both Perry and Ian point out:
>And, as we know, the algorithms rarely fail. [but systems do] ...

Absolutely! The techniques I suggested used the simplest 
combining function I could think of: XOR. But complexity is the 
mortal enemy of reliability and security.

>Do you really have the evidence that such extra effort is required?

I don't have any evidence, which is why I included Paranoid it 
the message subject. I do know that NSA is well served when 
people believe things about cryptography which aren't true. If 
you believe TLS is broken[1] then you might use something much 
weaker in its place. If you believe AES/RSA/ECDSA etc. are 
strong when they aren't you will continue to rely on them.

>Remember, while you're building this extra capability, 
>customers aren't being protected at all, and are less likely to 
>be so in the future.

I see this a the crux of our problem as responsible crypto 
people. The systems we thought were working are broken. For both 
professional and political reasons we need to fix them quickly.

My morning paper includes the comic "Non Sequitur". Today's 
strip has one of the regular characters being visited by two NSA 
agents. This story is front and center in the public's 
attention. There is no better time to press for whatever 
disruptive changes may be needed.

What we need is working code we can get adopted. It can be 
prototype code with more complete versions to come later. But 
our best chance of adoption is now.

On 9/17/13 at 8:54 AM, perry at piermont.com (Perry E. Metzger) wrote:

>(Of course, if the endpoints are trusted hardware running a formally
>verified capability operating system and you still have time on your
>hands, hey, why not? Of course, when I posted a long message about
>modern formal verification techniques and how they're now practical,
>no one bit on the hook.)

And I happen to have one in my back pocket. :-)

Yes, CapROS[2] isn't proven, but it is mature enough to build 
Perry's household encryption box. (There are ports to both X86 
and ARM. Device drivers are outside the kernel. The IP stack 
works. You probably don't need much more.) Any code that works 
in CapROS will probably port easily to a proven capability OS.

[And yes Perry, I was very impressed by your arguments for 
program proving technology. It is a bit out of my area of 
expertise. But I have always thought that different ways of 
looking at programs can only help them be more reliable, and 
proving is a different way.]

>All that said, even I feel the temptation for low performance
>applications to do something like Bill Frantz suggests. It is in the
>nature of people in our community to like playing with such things.
>Just don't take them *too* seriously please.

Hay, I like playing in the crypto sandbox, and redundancy is a 
classic technique. I have seen questions about DH -- factoring 
and key sizes, and EC -- cooked curves. If you worry about these 
issues, and don't have a third alternative, combining them seems 
like a good idea.

[1] And TLS is big enough to share with the internet the 
characteristic that it can be two things. The internet is always 
up somewhere. Some parts of TLS are secure for certain uses. The 
internet is never all up. Some parts of TLS are seriously broken.

[2] <http://www.capros.org/>

Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032

More information about the cryptography mailing list