[Cryptography] block size / block cipher versus stream cipher

[Phillip Hallam-Baker]

On Sat, Mar 20, 2021 at 9:11 PM John Denker via cryptography <
cryptography at metzdowd.com> wrote:

> On 3/19/21 9:38 AM, Phillip Hallam-Baker wrote:
>
> > I started to think that maybe we have got to the
> > point where we should move past the 128 bit block size of AES.
>
> > The obvious replacement choice is 256 bits.
>
> ===============
>
> 3) Block chaining modes are IMHO a fig leaf, used to cover up
>  the ugliness of non-agile keying. It allows a key to be re-used
>  from one block to another. In contrast, IMHO a proper cryptosystem
>  simply uses a different key for each block. It does not require
>  an expensive "key-scheduling" step, and it is not vulnerable to
>  related-key attacks.
>
>  Many well-known ciphers have expensive key-scheduling and/or
>  related-key issues.
>

What I am looking at is ways to tune a cipher so that I can use frequent
rekeying of the
symmetric key to avoid the need to go through an expensive public key
agreement.

Rekeying on every block is a bad idea. Rekeying the symmetric cipher
between each
frame of video is a very different proposition because I can do that in
parallel and
it costs me nothing.

Lets say I am using AES-OCB for encryption and the initial 16 bytes of each
packet contain:

* Unique stream identifier  (24 bits)
* Unique sequence number of frame within stream (32 bits)
* Unique sequence of packet within frame identifier (7 bits)
* Wibble bit (1 bit)
* Bitmapped field acknowledging packets sent (56 bits)

These are not the QUIC values, assume I know what I am doing though.

The end goal here is to be able to process an entire video frame and send
it in one chunk so
that it can be encrypted/decrypted as one unit

I was asking about block size for several reasons:

* Security
* Performance
* Should I build for a 16 or 32 bit initial block?

My plan is to encrypt the first block of the packet in ECB mode using a key
that is fixed for
the lifetime of the connection. Note that NONE of the information in this
field is confidential
as far as the application is concerned. But why give any information out to
traffic analysis
when we don't need to?

An all zero first block means that the packet is an initial key agreement
packet. All zero first
blocks are avoided by decrypting the all zeros ciphertext and setting the
wibble bit so it is
never emitted.

4) Key size is not the same as block size. PHB is AFAICT mostly
>  arguing for a 256 bit key, which is fine with me. In contrast,
>  I have yet to hear a persuasive argument for a 256-bit block,
>  or any block at all.
>

When PHB says block size, he almost certainly means block size. I am not
confusing it
with key size because I only use 256 bit keys.

At this point it seems reasonably clear that 256bit blocks is a long term
prospect at best,
it will be a decade at least before we have a NIST or similar standard.


So that just leaves performance. And that could be the deciding factor
because AES is a
32 bit cipher in a 64 bit world. Processing my video pages using 256 bit
blocks might well
allow me to do so twice as fast given equivalent optimization.

The approach I am thinking of has the sender and receiver pre-allocating
large buffers that
are large enough to hold a full frame of video in compressed form. (They
are going to need
to hold a full frame of uncompressed at some point in the pipeline, so this
should not be
prohibitive).

Assuming 4K, 30fps video at 16,000 Kb/s, that is ~70KB per frame which is
about 60
packets.

So the idea here is to design the crypto framing so that I can precalculate
the OCB tables
before the frame is sent and I can optimize the packet layout so I can word
align data for fast
processing. The aim here being to avoid the need to copy data. I get my
series of ciphertext
blocks, and write the outputs to the corresponding place in the plaintext
buffer. I only attempt
decompression if the auth tag checks out.

The objective here is to limit lag to no more than two or three frames and
try to make it
one frame or less.

 Example #3: Block chaining modes are dead on arrival if we need
>  to do random access.
>

OCB can be configured so it can be used in the same manner as ECB (i.e.
random lookup)
but with a performance penalty for each 'seek' operation. And you can't do
authentication of
course.


Phill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210322/53b11988/attachment.htm>