25

Bitslicing is a technique where computation is: Reduced to elementary operations (called gates) with a single bit output (typically NOR, XOR, and similar like OR AND NAND NXOR, often with further restriction to two inputs), rather than operations on words or integers spanning several bits. Executed in parallel, with as many simultaneous instances (on a ...


22

The basic idea of bitslicing, or SIMD within a register, involves two parts: expressing the cipher in terms of single-bit logical operations (AND, OR, XOR, NOT, etc.), as if you were implementing it in hardware, and carrying out those operations for multiple instances of the cipher in parallel, using bitwise operations on a CPU. That is, in a bitsliced ...


10

SPECK was actually designed with 8-bit CPUs in mind. I use Simon and Speck extensively, and there's example source code and comparisons out there, as well as a good paper. The references are good and will lead you the the original sources. AES is generally faster but takes more resources, which you may or may not have. I do not use AES on a MCU because ...


10

I second Richie Frame's observation that AES is an excellent choice. I'd use AES-128 in CTR mode, which has the advantage that decryption is the same as encryption (thus is as fast, contrary to some other modes). Update: SPECK, considered in this other answer, is good if compactness or speed per encryption for narrow block size are the choice criteria. ...


9

Thought I'd begin with some references for you that might be of interest. These terms are used as key 'selling points' for a number of schemes, including many of the CAESAR submissions. Some examples using the terms specifically are given below - most of which are from CAESER because I have the zoo in-front of me: "Online": OCB, Ascon, CBA, APE, NORX "...


9

Bitslicing is a technique that allows multiple instructions/Data points to be encoded into a single register. The idea is that you encode several bitwise operations within a single register. So, instead of 32 bitwise OR operations in sequence, you could reduce the total number of operations by cramming the data into SIMD registers and executing in ...


7

Ascon and ACORN both have interesting features. Let's discuss their pros and cons for some properties stated during the CAESAR competition for lightweight AEADs: Fits into small hardware area and/or small code for 8-bit CPUs On this point, ACORN is more efficient as its internal state is smaller than the one used by Ascon (293 vs 320 bits). Moreover, ...


6

There is no official definition, of course. However, at least in my experience, the word is used consistently. The word lightweight typically refers to something that is significantly less expensive to use than other stuff, while at the same time achieving the same desired effect, but this lightweight-ness has some cost. (If there was no cost to lightweight-...


5

In fact, for public-key operation (message encryption and signature verification, as opposed to message decryption and signature generation), RSA and, even more, the Rabin cryptosystem, outperform ECC. This may matter to, for instance, low-power embedded systems that try to connect to a powerful server with a TLS-like protocol. In the domain of signatures, ...


5

When an embedded device needs asymmetric crypto to encrypt, (e.g. measurements it makes) or check authenticity (e.g. of commands or firmware updates it receives), there is no need for a private key or key generation in the device, and nothing beats RSA and Rabin on simplicity and speed (for RSA: with $e=3$, which is safe when used with proper padding); plus ...


5

You benchmarked a highly optimized AES implementation against a reference implementation of CLEFIA: * NOTICE * This reference code is written for a clear understanding of the CLEFIA * blockcipher algorithm based on the specification of CLEFIA. * Therefore, this code does not include any optimizations for * high-speed or low-cost implementations or any ...


5

Why is symmetric lightweight cryptography only about block ciphers and not about stream ciphers? Why that assumption? There is a lot of work concerning stream ciphers for lightweight cryptography (LWC). You can find a relevant list here. Plus, last week the ChaCha20-Poly1305 cipher suites (which are considered as lightweight) have been standardized in this ...


4

"Lightweight" implies a comparison with a reference implementation or with another "heavyweight" implementation, so it's always context dependent. Since there is no single industry standard algorithm or protocol, let alone an industry standard reference implementation of each, nothing can be used to measure other algorithms to meaningfully sort them into ...


4

MICKEY appears to be a good low-power stream cipher but, in the context of the eSTREAM portfolio, it does not seem to excel at anything in particular. Trivium and Grain have more implementation flexibility and lower area, if one wishes, and Trivium also allows for fast bitsliced software implementations that rival the software eSTREAM candidates in speed. ...


4

If you have a nonrepeating (but possibly predictable) value, you can convert that into an unpredictable CBC-mode IV at fairly minimal cost. Here's how: Prepend the 128 bit nonrepeating value to the message CBC mode encrypt the (value, message), using any IV that's not correlated to the nonrepeating value (all 0's work) Use the first 16 bytes of the ...


4

I would personally use triple Diffie-Hellman, which is used often in secure instant-messaging protocols but unfortunately not very well-known beyond that. Essentially, both parties have a long-term identity DH keypair, which they must securely share beforehand (through some CA system, manual fingerprint confirmation like SSH, etc). In each session, both ...


4

When using lightweight ciphers, the block size can make a huge difference to security. Fortunately, there has been a lot of work in recent years on tight bounds for modes of operations, and methods for going beyond the birthday bound. These modes are not stated as being especially for lightweight ciphers, so don't search for that. However, there is no doubt ...


4

I do not have benchmarks on this particular processor, so this answer is opinion / guesswork. Gimli is fast and low-memory, but is just a permutation. Ciphers can be pretty trivially implemented on top of it though. It was designed to be efficient on a wide variety of hardware, and there is a reference implementation for an 8-bit AVR microcontroller. ...


4

Well, one possibility to generate a moderately lightweight certificate would be to use this theorem: If we have values $p, q, g$ such that: $1 < g < p$ $q > \sqrt{p}$ $q \mid p-1$ $g^q \equiv 1 \pmod p$ $q$ is prime Then $p$ is prime. So, for a certificate, we would have a list of $(p_i, g_i)$ values such that $p_{i-1}, p_i, g_i$ meet the above ...


4

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point. For example, the CTR mode uses only Encryption, and CFB, OFB. It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be ...


4

Let $\bf A$ be an $n \times n$ binary matrix. Let we want to check that whether $\bf A$ is an MDS matrix over the finite field $\mathbb{F}_{2^k}$ for some $k$? The necessary condition is that $k\mid n$ which means $n=km$ for some integer $m$. Now Let $\bf A$ be $km \times km$ binary matrix. The first step is that to consider the matrix $\bf A$ as a block ...


4

I believe this is simply a statement of the intention to meet the submission requirements set out by NIST for lightweight ciphers. Note that the paper linked in the question refers to "security goals". As per section 3.1: An AEAD algorithm shall not specify key lengths that are smaller than 128 bits. Cryptanalytic attacks on the AEAD algorithm ...


3

As mentioned in the comments already, you do not need collision resistance. You can get away with target collision resistance (TCR). The security game for TCR considers families of hash functions and requires the adversary to select the message it will find a collision for before it learns under which function of the family it has to find it. This is ...


3

Salsa/ChaCha and the other eSTREAM winners are likely to be the "fastest but still secure" options today. Don't forget authentication of course. Reduced-round ChaCha/Poly1305 is likely to be the fastest software-only option, due to tuned implementations in the libsodium and NaCl libraries. UPDATED: The following slide deck has good info on state of the art ...


3

Yes, the problem of multicast one-way authentication can be solved using symmetric cryptography only, assuming (at least) one of the following applies (there might be other ways): we trust each receiving party to hold a common secret key secret, and not to use it nefariously; we accept overhead in the broadcasted message growing linearly with the number $n$ ...


3

As for every benchmark, it all depends on the computing platform. As mentionned in comment, you will find benchmarks at bench.cr.yp.to that include NIST LWC finalists and ChaCha-20. However, most of the architectures considered for those benchmarks are rather high-end computing platforms, and they do not necessarily reflect the landscape of constrained ...


2

Here you have a study about different cryptographic methods in different IoT devices: Midgar: Study of communications security among Smart Objects using a platform of heterogeneous devices for the Internet of Things In this study, the authors (Sánchez-Arias, García, and García-Bustelo) explain the time that the different methods need to send messages and a ...


2

You should take a look at ISO/IEC 29192 which is a standard for lightweight cryptography that specifies several techniques for block/stream ciphers, asymmetric techniques and hash functions. Specifically, the fifth subsequent part ISO/IEC 29192-5 is about hash functions and specifies three such functions suitable for applications requiring lightweight ...


2

A bona fide use case for encryption only is inside a true random number generator (TRNG). If you have something small like:- it's common to whiten the raw entropy signal using a cryptographic primitive. PRESENT could be used in some form of CFB mode, although there are examples of vanilla ECB mode being used. The designers of these simple key type TRNGs ...


2

Ciphers that are targeted for light-weight applications often have some common, but one-off, use cases. I have an IC with and ADC that is passively powered via RFID, and then sends encrypted data via SIMON. There's no commands required, so it is strictly one-way. I illuminate the IC electrically, and then it sends me a sample from the sensor. PRESENT is ...


Only top voted, non community-wiki answers of a minimum length are eligible