Hacker News Reader

Comment by Taek | Hacker News Reader

Even the tiniest MCU can typically perform more than one cryptographic operation per second. If your MCU has any cycles to spare at all it usually has enough cycles for cryptography.

If you don't have any cycles to spare, you can upgrade to an MCU that does have cycles to spare for less than $0.50 in small batches, and an even smaller price delta for larger batches.

Any device that doesn't use cryptography isn't using it because the manager has specifically de-prioritized it. If you can't afford the $0.50 per device, you probably can't afford the dev that knows his way around cryptography either.

View on HN

> Even the tiniest MCU can typically perform more than one cryptographic operation per second. If your MCU has any cycles to spare at all it usually has enough cycles for cryptography.

Well, no. If you can do 1 AES block per second, that's a throughput of a blazing fast 16 bytes per second.

I know that's a pathological example, but I do understand your point - a typical workload on an MCU won't have to do much more than encrypt a few kilobytes per second for sending some telemetry back to a server. In that case, sure: ChaCha20-Poly1305 and your job is done.

However, what about streaming megabytes per second, such as an uncompressed video stream? In that case, lightweight crypto may start to make sense.

This whole framing is weird, because you can't spend $0.50 per already-deployed part to upgrade to something that can viably do AES.

1 operation per second would refer to cryptographic signatures. If you are doing Chacha, the speeds are more like 1 mbps. AES is probably closer to 400 kbps.

An uncompressed video stream at 240p, 24 frames per second is 60 mbps, not really something an IoT device can handle. And if the video is compressed, decompression is going to be significantly more expensive than AES - adding encryption is not a meaningful computational overhead.

If it's compressed you don't need to decompress it first.

on the receiving end.

The device doing the decryption may not be the same device that does the decompression.

Eg a small edge gateway could be doing the VPN, while the end device is decoding the video.

A VPN’s encryption is different than a streaming platform’s encryption. The streamer’s encryption is their form of rights management. So the device/app decompressing the video very much is the point of decryption. If not, the rights management is very broken. If the small edge gateway is somehow decrypting the video stream, you’d have a very rogue device that lots of people would be curious to learn more

CCTV doesn’t need rights management. Nor do advertising billboards.

Why would you compare an uncompressed video stream to anything in this discussion? Especially at such a small frame size in modern video usage.

Modern encrypted streaming uses pre-existing compressed video where the packets are encrypted on the way to you by the streaming server. It would have to uniquely encrypt the data being sent to every single user hitting that server. So it's not just a one and done type of thing. It is every bit of data for every user. So that scales to a lot of CPU on the server side to do the encryption. Yes, on the receiving side while your device is only dealing with the one single stream, more CPU cycles will be spent decompressing the video compared to decrypting. But again, that's only have of the encrypt/decrypt cycle

>Even the tiniest MCU can typically perform more than one cryptographic operation per second. If your MCU has any cycles to spare at all it usually has enough cycles for cryptography.

>1 operation per second would refer to cryptographic signatures. If you are doing Chacha, the speeds are more like 1 mbps. AES is probably closer to 400 kbps.

It sounds to me like you, sir or madame, have not worked with truly tiny MCUs. :-)

But yes, there are inexpensive MCUs where you can do quite a bit of crypto in software at decent speeds.

>If you don't have any cycles to spare, you can upgrade to an MCU that does have cycles to spare for less than $0.50 in small batches, and an even smaller price delta for larger batches.

The monetary cost is most likely not the problem. Tacking on significant additional work is bound to consume more power and generate heat. Tiny devices often have thermal and power limits to consider.

The problem is it isn't significant work. You can perform ChaCha8 on pen and paper in ~30 minutes. It's literally 768 single cycle 32 bit integer operations.

768 single cycle instructions to do WHAT? To encode a few bytes or something? You can't convince me that the cost of cryptography is never prohibitive. Boldly asserting that your idea of "significant work" is universal for all applications isn't going to convince me, nor are weird anecdotes about tangentially related things.

Reply on news.ycombinator.com