Allegation that the OpenBSD IPSEC stack contains FBI backdoors

[Coleman Kane]

On 12/14/2010 10:50 PM, Benjamin Scott wrote:
> On Tue, Dec 14, 2010 at 9:35 PM, Roger H. Goun <roger at bcah.com> wrote:
>> http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
> "Since we had the first IPSEC stack available for free, large parts of
> the code are now found in many other projects/products.   Over 10
> years..."
>
>   And no one else in the world has looked at the code and noticed the
> backdoors in the intervening ten years?  While possible, it makes the
> story a bit harder to swallow.
>
> -- Ben
It is not always so obvious. Many encryption algorithms and key exchange
systems back then relied upon large hard-coded constant-value lookup
tables for various purposes in the algorithm. These would either be hard
coded right in the source code, or would be the product of a run-time
formula that generated dynamic tables according to the key provided by
the user.

The origins of the hard-coded cases could be entirely mysterious to any
developers, and by their nature would be good places to hide obscure
weakness. The 3DES algorithm was, for years, rumored to contain such a
weakness in the design of its hard-wired S-box lookup tables. Much
research has gone in to studying them, and it appears more likely that
they actually do work as intended: they increase resistance to some
common cryptanalysis techniques.

In another case, it was rumored for a time that Rijndael was chosen over
Twofish as the sanctioned AES
algorithm because of supposed weaknesses in the algorithm's S-box
generation code so that the US could crack it.

In some cases, the algorithms used may just rely upon arbitrarily-picked
integer constants, and in other cases, like above, they might have been
very specifically selected. In many cases, the author's word and some
published research may not have been scrutinized. The trust that many
non-mathematician security developers put into block cipher algorithms
is akin to the trust in OpenVPN that you or I may have in simply
installing it and assuming that it is keeping our stuff private.

My guess is that this event may spark an urgent code-audit on the common
security systems which we rely upon out there. It's good to have these
come along every once in awhile, as it reminds us that we need to keep
studying this stuff. There are scant few software that we rely upon on a
daily basis that are more complex than encryption libraries, and they
just also happen to be the most opaque to us as well.

-- 
Coleman Kane