“To keep your secret is wisdom; but to expect others to keep it is folly.” – Samuel Johnson
Can you keep a secret?
OK, the identity of this man may be a secret to those of us who didn’t care much for history or literature in high school, so I’ll let you in on it:
Samuel Johnson was a famous eighteenth century English writer. While he didn’t contribute to either the RSA or ECC algorithms, he was definitely on to something when it comes to ideals of security.
Secrets are undoubtedly important,
and vital like never before in our modern world. Because modern network technology enables us to convey information, including monetary value, almost instantly world-wide, it inherently demands that we consider the need for privacy and security—and that means secrecy by encryption.
Transmitting a headline to a Times Square marquee is one thing; swiftly conveying an important business contract to a colleague in Paris, or an invoice payment to a creditor, is an entirely different animal: security that is only available through the use of strong encryption is an absolute necessity.
Even in the case of the marquee, we need to prevent “bad actors” from injecting unwanted messages, right? As the Internet of Things continues to expand, the veritable explosion of IoT devices gives black-hat hackers an ever increasing number of possible access points to attack, making device security more crucial than ever before. Are your IoT devices practicing “safe connex?”
As you might imagine, there can be some pretty heavy-duty math involved in the algorithms that give us strong encryption. We won’t be digging that deeply today, but if you love to work through obscure equations, you’ll find some enticing references at the end of this article.
A Little History
Prior to the last quarter of the 20th century, all cryptosystems were symmetrical; that is, the same key was used both to encrypt and decrypt messages. This meant that both the sender and receiver had to have that key in hand.
By analogy, some systems in the physical world work easily in one direction, but with much greater difficulty in the other.
For example, lobster traps are easy for crustaceans to enter but hard for them to exit. One-way mirrors, check valves, and trapdoors are other common physical devices that operate easily in only one direction.
Asymmetric (also known as public key) encryption systems are somewhat like these physical items. They use mathematical functions that are easy to compute in one direction but nearly impossible in the other.
The result is that, with the right software tools, you can choose a very large random number—known only to you—and create an asymmetric key pair (called public and private keys), but publish only the public key. Anyone wishing to communicate with you can encrypt their message using your public key. However, because only you have the private key of the pair, only you can decrypt the message.
Modern IoT devices begin their client/server communication sessions by exchanging their respective public keys. Once the client and server are in possession of one another’s respective public keys, all further interaction can then be safely secured by encryption.
It took a second team of math geniuses, Ron Rivest, Adi Shamir, and Leonard Adleman, to come up with a practical formula to actually implement the concept. The RSA algorithm they introduced in 1977 is still in use today, and although there is no elegant proof that it is unbreakable, (so far) no one has as yet found a provable flaw.
The general idea behind RSA is to start with a random number of substantial size, and then run it through the magic RSA math function that produces two related numbers (a secret, or private key and a public key). The public key is then used to encrypt messages that can only be decrypted using the private key.
Elliptical Curve Cryptography (ECC)
The next major development in asymmetric codes, known as Elliptic-curve cryptography, was introduced independently by two mathematicians (Neal Koblitz and Victor S. Miller—one from academia, and one from the military) in 1985. As the name implies, ECC is based on mathematical equations that describe ellipses.
Like the RSA algorithm, the equations involved in ECC provide us with functions that have a very low “computational cost” in one direction, but require far more computation in the other direction. As an added benefit, the keys produced by this algorithm are significantly smaller than those produced by RSA for an equivalent level of security.
Which To Choose: RSA or ECC?
But what criteria can you use to choose either RSA or ECC for a particular application? And once you’ve made that binary choice, which of the several flavors of each is the right one for you?
You could try darts, or maybe just flip a coin… But that may not impress the boss when he asks you for your rationale.
Comparing RSA and ECC
Fortunately, there are some objective metrics and other indications that can help you decide which is best for your project. The most important one is probably the key size vs security level.
For comparable levels of security, ECC keys are smaller than RSA keys and can be computed considerably faster. To give you a rough idea of how big a difference this is, a 256 bit ECC public key is said to provide security equivalent to a 3072 bit RSA public key. This can be a significant consideration if you are, for example, trying to create a low power, low cost system. It can also give you faster SSL handshaking and consequently faster web page loading.
On the other hand, although keys are much larger and computation is slower, RSA algorithms and code are reputed to be easier to understand; check out this one-page, simple RSA implementation. And there are other considerations.
You’ve probably heard the saying “I’m from the government, and I’m here to help?” Some have expressed concern over whether certain elliptical curves were chosen in order to provide government agents with a “back door” means of decryption. In fact, it’s been reported that some versions of ECC almost certainly contain “back doors,” and others are suspect.
If you have a healthy level of skepticism, this may result in your rejecting the curves promulgated by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA)… unless, of course, you are required to use them for a government funded project.
There also may be patent issues surrounding the use of ECC. Although many have expired or are on the verge of expiration, you may want to at least review the literature and patent history. If not consider, consulting your legal team on the matter.
What’s the good news?
You’ll be happy to learn that NetBurner provides you with the encryption support you need to secure your IoT devices, regardless of your choice of RSA or ECC. Whether you’re remotely controlling a manufacturing line or building a device that lets a homemaker turn on the oven before leaving the office, you don’t want “bad actors” taking over or even merely disrupting that communication. In addition to providing a library that supports a wide range of ciphers, our latest NNDK tools release, 3.2, contains scripts to help you create a self-signed certificates and keys using either ECC and RSA (our next 2.x release will contain these as well).
What’s that you say? The list of cipher names looks like an indecipherable foreign language?
Not to worry, here’s a link to the secret decoder ring you need to translate most, if not all of those obscure strings of acronyms: Cipher suite definitions
Security will only become more important as both the number of connected devices in the world as well as the types of tasks they are used to complete increases. This is especially true in embedded systems, where computing power and available resources are usually constrained, yet the data that is generated and managed is often sensitive. Hopefully our overview of RSA and ECC was both interesting and provided some helpful information when considering which algorithms should be employed in your next project. As always, we love feedback, and are always interested in hearing your thoughts. Please feel free to leave a comment below, or contact us directly at firstname.lastname@example.org.
Digging Deeper: Some Interesting Links
If what you’ve read so far about asymmetric encryption methods and encryption keys piques your interest, and you want to plunge into the deep end of the pool to learn more, here are some excellent references to help you:
General Web Resources
- RSA Implementation in Python: Website
- An excellent 4-Part Series on ECC: Elliptic Curve Cryptography: a gentle introduction
- An Elliptic Curve Drawing Program: Website
- Plot Elliptic Curves over Finite Fields: Website
- Bitcoin and ECC: Elliptic Curve Digital Signature Algorithm ~ The Cryptography of Bitcoin
- Key Size Comparison: RSA vs ECC Comparison for Embedded Systems from Atmel
- Pros and Cons: Comparing ECC vs RSA from Linked In
- NetBurner’s SSL Guide: “Creating a Self-Signed SSL/TLS Certificate for Secure IoT Applications”
- NetBurner TLS: “Cover Your Data Assets with TLS”
- WebSockets for Real-Time Web and IoT Applications: Part 1, Part 2, Part 3
- SSL Manual: NetBurner SSL Programming Guide
- NetBurner Cipher Support: The Latest Ciphers June 2018
Encryption — Converting plain text to cipher text to obscure the meaning
Symmetric encryption — A cipher that uses the same key for both encoding and decoding
Asymmetric encryption — A cipher that uses different keys for encoding and decoding
Public key encryption — A widely used form of asymmetric encryption
RSA — The first viable public key encryption system
ECC — Elliptic-curve public key encryption
SSL — A network Secure Socket Layer; uses encryption for security
TLS — Transport Layer Security, an upgrade for SSL