<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 1, 2023 at 2:30 AM Nico Williams <<a href="mailto:nico@cryptonector.com">nico@cryptonector.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 29, 2022 at 03:27:41PM -0500, Phillip Hallam-Baker wrote:<br>
> I am writing a very small scale scheme for use on a UDP based presence<br>
> service. I am not concerned about traffic analysis at this point, I will<br>
> add an obfustification layer later on. Same for rekeying the connection,<br>
> just starting things off with a Kerberos like scheme.<br>
<br>
Are the keys involved session keys or long-term keys?  You mention<br>
rekeying, so I assume we're talking about session keys produced by a<br>
reasonable key exchange.  If it's long-term keys then OCB is not the<br>
droid you're looking for.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">What is your issue with OCB? I am trying to think of something that wouldn't have an issue...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">All my constructions tend to have the following form</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Perform a key exchange between the client device and the service host using the device level keys, KDF the result to 256 bits.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I can't remember quite what I was doing last Dec, I might have been looking to get more performance than maybe I should because I was looking to build a QUIC like transport which gave absolutely nothing away to traffic analysis (or at least the minimum). I have since backed out that code since the implementation barrier is a bit high for anyone looking to write a client that can interop.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">So, the current scheme is limited to a secure presence protocol. Messages consist of 1-16 UDP packets with a salted key+IV derivation per message. Which is probably not going to violate your long term key concern.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small"></div></div></div></div>