[Cryptography] block size / block cipher versus stream cipher

[Phillip Hallam-Baker]

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

> On Monday, March 29, 2021 6:11 PM, Phillip Hallam-Baker <
> phill at hallambaker.com> wrote:
>
> Not for these use cases. And some of the devices may not have public key
> available.
> In the longer term, I want to be able to keep a symmetric key session
> going Kerberos style forever if need be.
>
>
> Building an identity system on long lived shared secrets seems like a bad
> idea, particularly as elite trust and trustworthiness is in long term
> decline, as for example the crisis of distrust in accountants and
> accounting that led to SoX.
>

The whole point of this project is to question existing assumptions and see
what happens when we reject notions that are widely held but based on 197s
thinking. thirty years of experience tells me that key rotation
requirements are far more often a cause of failure than prevent an attack.

There might well be concerns about long term secrets but these are separate
from and disjoint from concerns at the physical layer.

Conventional thinking says that when Alice returns home and here mobile
device can connect to the 960Mbs Wifi drop, her video conference call
should move off her 2Mbs 3G connection to her house. Fair enough. But what
if that house connection is flaky because the fiber is disconnected? And
when should we make the transition? What if she is just going past her
house?

I reject the notion of a sharp transition completely. The WiFi connection
should be phased in and phased out and this process should not require any
cryptographic concerns to be considered.

Another real world use case is debugging an IoT device which may be WiFi
connected or USB connected. I want my debug info to get through when I
unplug either.



> Recommended practice on shared secrets in the Libsodium documentation is
> to keep them in locked memory so that they don't get stored to disk, and
> replace those shared secrets on every reasonable occasion to do so.
>

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.


And it seems to me that change in network address is such an occasion -
> that you should not be keeping shared secrets around through an event that
> might correspond them no longer being in the control of a single client.
> Maybe the network address changed because of physical events at the client
> end.
>

This is a concern embedded in a particular set of circumstances that is
only sometimes applicable. It is a valid application concern, it is not a
valid architectural concern. The architecture should allow the application
to decide whether to react and react if appropriate.

Forcing application behavior in response to a set of limited concerns is a
major red flag in architecture. At one point some bright spark decided that
SMTP mail servers should automatically wrap the lines of email messages at
72 columns so they fit on a VT100. In the process, he ensured that the
wrapping would be wrong for every other terminal width and you can still
see the results of this mistake today.

One of the main reasons Windows, Linux and OSX periodically pause for no
particular reason is because some dim bulb decided to poll for the
completion of some operation and the machine is busy waiting in a tight
loop buried deep in some device driver.


Another aspect of the design of the presentation layer I have
conceptualized but not yet implemented is a three way handoff in which
Alice and Bob establish a connection through a presence service. This is
constantly required in video conferencing situations. If Alice and Bob are
both behind a NAT device, they have no means of knowing the external UDP
port of the other. And Alice certainly doesn't want Bob to be able to call
any time he chooses in any case. So we need a presence service.

In the traditional situation, Bob calls the presence service, gets UDP
address, port from the presence service and uses that to connect to Alice,
fair enough but now we have that connection request happening EnClair. Yuk!

Here is a better scheme:

Alice's device connects to the presence service and uploads some number of
stream IDs to it for use as 'connection tokens'.

Bob's device makes a connection request to the presence service (this may
be direct or mediated through Bob's presence service). After the request is
authenticated and authorized one of the stream IDs is returned to Bob
together with the device connection info.

Bob's device can now make an encrypted connection request to Alice's device
using the unique stream number. The only data Alice sends enclair now is
her ephemeral key.


Of course, in a practical situation, we might well go a bit further and
send a 'fat' connection token which has a one time authentication public
key and a kerberized ticket.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210331/b9b312b8/attachment.htm>