[Cryptography] Derive IV from time in ticks.

[Nico Williams]

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.

> 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 nonces

In _Kerberos_ a long-term key is any of:

 - the keys that tickets are encrypted to by the Kerberos ticket
   granting service (TGS) and authentication service (AS)

 - keys derived from passwords for user authentication at the Kerberos
   authentication service (AS)

In Kerberos there is no way to reliably keep a monotonic counter because
the AS and TGS are replicated and run on multiple servers, and it's all
stateless, so there is no way to keep a counter synchronized.

Some years ago (maybe ten?) we had a discussion on kitten at ietf.org about
adding AEAD cipher modes to Kerberos, and if I remember correctly I
proposed using timestamps and local metadata like PIDs and counters to
construct nonces for GCM/CCM/OCB.  And we couldn't get consensus for
that because a) for long-term session keys the cipher mode constructions
we have in Kerberos are good enough, b) the safety of this scheme was
not clearly awesome, c) we only really wanted AEAD for session keys.

We do now have a new effort to use AEAD cipher modes for only session
keys in Kerberos.  The main concern right now in KITTEN WG is about how
to make sure those cipher modes are never used with long-term session
keys.  Luke Howard has a couple of Internet-Drafts on this:

 - draft-howard-krb-aead-01.txt
 - draft-howard-gssapi-aead-01.txt

> 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

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?

Nico
--