Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Peter Gutmann
"James A. Donald" writes: >It takes about one hour per hundred lines of source code. I would hope that anyone clever enough to implement some very tricky crypto algorithms would also be clever enough to backdoor them in a way that could never be discovered. Or to turn that around, if you were

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread James A. Donald
Sandy Harris writes: First, it is open source. The code can be audited, and anyone with really On 2010-12-16 2:12 PM, Chris Palmer wrote: People make too much of this. In my experience, given the level of detail that you need to absorb to properly audit this kind of C code, it's not really all

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Chris Palmer
Sandy Harris writes: > First, it is open source. The code can be audited, and anyone with really People make too much of this. In my experience, given the level of detail that you need to absorb to properly audit this kind of C code, it's not really all that different from auditing disassembled o

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Sandy Harris
On Thu, Dec 16, 2010 at 4:38 AM, Jon Callas wrote: >> That said, I would not recommend people to write their own crypto, as >> cryptography is hard enough to foster any kind of fault, glitch or >> defect. In turn, this may leads to incidents that promise to be no >> less severe than those arising

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Jon Callas
> That said, I would not recommend people to write their own crypto, as > cryptography is hard enough to foster any kind of fault, glitch or > defect. In turn, this may leads to incidents that promise to be no > less severe than those arising from a backdoor in OpenBSD IPSec stack, > if any. Perha

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Jon Callas
Oh, come on. The summary of this is: I worked on X_1, X_2, ... X_n. I used to have a clearance but now I don't, so therefore what I'm saying is true. You can trust me because I've been quoted by the New York Times. Here's what I said. It is certainly possible that there are back doors somewhere

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Alfonso De Gregorio
On Wed, Dec 15, 2010 at 4:11 AM, Rayservers wrote: > Moral: never depend on only one network security layer, and write and verify > your own crypto. Recall Debian and OpenSSL. A cautionary word about the risks of software monoculture and the importance of diversity and depth of defense for the r

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Marsh Ray
On 12/15/2010 02:31 AM, Jon Callas wrote: But this way, the slur has been made in a way that is impossible to discuss. I think evidence is called for, or failing that, and actual description of the flaw. Hot off the presses. Haven't yet decided how much this counts for information. But he do

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Marsh Ray
On 12/15/2010 01:38 AM, Peter Gutmann wrote: This is one of those things where those who know the truth won't be able to talk about it, and those who can openly talk about it don't know the truth. Having pointed out that distinction, I'll now talk about it :-). It violates the principle of leas

Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

2010-12-15 Thread Jon Callas
Me, I figure that extraordinary claims require a smidgen of actual evidence. It's really easy to say that a decade ago, system foo had back doors snuck in it. But -- what were the back doors? A bum random number generator? Keygen that made RSA keys with a known, fixed prime? What? My view is th