19

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


16

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 ...


12

For your application: "I need the (underpowered 8-bit) slave to be able to tell if a command issued is really trustable", RSA signature with low public exponent ($e=3$), or Rabin (an analog with $e=2$), is likely the most appropriate, assuming you can't trust the slaves to keep a key secret, which is the only realistic assumption unless that slave uses ...


12

The paper Enabling Standardized Cryptography on Ultra-Constrained 4-bit Microcontrollers (page 255) describes such an implementation.


12

Yes, AES could be implemented on a 4-bit micro-controller such as this EM6626, and that would not be rocket science or stupidly slow. This application note illustrates that all kind of 8-bit operations are simple, and table lookups are possible. In fact, tables are not even indispensable if performance is non-critical; see this minimalist AES source code in ...


9

In summary: the premise "there is so little space in the bootloader that no cryptographically secure decryption algorithm can be implemented there" is likely wrong; thus security-by-obscurity is not the way to go. The method described in the question attempts to "prevent theft from the publicly released update"; but it fails to do that if an adversary ...


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

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. ...


6

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 ...


6

Ascon and ACORN both have interesting features. Let 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, thanks ...


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

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

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-...


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

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 ...


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

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 ...


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

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 ...


3

"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 ...


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

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 ...


3

Have you considered using symmetric key crypto (MAC) instead ? Elliptic Curve Crypto or even regular (but costly) modular arithmetic might be overkill in your case. As I understand it you would be able to precharge MAC keys into your master and slaves before deployment and you would be set. You can even generate a different key for each so that the ...


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 ...


2

Someone answered it in another "exchange" site: https://electronics.stackexchange.com/questions/1830/md5-implementation-for-microcontroller There you have links to C implementations, etc. And yes, it's possible to implement MD5 and SHA1 in 8bits, you'll just have to worki with 16 (or 32) bits operations, not that hard...


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 ...


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