Cryptography Mailing List 2024

 

How to De-Bollocks Cryptography?

As a reply to Peter Gutmann's posting to the list I started the following request:

I firmly believe that Peter's conclusion [1] is correct: "COMPLEXITY IS THE ENEMY OF SECURITY" So we must find practical ways to solve the complexity problem or at least to tackle it. But bear in mind what Einstein once said: "Everything should be made as simple as possible *but no simpler.*" There are limits to reducing complexity (to avoid the term simplicity). If we cannot find compelling answers to the complexity problem in Cryptography the churn will continue. If you have any idea how to attack the complexity problem, hammer it out and post it here, it might be developed into a candidate for consent. Be practical and be constructive. -ralf

This lead to a number of interesting replies that can be found here as a chronological listing.

This is my reply to Victor Dukhovni's suggestion for a less-complex TLS solution:

Thanks Victor for the link. The introduction https://strobe.sourceforge.io/papers/strobe-latest.pdf is well worth reading. It seems that it is possible to implement secure communication protocols with a very limited number of operations (10 different core functions) and 4 bits of flags all based on one STROBE primitive (KECCAK-f). The interesting part is the fact that while the protocol for information exchange moves on, a transcript of past stages is recorded that affects future operations. "Strobe maintains a running hash of the protocol transcript, which is the sequence of all operations and their data as seen by the application layer." The inclusion of these transcripts in subsequent operations clearly helps to ensure, that the protocol develops as expected. Though it also imposes limitations to what the protocol can achieve. The paper claims that TLS can be implemented based on minimal STROBE operations. While the implementation is targeted on IoT systems with limited computation powers, this idea is IMHO quite interesting and promising. -ralf

Peter Gutmann focussed on the false direction innovation in Cryptography has turned into.

Jon Callas contributed some interesting ideas about security and complexity.

Peter Gutmann's more detailed description of the attitude of standards commitees and protocol designers with regard (but not limited) to TLS.

... which led to a solution called "WIREGUARD".

On Mon, 12 Aug 2024, Peter Gutmann wrote: > Kent Borg <kentborg at borg.org> writes: > > > If only there were someone with some common sense and visibility and > > cryptography credentials to lead an effort to define a "TLSsimple" standard. > > We've already got it, it's called WireGuard. One guy came up with a better > design than more than two decades of continuous work by standards committees > could produce, and despite being (figure randomly pulled from thin air) twenty > times smaller than IPsec and TLS, no-one seems to be upset about all the > essential and critical features that it doesn't have. > > It also seems to be a helluva lot more secure than either IPsec or TLS have > been, probably because it's not packed with said "features". In fact it > pretty much follows the design thinking I mentioned towards the end of the > Bollocks talk that leads to really hard-to-compromise designs, one cipher > suite, one mode, and not much more. What's interesting from a practical view is the way they omit the whole PKI nonsense. WireGuard is for use cases in which one party A knows to which other party B they want to exchange information securely. WireGuard introduces something they call "Cryptokey routing". Every participating machine with a working IP address is identified by a 32 byte string that works as a public key for ECDH key exchange. This 32 byte string is recorded in the "Cryptokey Routing Table" of every other machine that wants to establish a secure connection together with the allowed IP range of the other peer. This range could be limited to a single IP or more. Once the "Cryptokey routing tables" of every participating peer are set up, the WireGuard virtual interfaces (wg0) are fired up and data can float between the peers (authenticated and encrypted). That's it from the user's point of view. So packets arriving from not-allowed IPs are dropped. And after the initial handshake, only authenticated data from the established peer comes out of the interface wg0. The rest is silence! If you want to connect to arbitrary internet host, it's nothing for you. But if you know what your destination is, WireGuard is a good try. And BTW its not fiction, but audited minimal code that can be installed on most OS not just Linux. -ralf