Re: Five Theses on Security Protocols
On Sun, Aug 01, 2010 at 11:20:51PM +1200, Peter Gutmann wrote: > >But, if you query an online database, how do you authenticate its answer? If > >you use a key for that or SSL certificate, I see a chicken-and-egg problem. > > What's your threat model? My threat model is practice. I assume Perry assumed that you have some pre-established trust relationship with the online database. However, I do not see myself having much of those. Yes, my browser comes preloaded with a set of root certificates, but Verisign is as much a third party to me as any SSL protected website I want to visit. Anyway, suppose we do all trust Verisign. Then everybody needs its public key on their computers to safely communicate with it. How is this public key distributed? Just like those preloaded root certs in the browser? What if their key gets compromised? How do we revoke that key and get a new one? We still have all the same problems with the public key of our root of trust as we have with long-lived certificates. Perry says we should do online checks in such a case. So which online database can tell us if Verisign's public key is still good? Do we need multiple trusted online databases who can vouch for each other, and hope not all of them fail simultaneously? Another issue with online verification is the increase in traffic. Would Verisign like it if they get queried for a significant fraction of all the SSL connections that are made by all users in the world? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: init.d/urandom : saving random-seed
On Sat, Jul 31, 2010 at 04:55:18AM -0700, John Denker wrote: > > 2. How dangerous it is to feed the pool with stale seed data in the next > >boot (i.e. in a failure mode where we do not regenerate the seed file) ? [...] > Now, to answer the question: A random-seed file should never be reused. > Never ever. > > Reusing the random-seed file makes the PRNG very much worse than it would > otherwise be. By way of illustration, suppose you are using the computer > to help you play "battleship" or "go fish" against a ten-year-old opponent. > If you use the same 'random' numbers after every reboot, the opponent is > going to notice. You are going to lose. In more-demanding situations, > against an opponent with more skill and more motivation, you are going to > lose even more miserably. I do not think replaying a "stale" seed file at boot is any worse than not replaying that file. The real issue is how to ensure a fresh seed file. However, looking at Debian's /etc/init.d/urandom, right after writing the seed file to /dev/urandom, it immediately creates a new one by reading from the freshly seeded /dev/urandom again. There is a comment right above that section in the script: "Hm, why is the saved pool re-created at boot? [pere 2009-09-03]". Of course that is to ensure there is always a fresh seed file, even if the system crashes and cannot writte a new seed file at shutdown time. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Five Theses on Security Protocols
On Sat, Jul 31, 2010 at 12:32:39PM -0400, Perry E. Metzger wrote: > 1 If you can do an online check for the validity of a key, there is no > need for a long-lived signed certificate, since you could simply ask > a database in real time whether the holder of the key is authorized > to perform some action. The signed certificate is completely > superfluous. > > If you can't do an online check, you have no practical form of > revocation, so a long-lived signed certificate is unacceptable > anyway. But, if you query an online database, how do you authenticate its answer? If you use a key for that or SSL certificate, I see a chicken-and-egg problem. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Gutmann Soundwave Therapy
On Fri, Feb 01, 2008 at 02:51:36PM +0800, Sandy Harris wrote: > What I don't understand is why you think tinc is necessary, > or even worth the trouble. > > IPsec is readily available -- built into Windows, Mac OS > and various routers, and with implementations for Linux > and all the *BSDs -- has had quite a bit of expert > security analysis, and handles VPNs just fine. > > Does tinc do something that IPsec cannot? Yes, there are a few reasons why people use tinc instead of IPsec. Those people who tried both tell me tinc is much easier to set up. Tinc tunnels over UDP and/or TCP. This allows it to work in situations where IPsec would not, for example behind (masquerading) firewalls. Tinc does not need fixed IP addresses at endpoints; endpoints can have more than one IP address, or hostnames, so it even works when one has dynamic DNS. With tinc, you can set up VPNs with more than 2 nodes, not by configuring more tunnels, but just by specifying endpoints. Tinc itself will handle the packet routing. It tries to set up a full mesh, but it has a built-in routing protocol, not unlike OSPF, that can route packets via intermediate nodes if that is necessary. As a side effect it provides some redundancy. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Gutmann Soundwave Therapy
On Thu, Jan 31, 2008 at 03:46:47PM -0500, Thor Lancelot Simon wrote: > On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote: > > > > Peter sent us his write-up up via private email a few days before he > > posted it to this list (which got it on Slashdot). I had little time to > > think about the issues he mentioned before his write-up became public. > > When it did, I (and others too) felt attacked in a cruel way. Peter > > ignored all the reasons *why* we used the kind of crypto we did at > > that moment, compared it to a very high standard, and made it feel like > > every thing we didn't do or didn't do as well as SSL made our crypto > > worthless. > > There is no valid reason to ship snake oil cryptography (at any moment). > > There is no standard but a high standard which is appropriate for > comparison. > > Since SSL was already available, there was no excuse to do anything > worse. Please understand the following: I am not defending the use of our less-than-SSL crypto in tinc. But there are reasons why we implemented it the way we did at that time. It doesn't matter whether these reasons were bad or good. The result of ignoring the why, and "attacking" others by pointing out everything they do wrong in your perspective (even though your perspective is perfectly right), and then finishing off the way Peter did, which is easily perceived as an insult if you are on the receiving end of it, does not encourage others to fix the problems, but rather puts others in defensive mode. Are you out to help others, or just to look down on them? If it's the first, then please make others accept your help by just formulating things in a more friendly way (although a patch with a fix would soften up things as well). If it's the latter, please continue just as you are doing now. Now some (good and/or bad) reasons why we ended up with our lesser-than-SSL crypto, in no particular order: - SSL was not perceived at that time as a solution for our problem. - We were application writers, not security specialists. We had to encrypt traffic, we did the best to our knowledge at that time. - I had read Schneier's Applied Cryptography from front to end a few times. It made me feel I knew everything about crypto. Even Bruce admits he thought at that time he had put everything a programmer needed to know about crypto in that book. It doesn't mention SSL. - We needed to tunnel data over UDP, with UDP semantics. SSL requires a reliable stream. Therefore, we had to use something other that SSL to tunnel data. - It was fun to come up with a full duplex authentication scheme using RSA. More fun than using someone elses stuff. - Because we could. - We were Free Software developers who did it in our spare time for fun, we were not a company that sells it as one of its products. > It seems that you still don't understand those things, or you would not > complain about them even at this far removed date. How unfortunate. It seems that you haven't read the rest of my email, or you would not have written that sentence. I am enlightened now :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Gutmann Soundwave Therapy
On Tue, Jan 29, 2008 at 12:26:21PM -0500, Perry E. Metzger wrote: > Clearly, more people need to know about "Gutmann Soundwave Therapy". > > Ivan Krstić <[EMAIL PROTECTED]> writes: [...] > > [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238 > > As it turns out, the central image of Peter's post was popularized > earlier*. > > However, Peter clearly said this first in a security context, and I > hope that the term "Gutmann Soundwave Therapy" spreads widely within > our field as a way of ridiculing the desire to invent your own crypto > algorithms and protocols. When it gets to the point where salesmen are > vaguely aware of the phrase and fear it, we will know we have done our > job successfully. As one of the main developers of tinc, I have been at the receiving end of Gutmann's therapy, or "drive-by shooting" as I experienced it at that time. Peter sent us his write-up up via private email a few days before he posted it to this list (which got it on Slashdot). I had little time to think about the issues he mentioned before his write-up became public. When it did, I (and others too) felt attacked in a cruel way. Peter ignored all the reasons *why* we used the kind of crypto we did at that moment, compared it to a very high standard, and made it feel like every thing we didn't do or didn't do as well as SSL made our crypto worthless. We had some other people sending us security reviews of tinc, Jerome Etienne for example. With them, we never had that feeling of being "attacked". The conversations we had with them encouraged us to improve tinc. Peter's write-up was the reason I subscribed to this cryptography mailing list. After a while the anger/hurt feelings I had disappeared. I knew then that Peter was right in his arguments. Nowadays I can look at Peter's write-up more objectively and I can see that it is not as ad-hominem as it felt back then, although the whole soundwave paragraph still sounds very childish ;) When tinc 2.0 will ever come out (unfortunately I don't have a lot of time to work on it these days), it will probably use the GnuTLS library and authenticate and connect daemons with TLS. For performance reasons, you want to tunnel network packets via UDP instead of TCP, so hopefully there is a working DTLS implementation as well then. I hope that in the future, if you see an application doing something wrong, you don't immediately give the developers the soundwave therapy. Be a little bit more gentle and try to find out why it was written that way in the first place. It will create a lot more understanding and willingness from the developers to fix the problems. Also, from experimenting with a version of tinc that uses TLS, I can tell you that it not the perfect solution for our problem. The main issue I see with SSL and TLS is with the credentials. Both X.509 and OpenPGP are focussed on URLs or email addresses. It is not clear to me how to store other information (like which subnets a node on the VPN is authorised to use) in such credentials in a nice way, other than shoehorning it into a CN (X.509) or uid (OpenPGP) field. Certificate chain verification is something that often goes wrong; some SSL libraries do not offer that functionality, or only do it when an application explicitly requests it. With OpenPGP you can have a web of trust, but how do you make use of it in an automated way? I expect that the next round of penis-shaped soundwave therapy will not be focussed on whether or not an application uses SSL, but on how it (mis)uses SSL. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: World's most powerful supercomputer goes online
On Sat, Sep 01, 2007 at 03:46:45PM +1200, Peter Gutmann wrote: > I feel I should add a followup to the earlier post, this was implied by the > rhetorical question about what the LINPACK performance of a botnet is, but > I'll make it explicit here: > > The standard benchmark for supercomputers is the LINPACK linear-algebra > mathematical benchmark. Now in practice the LINPACK performance of a botnet > is likely to be nowhere near that of a specially-designed supercomputer, since > it's more a distributed grid than a monolithic system. On the other hand bot- > herders are unlikely to care much about the linear algebra performance of > their botnet since it doesn't represent the workload of any of the tasks that > such a system would be used for. Another interesting use may be data hiding. The botnet software could store information in RAM (never on disk), and replicate it to other nodes. If one node goes down, other nodes will still have the information. If one node detects that virusscanners or forensic tools are being used, it can easily wipe the information from RAM or just reboot the machine without fear that the information would really be lost.=20 Experience with tinc (a VPN daemon with peer-to-peer like architecture, which replicates certain information to all daemons in a single VPN), showed that even in a network with only 20 nodes, it is extremely hard to get rid of information. You either need to shut down all daemons at the same time to make sure all state is lost, or modify the software to allow explicit deletion of certain information. With more that 1 million nodes it will be even harder to delete data. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: BETA solution, Re: Failure of PKI in messaging
On Thu, Feb 15, 2007 at 02:47:05PM -0800, Ed Gerck wrote: > Zmail actually reduces the amount of trust by not storing your usercode, > password, or keys anywhere. This makes sense for zmail, and is an incentive > to actually do it, to reduce risk -- anyone breaking into any zmail server, > even physically, will not find any key or credential material for any user > and, hence, cannot decrypt any user area (the user area keeps the address book > and contact keys, all encrypted using the user keys that are not there), or > user messages collected from ISPs. Where are the usercode, password and keys stored then? [...] > This will actually be available in v3.x, with an option for client-based > super-encryption. If you are concerned about zmail peeking into the raw > message, which zmail does not do, you can simply agree with your message > partner on an out-of-band passphrase and use it in your client (without > zmail access) to encrypt. Your recipient can do the same to decrypt. What > you get from zmail is the secure routing and distribution -- for example, > you can require the recipient to login, allow the recipient to prevent > phishing, and expire the message in 7 days. You can also request a return > receipt telling you when, where, how, and by whom the message was decrypted. /If/ I trust ZMail (the people behind it and the X.509 stuff that secures the website) then yes, this is functionality not offered by SMTP and PGP or S/MIME. But I don't see this replacing PGP or S/MIME. I also still don't see how this improves the trust model. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: long-term GPG signing key
On Sat, Jan 14, 2006 at 12:30:25PM -0700, Anne & Lynn Wheeler wrote: > Guus Sliepen wrote: > > By default, GPG creates a signing key and an encryption key. The signing > > key is used both for signing other keys (including self-signing your own > > keys), and for signing documents (like emails). However, it is possible > > to "split" the signing key into a master key that you only use to sign > > other keys, and a key dedicated to signing documents. You can revoke the > > latter key and create a new one whenever you want, the master key is > > still valid. Also, when people sign your key, they sign your master key, > > not the subkeys. The signatures you accumulated will also still be > > valid. You can also keep the master key safely tucked away on an old > > laptop that you keep in a safe, and only export the subkeys to your > > workstation. That way the master key is very safe. > as in previous post ... i assert that fundamental digital signature > verification is an authentication operation > http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing keys > > and doesn't (by itself) carry with it characteristics of human > signature, read, understood, approves, agrees, and/or authorizes. It depends on how it is used. For example, when I sent this email, I typed in the passphrase of my PGP key, authorising GnuPG to create a signature for this email. This comes very close to "human signing". I read, understood, approve etc. with the contents of this email. If assymetric cryptography is used to automatically sign a credit card transaction without the user having to do more than click a button, then I agree that in that situation, the digital signature is not the same as a human signature. [...] > it is when you start equating private keys with certification and truth > characteristics that you move into a completely different risk and > threat domain. I don't equate private keys with that. I do equate signatures made with those keys with that. > the other foray into embellishing private keys and digital signatures > with human signature type characteristics was the non-repudiation > activity. however, it is now commoningly accepted that to embellish > digital signatures with non-repudiation attributes requires a whole lot > of additional business processes ... not the simple operation of > generating an authentication digital signature. [...] > the corollary is that digitally signed certificates and > private keys embellished with certification and truth characteristics > become less and less meaningful. That is probably true, but in the mean time Travis still wants to know how to create a PGP key with the properties he wishes for. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: long-term GPG signing key
On Tue, Jan 10, 2006 at 03:28:49AM -0600, Travis H. wrote: > I'd like to make a long-term key for signing communication keys using > GPG and I'm wondering what the current recommendation is for such. I > remember a problem with Elgamal signing keys and I'm under the > impression that the 1024 bit strength provided by p in the DSA is not > sufficiently strong when compared to my encryption keys, which are > typically at least 4096-bit D/H, which I typically use for a year. > > The whole reason I'm using a signing key is that I have numerous older > keys which have now expired and so the signatures on them are > worthless. I don't attend many keysigning parties so it's hard to > make the system work without collecting signatures over a long period > on some very high strength key. Also, I'd like to use the signing key > as a kind of identity, not tied to any particular email address, and > only used to sign communication keys, which *are* tied to a email > address and have shorter expiration times. > > Does anyone have any suggestions on how to do this, or suggestions to > the effect that I should be doing something else? By default, GPG creates a signing key and an encryption key. The signing key is used both for signing other keys (including self-signing your own keys), and for signing documents (like emails). However, it is possible to "split" the signing key into a master key that you only use to sign other keys, and a key dedicated to signing documents. You can revoke the latter key and create a new one whenever you want, the master key is still valid. Also, when people sign your key, they sign your master key, not the subkeys. The signatures you accumulated will also still be valid. You can also keep the master key safely tucked away on an old laptop that you keep in a safe, and only export the subkeys to your workstation. That way the master key is very safe. About keys being tied to "email addresses" (uids): you can create a uid with just your name, no email address, and if you like a comment with your birthday or passport number in it. Let people sign that uid. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: The future of security
On Sun, May 30, 2004 at 12:36:53PM -0700, bear wrote: > The bigger problem is that webs of trust don't work. > They're a fine idea, but the fact is that nobody keeps > track of the individual trust relationships or who signed > a key; few people even bother to find out whether there's > a path of signers that leads from them to another person, > or whether the path has some reasonably small distance. PGP keys are used extensively in the Debian community; new developers are only accepted if their PGP key has been signed by another Debian developer, so that their always is a trust path from one developer to any other. Some important things, like the upload of new packages or submitting votes, will only be accepted by the automated services if everything is properly signed. There is a strong incentive in this community to have a signed PGP key; if you didn't have one you couldn't do anything. In other areas there just is no incentive for having such a thing... like email; it works even if you don't sign it. > I have not yet seen an example of "reputation" favoring > one person over another in a web of trust model; it looks > like people can't be bothered to keep track of the trust > relationships or reputations within the web. I think that's because the tools are lacking. GnuPG can determine trust paths, but you have to manually assign trust levels to certain keys and update the trustdb (which takes an awfully long time). If it would just work a bit faster and determine and show trust paths out of the box, I think PGP's web of trust model would be used a lot more. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Open Source (was Simple SSL/TLS - Some Questions)
On Thu, Oct 09, 2003 at 09:42:18AM -0400, Perry E. Metzger wrote: > > If you want a VPN that road warriors can use, you have to do it with > > IP-over-TCP. Nothing else survives NAT and agressive firewalling, not even > > Microsoft PPTP. > > Unfortunately, IP over TCP has very bad properties. TCP stacks figure > out what the maximum bandwidth they can send is by increasing the > transmission rate until they get drops, and then backing off. However, > the underlying TCP carrying the IP packets is a reliable, > retransmitting service, so there will never be any drops seen by the > overlayed TCP sessions. You end up with really ugly problems, in > short. > > Port-forwarded TCP sessions, a la ssh, work a lot better. If you run your VPN over TCP, and the VPN daemon therefore knows that every packet it sends to the other side of the connection will arrive anyway, you can do proxy-ACK, which essentially means you automatically do port-forwarding for all TCP sessions on the virtual network interface. Still, not only is TCP-over-TCP a problem, anything realtime over TCP (like VoIP, games, streaming video) suffers from it. SCTP (RFC 2960) looks like a solution, although I don't know of NATs that support it, and although some platforms already have some support for it in their kernels, I don't think it's possible to write a user space application using SCTP yet. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Simple SSL/TLS - Some Questions
On Fri, Oct 03, 2003 at 05:55:25PM +0100, Jill Ramonsky wrote: > It's worth summing up the design goals here, so nobody gets confused. > Trouble is, I haven't figured out what they should all be. The main > point of confusion/contention right now seem to be (1) should it be in C > or C++?, (2) should it support SSL or TLS or both? If the applications have to interact with legacy systems, then they'd need SSL... > Regarding the choice of language, I think I would want this library (or > toolkit, or whatever) to be somehow different from OpenSSL - otherwise > what's the point? I mean ... this may be a dumb question, but ... if > people want C, can they not use the existing OpenSSL? Or is it simply > that OpenSSL is too complicated to use, so a "simpler than OpenSSL" C > version is required. What I mean is, I don't want to duplicate effort. > That seems dumb. OpenSSL is very large, and although the API is pretty consistent and easy to work with, the SSL part of it looks complicated anyway. Another thing that is very annoying about OpenSSL is its license (and this has probably been an incentive to create GnuTLS). > My inclination is still to go with C++, and figure out > a way of turning it into C later if necessary ... but if majority > opinion says otherwise I'll reconsider. Well as long as your library has a decent C interface, I wouldn't mind if it was written in C, C++, Haskell or something even stranger. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Monoculture
On Thu, Oct 02, 2003 at 02:21:29PM +0100, Jill Ramonsky wrote: > Thanks everyone for the SSL encouragement. I'm going to have a quick > re-read of Eric's book over the weekend and then start thinking about > what sort of "easy to use" implementation I could do. I was thinking of > doing a C++ implentation with classes and templates and stuff. (By > contrast OpenSSL is a C implementation). Anyone got any thoughts on > that? Writing a C++ library almost certainly means your application has to be written in C++ as well. I think it is easier to create a C++ wrapper for a C library than a C wrapper for a C++ library (especially if you use all the OO features, although nothing prevents you from following the OO paradigm in C). Because of that, I think you reach more application builders with a C library. > Also - anyone thinking of using something like this - could you > post (in another thread maybe) suggestions as to what kind of "simple" > interface you actually want? As in, what you want it to do? As a programmer I'd like to see something that allows you to: a) specify credentials b) do TLS_start() c) have a TLS_read() and TLS_write() function which work EXACTLY the same as the read() and write() functions d) TLS_stop() Each of those steps can return a fatal error, but I'd rather not have to deal with warnings and other stuff that needs intervention of the application itself, and I also don't want to write callback functions if it's not really necessary. > Some advice on licensing wouldn't go amiss either. (GPL? ... LGPL? ... > something else?) I'd say LGPL or BSD, without any funny clauses. By the way, also have a look at GnuTLS and libgcrypt: - http://www.gnu.org/software/gnutls/ - http://www.g10code.com/p-libgcrypt.html -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Monoculture
On Wed, Oct 01, 2003 at 04:54:35PM -0400, Thor Lancelot Simon wrote: > > Uhm, before getting flamed again: by "our own", I don't mean we think we > > necessarily have to implement something different from all the existing > > protocols. We just want to understand it so well and want to be so > > comfortable with it that we can implement it ourselves. > > In that case, I don't see why you don't bend your efforts towards > producing an open-source implementation of TLS that doesn't suck. We don't want to program another TLS library, we want to create a VPN daemon. > If you insist on not using ESP to encapsulate the packets -- which in > my opinion is a silly restriction to put on yourself; the ESP encapsulation > is extremely simple, to the point that one of my former employers has a > fully functional implementation that works well at moderate data rates > on an 8088 running MS-DOS! If you read our response, you'd have seen that we plan to make packet encapsulation in tinc work just like ESP, but optionally allow (parts of) the IV and HMAC to be omitted. [...rehash of arguments against doing it yourself...] We are going to do it ourselves anyway, and maybe (or maybe not) it will end up as being a simple and clean implementation of one of the existing, widely peer-reviewed and accepted protocols you mentioned. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Monoculture
On Wed, Oct 01, 2003 at 02:24:00PM -0400, Ian Grigg wrote: > What is written in these posts (not just the present one) > does derive from that viewpoint and although one can > quibble about the details, it does look very much from > the outside that there is an informal "Cryptographers > Guild" in place [1]. I agree with that. First of all, even foolishly childish application builders like me know that cryptography is hard to get right (that's what we say up front in the README and manpage of tinc). And we also know there is a group of people specialised in security, who know much more than we can learn without spending a large amount of time. Furthermore, the reactions of those people to our products is not very encouraging most of the time. So yes, it looks like there is a kind of crypto cabal or guild. > I don't think the jury has reached an opinion on why > the cryptography group looks like a guild as yet, > and it may never do so. A guild, of course, is either > a group of well-meaning skilled people serving the > community, or a cartel for raising prices, depending > on who is doing the answering. I noticed both kinds of people exist :) > > I'd encourage the designer of the protocol who asked the original question > > to learn the field. Unfortunately, he's going about it a sub-optimally. > > Instead of hoping to design a just protocol and getting others to throw > > darts at it (or bless it), he might have better luck (and learn far > > more) by looking at the recent literature of protocol design and analysis > > and trying to emulate the analysis and design process of other protocols > > when designing his own. Then when he throws it over the wall to the rest > > of the world, the question would be not "is my protocol any good" but > > rather "are my arguments convincing and sufficient?" [...] > None of that is likely to happen. The barrier to entry > into serious cryptographic protocol design is too high > for the average builder of new applications [2]. He has, > after all, an application to build. And, in the case of building free software, the builder cannot afford to spend much resources (like time and money) to improve his knowledge of crypto. In our (tinc's) case, we do it just for fun. > What *is* going to happen is this: builders will continue > to ignore the guild. They will build their application, > and throw any old shonk crypto in there. Then, they will > deploy their application, in the marketplace, and they will > prove it, in the marketplace. Well we do try to put decent crypto in there... but sometimes we don't know when it's decent enough. > [2] We can argue the detail, but my point here is that the > barrier to entry is too high, so ignoring the guild is the > most likely result. That said, here are some points. Personally I'm not so scared by the barrier, but I did feel there was one. > It's nice that the literature is open and available. What > is not nice is how much there is of it. I guess that's unavoidable. > It's nice that we have an open community that discusses these things. > What is not nice is that, in trying to determine the one path, the > advice of the community reduces to useless baubles like "use SSL" or > "why did you do that?" It's great that the community has standards, > but those standards seem to be excessive in the extreme. That's also what I feel. But then again, I can imagine that for someone who has spent years in this field that "newcomers" or "amateurs" like us should listen to them and stop their silly attempts at crypto. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Monoculture
On Wed, Oct 01, 2003 at 02:34:23PM -0400, Ian Grigg wrote: > Don Davis wrote: > > > note that customers aren't usually dissatisfied with > > the crypto protocols per se; they just want the > > protocol's implementation to meet their needs exactly, > > without extra baggage of flexibility, configuration > > complexity, and bulk. [...] > Including extra functionality means that they have > to understand it, they have to agree with its choices, > they have to follow the rules in using it, and have > to pay the costs. If they can ditch the stuff they > don't want, that means they are generally much safer > in making simple statements about the security model > that they have left. You clearly formulated what we are doing! We want to keep our crypto as simple and to the point as necessary for tinc. We also want to understand it ourselves. Implementing our own authentication protocol helps us do all that. Uhm, before getting flamed again: by "our own", I don't mean we think we necessarily have to implement something different from all the existing protocols. We just want to understand it so well and want to be so comfortable with it that we can implement it ourselves. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Mon, Sep 29, 2003 at 02:07:04PM +0200, Guus Sliepen wrote: > Step 2: > Exchange METAKEY messages. The METAKEY message contains the public part > of a key used in a Diffie-Hellman key exchange. This message is > encrypted using RSA with OAEP padding, using the public key of the > intended recipient. After comments and reading up on suggested key exchange schemes, I think this step should be changed to send the Diffie-Hellman public key in plaintext, along with a nonce (large random number) to prevent replays and the effects of bad DH public keys. Instead of encrypting both with RSA, they should instead be signed using the private key of the sender (the DH public key and nonce wouldn't fit in a single RSA message anyway). IKEv2 (as described in draft-ietf-ipsec-ikev2-10.txt) does almost the same. However, IKEv2 does not send the signature directly, but first computes the shared key, and uses that to encrypt (using a symmetric cipher) the signature. I do not see why they do it that way; the signature has to be checked anyway, if it can be done before computing the shared key it saves CPU time. Encrypting it does not prevent a man in the middle from reading or altering it, since a MITM can first exchange his own DH public key with both sides (and hence he can know the shared keys). So actually, I don't see the point in encrypting message 3 and 4 as described at page 8 of that draft at all. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Mon, Sep 29, 2003 at 09:35:56AM -0700, Eric Rescorla wrote: > Was there any technical reason why the existing cryptographic > skeletons wouldn't have been just as good? Well all existing authentication schemes do what they are supposed do, that's not the problem. We just want one that is as simple as possible (so we can understand it better and implement it more easily), and which is efficient (both speed and bandwidth). > > And I just ripped TLS from the list. > > Define "ripped". This certainly is not the same as TLS. Used as a skeleton. Don't ask me to define that as well. > > Several people on this list have already demonstrated that they are very > > willing to analyse new protocols. > > Actually, no. People are willing to take a quick look and > then shoot bullets at your protocol. True. I've already heard Peter Gutmann's writeup being described as "drive-by shooting" :). > That's not the same a sdoing a thorough analysis, which can take > years, as Steve Bellovin has pointed out about Needham-Schroeder. True, but we can learn even from the bullet holes. > Look, there's nothing wrong with trying to invent new protocols, > especially as a learning experience. What I'm trying to figure > out is why you would put them in a piece of software rather > than using one that has undergone substantial analysis unless > your new protocol has some actual advantages. Does it? We're trying to find that out. If we figure out it doesn't, we'll use one of the standard protocols. We also do not know every existing protocol, maybe we'll find one we are happy with. I'm currently decoding RFC 2409 and trying to look if one of IKE's modes of operation does what we want. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
On Mon, Sep 29, 2003 at 09:51:20AM -0700, Bill Stewart wrote: > > =Step 1: > > Exchange ID messages. An ID message contains the name of the tinc > > daemon which sends it, the protocol version it uses, and various > > options (like which cipher and digest algorithm it wants to use). > > By "name of the tinc daemon", do you mean identification information? > That data should be encrypted, and therefore in step 2. > (Alternatively, if you just mean "tincd version 1.2.3.4", that's fine. No, identification information. But still, it's just a name, not a public key or certificate. It is only used by the receiver to choose which public key (or certificate etc) to use in Step 2. This information does not have to be encrypted, it has just as much meaning as the IP address the sender has. > > Step 2: > > Exchange METAKEY messages. The METAKEY message contains the public part > > of a key used in a Diffie-Hellman key exchange. This message is > > encrypted using RSA with OAEP padding, using the public key of the > > intended recipient. > > You can't encrypt the DH keyparts using RSA unless you first exchange > RSA public key information, which the server can't do without knowing > who the client is (the client presumably knows who the server is, > so you _could_ have the client send the key encrypted to annoy MITMs.) With tinc, public keys are never exchanged during authentication, they are known beforehand. And again, there is no distinction between a client and a server, it is peer to peer. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Mon, Sep 29, 2003 at 11:54:20AM -0700, Eric Rescorla wrote: > > Well all existing authentication schemes do what they are supposed do, > > that's not the problem. We just want one that is as simple as possible > > (so we can understand it better and implement it more easily), and which > > is efficient (both speed and bandwidth). > > In what way is your protocol either simpler or more efficient > than, say, JFK or the TLS skeleton? Compared with JFK: http://www.crypto.com/papers/jfk-ccs.pdf section 2.2 shows a lot of keys, IDs, derivatives of keys, random numbers and hashes of various combinations of the previous, 3 public key encryptions and 2 symmetric cipher encryptions and HMACs. I do not consider that simple. Compared with the entire TLS protocol it is much simpler, compared with just the handshake protocol it is about as simple and probably just as efficient, but as I said earlier, I want to get rid of the client/server distinction. > Again, it's important to distinguish between learning experiences > and deployed protocols. I agree that it's worthwhile to try > to do new protocols and let other people analyze them as > a learning experience. But that's different from putting > a not fully analyzed protocol into a deployed system. [...] > Well, I'd start by doing a back of the envelope performance > analysis. If that doesn't show that your approach is better, > then I'm not sure why you would wish to pursue it as a > deployed solution. I will not repeat our motiviations again. Please don't bother arguing about this. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Mon, Sep 29, 2003 at 05:57:46PM +0200, Guus Sliepen wrote: > > Now, the attacker chooses 0 as his DH public. This makes ZZ always > > equal to zero, no matter what the peer's DH key is. > > I think you mean it is equal to 1 (X^0 is always 1). Whoops, stupid me. Please ignore that. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Mon, Sep 29, 2003 at 07:53:29AM -0700, Eric Rescorla wrote: > I'm trying to figure out why you want to invent a new authentication > protocol rather than just going back to the literature and ripping > off one of the many skeletons that already exist ( Several reasons. Because it's fun, because we learn more from doing it ourselves (we learn from our mistakes too), because we want something that fits our needs. We could've just grabbed one from the shelf, but then we could also have grabbed IPsec or PPP-over-SSH from the shelf, instead of writing our own VPN daemon. However, we wanted something different. > STS, If you mean station-to-station protocol, then actually that is pretty much what we are doing now, except for encrypting instead of signing using RSA. > JFK, IKE, SKEME, SIGMA, etc.). And I just ripped TLS from the list. > That would save people from the trouble of having to analyze the > details of your new protoocl. Several people on this list have already demonstrated that they are very willing to analyse new protocols. Also, I don't *expect* you to do so, if you don't want to ignore me. > Why are you using RSA encryption to authenticate your DH rather > than using RSA signature? If we use RSA encryption, then both sides know their message can only be received by the intended recipient. If we use RSA signing, then we both sides know the message they receive can only come from the assumed sender. For the purpose of tinc's authentication protocol, I don't see the difference, but... > Now, the attacker chooses 0 as his DH public. This makes ZZ always > equal to zero, no matter what the peer's DH key is. I think you mean it is equal to 1 (X^0 is always 1). This is the first time I've heard of this, I've never thought of this myself. In that case I see the point of signing instead of encrypting. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote: > I hope Guus and Ivo circulate their version 2.0 > protocol before they do any coding, so that any remaining flaws can be easily > fixed in the paper design without changing a single line of code, saving time > and effort. I've been comparing tinc's current authentication protocol with the TLS handshake protocol as described in draft-ietf-tls-rfc2246-bis-05.txt. The basic structure is mostly the same: the ID messages in tinc are TLS's Hello messages, the METAKEY message in tinc is similar to TLS's RSA encrypted premaster secret message, the ChangeCipherSpec is implicit in tinc, and tinc's CHALLENGE/RESPONSE messages serve the same purpose as TLS's finished message (which contains verify_data). TLS makes a distinction between a client and a server. If possible I wish to avoid making that distinction. If possible, I would also like to continue to be able to use an RSA public/private keypair. This made me *sketch* the following _authentication_ protocol: == Step 1: Exchange ID messages. An ID message contains the name of the tinc daemon which sends it, the protocol version it uses, and various options (like which cipher and digest algorithm it wants to use). Step 2: Exchange METAKEY messages. The METAKEY message contains the public part of a key used in a Diffie-Hellman key exchange. This message is encrypted using RSA with OAEP padding, using the public key of the intended recipient. After this step, both sides use Diffie-Hellman to compute the shared secret key. From this master key, keys and IVs for symmetric ciphers and digest algorithms will be derived, as well as verification data. From this point on all messages will be encrypted. Step 3: Exchange VERIFY messages. The VERIFY message contains verification data extracted from the master key, so each recipient can verify that the key exchange went well. Step 4: Exchange ACK messages. This will signal each side that the other side acknowledges the authentication. The ACK message will contain some more data which has nothing to do with authentication. == I currently think this has none of the problems the current protocol has, and also makes sure we have perfect forward security (if keys are renewed using Diffie-Hellman periodically). Some questions: - Some people keep saying that "you shouldn't send the same kinds of messages". TLS sends different kinds of messages depending on its role (client or server). Is there a reason behind this? - Would it be nice to move all the cryptographic parameters exchanged in step 1 into the encrypted message in step 2? That way an attacker cannot see which encryption and digest algorithms will be used, which might make an attack less feasible. - Did I miss something? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Tinc's response to "Linux's answer to MS-PPTP"
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote: > Perhaps a HMAC per "chunk", rather than per the payload of a single UDP > datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of > payload may work. This will increase latency. That would not work either. It would have the same problems as a packet that has been split into 5 fragments: if one of the fragments gets lost, the whole packet will be discarded. Fragment reassembly is also something that is not completely trivial, in the past there have been some simple DoS attacks for various operating systems that did not implement IP fragment reassembly correctly. Each UDP packet must stand on its own, just like the network packet that has been encapsulated within it. > This should be redone from scratch, I would look at either using > Diffie Hellman Key Exchange combined with digital signatures or the updated > Needham Schroeder Public Key Protocol. Exchange two symmetric keys, > one used for bulk data encryption, the other used for the HMAC > authentication. I think I prefer the Diffie-Hellman key exchange; the Needham Schroeder public key protocol needs more round trips and one more RSA encryption/decryption step. > I expect this is a reference to "Why TCP Over TCP Is A Bad Idea" > <http://sites.inka.de/~bigred/devel/tcp-tcp.html> Yes. > If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their > high tolerance for unncessary weakness, I think tinc 2.0 could end up being > a secure piece of software. I hope Guus and Ivo circulate their version 2.0 > protocol before they do any coding, so that any remaining flaws can be easily > fixed in the paper design without changing a single line of code, saving time > and effort. Those are the first encouraging words I've heard since Peter Gutmann's writeup was posted on Slashdot, thank you! We do plan to get rid of all the weaknesses, and once we know what we want and we have a draft, I'll post it in this mailing list. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Tinc's response to "Linux's answer to MS-PPTP"
t 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? About half a year I guess. But, we didn't design the current protocol as a replacement of SSL. In fact we replaced something that was worse than the current protocol. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Tinc's response to "Linux's answer to MS-PPTP"
Hello Peter Gutmann and others, Because of its appearance on this mailing list and the Slashdot posting about "Linux's answer to MS-PPTP", and in the tinc users' interest, we have created a section about the current security issues in tinc, which currently contains a response to Peter Gutmann's writeup: http://tinc.nl.linux.org/security I want to emphasize for the cryptography community here that certain tradeoffs have been made between security and efficiency in tinc. So please read the response as "why we think we need to do/used to do it this way" instead of "why we think tinc is still as secure as anything else". Comments are welcome. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
