"James A. Donald"<[email protected]> 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.
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
