[Cryptography] block size / block cipher versus stream cipher

[jrzx]

On Tue, Mar 30, 2021 at 10:37 PM jrzx <jrzx at protonmail.ch> wrote:

>> Recommended practice on shared secrets in the Libsodium documentation ....

On Wednesday, March 31, 2021 9:54 AM, Phillip Hallam-Baker <phill at hallambaker.com> wrote:

> That might be appropriate for some devices. But probably not for a lightbulb
> running off an 8bit CPU that will never actually do anything other than authenticate
> commands to turn itself on and off.

A system capable of communicating is going to be running wifi or an ethernet connected
usb. It is going to be at least equivalent to the RP2040, which can do asymmetric
cryptography and do it considerably faster than humans can perceive.

You propose an identity system. Shared secrets are fine if there is only one human
involved, as with a garage door opener or a car door opener, but in an identity system
there are always at least three humans involved, typically the human issuing the
authorization to the devices of another human, and an unknown and unidentifiable
member of an out of control bureaucracy in the middle.

No one is using eight bit CPUs any more. The smallest SoC you can readily
lay your hands is the thing the Rasberry pi pico is built around

The Rasberry Pi pico is 32 bits, dual core $4.00 in single unit quantities.

Suggested use, turning on a lightbulb.

Even if they are just turning on a lightbulb, they load an entire linux derived
operating system to do it.

I don't know what the SoC costs by itself, but the SoC embedded in a tiny little
board, the Rasberry Pi pico, is four dollars in single unit quantities,

You are not going to authenticate commands to a small cpu running a lightbulb,
because you want it to turn on whenever light levels are low and there is
movement in the vicinity, and turn off after a timeout.

You will, however, want to authenticate commands to a system that
automatically unlocks doors when an employee shows up, and ceases
to automatically unlock doors when that employee gets fired.

For which function durable shared secrets are a really bad idea.

If you want to authenticate a command as coming from a particular entity,
it normally matters a great deal that the human that issues the authorization
to another human can know that he has only authorized that particular
human's devices, and if that human loses control of the authorization,
it is that particular human's fault, not the fault of some unknown bureaucrat
in an out of control bureaucracy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210331/b22dcbb0/attachment.htm>