Richard Pieri <[email protected]> writes: > Mike Small wrote: >> How do you examine closed source crypto? It's a fair argument that the >> code being available isn't sufficient to have all its bugs (intentional >> or normal) found, but if the code's not available at all... > > That's both simple and not so simple: you compare what should be > deterministic results, and you look for deterministic results when > there should be none. In other words, you attack the closed cipher or > hash implementation of an algorithm the same way you would attack an > open source implementation of that algorithm.
So you're left with only black box testing. No static analysis tools, no runtime memory debuggers, no discussing the problem and the general code quality in public forums, no forking the project and trimming the awful 300,000 lines down to something more manageable with the "exploit mitigation countermeasures" removed ( http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse https://github.com/jmhodges/libssl/commit/a859bfd6cf329c704dfc609d8cd1cb88d5c96b14 ), no disabling compiled in features you didn't need and disagreed with in the first place (https://github.com/jmhodges/libssl/commit/2d2fc3d85a58481a8879f480760e23f93c83ee3b ), no looking through the maintainers' bug reporting systems or mailing lists for patches they failed to incorporate (http://freshbsd.org/commit/openbsd/11cbae04e4e3f497c05688fd939136f8e35b52e2 ), etc. And what about side channels? Surely it's easier to find them if you can examine (all of) the code. _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
