I'm posting this message in the spirit of honesty and transparency. My name was recently involved in allegations of FBI involvement in the development of OpenBSD IPSEC. For the record: I am not, nor have I ever been, affiliated with or employed by the FBI or any other government agency. My advocacy of OpenBSD has been strictly due to my appreciation of the project. There is no secret agenda here. -- Scott

If this type of thing really did happen and this actually is going on something as simple as systrace or dtrace would have found it correct? Surely folks have monitored and audited the actual function and traffic that goes across the wire... conversely amd has a "debugger" that'll get you access to more goodies than you could imagine and just recently I discovered a similar "debugger" on the wifi chip on my phone. Guess its better it doesn't work anyhow ;) Brandon

It's generally impossible to see from a datastream if it leaks key data. It can be pretty damn hard to verify code to show it does not leak key data

On Wed, 15 Dec 2010 07:48:46 +0100 I think if it leaks data, it must leak data somewhere, i.e. there must be a server somewhere, and this server must have an ip. so if you look at your traffic, and you will find an ip other then ip of your server, you will know where the leak goes. -- With best regards, Gregory Edigarov

That's not necessary, key data can be leaked in or alongside the encrypted datastream itself, there's no need to send it anywhere. And it doesn't have to be a whole key, just something that makes things cryptanalysis simpler. *If there's something there*. Remember these are still just allegations at this stage.

That fixes the issue for me and seems like a reasonable approach. The bug also exists in newer development versions of nvi. - todd

Yup, that's fine. This was in place in this initial import of this code, suprised i've not noticed and cleaned it up yet. -- In Pocataligo, Georgia, it is a violation for a woman over 200 pounds and attired in shorts to pilot or ride in an airplane.

This is a MIME-encoded message that mnasskdj sent through Multiply. To read it, you need a HTML-capable mail client.

Hi Thomas, There are a few clean-up diffs floating around the guys in the logs, some of which has some of the stuff you have below. The clean-ups have not been forgotten. Cheers,

Is it reasonable to assume the patch will be accepted? Thanks for looking, --patrick

On Wed, Dec 15, 2010 at 11:33 AM, Peter N. M. Hansteen <peter@bsdly.net> http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-al It is easy to shoot one's mouth off like that about bounty offered, given the ridiculously constrained "conditions" the bounty is offered under. He might as well offered a million USD. No one will be able to prove this under these restrictions. --patrick

His conditions aren't "ridiculously constrained", they seem to be pretty much approproiate for the allegations. -d

seriously? # - that the OpenBSD Crypto Framework contains vulnerabilities # which can be exploited by an eavesdropper to recover plaintext # from an IPSec stream, There is a big assumption about the alleged backdoor or leak; i.e., that it is used to directly extract "plaintext" out of an IPSEC stream. OK. Maybe reasonable. # - that these vulnerabilities can be traced directly to code # submitted by Jason Wright and / or other developers linked # to Perry, and Do they really ...

Oepeirh b hmrepmer l`c`ghm WWW.GOORIN.RU Nrohq`r|q nr p`qq{kjh [demime 1.01d removed an attachment of type image/jpeg which had a name of mid31__owear18a.jpg]

USB. Need I say more? :-) I now have a USB device in hand which has a 'READONLY' physical switch on the top. If set to READONLY, this device spews error messages when writes are attempted. And the device freaks out so that ALL subsequent i/o's fail. I saw this: http://lists.wpkg.org/pipermail/stgt/2010-March/003569.html and hacked together the diff below to record the WRITE PROTECT info that dev_spec provides. I unified the sd and st cases to use the same flag. The USB device is now ...