[Cryptography] Derive IV from time in ticks.

[Phillip Hallam-Baker]

On Fri, Feb 3, 2023 at 6:36 PM Nico Williams <nico at cryptonector.com> wrote:

> On Thu, Feb 02, 2023 at 12:01:38PM -0500, Phillip Hallam-Baker wrote:
> > On Wed, Feb 1, 2023 at 2:30 AM Nico Williams <nico at cryptonector.com>
> wrote:
> > What is your issue with OCB? I am trying to think of something that
> > wouldn't have an issue...
>
> OCB fails pretty catastrophically with key&nonce reuse.
>

Do you have a link for that? The whole point of OCB was not to fail
catastrophically like GCM does.

Reuse the IV in GCM and you have a stream cipher so it is schoolboy level
cryptanalysis. The tweakable cipher structure is supposed to make that
hard. Did Phil Rogaway really blow it?

GCM-SIV is not an option for me because I have to be able to encrypt very
large quantities of data, routinely in the 'no ordinary machine has this
much RAM'. range.

> I am not following your distinction between long and short term keys. All
> > my data is stuff I want to keep secret for long term. But this is for
> > encryption at the presentation level and the content is encrypted inside.
>
> session keys == symmetric keys used by a process/thread/whatever that can
>                 reliably maintain a sequence number or chained IV for
>                 sending and a sequence number window or chained IV for
>                 receiving
>
> long-term keys == symmetric keys that are not like session keys, and so
>                   there isn't anything like a reliable counter that can
>                   be used to construct non-repeating nonce
>

My problem with that distinction is that any primary key that gets applied
to more than one envelope is going to start looking like a long term key.
So I am doing my best to avoid nonce reuse and I am pretty certain my code
achieves that. What I am less confident about is preventing other folk from
extending the spec and blowing a hole in it in the process.

So for example, in my scheme, a service host starts up and starts appending
data to a log file. It should perform a key exchange each time it starts up
and once an hour and append that into the sequence. So if the log has a
million entries recorded over a year, there might be only ~750 key
exchanges.

I am going to do it right but I am pretty sure some numpty is going to come
along and decide to write out the primary secret to a store and once that
happens there is no way to guarantee any counter gets updated.

> All my constructions tend to have the following form
> >
> > 1) Perform a key exchange between the client device and the service host
> > using the device level keys, KDF the result to 256 bits.
> >
> > 2) (optional) Having established an initial secure tunnel, ratchet in key
> > exchanges under the user key and service key, KDF the result to 256 bits.
> >
> > 3) For each unit of data to be encrypted (envelope for data level, packet
> > for transport level) pick a salt value, use a KDF to obtain whatever
> > encryption key, MAC key and IV you need.
>
> The key question is whether you can have a reliable, monotonic counter.
>
> By the sounds of it these are what in Kerberos-land we'd call
> "long-term keys".
>
> If you can't keep a reliable, monotonic counter and you still want to
> use OCB, you do have plenty of bits to attempt to avoid key&nonce reuse:
> all the bits of salt that you use in your KDF, and all the bits of the
> nonce.  You could use all of these metadata:
>
>  - time (as granular as your local system clock allows)
>  - a PID/TID
>     - a start time for the PID/TID
>  - a local message counter (can be ephemeral for the process/thread)
>  - a per-message block counter
>

Hence my interest in using ticks.

But the other thing with ticks is that it potentially gives a guard against
transaction replay attacks which was my original question.



> IIRC I or someone proposed something like that for Kerberos and we
> couldn't get consensus.  But maybe for your system this would do?
>
> I think the most important questions will be:
>
>  - how likely is a key&nonce reuse event for your system given a design
>    like this?
>
>  - can an attacker force your devices to reuse a key&nonce?
>
>
Forced no. But numpties can be a risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20230206/7eecb417/attachment.htm>