Lightweight!

Pac-Man Fever, by Buckner & Garcia, via Wikipedia

A Pac-Man song? I should not have found that surprising, but I did.

Originally called Puck Man (from the original Japanese title “Pakkuman”), the name of the game was changed to Pac-Man prior to release for reasons which should be obvious.

As to where the boxing comes in, I’m not entirely sure...

What? Wrong Pac-Man?

Oh! Right.

So, Manny Pacquiao, also known as “PacMan”, is regarded as one of the greatest professional boxers of all time. He has won twelve major world titles, has won titles in multiple weight classes, and has held world championships across four decades (1990s, 2000s, 2010s, and 2020s).

While I am not a big fan of sports like boxing, I sometimes watch “highlight reels”, and am interested in the similarities and differences between boxing and various martial arts. One thing I find particularly interesting is the incredibly precise attention to timing, distance and body position, which can be difficult to appreciate unless you know what you are looking for.

As an example, I have seen a number of cases where Pacquiao has “obviously” been punched squarely in the face at the same time he is punching his opponent. His opponent is staggered, but Pacquiao is apparently unaffected. How can this be?

Simply put, his opponent’s glove may be in contact with Pacquiao’s head, but there is no force behind it – usually because of a combination of Pacquiao pulling his head back, and of his own strike neutralizing his opponent’s momentum.

Realizing this made me think of an opportunity I had to free-spar with our Sensei, many years ago. While the vast majority of people I have trained with or watched will block (or sidestep) and counter an incoming attack, our Sensei did not. Instead, even while I saw my hand brush his karate-gi, I felt his fist strike me in the chest with near-perfect aim and control. It was enough to stop me cold without injuring me, and there was absolutely no doubt that the blow could have disabled me, but for the precise control.

Remembering that event helped me realize exactly how Pacquiao could “absorb” so much punishment without apparently even noticing – the simple fact is that most of the “blows” had no force to them, and you eventually learn to read which ones actually did.

One of Pacquiao’s various titles was in the lightweight weight class.

Which is where the encryption comes in.

While it’s easy to believe that “everything” is encrypted now, that refers mainly to communications on the web, rather than the devices that represent the “Internet of Things” (IoT). While the term arguably refers only to devices directly connected to the internet, there are an enormous number of devices which might not be directly connected, but are usually accessible via the internet in some way.

Think of “smart home” devices, such as lights, heating and air conditioning, media, security systems, and cameras. Then think of RFID tags, medical implants, machines of various types, cars, farm devices and equipment, water systems, power systems, and a hundred other industries.

And then add the sensors used to provide information to all of those systems.

The actual number of devices is unknown, but is generally assumed to be in the billions already, and growing with extraordinary speed.

Without addressing the lack of comprehensive legal requirements for encryption on devices like these, one of the major challenges is around the capacity of the devices. While some - like smartphones, tablets, and routers – have sufficient capacity (processing power, memory, and such) to use “web“ encryption, a vast number of devices are small, with limited processing power, memory, and battery life, or used where communications throughput and low-latency are essential.

Many of theses “resource constrained” devices use cryptography that ranges from insufficient to non-existent, which highlights a need. It should be noted that, for some applications, such as generating a hash in order to confirm that the firmware of a tiny sensor hasn’t been tampered with, or to encrypt the payload of a sensor’s output every few seconds in order to prevent “counterfeit” results from being injected, “web-standard” encryption (such as AES) would represent massive overkill for the security needs of the application in question, especially if it meant that the sensor needed additional processing power, memory, and/or battery capacity as a result.

In Episode 1039 of Security Now, Steve Gibson mentioned and briefly reviewed the recent news that NIST has finalized a “Lightweight Cryptography” standard, for resource constrained devices.

A clear standard in this area is an important milestone, both for standardization and for defining a “trusted” encryption methodology for such devices.

I found a very interesting playlist, Lightweight Cryptography for the Internet of Things, which included a section on “Disasters”. This section can really be summarized by “don’t roll your own crypto”, and highlights the need for this new standard.

I then found a more recent video, which provided an overview of how the Ascon family of ciphers and hash functions works. When compared with AES, it it requires less code and less memory, but still provides a reasonable level of protection – exactly what a lightweight standard needs.

Now that we have a standard, the question is whether it will be adopted by industry, lawmakers, or both. In any case, it’s a step on the path to improved security for the increasing deluge of IoT devices, gadgets, sensors, tags, widgets, doodads, gizmos, and assorted other thingamajigs. A very good thing!

Cheers!