Open Invitation to the Pricate Sector and Cryptographic Corporations:
We do understand that some material simply has to be protected, for a variety of reasons. However, that does not preclude cooperation. We would welcome any company or organization involved in cryptography to work with us to provide secure mechanisms by which their encryption system could be accessed via mcryptlib. Indeed, we would welcome any assistance from the private sector with the sole reminder that code whose restrictions conflict with the GPL cannot be embedded in mcrypt or mcryptlib and cannot be provided by us.
Why should any organization do such a thing? It showcases their technology. It provides a level playing-field in which they can demonstrate the superiority of their work, the advantages of their mechanisms, and the benefits of their approach. It would do so in a way that doesn't require re-coding on the part of evaluators and therefore gives potential customers an incentive to take a look.
Doesn't this mean that the module has to be Open Source? No. Binary-only modules are entirely acceptable. The only restrictions are that they have to conform to the mcryptlib API, and have to be shipped by someone other than us. We would be happy to provide links to such modules.
What other possible benefits are there? There are many International standards in computing. CORBA, SQL, HTML, etc, are all examples of open standards that have succeeded in the market place. We see no reason why this cannot happen in cryptography. NESSIE and NIST use similar, but not identical, APIs. The current dispute between SSH and the IETF demonstrates that, even when a standard is established, corporations have to be wary when using it.
It is therefore my proposal to produce a definitive, universal API for cryptography. This API would allow you to define scopes. eg: in the US, for Government work, you are required to use FIPS-approved algorithms. It would allow you to define any oter restictions or tuning requirements you might have. Within those parameters, the software you write could use any encryption and authentication algorithm available. Without you having to change a single line of code.
By being flexible, code written to comply with US restrictions could be exported to Europe, and would automatically meet EU restrictions. All you'd need to change is the file with the scoping rules. One codebase meeting many rules and regulations. One version + many markets = greater profits.
Is the existing code ready for this? It's close, but we need the help of people who have actual problems in security to solve, or who have markets they can't exploit because it's too expensive to pay their programmers merely to keep track of the latest regulations in some sector. Sure, the people who are working on this project are all top-line programmers. The software we have would not exist if we weren't. If the only information the provate sector provided us was a list of common needs and complaints, it would be enough. From there, we could develop a standard that met those needs and complaints, and which allowed businesses to concentrate on their business and not on the politics of the hour.
Sounds too good to be true? It's already happened with the Internet, with databases, with electronic mail, with the world-wide web, and even with programs distributed over many computers. There are recognised, established standards for all of these. It doesn't matter if the database software is replaced, or a different electronic mail server is used. Everything works the same. You don't need to re-write the Windows Operating System, simply because something changes.
With encryption, until now, it's not been so simple. Everyone has their own API. Everyone has their own approach. A few libraries exist that support multiple algorithms, but even those aren't interchangable. It's not that people are going their own direction, it's that they're making it so hard to follow.
I therefore ask those in the private sector to use libmcrypt and mcrypt as a starting point in producing an acceptable, practical standard that industry can adopt, and to help those of us who maintain these programs in moving towards such a standard.
Thank you for reading this open letter, and for any response you might have.
John Smith, current maintainer for mcrypt and mcryptlib