Rule 8 of 12 · Chapter II — Designing for Disclosure
Validate the design by handing a full specification and a working implementation to someone whose job is to break it.
Why this rule exists
Everything up to this point is intention; adversarial testing is the only evidence. A reviewer given partial information reports on the gap in their knowledge rather than on your system, and you learn nothing about what happens when the specification is on the attacker's desk. Withholding details makes the engagement look better and your system no safer.
In practice
Give the testers the protocol document, the source, the build, the key hierarchy, and the deployment topology — everything except live production key material. Ask them to attack the design as well as the code, and to state what they could not get to and why. Treat findings that say 'this only works because we were not told X' as the most important ones, and fix the design, not the disclosure.
When it doesn't apply
Black-box exercises still have a place when you are testing detection, response, or an operations team rather than the cryptographic design itself. Keep that assessment separate and do not let its clean result stand in for a specification review.