Although encryption is the primary goal, many encryption systems depend on a combination of tools to accomplish other tasks. Public-key cryptography is one of those tools. Although public-key cryptography is rarely used for encryption of long strings of data because of its fairly slow performance, public keys are used heavily for signing messages (authentication and integrity checking) as well as encrypting short strings (such as session keys).
One algorithm is heavily used in public-key cryptography: Rivest-Shamir-Adleman (RSA), the original public-key cryptography algorithm from 1978. The Digital Signature Algorithm, or DSA, based on a 1984 algorithm developed by Egyptian cryptographer Taher Elgamal and used only for signing, not encrypting, is also widely available.
When network managers have a choice between the two, typically RSA is more widely supported — mainly because it can be more widely applied.
One important consideration for security-conscious managers is key size. RSA keys should be chosen based on the sensitivity of the information being protected and the expected lifetime of the sensitivity. Keys sizes of 512 bits are now considered insecure — one was “broken” in 1999 in seven months.
RSA (the company), through its RSA Laboratories, suggests that organizations select key sizes of 1,024 bits (considered about equal to an 80-bit symmetric encryption key) for ordinary enterprise use and 2,048 bits (similar in strength to a 112-bit symmetric encryption key) for extremely valuable data, such as certification authority root keys.
For information that must be protected for more than 20 years, the U.S. National Institute of Standards and Technology recommends a 3,072-bit RSA key, which is roughly equivalent in strength to a 128-bit symmetric encryption key.
An even more important area of attention when using RSA is key lifecycle. Most RSA (and DSA) keys are used many times over their lifetime; for instance, when incorporated into digital certificates. Enterprise security managers should strictly require that keys be replaced every few years. A maximum of three years is considered good practice.
What Is Elliptic Curve Cryptography?
When an organization doesn’t control the infrastructure, there’s a huge question to answer: Will the organization’s cloud service provider safeguard its data? Or is it up to the entity to do that?
It’s critical to alleviate this concern through encryption use. Any cloud application, whether private, public or hybrid, must use an encrypted VPN for all communication. Encrypting data in transit solves some problems and is a clear requirement for any cloud-based application. But encrypting data in transit doesn’t help secure data at rest.
Cloud applications have two significant risks that encryption can help mitigate. One risk is familiar: An application could have holes or bugs that let an unauthorized party view sensitive data. The other risk, more specific to cloud service providers, is that the infrastructure might not be secure.
Encrypting data in the app protects against both types of risk but may not be desirable. For example, cloud-based email, such as an outsourced Microsoft Exchange service, will easily support Secure/Multipurpose Internet Mail Extensions to encrypt sensitive mail on the server. But S/MIME presents a different set of problems, including interference with archiving and search, long-term key storage issues, and generally weak support in popular mobile and web-based email clients.
Learn more about enterprise encryption in our free white paper.