[Discuss] AeroFS

[smallm at panix.com (Mike Small)]

Richard Pieri <richard.pieri at gmail.com> 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.