Cryptography libraries are inflexible and difficult for developers to integrate with their applications. These difficulties may be contributing to applications, like PGP, that are nonintuitive for end-users and are often used improperly or not at all.
In this paper we argue that the best place for cryptography to be implemented is at the Operating System level rather than the current application-layer approach.
We introduce and define a new general-purpose network cryptography library that integrates directly with the Operating System. This capability is flexible and easy to adopt because it can be used with the sockets interface, which developers are already familiar with, in addition to creating a general cryptography library that can be used in non-network situations.
This technology will allow developers to focus on application usability rather than struggle with the learning curve required to properly use a specific cryptography library as required by current practices.
A holistic cryptography library is the only way to resolve the security and flexibility problems currently being experienced on the Internet.
Although this type of a change could affect a majority of the users on the Internet because they would need to update Operating Systems and applications, this scope is not without precedent. In 1998 RFC2460 was published detailing IPv6 because IPv4 was running out of address space.
This issue became significant on February 13, 2011 when the IPv4 address space was exhausted. IPv6 is being deployed to resolve this exhaustion by supporting more addresses.
This conversion process will occur gradually over time, which will lessen the effect on Internet users since developers will be able to gradually integrate these changes over time and push updates in new software versions.
We describe how TCP/IP’s transmission protocols security could be updated in the same way the IP has been updated, but for a different purpose. This update could support an easy-to use cryptography interface that is flexible.
This functionality should complement existing transmission features, not replace them. The transmission protocols we have described will use the existing C sockets interface and other interfaces currently in use.
Not all protocols need to be encrypted, but any protocol carrying personal or sensitive information should be. This functionality could be built into the OS to make application enhancement less complicated for developers and more secure for everyone.
This capability creates a unified library, based on an Operating System portable application, which is easy for developers to integrate with existing unencrypted network communications. This library would centralize cryptography so future vulnerabilities only need to be patched in a single place.
To read this external content in full, download the paper from the author’s articles archive at the University of Massachusetts, Lowell.