Re: New toy: SSLbar
Steven M. Bellovin wrote: From a security point of view, why should anyone download any plug-in from an unknown party? In this very specific case, why should someone download a a plug-in that by its own description is playing around in the crypto arena. I think this is a problem for all open source projects. Suppose I wrote a trojan open source product. Although the code is open for review, how many people actually do review it? I could list the product on Freshmeat, and if it looked like an exciting piece of technology, quite a few people might download it. Probably quite soon someone will find the back door, the story would probably be reported on sites like Slashdot, and the game would be up. However, I could have done a lot of harm in the meantime. The other approach would be to contribute trojan code to another open source product. I don't personally think that there is any of SCO's IP in the Linux kernel, but SCO's story isn't completely implausible. A rogue contributor could submit code that was SCO's copyright -- or contained a back door. In the case of the Linux kernel, I doubt a back door would work because there seems to be quite a lot of peer review. However, for other projects it might work okay. These attacks apply in the corporate world as well, but to a lesser extent. Usually you have a better idea who someone is when you pay them money; this is a deterrent because it is a crime to ship trojan software wilfully. It also takes effort to infiltrate someone into a company's programming team; contributing code from an anonymous Internet account is much easier. On the other hand, once a back door is installed in binary-only software, it is much less likely to be found. The Interbase back door was only found when the source was opened. I think there are two defences against these attacks. The first is based on developers' reputations. If you don't have a strong reputation, people are much less likely to report on your new open source product, and much less likely to download it. This means that an attack might succeed against a few people, but it would be unlikely to compromise thousands of machines. (A moderated Freshmeat would be nice here -- you could have a site where a condition of listing your project was that you reviewed a certain number of others.) The second defence is the amount of work that it takes to produce a project that someone would be interested in. If I produced a clone of Word, and put a back door in it, no doubt lots of people would download it. However, the work is not justified by the reward; there are simpler ways of compromising machines. -- Pete - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
Steven M. Bellovin wrote: Please don't take this personally... None taken here, and I doubt that the author of the tool (who has just joined this list it seems) would take any! From a security point of view, why should anyone download any plug-in from an unknown party? In this very specific case, why should someone download a a plug-in that by its own description is playing around in the crypto arena. How do we know it's not going to steal keys? Is the Mozilla API strong enough that it can't possibly do that? Is it implemented well enough that we trust it? (I see that in this case, the guts of the plug-in are in Javascript. Given how often Javascript has played a starring role in assorted security flaws, that doesn't reassure me. But I do appreciate open source.) It's an issue. I think the answer requires the same analysis as always: someone would download this plug-in if the result were likely more security in the overall browsing experience. So, the question then arises, could this plug-in give more security than the exposure to an untrustworthy party warrants? On the one hand, the plug-in isn't likely to be terribly effective, as is fairly obvious, as has been pointed out. OTOH, one might be downloading a trojan. Well, that's possible. Is it likely? I don't think so, and here's why: If this were an attack, it would be unlikely to be effective. There is a known site (albeit with a masked identity) with a webpage, etc. So there are tracks, and angry emails to the owner of the site will incur a cost for the attacker. Few people use keys, making this an obscure approach. I suppose if the target really *was* keys, then the challenge would be to target those key users ... against which, the users of keys are likely to be more security conscious than other victims. If the person was indeed a crook, why would he use open source? And, even though Javascript may have a poor security record, that's to do with bugs in its model and code efforts and potential security breachs, not with crooks acutally inserting code to steal value. I.e., theoretical breaches of security, not actual breaches of security. Also, to impune the plug-in arrangement is to impune all plug-ins, and to impune the download from an unknown is to impune all downloads from unknowns. What is the risk of downloads being trojaned, and the risk of plug-ins being aggressive? These are unknowable risks, a priori, so we have to resort to statistics and cost-benefit to work out the probability. And here, statistics is on our side. In practice, an attack is rarely initiated via a download, or via a plug-in. I.e., download this fantastic tool which just so annoyingly includes a trojan from the person who manages the site doesn't seem to occur as a real attack with any frequency. (Partly because it takes a long time to find the right victim, and partly because it leaves the attacker static and vulnerable, I'm guessing. In comparison, it seems that attackers get much better results by using targetted mass mailings tools to deliver their EMD.) So on balance, I won't download the tool, because its effectiveness is low. But so is its risk. Other people might come to other conclusions, but I personally don't buy the argument that just because I don't know the site, it shouldn't be touched. Life is full of risks. Only by taking risks do we understand what works and what doesn't. Real-life security is like that, as in practice, we know that not all can be covered in security, as it is simply too expensive to be 100% safe. So we have to take some risks in some areas. EMD - emails of mass destruction? -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
In message [EMAIL PROTECTED], Ian Grigg writes: Also, to impune the plug-in arrangement is to impune all plug-ins, and to impune the download from an unknown is to impune all downloads from unknowns. Sounds about right... ... I.e., download this fantastic tool which just so annoyingly includes a trojan from the person who manages the site doesn't seem to occur as a real attack with any frequency. In fact, the come and get it method seems to exceed the scan and 'sploit method of building botnets. That is, Trojans are a very active method of infection. (Partly because it takes a long time to find the right victim, and partly because it leaves the attacker static and vulnerable, I'm guessing. In comparison, it seems that attackers get much better results by using targetted mass mailings tools to deliver their EMD.) Botnets communicate via IRC, among many other ways. Sometimes, they even use encrypted channels --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
On Wed, Jun 25, 2003 at 12:02:39PM +0100, Pete Chown wrote: On the other hand, once a back door is installed in binary-only software, it is much less likely to be found. The Interbase back door was only found when the source was opened. I doubt the truth of this statement. Certainly, the back door was only published after the source was opened. But, just as Matt Blaze found out when he published his attack on pin-and-tumbler locks, fields other than computer security do not have a culture of public disclosure. In all likelihood the Interbase back door was discovered and carefully promulgated among the gray- and black-hat communities interested in that product. Closed-source is not much of a guarantee in the face of a determined attacker. Or in the face of a large number of capable, interconnected, curious hackers (in the traditional sense of the word). -andy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Draft Edition of LibTomMath book
The Draft Edition of the LibTomMath book [book about how to implement bignum math] is freely available on my site at http://book.libtomcrypt.org Keep in mind it is a draft and has not been edited yet. However, if you ever wanted to learn how to implement efficient [portable too] bignum math routines you might want to give it a read. Enjoy, Tom __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
re: Draft Edition of LibTomMath book
Just a quick comment. The PDF is not a web friendly PDF so you if you are trying to view it inline with your browser you have to wait for it to download completely first. I've managed 80KB/sec off the site so it doesn't take too long to grab it.Alternatively you can grab the .PDF.BZ2 file and decompress it locally. I'm only making this comment because I've noted quite a few incomplete downloads... Thanks, Tom http://book.libtomcrypt.org __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DH: pubkeys for p and g
The Check Point Firewall-1 Docs insist, that the public keys be used for p and g for the Oakley key exchange. I ask you: is this possible? - which of the two pubkeys will be p, which g? - are they both always primes? - are they both always suitable generators mod p? It just seems to me that Check Point isn't entirely sure themselves here. I'd appreciate a short cleanup... To my knowledge, g and p are globally defined, either in DH Groups (which are nothing but pre-defined g's and p's, right?), or otherwise set constant. Am I wrong about this? Thanks. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid PGP subkeys? use subkeys.pgp.net as keyserver! one should never do anything that one cannot talk about after dinner. -- oscar wilde pgp0.pgp Description: PGP signature
Re: Draft Edition of LibTomMath book
On Wed, 25 Jun 2003, tom st denis wrote: The Draft Edition of the LibTomMath book [book about how to implement bignum math] is freely available on my site at http://book.libtomcrypt.org Keep in mind it is a draft and has not been edited yet. However, if you ever wanted to learn how to implement efficient [portable too] bignum math routines you might want to give it a read. Enjoy, Tom One thing that I've noticed for a long time is that there are *VERY* few math libraries that don't leave whatever numbers they're working with in memory when deallocating (deallocating heap via free() or deallocating stack via returning from a procedure call or deallocating swapspace by getting paged back in off a disk). And numbers that an application leaves lying around in whatever working memory or media it's using, can be discovered and exploited by other programs - frequently by unauthorized ones. Windowing systems have the same kind of leakage, but you can avoid using windowing systems with a crypto program; there's no need to put sensitive information like keys or passwords on the screen ever. Admittedly, I'd like to have a secure windowing system, but it seems unlikely. But I think Math is indispensable to crypto, and there ought to be a secure mathematics library. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Draft Edition of LibTomMath book
--- bear [EMAIL PROTECTED] wrote: One thing that I've noticed for a long time is that there are *VERY* few math libraries that don't leave whatever numbers they're working with in memory when deallocating (deallocating heap via free() or deallocating stack via returning from a procedure call or deallocating swapspace by getting paged back in off a disk). And numbers that an application leaves lying around in whatever working memory or media it's using, can be discovered and exploited by other programs - frequently by unauthorized ones. Very true. LibTomMath will actually wipe the memory allocated [via memset] before free'ing but I leave it up to the end user to lock their heap from swapping. Tom __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
