Unless of course someone was capturing the entire stream as it traversed the
internet and then simply extracted the keys later on.
On Dec 15, 2010 5:22 AM, "Gregory Edigarov" <g...@bestnet.kharkov.ua> wrote:
> On Wed, 15 Dec 2010 07:48:46 +0100
> Otto Moerbeek <o...@drijf.net> wrote:
>
>> On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote:
>>
>> > 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 ;)
>>
>> 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
>
> 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.
>
> just my 0.5 cents
>
>> -Otto
>>
>> > Brandon
>> > On Dec 14, 2010 8:33 PM, "Damien Miller" <d...@mindrot.org> wrote:
>> > > On Tue, 14 Dec 2010, Bob Beck wrote:
>> > >
>> > >> I wonder a lot about the motives of the original sender sending
>> > >> that
>> > message.
>> > >
>> > > Ignoring motive, and looking at opportunity:
>> > >
>> > > We have never allowed US citizens or foreign citizens working in
>> > > the US to hack on crypto code (Niels Provos used to make trips to
>> > > Canada to develop OpenSSH for this reason), so direct
>> > > interference in the crypto code is unlikely. It would also be
>> > > fairly obvious - the crypto code works as pretty basic block
>> > > transform API, and there aren't many places where one could
>> > > smuggle key bytes out. We always used arcrandom() for generating
>> > > random numbers when we needed them, so deliberate biases of key
>> > > material, etc would be quite visible.
>> > >
>> > > So a subverted developer would probably need to work on the
>> > > network stack. I can think of a few obvious ways that they could
>> > > leak plaintext or key material:
>> > >
>> > > 1. Ensure that key bytes somehow wind up as padding. This would
>> > > be pretty obvious, since current IPsec standards require
>> > > deterministic padding. Our legacy random padding uses
>> > > arc4random_buf().
>> > >
>> > > 2. Arrange for particular structures to be adjacent to
>> > > interesting data, like raw or scheduled keys and "accidentally"
>> > > copy too much.
>> > >
>> > > 3. Arrange for mbufs that previously contained plaintext or other
>> > > interesting material to be "accidentally" reused. This seems to
>> > > me the most likely avenue, and there have been bugs of this type
>> > > found before. It's a pretty common mistake, so it is attractive
>> > > for deniability, but it seems difficult to make this a reliable
>> > > exploit. If I was doing it, I'd try to make the reuse happen on
>> > > something like ICMP errors, so I could send error-inducing probe
>> > > packets at times I thought were interesting :)
>> > >
>> > > 4. Introduce timing side-channel leaks. These weren't widely
>> > > talked about back in 2000 (at least not in the public domain),
>> > > but have been well researched in the years since then. We have
>> > > already introduced countermeasures against the obvious memcmp()
>> > > leaks using timingsafe_bcmp(), but more subtle leaks could still
>> > > remain.
>> > >
>> > > If anyone is concerned that a backdoor may exist and is keen to
>> > > audit the network stack, then these are the places I'd recommend
>> > > starting from.
>> > >
>> > > -d
>>
>
>
> --
> With best regards,
> Gregory Edigarov
