[Cryptography] Low grade randomness for padding.

Phillip Hallam-Baker phill at hallambaker.com
Tue Feb 9 15:40:21 EST 2021


So, the last thing I need to write for the Mesh is a presentation layer.
This has the primary function of providing authentication over HTTP and
encryption and authentication over UDP.

The UDP packet format is intentionally as opaque as possible, there are two
basic types of packet

1) Control (limited to connection establishing/re-establishing)
2) Data

A Data packet is distinguished from control by bit 7 on the first byte
being set or clear.

A service receives a data packet as a triple:

{SourceIP, SourcePort, packet }

This is used by the host to map the packet to a connection for processing.
If this fails because of NAT cone shapes being wrong or remapping occurs,
we will use a ticket to reassociate.

The connection has a primary key established through the control channel
The primary key and nonce are used as input to a KDF to generate the Key
and IV for GCM or OFB encryption of the packet.


The format of the data packet is:

byte[nn] nonce
byte[nt] authTag
byte[nc]ciphertext

where nn= 16, nt = 16, nc = 1200-32

The ciphertext uses a more flexible tag-length-value encoding. The basic
layout will be:

<stream id>
<stream sequence#>
<resend count>
<payload>
<padding>

The basic idea here being that we simply fill each packet out to the max.
But should this be set to all zeros or should this be randomized.

Zeros: simple, minimizes opportunity for side channel games
Random: minimizes known plaintext for attacker.

If I do go with random, is there a cheap way to generate random padding I
should be thinking of? I don't need this to be particularly random.

One possibility is to put the zeros through GCM with a different key. Seems
wasteful though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210209/3ede290d/attachment.htm>


More information about the cryptography mailing list