And a response. I have taken the liberty of copying the various portions of the contents of the webpage to this email for response. I apologize for the formatting confusion which may mistake Peter Gutmann's comments with those of the semi-anonymous misinformed person under scrutiny.
I would have CC'd the author of the response page, but it fails to mention an author, in spite of the "Comments are welcome" statement at the beginning. > On September the 15th Peter Gutmann contacted us and showed us part of a writeup which he > posted to a cryptography mailing list on the 22th. In this writeup he identifies several security issues > in CIPE, VTun and tinc. Below we will examine his findings and explain why some flaws or > weaknesses Peter Gutmann found are in fact not a problem at all for a VPN daemon like tinc. > As a reader you are ultimately left to draw your own conclusions, I encourage you to read all the > arguments from both sides and, if possible, verify them by reading the documentation and source > code of tinc. Comments are welcome. > Predictable IV Proposed solution: provide the option of a "full IV and move the sequence number out of the ciphertext," note that this is an _option_, instead of the necessary for security always. > Truncated MAC > tinc will continue to use only the first 32 bits by default. Simply put this is unacceptable from a security standpoint. The view taken is that the extra 128 bits represents a significant overhead in the communication. So I did the math, sending the extra 128 bits over a 52kbs would take 0.002 seconds, and over a T1 the time cost is an absolutely enormous 0.00008 seconds. The other consideration is the potentially the computation time argument, but SHA-1 is used regardless, the computation time is identical. There is no justification in even a dialup environment for not using the full HMAC. > Use of RSA > Tinc uses RSA encryption only once, during authentication. <sarcasm> Yeah authentication is such a minor thing that major flaws are completely aceptable.</sarcasm> > A message is sent which has the same length as the RSA key, and is > completely filled . . .using real random data (OpenSSL's RAND_bytes()). I really wish people would actually read documentation *before* making stupid claims like this, in fact to quote the OpenSSL docs "These functions implement a cryptographically secure pseudo-random number generator (PRNG). " Any claim that OpenSSL implements a "real" random number generator are completely false. > So, the message does not have low entropy and doesn't contain predictable > bits. Read the docs, the message has 0 entropy (actually marginally above 0, but these are simple rounding errors), that's what a pseudo-random number generator means. > However, there is no guarantee that the message was encrypted using the > correct public key or that noone has tampered with it. This is of no concern > for tinc though. There goes that authentication doesn't matter problem again, remind is tinc supposed to have any sembalnce of security? or is it just a stupid toy designed for young children to keep they're even younger siblings out of their personal matters? > Part of the message is used as the key for the symmetric cipher that is used > by the sender of this key to encrypt the rest of the messages it will send. A > challenge-response exchange right after exchanging the RSA encrypted > messages is done to ensure that both the sender of the symmetric cipher key > has the right public key, the recipient has the right corresponding private > key, and the message was not tampered with (because that would change the > symmetric cipher key). Whoever designed and stated this has no idea about cryptographic security. Using a "part" of a shared secret, generated by a pRNG on only one side, introduces horrific flaws in the protocol. Pretending that poorly done RSA encryption magically solves the problem will only risk everything that has ever been encrypted using tinc. > Authentication protocol > First of all, we assume Mallet does not know the private keys of Bob and > Alice (Bob and Alice are not compromised), and Bob and Alice do not know > Mallet at all (they don't trust Mallet, otherwise he could've made a > connection without having to resort to a cryptographic attack). Good luck keeping that assumption true, with the oracle attack listed above that won't stay true very long at all. > First, keys for the > symmetric cipher encryption are exchanged. Mallet cannot decrypt keys he > gets from Bob and Alice, because he doesn't have their private keys. But he does, he spoofed each connection and acted as initiator for both, now it's a simple matter of resending. Your entire model is based on a misunderstanding of what RSA does and does not offer. What you're missing is that the connection iniator sets all the keys and can determine all the keys (assuming the uncontested simplified message flow is correct). Mallet can very easily perform a complete man-in-the-middle attack > Configuration skipped, configuration is the least of the issues here. > General issues > - Don't use the same key for encryption and authentication. > Nowhere in the authentication protocol does this happen. Everywhere in the authentication protocol does this happen. RSA is used only once, and only a public key is necessary. From there the keys are a derivative of the same key, so the same key is used for encryption and authentication. > - Don't have the key chosen entirely by one side (even if it's only Alice > and Bob on the line rather than Mallet, if one of the two has a poor RNG, > all communications from them are compromised). > This is a valid point. Tinc can easily be changed to use keys composed of > what both sides send, for example by using the Diffie-Helman scheme. This is > planned for tinc 2.0. My guess is that you will once again use it in an insecure method, use either signed ephemeral keys, or introduce randomness form both sides, otherwise you will have the same problems from slightly different angles. > - Bind the identity of the principals to the authentication. > The authentication is done using RSA encryption, the RSA keys are directly > bound to the identities of the tinc daemons. Completely incorrect. When Mallet(Alice) contacts Bob, Bob is authenticated, but Mallet(Alice) is not. Additionally Bob is not properly authenticated due to the gaping holes in the initial protocol. > - Don't use the same messages in both directions. > Tinc doesn't send the same messages, it sends the same kinds of messages. Exactly the problem. Once a message type has been sent in the connection, change the message type (even if it's just a transfer number), this will address yet another gaping hole. > - Don't act as an oracle for an attacker. > Apart from possibly being susceptible to a timing attack, we don't believe, > and Peter Gutmann has not convinced us, that tinc can be used as any other > kind of oracle. You provide all the chosen ciphertext information Mallet could want. You act as an oracle. > As it stands the handshake protocol only narrowly avoids a variety of > basic attacks, making it quite brittle in that the most trivial change (or > someone thinking about possible attacks a bit further :-) would probably > kill it. > I think this holds for virtually all cryptographic handshake protocols. Only the really bad ones, all the ones that are used by real cryptographic engineers miss attacks by large amounts. > Thoughts > VTun even mentions it is not intended to be > secure, and CIPE focuses more on usability than on security. And tinc goes out of it's way to avoid any semblance of good security. > Furthermore, SSL and SSH are > reliable stream based protocols, unsuitable for VPNs Someone doesn't pay much attention to what they write. Both SSL and SSH _ARE_ VPN protocols, that you don't recognise them as such reflects a great deal on lack of knowledge in the area of security. > [VPNs] work best with unreliable datagrams Ummmm, do you realize how dumb that sounds? > Both SSL and SSH have had their security > problems . . , as perfect as Peter Gutmann would let us believe. They may not be perfect but in neither case can Mallet do as much damage as easily, even the recent break in OpenSSH did not allow a compromise as big as even the smallest of the problems briefly explored in tinc. > Apart from that, there is no reason why people shouldn't create new > protocols, which might in time become just as strong or even stronger. Even > great names as Ron Rivest didn't get it right the first time. Yeah but the "great names" admit they are wrong, and fix things. You have instead taken every possible moment to insist that tinc is good, something that even the barest educated layperson can see is simply and completely false. > Whenever someone thinks that they can replace SSL/SSH with something much > better that they designed this morning over coffee, their computer speakers > should generate some sort of penis-shaped sound wave and plunge it > repeatedly into their skulls until they achieve enlightenment. > A very professional and constructive argument. I think here Gutmann went a bit overboard in his recommendation, but regardless the idea that someone should replace SSH/SSL with something designed by an amateur without the knowledge necessary to make it correct is a bad idea. In fact I have several years of experience and I have a potential replacement protocol that I think may in some cases be better than SSL/SSH, even with my experience I have held off publishing it for about 4 years now while I verify that it will in fact stand up to attack. How long was it between the inducement of this idea and it's release? > We have no obligation to justify anything we do. We also do not believe SSL > is the be-all, end-all of cryptography. Actually you have that backwards. In security you have every obligation to justify every single portion of every line of code in every product. However, SSL is far from the be-all, end-all of security. In fact if it were Gutmann would have simply recommended that everyone use one of the many SSL-VPN products available (in spite of the errant belief that SSL is "unsuitable for VPNs"). If anyone wants to make a toy that is only useful at keeping baby siter grade atackers out tinc is suitable (at least until someone writes a small script to perform any of the numerous breaks outlined by Gutmann), for anyone that actually needs to protect something worth more than $0.05 use something that offers real security. Joe Trust Laboratories Changing Software Development http://www.trustlaboratories.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]