On 9/17/13 at 2:48 AM, [email protected] (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, [email protected] (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
_______________________________________________
The cryptography mailing list
[email protected]
http://www.metzdowd.com/mailman/listinfo/cryptography
