<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">So I am into the closing stages here writing up a small presentation layer with some surprises for the wannabe censor.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Why not make every host a potential onion routing node at the packet level, thought I. This approach also has some interesting leverage in protecting against quantum cryptanalysis.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Consider the case in which Alice establishes a video chat with Bob. Since both people are using mobile clients with varying IP addresses, this must entail use of a presence server for discovery at some point. So our protocol is going to involve a conversation like:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice->Presence: Where is Bob? I wanna talk</div><div class="gmail_default" style="font-size:small">Presence -> Alice: Bob can be reached through a wide cone NAT on {IP, port}<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Only of course we would want all this to be authenticated and we want a four corner model on this to provide protection against abuse.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So after we have factored all of the necessary authentication etc. and Kerberos ticketing for performance, what we end up with is a two layer security model:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Application layer (Mesh chat): Using Alice and Bob's public/private device keys</div><div class="gmail_default" style="font-size:small">Presentation layer (transport): Using kerberized tickets mediated by the Mesh Service Providers for Alice and Bob.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And the reason I am not using TLS for the presentation layer is that it doesn't ratchet and ephemeral keys replace the keys established in the master key agreement rather than both being used to drive a key derivation function. (Could the NSA have jiggered it? Of course)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Since Alice and Bob both have the benefit of a shared secret established in both contexts, my plan is to fuse these by means of the KDF. What this will provide is 'graceful degradation' in the case that quantum cryptanalysis becomes possible before resistant algorithms.</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">But anyways, here is my problem. The initial draft of the spec had a fresh nonce for every packet which was used to derive a new key and a new IV for each packet. Problem being of course that this is likely to be rather inefficient. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If we follow the ideology of AEAD encryption being better, maybe we should just rely on the IV being different for every packet?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Well no, not when GCM turns AES into a stream cipher. If I can get 2^48 packets, I can start decrypting some. This seems like playing a shell game in which a really strong cipher got bartered down to a weak one. 2^48 packets is a lot of data but it is well below the 2^128 work factor I am designing to. </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">So I see two possible options here:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Cheap means of rotating the key on every use.</div><div class="gmail_default" style="font-size:small">2) Use KDF</div><div class="gmail_default" style="font-size:small">3) Move to OCB3 which is not a stream cipher.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thoughts?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>