Speck (cipher)

Reference code

The following is the designers' reference implementation, written in C, of the Speck variant with a 128-bit block size and key, where key = (K[1], K[0]). It is adapted from their IACR ePrint.

<span id="mwWA"></span><span class="cp" id="mwWQ">#include</span><span class="w" id="mwWg"> </span><span class="cpf" id="mwWw"><stdint.h></span> <span class="cp" id="mwXA">#define ROR(x, r) ((x >> r) | (x << (64 - r)))</span> <span class="cp" id="mwXQ">#define ROL(x, r) ((x << r) | (x >> (64 - r)))</span> <span class="cp" id="mwXg">#define R(x, y, k) (x = ROR(x, 8), x += y, x ^= k, y = ROL(y, 3), y ^= x)</span> <span class="cp" id="mwXw">#define ROUNDS 32</span> <span class="kt" id="mwYA">void</span><span class="w" id="mwYQ"> </span><span class="nf" id="mwYg">encrypt</span><span class="p" id="mwYw">(</span><span class="kt" id="mwZA">uint64_t</span><span class="w" id="mwZQ"> </span><span class="n" id="mwZg">ct</span><span class="p" id="mwZw">[</span><span class="mi" id="mwaA">2</span><span class="p" id="mwaQ">],</span> <span class="w" id="mwag"> </span><span class="kt" id="mwaw">uint64_t</span><span class="w" id="mwbA"> </span><span class="k" id="mwbQ">const</span><span class="w" id="mwbg"> </span><span class="n" id="mwbw">pt</span><span class="p" id="mwcA">[</span><span class="mi" id="mwcQ">2</span><span class="p" id="mwcg">],</span><span class="w" id="mwcw"> </span> <span class="w" id="mwdA"> </span><span class="kt" id="mwdQ">uint64_t</span><span class="w" id="mwdg"> </span><span class="k" id="mwdw">const</span><span class="w" id="mweA"> </span><span class="n" id="mweQ">K</span><span class="p" id="mweg">[</span><span class="mi" id="mwew">2</span><span class="p" id="mwfA">])</span> <span class="p" id="mwfQ">{</span> <span class="w" id="mwfg"> </span><span class="kt" id="mwfw">uint64_t</span><span class="w" id="mwgA"> </span><span class="n" id="mwgQ">y</span><span class="w" id="mwgg"> </span><span class="o" id="mwgw">=</span><span class="w" id="mwhA"> </span><span class="n" id="mwhQ">pt</span><span class="p" id="mwhg">[</span><span class="mi" id="mwhw">0</span><span class="p" id="mwiA">],</span><span class="w" id="mwiQ"> </span><span class="n" id="mwig">x</span><span class="w" id="mwiw"> </span><span class="o" id="mwjA">=</span><span class="w" id="mwjQ"> </span><span class="n" id="mwjg">pt</span><span class="p" id="mwjw">[</span><span class="mi" id="mwkA">1</span><span class="p" id="mwkQ">],</span><span class="w" id="mwkg"> </span><span class="n" id="mwkw">b</span><span class="w" id="mwlA"> </span><span class="o" id="mwlQ">=</span><span class="w" id="mwlg"> </span><span class="n" id="mwlw">K</span><span class="p" id="mwmA">[</span><span class="mi" id="mwmQ">0</span><span class="p" id="mwmg">],</span><span class="w" id="mwmw"> </span><span class="n" id="mwnA">a</span><span class="w" id="mwnQ"> </span><span class="o" id="mwng">=</span><span class="w" id="mwnw"> </span><span class="n" id="mwoA">K</span><span class="p" id="mwoQ">[</span><span class="mi" id="mwog">1</span><span class="p" id="mwow">];</span> <span class="w" id="mwpA"> </span><span class="n" id="mwpQ">R</span><span class="p" id="mwpg">(</span><span class="n" id="mwpw">x</span><span class="p" id="mwqA">,</span><span class="w" id="mwqQ"> </span><span class="n" id="mwqg">y</span><span class="p" id="mwqw">,</span><span class="w" id="mwrA"> </span><span class="n" id="mwrQ">b</span><span class="p" id="mwrg">);</span> <span class="w" id="mwrw"> </span><span class="k" id="mwsA">for</span><span class="w" id="mwsQ"> </span><span class="p" id="mwsg">(</span><span class="kt" id="mwsw">int</span><span class="w" id="mwtA"> </span><span class="n" id="mwtQ">i</span><span class="w" id="mwtg"> </span><span class="o" id="mwtw">=</span><span class="w" id="mwuA"> </span><span class="mi" id="mwuQ">0</span><span class="p" id="mwug">;</span><span class="w" id="mwuw"> </span><span class="n" id="mwvA">i</span><span class="w" id="mwvQ"> </span><span class="o" id="mwvg"><</span><span class="w" id="mwvw"> </span><span class="n" id="mwwA">ROUNDS</span><span class="w" id="mwwQ"> </span><span class="o" id="mwwg">-</span><span class="w" id="mwww"> </span><span class="mi" id="mwxA">1</span><span class="p" id="mwxQ">;</span><span class="w" id="mwxg"> </span><span class="n" id="mwxw">i</span><span class="o" id="mwyA">++</span><span class="p" id="mwyQ">)</span><span class="w" id="mwyg"> </span><span class="p" id="mwyw">{</span> <span class="w" id="mwzA"> </span><span class="n" id="mwzQ">R</span><span class="p" id="mwzg">(</span><span class="n" id="mwzw">a</span><span class="p" id="mw0A">,</span><span class="w" id="mw0Q"> </span><span class="n" id="mw0g">b</span><span class="p" id="mw0w">,</span><span class="w" id="mw1A"> </span><span class="n" id="mw1Q">i</span><span class="p" id="mw1g">);</span> <span class="w" id="mw1w"> </span><span class="n" id="mw2A">R</span><span class="p" id="mw2Q">(</span><span class="n" id="mw2g">x</span><span class="p" id="mw2w">,</span><span class="w" id="mw3A"> </span><span class="n" id="mw3Q">y</span><span class="p" id="mw3g">,</span><span class="w" id="mw3w"> </span><span class="n" id="mw4A">b</span><span class="p" id="mw4Q">);</span> <span class="w" id="mw4g"> </span><span class="p" id="mw4w">}</span> <span class="w" id="mw5A"> </span><span class="n" id="mw5Q">ct</span><span class="p" id="mw5g">[</span><span class="mi" id="mw5w">0</span><span class="p" id="mw6A">]</span><span class="w" id="mw6Q"> </span><span class="o" id="mw6g">=</span><span class="w" id="mw6w"> </span><span class="n" id="mw7A">y</span><span class="p" id="mw7Q">;</span> <span class="w" id="mw7g"> </span><span class="n" id="mw7w">ct</span><span class="p" id="mw8A">[</span><span class="mi" id="mw8Q">1</span><span class="p" id="mw8g">]</span><span class="w" id="mw8w"> </span><span class="o" id="mw9A">=</span><span class="w" id="mw9Q"> </span><span class="n" id="mw9g">x</span><span class="p" id="mw9w">;</span> <span class="p" id="mw-A">}</span>

