This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
This article has been automatically rated by a bot or other tool because one or more other projects use this class. Please ensure the assessment is correct before removing the |auto= parameter.
This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography
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)[reply]
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)[reply]
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)[reply]
