<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Fri, Feb 3, 2023 at 6:36 PM Nico Williams <<a href="mailto:nico@cryptonector.com">nico@cryptonector.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 02, 2023 at 12:01:38PM -0500, Phillip Hallam-Baker wrote:<br>
> On Wed, Feb 1, 2023 at 2:30 AM Nico Williams <<a href="mailto:nico@cryptonector.com" target="_blank">nico@cryptonector.com</a>> wrote:<br>
> What is your issue with OCB? I am trying to think of something that<br>
> wouldn't have an issue...<br>
<br>
OCB fails pretty catastrophically with key&nonce reuse.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Do you have a link for that? The whole point of OCB was not to fail catastrophically like GCM does.</div><br></div><div><div class="gmail_default" style="font-size:small">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?</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I am not following your distinction between long and short term keys. All<br>
> my data is stuff I want to keep secret for long term. But this is for<br>
> encryption at the presentation level and the content is encrypted inside.<br>
<br>
session keys == symmetric keys used by a process/thread/whatever that can<br>
reliably maintain a sequence number or chained IV for<br>
sending and a sequence number window or chained IV for<br>
receiving<br>
<br>
long-term keys == symmetric keys that are not like session keys, and so<br>
there isn't anything like a reliable counter that can<br>
be used to construct non-repeating nonce<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><div class="gmail_default" style="font-size:small"></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> All my constructions tend to have the following form<br>
> <br>
> 1) Perform a key exchange between the client device and the service host<br>
> using the device level keys, KDF the result to 256 bits.<br>
> <br>
> 2) (optional) Having established an initial secure tunnel, ratchet in key<br>
> exchanges under the user key and service key, KDF the result to 256 bits.<br>
> <br>
> 3) For each unit of data to be encrypted (envelope for data level, packet<br>
> for transport level) pick a salt value, use a KDF to obtain whatever<br>
> encryption key, MAC key and IV you need.<br>
<br>
The key question is whether you can have a reliable, monotonic counter.<br>
<br>
By the sounds of it these are what in Kerberos-land we'd call<br>
"long-term keys".<br>
<br>
If you can't keep a reliable, monotonic counter and you still want to<br>
use OCB, you do have plenty of bits to attempt to avoid key&nonce reuse:<br>
all the bits of salt that you use in your KDF, and all the bits of the<br>
nonce. You could use all of these metadata:<br>
<br>
- time (as granular as your local system clock allows)<br>
- a PID/TID<br>
- a start time for the PID/TID<br>
- a local message counter (can be ephemeral for the process/thread)<br>
- a per-message block counter<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Hence my interest in using ticks. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But the other thing with ticks is that it potentially gives a guard against transaction replay attacks which was my original question.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
IIRC I or someone proposed something like that for Kerberos and we<br>
couldn't get consensus. But maybe for your system this would do?<br>
<br>
I think the most important questions will be:<br>
<br>
- how likely is a key&nonce reuse event for your system given a design<br>
like this?<br>
<br>
- can an attacker force your devices to reuse a key&nonce?<br><br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Forced no. But numpties can be a risk.</div><div class="gmail_default" style="font-size:small"></div></div></div>