Note that this code computes the round keys (key schedule) on-demand. In practice, as with other block ciphers it is common for implementations to compute the round keys just once and cache them, rather than recomputing them for every block encrypted or decrypted. Although, as the authors point out, "Given that small code size was a major goal of the design, it made sense to reuse the round function for round key generation. This approach enables on-the-fly round key generation for microcontroller implementations, using just the round function code, very little ROM, and no RAM beyond what is required to hold the key and plaintext."

For 16-bit words (Speck32), the rotates are 7 bits right and 2 bits left; for all other word sizes, they are 8 and 3 as shown here.

If the key is more than 2 words long, there are 2 or 3 a values, which are used in rotation.

Endianness

The original Speck paper does not explicitly state the endianness of bytes when the plaintext block is interpreted as the two words used in the cipher algorithm. The test vectors given in the paper suggest big-endian order. However, the authors of the algorithm have advised some implementers that little-endian byte order is to be used for keys, plaintext, and ciphertext, and the practice was accepted by others.

Performance

According to ECRYPT's stream cipher benchmarks (eBASC), Speck is one of the fastest ciphers available, both for long as well as short messages. Some median performances for long messages (128-bit, 128-block size version) are: 1.99 cycles per byte (cpb) on an AMD Ryzen 7 1700; 1.27 cpb on an Intel Core i5-6600; 15.96 cpb on a Broadcom BCM2836 Cortex A7. For example, on the ARMv7 platform, Speck is about 3 times faster than AES.

When implemented on 8-bit AVR microcontroller, Speck encryption with 64-bit blocks and 128-bit key consumes 192 bytes of flash memory, temporary variables consume 112 bytes of RAM, and takes 164 cycles to encrypt each byte in the block.

Salsa20 is a stream cipher with comparable performance, but it is difficult to use stream ciphers securely in some applications where block ciphers like Speck work well. This led Google to add an implementation of Speck in Linux kernel version 4.17, planning to offer it as an option for disk encryption on low-end Android devices that would otherwise be unencrypted due to slow AES performance on processors that lack AES instructions. Speck was later dropped from the Linux kernel due to backlash and concerns, and Google switched to the Adiantum algorithm instead.

Security

Cryptanalysis

The designers claim that Speck, though a "lightweight" cipher, is designed to have the full security possible for each block and key size, against standard chosen-plaintext (CPA) and chosen-ciphertext (CCA) attacks. Resistance against related-key attacks was also stated as a goal, though a less crucial one as attacks in that model are not relevant for typical use cases. No effort was made to resist attacks in the known-key distinguishing attack model, nor did the designers evaluate Speck for use as a hash function.

