The December 2022 issue of IEEE Spectrum is here!

Close bar

Intel Creating Cryptographic Codes That Quantum Computers Can't Crack

Intel researchers developed a hardware accelerator that helps IoT devices use post-quantum cryptography

3 min read
Cyber security illustration.
Illustration: iStockphoto

The world will need a new generation of cryptographic algorithms once quantum computing becomes powerful enough to crack the codes that protect everyone’s digital privacy. An Intel team has created an improved version of such a quantum-resistant cryptographic algorithm that could work more efficiently on the smart home and industrial devices making up the Internet of Things.

The Bit-flipping Key Encapsulation (BIKE) provides a way to create a shared secret that encrypts sensitive information exchanged between two devices. The encryption process requires computationally complex operations involving mathematical problems that could strain the hardware of many Internet of Things (IoT) devices. But Intel researchers figured out how to create a hardware accelerator that enables the BIKE software to run efficiently on less powerful hardware.

“Software execution of BIKE, especially on lightweight IoT devices, is latency and power intensive,” says Manoj Sastry, principal engineer at Intel. “The BIKE hardware accelerator proposed in this paper shows feasibility for IoT-class devices.”

Intel has been working in cooperation with several other companies to develop BIKE as one possible quantum-resistant algorithm among the many being currently evaluated by the U.S. National Institute of Standards and Technology. This latest version of BIKE developed primarily by the Intel team was presented in a paper [PDF] during the IEEE International Conference on Quantum Computing and Engineering on 13 October 2020. 

BIKE securely establishes a shared secret between two devices through a three-step process, says Santosh Ghosh, a research scientist at Intel and coauthor on the paper. First, the host device creates a public-private key pair and sends the public key to the client. Second, the client sends an encrypted message using the public key to the host. And third, the host decodes the encrypted message through a BIKE decode procedure using the private key. “Of these three steps, BIKE decode is the most compute intensive operation,” Ghosh explains.

The improved version of BIKE takes advantage of a new decoder that requires less computing power. Testing showed that this enabled the computation of a single BIKE decode operation in 1.3 million cycles at 110 MHz on an Intel Arria 10 FPGA in 12 milliseconds, which is fairly competitive compared to other options.

BIKE is well suited for applications where IoT devices are used for encapsulation and a more capable device takes the role of host to generate the keys and perform the decapsulation procedure,” Ghosh says.

This also represents the first hardware implementation of BIKE suitable for Level 5 keys and ciphertexts, with level 5 representing the highest level of security as defined by the U.S. National Institute of Standards and Technology. Each higher level of security requires bigger keys and ciphertexts—the encrypted forms of data that would look unintelligible to prying eyes—which in turn require more compute-intensive operations. 

The team was previously focused on BIKE implementations suitable for the lower security levels of 1 and 3, which meant the public hardware implementation submitted to NIST as reference did not support level 5, says Rafael Misoczki, coauthor on the paper who was formerly at Intel and is now a cryptography engineer at Google.

The latest hardware implementation for BIKE takes the security up a couple of notches.

“Our BIKE decoder supports keys and ciphertexts for Level 5 which provides security equivalent to AES-256,” says Andrew Reinders, security researcher at Intel and coauthor on the paper. “This means a quantum computer needs 2128 operations to break it.”

The latest version of the BIKE hardware accelerator has a design that offers additional security against side-channel attacks in which attackers attempt to exploit information about the power consumption or even timing of software processes. For example, differential power analysis attacks can track the power consumption patterns associated with running certain computational tasks to reveal some of the underlying computations.

In theory, such attacks against BIKE might attempt to target a small block of the secret being shared between two devices. That block size depends upon how many secret bits work together in underlying sub-operations, Reinders says. Because a BIKE block size is 1-bit, a BIKE hardware design that processed a single secret bit at a time would be highly vulnerable to such a differential power analysis attack.

But the new BIKE hardware accelerator offers protection against such attacks because it performs all the computations for the 128-bits of secret in parallel, which makes it difficult to single out power consumption patterns associated with individual computations.

The BIKE hardware accelerator also has protection against timing attacks, because its decoder always runs for a fixed number of rounds that are each the same amount of time.

BIKE was previously chosen as one of eight alternates in the third round of NIST’s Post-Quantum Cryptography Standardization Process that is currently narrowing down the best candidates to replace modern cryptography standards. Seven other algorithms were selected as finalists, making for a total of 15 algorithms remaining under consideration from a starting group of 69 submissions.

The researchers have submitted their revised version of BIKE for the third round of the NIST challenge and are currently awaiting comments. If all goes well, the federal agency plans to release the initial standard for quantum-resistant cryptography in 2022.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}