Talk:Interlock protocol

Clarify "zipless"
What does "zipless" mean for a secure channel? --68.102.252.87 06:47, 30 July 2005 (UTC)

Forced latency protocol
I'm the inventor the Forced Latency Protocol. The Forced Latency Protocol is not a variant or an extension of the Interlock Protocol. They are both protocols which attempt to defend against Man-In-The-Middle attack even when the honest participants do not share any pre-existing keying material. There the similarities end. --Zooko Wilcox-O'Hearn —Preceding unsigned comment added by Zooko (talk • contribs) 06:09, 31 May 2010 (UTC)


 * The concept seems pretty analogous, both rely on an all-or-nothing transform and split encrypted messages in half. The only thing that's changed is the added delay. But obviously I'm no expert. Can you explain what am I missing?
 * Also I am unable to locate any sources for the forced-latency protocol (all that I can find on the Internet are based on this Wikipedia article). I doubt it can satisfy the notability criteria so it does not warrant its own article. Alternatively it can be removed entirely on the basis of failing verifiability. -- intgr [talk] 16:45, 31 May 2010 (UTC)


 * Please do not remove this. Defenses against MITM attacks that work are rare and poorly documented.  I prefer seeing this page with at least one "fixed" version.  That said, while I do believe this protocol works, the description needs some enhancements.  There is no reason that Z must delay sending Ez',b(Ma)<1> to B once he receives Ea,z(Ma)<2> from A.  This change accelerates his handshake to have normal timing.  However, in this case improper delayed timing for delivering the data (>= 3T vs >= 2T) indicates a possible MITM attack.  Also, the contents of Ma and Mb should be described.  Ma<1> could contain an encrypted request to the server and a copy of Ka, while Ma<2> could contain the decryption key for Ma<1>,  Mb<1> could contain an encrypted form of Kb, and Mb<2> could contain the decryption key for Mb<1> and a response to the request in Ma<1>, such as OK, or NOT FOUND, and the hash digest of data.  Is this more or less accurate?WaywardGeek (talk) 23:01, 4 February 2015 (UTC)