As of 2018, no successful attack on full-round Speck of any variant is known. Due to interest in Simon and Speck, about 70 cryptanalysis papers have been published on them. As is typical for iterated ciphers, reduced-round variants have been successfully attacked. The best published attacks on Speck in the standard attack model (CPA/CCA with unknown key) are differential cryptanalysis attacks; these make it through about 70–75% of the rounds of most variants, though these best attacks are only marginally faster than brute-force. The design team states that while designing Speck, they found differential attacks to be the limiting attacks, i.e. the type of attack that makes it through the most rounds; they then set the number of rounds to leave a security margin similar to AES-128's at approximately 30%.

Speck has been criticized for having too small a security margin, i.e. too few rounds between the best attacks and the full cipher, in comparison to more conservative ciphers such as ChaCha20. Ciphers with small security margins are more likely to be broken by future advances in cryptanalysis. Speck's design team counters that there is a real-world cost to unnecessarily large security margins, especially on lightweight devices, that cryptanalysis during the design phase allowed the number of rounds to be set appropriately, and that they targeted AES's security margin.

Speck includes a round counter in the key schedule. The designers state this was included to block slide and rotational cryptanalysis attacks. Still, rotational-XOR cryptanalysis has been used to find distinguishers against reduced-round versions of Speck. Though the authors don't describe standard key-recovery attacks based on their distinguishers, their best distinguishers on Speck32 and Speck48 in the known-key distinguishing attack model for certain weak key classes make it through slightly more rounds than the best differential distinguishers. One of the authors has said that his research was resource-constrained and that rotational-XOR distinguishers on more rounds are probably possible. However, this type of cryptanalysis assumes the related-key or even the known-key attack models, which are not a concern in typical cryptographic protocols and solutions. The designers also state that Speck was not designed to resist known-key distinguishing attacks (which do not directly compromise the confidentiality of ciphers).

The designers state that NSA cryptanalysis found the algorithms to have no weaknesses, and security commensurate with their key lengths. The design team says that their cryptanalysis included linear and differential cryptanalysis using standard techniques such as Matsui's algorithm and SAT/SMT solvers, though a full list of techniques used is not given. Speck's designers have been criticized for not providing more details on NSA cryptanalysis of the ciphers.

The NSA has approved Simon128/256 and Speck128/256 for use in U.S. National Security Systems, though AES-256 is still recommended for non-constrained applications.

Side-channel attacks

Being an ARX cipher, Speck does not use S-boxes or other lookup tables; it is therefore naturally immune to cache-timing attacks. This contrasts with ciphers that use lookup tables such as AES, which have been shown to be vulnerable to such attacks. However, like most block ciphers (including AES) Speck is vulnerable to power analysis attacks unless hardware countermeasures are taken.

Block and key sizes

Although the Speck family of ciphers includes variants with the same block and key sizes as AES (Speck128/128, Speck128/192, and Speck128/256), it also includes variants with block size as low as 32 bits and key size as low as 64 bits. These small block and key sizes are insecure for general use, as they can allow birthday attacks and brute-force attacks, regardless of the formal security of the cipher. The designers state that these block and key sizes were included for highly resource-constrained devices where nothing better is possible, or where only very small amounts of data are ever encrypted, e.g. in RFID protocols. Only the variant with a 128-bit block size and 256-bit key size is approved for use in U.S. National Security Systems.

Standardization efforts and controversies

Initial attempts to standardise Simon and Speck through the International Organization for Standardization (ISO) failed to meet the required super-majority vote, and the ciphers were not adopted. Expert delegates to the ISO from several countries including Germany, Japan and Israel opposed the NSA's efforts to standardise the ciphers, citing concerns that the NSA is pushing for their standardisation with knowledge of exploitable weaknesses in the ciphers. The position was based on partial evidence of weaknesses in the ciphers, lack of clear need for standardisation of the new ciphers, and the NSA's previous involvement in the creation and promotion of the backdoored Dual_EC_DRBG cryptographic algorithm.

In response to concerns, the NSA stated that more than 70 security analysis papers from some of the world's leading cryptographers support NSA's conclusion that the algorithms are secure and NSA affirmed that it is not aware of any cryptanalytic techniques that would allow them or anyone else to exploit Simon or Speck.

After initial attempts to standardise the ciphers failed, the ISO standardised Simon and Speck in other working groups. As of October 2018, the Simon and Speck ciphers have been standardized by ISO as a part of the RFID air interface standard, ISO standard 29167-21 (for Simon) and ISO standard 29167-22 (for Speck), making them available for use by commercial entities.

On August 7, 2018, Speck was removed from the Linux kernel 4.20 release completely.

On February 7, 2023 NIST selected the Ascon authenticated cipher family as its Lightweight Cryptography Standard.