Re: Where to find bare-bone DSA-like authenticated signatures gneration/verification code?
Ian Grigg [EMAIL PROTECTED] writes: rhkelly wrote: Nelson Bolyard wrote: Getting crypto protocols right is very difficult. Lots of obvious and simple approaches are vulnerable to attacks. That is why NSS encourages the use of vetted crypto protocols and does not encourage roll-your-own crypto protocols. However, the fact remains that many applications (of which the one mentioned by the original poster might or might not be one) do require only one or two algorithms, to be included in the application build-base in source form. No such resource is readily available on the net - most crypto libraries (NSS included) are just a horrible mess from the software engineering point of view. Whether or not poor software engineering can still produce good security ought to be seriously examined. Peter Gutmann writes about this here: http://www.cs.auckland.ac.nz/~pgut001/#design (3rd bullet point, skip down, there are a bunch of links). Actually I think the 5th bullet point, covering Lessons Learned in Implementing and Deploying Crypto Software, might be more appropriate for this. I had thought that NSS was designed to support the activities of the applications in Mozilla. If that's the case, it won't be surprising that it isn't easy to use it as a general purpose crypto library. The differences are many... If it's a nice layered implementation where the higher layers build on the lower ones (e.g. SSL and S/MIME on PKCS #1 and 3DES-CBC, etc) you can support both. A problem with this (covered in Lessons Learned) is that way too many people think they can roll their own using the low-level interface (It's just 3DES encryption, how hard can it be?). In the cryptlib docs I warn users that if they don't know what an IV is they shouldn't be using the low-level interface, but it only works some of the time (the inevitable followup to the IV warning will be user email asking Why are the first 8 bytes of decrypted data corrupt?). Having said that, something like libtomcrypt will provide a fairly low-level interface for people who need that, and the library itself is very compact. Peter. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Looking for a solution for concurrent write access in NSS
Gervase Markham wrote: Keith Bostic wrote: Sleepycat Software is (of course!) happy to have Mozilla use Berkeley DB in any way at all. Our only concern would be in granting blanket rights to companies developing proprietary products as part of granting rights to the Mozilla group. Wouldn't it be possible to put together a license that spelled that out? Probably not, I'm afraid :-( Licenses used for Mozilla code have to be Free (http://www.gnu.org/philosophy/free-sw.html) and open source (http://www.opensource.org/docs/definition.php) - although the two definitions are basically identical. Any license which restricts commercial use, even if it's for people other than mozilla.org, doesn't meet those definitions. Well the current Sleepycat license is OSI Certified open source. It's restriction is that if you develop any software based on the solution, you have to distribute the source. So the point of Sleepycat is not to require a licence incompatible with open source. It seems to me Sleepycat could accept something like : - if you use the API of gdb directly, you must redistribute your source. - if you only use the API of NSS, you don't have to. Maybe they would wish to add somthong in the line of : If you use the NSS API to implement an application able to store and retrieve generic data, you must redistribute your source, just in case someone tries very hard to reimplement around NSS something that turns in back into a generic (key/data blob) storage application to get around the licence. Such a licence would put a restriction based on the way you use the software, not who you are, or how you sell it, so I think it's compatible. I don't see a difference in princip of such a restriction with the kind of restriction there is in LGPL (if you include in your project, you have to be GPL/LGPL, if you only link, you don't have to). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Missing function dbopen in nss3.dll
Hi, I have built nss3.dll for use by my ldap client using the build instructions at http://www.mozilla.org/directory/csdk.html. cvs co -r NSPR_4_2_2_RELEASE mozilla/nsprpub cvs co -r NSS_3_7_7_RTM mozilla/security/coreconf mozilla/security/nss cvs co -r DBM_1_61_RTM mozilla/dbm mozilla/security/dbm followed by cd mozilla/security/nss gmake nss_build_all The nss3.dll is compiled and built correctly. I have IPlanet 5.1 directory server installed on my Windows box. This runs happily if I put the nss3.dll that was bundled with SunOne 5.08 LDAP SDK in WINNT\System32. However if I replace the existing nss3.dll in WINNT\System32 from SunOne 5.08 LDAP SDK with the nss3.dll that I built, I get an error stating that function dbopen could not be located when I try to start my IPlanet 5.1 directory server. I have verified using dependency walker that the new dll built by me is indeed missing dbopen while the old nss3.dll from SunOne 5.08 contained it. Am I missing something while building NSS? Was dbopen function dropped/added in between versions? Any help is appreciated. Regards, Pradnyesh ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Looking for a solution for concurrent write access in NSS
Gervase Markham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Probably not, I'm afraid :-( Licenses used for Mozilla code have to be Free (http://www.gnu.org/philosophy/free-sw.html) and open source (http://www.opensource.org/docs/definition.php) - although the two definitions are basically identical. The Berkeley DB license is OSI Certified: http://www.opensource.org/licenses/sleepycat.php Regards, --keith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Keith Bostic[EMAIL PROTECTED] Sleepycat Software Inc. keithbosticim (ymsgid) 118 Tower Rd. +1-781-259-3139 Lincoln, MA 01773 http://www.sleepycat.com ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Where to find bare-bone DSA-like authenticated signatures gneration/verification code?
Admitting that in some of the preceding I've used an occasional unnecessarily direct phrase, I'd just like to offer a final, short summary of my proposition: Computer security landscape is unsatisfactory. There are many possible directions in which we could move to improve it: of these most acknowledged experts favour automating things to an even higher degree, at both crypto tool and application software fronts. I believe however that - for reasons of software engineering practicalities - such efforts have reached the point of diminishing returns, and that we should instead put more effort into making both the crypto library and application software users better equipped to use simpler tools with greater proficiency. Roger K. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Looking for a solution for concurrent write access in NSS
Keith Bostic wrote: Gervase Markham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Probably not, I'm afraid :-( Licenses used for Mozilla code have to be Free (http://www.gnu.org/philosophy/free-sw.html) and open source (http://www.opensource.org/docs/definition.php) - although the two definitions are basically identical. The Berkeley DB license is OSI Certified: http://www.opensource.org/licenses/sleepycat.php But the way Gervase interpreted you requirement, you would agree to include in NSS/Mozilla only with a restriction based on WHO uses the software or on WHAT they use it for which breaks either rule 5 or rule 6 of http://www.opensource.org/docs/definition.php. I suffested an alternative, but I am afraid it breaks rule 8. It depends on what is called a distribution and what is extract from that distribution, does it mean the right to separate a software from a group of software, or does it mean the right to isolate any part of the source, and use it with the same rights as the whole. I'm afraid this globally doesn't leave any way to make it work :-( A distribution of NSS that includes GDB and doesn't break any of this rules would have to be restricted to be used under GPL, and no more MPL. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Trust certificates in HW-Tokens
Hi Nelson, Andreas is ok - i use my gmx-account for spam trapping. I did not have my personal cert in the software token, but it was infact deleted (wich may not erase all the data in the software token ???). I will try to create a new db and test again. In the mean time I tried to reproduce with NSS-3.9 (used this to access my thunderbird-profile) to have useful information for opening a bug. There are some confusing messages but certutil 3.9 says, the cert is valid: \nss-3.9\bincertutil -d \Thunderbird\Profiles\default\sf21vcat.slt -V -n OpenSC Card:/C=DE/CN=Andreas Marx/emailAddress= -u S unable to enumerate apps: Transmit failed pkcs15.c:595:: returning with: Transmit failed Failed to load profile: File not found Enter Password or Pin for OpenSC Card: certutil: certificate is valid Is there a way to find out, wich nss-version was used in the build? In fact I will have to make my own build if I do not want to wait for a contributed build with nss-3.9 -- Andreas Nelson Bolyard wrote: Andreas Marx, a.k.a. caronte (?) wrote: I dont think its the extensions, as the certificate work well, if not stored in hw-token. Here is my CA: One more question. At one time, NSS had some problems that occurred when the same cert appeared in multiple tokens. I wonder if that was affecting you. I wonder if you originally had your personal cert and private key in the software token, then you exported that key/cert to a PKCS12 file, and transferred it to the HW token, but it was still also in the software token. Does that sound like a possible explanation? I'd be interested in knowing if you can reproduce this problem with a new cert DB that has only your root CA cert in it, and an empty key DB. /Nelson ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Missing function dbopen in nss3.dll
Pradnyesh Rane wrote: Am I missing something while building NSS? Was dbopen function dropped/added in between versions? In NSS 3.4 and later, the database code was separated in a PKCS#11 library called libsoftokn3.so . Also, I don't believe the dbopen symbol is exported from it . I'm not sure why the LDAP SDK would be depending on that symbol. It sounds like you will need a new LDAP SDK that's compatible with current versions of NSS. If that LDAP SDK is itself a shared library, you might be able to get that working. Otherwise you will have to wait for newer versions of iPlanet servers that work with current NSS (sometime late this year). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Download Books
eBooks at low Prices!! I sell quality eBooks at very low prices. and you can download them to your computer. With these eBooks you will learn how to be your own boss, how to make money on eBay and over 50 more great eBooks to choose from. Guaranteed. Download your E-Book NOW visit us at http://www.Thebookwiz.com/65883 With over 50 titles including: 1) 5 Steps to Personal Power 2) Making Money On Ebay 3) Top Sales Person 4) 1000+ Killer Internet Tips 5) and many more You won't find a better eBook site! No waiting, simply order and download your ebook now! visit us @ http://www.thebookwiz.com/65883 Thank You ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Where to find bare-bone DSA-like authenticated signatures gneration/verification code?
rhkelly wrote: Admitting that in some of the preceding I've used an occasional unnecessarily direct phrase, I'd just like to offer a final, short summary of my proposition: Computer security landscape is unsatisfactory. You got that right. Question is, why? And, seeing as us Internet security people have been doing this for a decade, do we have a good reason to do what we've been doing all that time, or, maybe thinking about changing the way we do things? There are many possible directions in which we could move to improve it: of these most acknowledged experts favour automating things to an even higher degree, at both crypto tool and application software fronts. I disagree with that path, partly because it hasn't worked in the past, and partly because there's no fun being the same as everyone else :) I believe however that - for reasons of software engineering practicalities - such efforts have reached the point of diminishing returns, and that we should instead put more effort into making both the crypto library and application software users better equipped to use simpler tools with greater proficiency. I think there is something we also have to recognise in applications building: developers don't have any time to use, learn, select, or verify good security. That applies as much to good products as it does to the schlock. It applies to the code their write, as much as the protocols they hack together. It seems to be that every new product there is faced with four choices: 1. do no security; 2. do a quick and nasty home built hack of a protocol; 3. create a good, aligned, secure, precise and appropriate crypto protocol; 4. use a standard tool that is already built, reviewed, tested and safe. Everyone suggests 4., but, that's too hard, because one still has to select the right one, or to pick the wrong one and then slave through the horribly hard API and all the special hooks and the must-do-else-your-cat-fries security parts... So, 4. is out. Sorry, SSL guys, it's just too hard. Then, 3. is easily dispensed with, as those wunderkinder just don't exist. Which leaves 1 or 2: Nothing or somthing really quick and dirty, and probably only somewhat secure. This is the SSH story. SSH 1 was widely thought to be pretty loose. What happened? It succeeded, partly because the author didn't worry overly about having perfect crypto - he rocked on ahead with something that was ok. Later on, when the product was a wild success, and the model was proven, there was a chance (somewhat costly) to repair that protocol, essentially by taking the good stuff from another protocol and grafting it in. In sum, I think the future in crypto, when it ever gets past 1. above, is at 2: we should consider ourselves lucky if a successful product has stuck some schlock in there, and there's an opportunity to come in later and clean it up. In that sense - Tom's crypto lib (PG mentioned the name) is the best thing that's happened in crypto libraries in a long time. Quick and dirty, fast and furious - lets the application developer slap in something now, and clean it up later. iang ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
