[Cryptography] block size / block cipher versus stream cipher

[Phillip Hallam-Baker]

On Wed, Mar 31, 2021 at 3:35 PM jrzx <jrzx at protonmail.ch> wrote:

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

No, it isn't. Of the 300+ devices I can control through the home automation
system, only 100 or so have that degree of processing capability.

And my point is that I want to be able to use both channels concurrently. I
see absolutely no reason to fetishize the notion of performing a public key
exchange just because we add a communication channel or modify an old one.
That is very clearly a layering violation to me.

I am going to rekey a channel when there is a need to rekey it because of
its age or the amount of data sent or some other reason. That is a policy
decision for the app designer, it is not my decision as a protocol
architect. We had to take these decisions for users back in the 1990s
because we only had weak algorithms and they wore out. Today the solution
is simply pick a good algorithm.


I am now looking at a hybrid mode for gaming. Say that Alice and Bob are
playing a game that involves real time video and movement information. Say
Alice has a cell phone which has low latency and a broadband channel with
high capacity. Why not use both?


I see no reason we shouldn't send a packet over ethernet and acknowledge it
via USB. Most of us have equipment which is in theory capable of fault
tolerant operation but that very very seldom works. And its not surprising
when people design protocols so that in the case that a data center loses
one of its two pipes, every server is suddenly slammed with half the
connected clients all trying to negotiate a key exchange at the same time.




> 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, I think talk of identity systems is utter tosh. I did not propose an
identity system, I don't believe in them. And I wrote the SAML 1.0 spec.
There is authentication and there is authorization. Pretty much every time
someone attempts to layer in 'identity', they get it wrong.

I do know what I want from this system and it is not 'identity'. I want to
be able to control every one of the devices in my local network
autonomously. I want the 20+ discrete CPUs in charge of different parts of
my Dalek to be able to intercommunicate.

Management of interpersonal trust is a completely different topic and that
has nothing to do with identity either.



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

More 8 bit processors were produced last year than the year before. The
number produced in the last three years has been greater than the total
number produced up to that date for every year in the past 20.

The problem is that as fast as existing applications graduate to faster
processors, twice as many new uses for 8-bit processors are found.

As a practical matter, I have set the lower threshold for the Mesh to be
requiring a 16 bit CPU and a decent chunk of memory. But I see no reason to
take design decisions that preclude 8 bit processors completely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210331/6925ef88/attachment.htm>