[Cryptography] block size / block cipher versus stream cipher

[Phillip Hallam-Baker]

On Mon, Mar 29, 2021 at 6:31 PM jrzx <jrzx at protonmail.ch> wrote:

> On Friday, March 26, 2021 8:41 AM, Phillip Hallam-Baker <
> phill at hallambaker.com> wrote:
>
> A host accepts UDP requests from multiple clients which MAY change their
> Source IP address and port at any time because of NAT deployment.
>
>
> Not at any time, not in the middle of active conversation, because that
> would break TCP and flow control
>

Yes, in the middle of a connection. TCP/IP is a separate protocol from
UDP/IP. UDP doesn't have flow control. We are adding it at the application
layer.



> If your NAT has some ports dynamically mapped, to allow incoming packets,
> it is not going to move the ports it has mapped to a new network address.
>

Again, this happens frequently. Some NATs drop the connection after a few
seconds of inactivity. The idea here is to be able to recover from that
situation.

We also want to deal with situations like Alice is connected to a video
conference on her phone, she enters the house, she now has WiFi and it is
fast. So seamlessly detect the fact that a faster connection became
available and make use of it. Or make use of both.



> Which means that time your source address changes, you are going to be
> renegotiating flow control, in which case you should be negotiating a new
> shared secret from asymmetric secrets.
>

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. It is highly likely that post quantum
crypto will have performance or other drawbacks. The drawback might turn
out to be not being delivered in a form we can use on time. So I do not
want to rely on rekeying.
QUIC is optimized to one particular use case. I am looking to optimize for
subtly different use cases and take account of the traffic analysis
considerations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210329/fb0866a1/attachment.htm>