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
Re: Reliance on Microsoft called risk to U.S. security
also sprach Ian Grigg [EMAIL PROTECTED] [2003.09.25.2253 +0200]: I wouldn't put all of the blame on Microsoft, Schneier said, the problem is the monoculture. On the face of it, this is being too kind and not striking at the core of Microsoft's insecure OS. For example, viruses are almost totally a Microsoft game, simply because most other systems aren't that vulnerable. Yes and no. First, I think that viruses will surface were e.g. Linux to take top position, albeit they may have to employ totally new paradigms to subvert the more advanced security architecture of UNIX. But I believe Schneier is right for the following reason: Microsoft is a monopolist who, despite enjoying bad press for the past four years, is managing to keep its sales going up each quarter. If you are in business, what do you care for? The steep sales curve, or the quality of your product? As long as Microsoft has the monopoly on the desktop, as long as new computers come with Windows per default, and as long as people stop complaining and actually take action against the crap that Redmond ships by switching to other systems in bulk, Microsoft has no reason to invest any money in a code rework. So, in the market for server platform OSs, is there any view as to which are more secure, and whether that insecurity can be traced to the OS? The defacement archive[1] has some statistics. But don't let yourself be fooled as one should not forget that while Windows usually comes with one web-, one mail-, one DNS server, there are like 27 and up in each category for UNIX. So theoretically, when comparing those categories, you need to include a factor of 27. 1. http://defaced.alldas.org/ -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! women love us for our defects. if we have enough of them, they will forgive us everything, even our gigantic intellects. -- oscar wilde pgp0.pgp Description: PGP signature
Re: Can Eve repeat?
That's pretty much what I was talking about when I said that it may be possible to clone an arbitrarily large proportion of photons - and that Quantum Cryptography may not actually be secure. A key point is the probability that the measurement/cloning operation has of disturbing the original state. Errors at the receiver are assumed to be the result of eavesdropping. The current canoncial paper on how to calculate the number of bits that must be hashed away due to detected eavesdropping and the inferred amount of undetected eavesdropping is Defense frontier analysis of quantum cryptographic systems by Slutsky et al: http://topaz.ucsd.edu/papers/defense.pdf (I don't want to take a position on whether cloning is or isn't possible - that's way out of my area of expertise!) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Thu, 25 Sep 2003, Ian Grigg wrote: On the face of it, this is being too kind and not striking at the core of Microsoft's insecure OS. For example, viruses are almost totally a Microsoft game, simply because most other systems aren't that vulnerable. While part of the security problems in Windows are Microsoft specific, in my view a large part is inherited from earlier graphiscal desktop designs, and is almost universal in this space. Specifically, when a user clicks (or double-clicks) on an icon there is not a clear distinction between Run and View. Instead we have the polymorphic Open. If files always opened in a safe viewer, (e.g. clicking on a .pl file fired up an editor, not the ActiveState Perl interpreter) a good part of the security problem with Graphical desktops, Microsoft's, Apple's, RedHat's, ... would be solved. The bizarre advice we give users to not open message attachments would be largely unnecessary (one also needs to close the the macro invocation problem, but this is not insurmountable). It is my contention that so long as activating an icon does not distinguish between Run and View all Graphical Shells will be insecure. -- Victor Duchovni IT Security, Morgan Stanley - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The Right Touch
http://www.forbes.com/forbes/2003/1013/050_print.html Forbes OutFront The Right Touch Elizabeth Corcoran, 10.13.03 We're spending billions for new voting machines that may not be any better than punch cards Three weeks before California was set to vote on Governor Gray Davis' recall, a federal appeals court postponed the election because of worries about flawed punch-card voting systems. The technology that could replace it may not be any better. Touch-screen voting systems, which look like automated teller machines, are easy to use, but they make recounts next to impossible--because, unlike ATMs, they produce no independent paper trail. That worries experts who insist they can be hacked, just like any computer. It's very, very hard to make these machines secure, says David Dill, a computer science professor at Stanford who has studied computer voting. The companies that make the new voting systems are steaming at these accusations. They're suggesting something magically happens between what you see on the screen and what's stored in the machine,says Thomas Swidarski, president of Diebold Election Systems. Voting technology became big business following Florida's swinging-chad fiasco in 2000. Last year Congress voted to dish out $3.8 billion to the states to upgrade voting booths and train poll workers. The dollars are going to a handful of firms, including Diebold, Sequoia Voting Systems and Election Systems Software. Diebold, the $2 billion (revenues) maker of safes and automated teller machines, has placed 47,000 voting machines, which cost as much as $3,500 apiece, in Georgia, Maryland, California, Virginia, Texas and Indiana. Ohio is reviewing a half-dozen bids to equip 11,614 precincts. One-third of California voters are supposed to be using touch screens to vote in March (most of the rest will be optically scanned). A state commission is still reviewing whether to recommend adding receipts to the machines. Touch-screen voting machines don't have keyboards, Internet connections or even ports that hackers could exploit. Votes are stored in duplicate, in a removable card locked inside the voting machine and in built-in semiconductor memory. The only way in is through the smart cards handed out at the polls. The system is supposed to be idiot-proof--voters cannot pick too many candidates. But what about security? In late July Johns Hopkins computer scientist Avi D. Rubin released a paper criticizing computer code discovered on the Internet that was an excerpt of the programming in Diebold's touch-screen machines. Rubin argued the cryptographic protection was so poor that a hacker could easily make illegal smart cards and register multiple votes. The paper prompted Maryland to delay awarding a $56 million contract for 11,000 machines to Diebold. Diebold countered that the code was out of date and out of context. Election workers, for instance, help combat fraud by taking precautions such as matching the number of card users to the votes registered. Diebold also issued a press release outing Rubin as an adviser to an Internet election technology company, VoteHere. He has since quit. But Diebold earned itself a black eye when its chairman, Walden O'Dell, sent a fundraising letter in August to Ohio Republicans, pledging that he is committed to helping Ohio deliver its electoral votes to the president next year. Accidents happen. Officials in Florida's Miami-Dade County are weighing the cost and benefits of retrofitting 7,200 voting machines with printers after voters there had trouble with touch-screen systems built by ESSfor the 2002 elections. Some voters reported that the machines registered a vote for a different candidate than the one they picked. Undetectable problems worry computer scientists even more. Software could shape the outcome of a surprise election--and we'll never know, says Dill. Sidebars Stacking The Deck - -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
efficiency?? vs security with symmetric crypto? (Re: Tinc's response to Linux's answer to MS-PPTP)
What conceivable trade-offs could you have to make to get acceptable performance out of symmetric crypto encrypted+authenticated tunnel? All ciphers you should be using are like 50MB/sec on a 1Ghz machine!! If you look at eg cebolla (more anonymity than VPN, but it's a nested forward-secret VPN related thing) it's even possible to do pretty immediate forward secrecy every second or something at minimal CPU cost. (I'll read the writeup but that trade-off argument sounds very wrong.) Adam On Fri, Sep 26, 2003 at 12:12:03PM +0200, Guus Sliepen wrote: 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] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
At 6:47 AM -0700 9/26/03, [EMAIL PROTECTED] wrote: While part of the security problems in Windows are Microsoft specific, in my view a large part is inherited from earlier graphiscal desktop designs, and is almost universal in this space. Specifically, when a user clicks (or double-clicks) on an icon there is not a clear distinction between Run and View. Instead we have the polymorphic Open. If files always opened in a safe viewer, (e.g. clicking on a .pl file fired up an editor, not the ActiveState Perl interpreter) a good part of the security problem with Graphical desktops, Microsoft's, Apple's, RedHat's, ... would be solved. The bizarre advice we give users to not open message attachments would be largely unnecessary (one also needs to close the the macro invocation problem, but this is not insurmountable). It is my contention that so long as activating an icon does not distinguish between Run and View all Graphical Shells will be insecure. The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. See: http://www.combex.com/tech/edesk.html http://www.combex.com/papers/darpa-review/index.html http://www.combex.com/papers/darpa-report/index.html Cheers - Bill - Bill Frantz| There's nothing so clear as | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
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.8 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
Re: A different Business Model for PKI (was two other subjects related to the demise of Baltimore)
Ed Reed [EMAIL PROTECTED] writes: 2) PKI vendors looked at that and must have said - gee, if we can get $100-$150/yr/user for managing identity around PKI certificates, why shouldn't we? Actually it's even better than that, the companies using the managed service are still expected to act as the RA (registration authority) for certs, so they do all the hard work (verifying users, etc etc). Verisign just give them access to a cert-management engine and collect the fees (OK, there's a bit more work to it than that, but still, the Verisign beancounters must be like pigs in clover over it). 3) the standards groups, PKIX in particular, still haven't addressed the cert life cycle management issues, and neither has the market place, in any coherent, interoperable fashion That's my perpetual gripe with PKIX, they're frantically busy distracting themselves with interesting (to them) but ultimately pointless and irrelevant additional standardisation of features so obscure that you need 15 pages of diagrams just to explain to users why they might be useful, while ignoring the fact that most people can't use even the most rudimentary parts of what's already there. This is presumably why the IETF finally shut them down, they realised they'd just keep endlessly churning out RFCs until the sun goes out (I'm not sure whether just leaving them alone to do that in perpetuity wouldn't have been the better option). After some research, it appears to me that there's a tidy little business possible for someone to break the mold. Can't be done. SPKI tried it, designing an eminently workable PKI (for the task they were trying to solve) and no-one was interested because it wasn't X.509. Certainly if you throw out all the X.500 baggage that we know doesn't work (X.500 DNs, directories, CRLs, etc etc, which is what SPKI did) you can build a very workable, usable, scalable PKI, but OSI digital ancestor-worship requirements say that you're not allowed to do that. Anyone care to make a go of it? Please, go ahead. I'll stand over here and watch. It's a vicious circle, X.509 doesn't work/doesn't do what people want, but anything that does work isn't X.509 and therefore won't be accepted by the market. SPKI was a heroic effort to break out of the cycle, but despite a lot of work and input from some very clever people, it ultimately failed for that reason. And unlike the OSI experience in the 1980s (which X.509 is a direct repeat of), for PKI there isn't any DARPA-spawned white knight to come in and fix things when it fails. To some extent this is computer darwinism in action. With networking protocols, some alternative to OSI (that is, a relatively functional set of networking protocols) had to evolve at some point, because computers had to communicate somehow. There was intense market pressure to get something that worked, and eventually it was the IP protocol suite. With PKI on the other hand no such pressure exists, since it's pretty much irrelevant for most people. Sure, your marketing folks can come up with all sorts of neat hypothetical scenarios where PKI would make things so much better, but in reality people and companies can do their banking, tax filing, buying and selling, share trading, and every other use that might justify a PKI, perfectly well without it. As a result there's no pressure on the people involved in PKI standardisation to create anything that meets any real-world requirement, allowing them instead to spend their time building great gothic cathedrals of infinite complexity whose sole purpose seems to be to strike awe and terror into the masses. What's left to vendors is a few niche markets, generally the same groups who are still trying to make a go of using X.400 (government departments/the military, a few large corporates, a few banks) who will keep struggling with X.509 for a number of years. That's a pretty small market to peddle your wares into, as companies like Baltimore, Entrust, and a number of other PKI vendors have found out. Peter (who probably now officially qualifies as a PKI curmudgeon). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]