But our security design is a company secret, shouldn't this provide high security?
Most probably, no.
Modern cryptography is driven by something known as Kerckhoffs' assumption. According to this assumption, system designers must assume that the attacker has full knowledge of the cryptographic functions in use, except for the secret keys. In other words, this means that security cannot be based on unknown characteristics of the system.
There are several reasons for this:
First of all, keeping a design secret is in fact pretty difficult to achieve: reverse engineering, former employees, patent search, are only a few of the numerous means an attacker has to obtain information about the way things work. Generally speaking, a widespread system will sooner or later be revealed.
Second, it is possible: nowadays' state-of-the-art allows us to build cryptographic primitives that will remain secure even if their details are publicly known, and huge amounts of data exchanges are observed by the attacker.
Third, it offers a basis for peer review, which is often a good idea. If you publish your intended security design before it is actually deployed, some (good and bad) guys are likely to start studying it. If there is a serious design flaw, chances are that some good guys will reveal it, which will allow you to correct it while there is still time.
Many people tend to disregard this assumption, confident that their secret, self-made implementation will be the exception to the rule, and the press is full of stories of large security projects that failed miserably once deployed, just after some pirates have recovered the code.
On the other hand, Kerckhoffs' assumption does not mean that design has to be revealed. As external consultant, our goal is to design a system that will keep secure even if much information about it gets revealed… which does not mean it will! Our work is usually performed under NDA. As the final customer, you may keep the entire property of the system we design for you, and therefore decide what exactly will be disclosed to third-parties.
Secure Hash Standard (SHS)
SHA-1 Broken: Collision Attack Found, Implications for Cryptography
NIST is issuing a tentative agenda for the development of a SHA successor
Does the proof of the Riemann hypothesis really bring the whole of ecommerce to its knees?
The Cost of Insecurity: Understanding the “Non-Loss” Benefit of Cryptography
The Cost of “Just Enough” Security: Why Good Cryptography isn’t More Expensive
Cryptographer Consulting: Security Transparency vs. Relying on Ourselves
Why do people believe they should handle cryptography themselves?
The Illusion of Simplicity: Why Designing Your Own Cryptography Fails
Why Do I Need a Cryptographer?
Founding Members
Academic and Historical References
What Is Our Methodology?
Security Courses, Cryptography Consulting, System Evaluation & TTP Services
Bridging The Gap Between Scientific Research And Industry Needs