[Cryptography] Derive IV from time in ticks.

[Phillip Hallam-Baker]

On Mon, Feb 6, 2023 at 5:32 PM Nico Williams <nico at cryptonector.com> wrote:

> On Mon, Feb 06, 2023 at 01:56:32PM -0500, Phillip Hallam-Baker wrote:
> > 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.
>
> RFC 7253, section 5.1, Nonce Requirements:
>
>    It is crucial that, as one encrypts, one does not repeat a nonce.
>    The inadvertent reuse of the same nonce by two invocations of the OCB
>    encryption operation, with the same key, but with distinct plaintext
>    values, undermines the confidentiality of the plaintexts protected in
>    those two invocations and undermines all of the authenticity and
>    integrity protection provided by that key.  For this reason, OCB
>    should only be used whenever nonce uniqueness can be provided with
>    certainty.  Note that it is acceptable to input the same nonce value
>    multiple times to the decryption operation.  We emphasize that the
>    security consequences are quite serious if an attacker observes two
>    ciphertexts that were created using the same nonce and key values,
>    unless the plaintext and associated data values in both invocations
>    of the encrypt operation were identical.  First, a loss of
>    confidentiality ensues because the attacker will be able to infer
>    relationships between the two plaintext values.  Second, a loss of
>    authenticity ensues because the attacker will be able to recover
>    secret information used to provide authenticity, making subsequent
>    forgeries trivial.  Note that there are AEAD schemes, particularly
>    the Synthetic Initialization Vector (SIV) [RFC5297], appropriate for
>    environments where nonces are unavailable or unreliable.  OCB is not
>    such a scheme.
>
> I would term that 'catastrophic'.  Though given no quantifiers (I can't
> find any in the literature) about the badness of key&nonce reuse for
> OCB3, it's hard to say how catastrophic.  What is the work factor to
> forge a message, recover plaintext, and/or recover the key given N
> key&nonce reuses?  It'd be nice to know.
>

I certainly would not. What Rogaway is saying there is that he can't prove
the correctness of the construction with nonce reuse. And I am not in the
least bit surprised that he can't. But not being able to formulate a formal
proof is not the same as 'collapses'. GCM definitely collapses, no question.

OCB leaks some information on nonce reuse. And I would expect that there
are integrity attacks possible. But that is a long way from 'collapse'.

This is why I get a bit worried about the application of formal methods.
There is a tendency to only do things that we can prove correct even though
our ability to prove zero knowledge is very limited and the schemes we can
write proofs about tend to be brittle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20230206/52fbd347/attachment.htm>