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

James A. Donald jamesd at echeque.com
Fri Dec 17 01:06:52 EST 2010


"James A. Donald"<jamesd at echeque.com>  writes:
>> Crypto algorithms have standard reference implementations, which are to a
>> greater or lesser extent copied wholesale. Any deviation from the usual is apt
>> to be noticeable.

On 2010-12-17 2:30 PM, Peter Gutmann wrote:
> That would require that you compare the code for algorithm X in project Y to
> the originaly copy held who knows where, taking into account that the version
> used in project Y may be several versions out of date from the reference one
> (and by several versions I mean "ten years or more" in some cases), and that
> it'll have been hacked over by who knows how many others for portability and
> performance reasons.  There'll be no way to tell whether any of the dozens of
> tweaks and changes are a backdoor or not.  How would you tell whether
> something like a cast "( uint32_t ) /* For Solaris 9 with the SunPro 4.2
> compiler */" is be a portability fix or a backdoor?

By figuring out whether it is logically equivalent to the reference 
implementation.

> If I wanted to backdoor
> something, I'd go for private-key leakage in DLP PKCs, which are notoriously
> bad in terms of leaking key bits if you even look at them funny.

If you are going to successfully interoperate with an actually good 
implementation, with someone else's implementation, then the only way to 
play funny games is at the protocol negotiation stage (which should show 
up in unit test) or at the stage where one constructs supposedly secret 
random numbers that are not in fact very random or secret at all.

If you are constructing random numbers by a well known and documented 
algorithm, then it your code can be checked for compliance with that 
algorithm at something around 100 lines per hour.  Of course, if you are 
making up your own algorithm, then no one can know if they are random or 
not, which is why you are not supposed to make up your own algorithm.




More information about the cryptography mailing list