Re: Where to find bare-bone DSA-like authenticated signatures gneration/verification code?
Ian Grigg wrote: 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. I have left a lot of your posts unanswered as I could have gone on for ages, but I couldn't let this one slip. What is your criteria for comparing the respective success of SSH and SSL ? I bet the later gets used by a heck of a lot more people every day, and it is supported by many more programs. You are free to use any proprietary security protocol you want, including a home built-one or double ROT13 . Nobody is forcing you to use SSL/TLS for your own applications. Obviously most businesses and financial institutions don't agree with your approach, as they prefer to use the open and very popular SSL/TLS protocol, which is supported by a host of programs from many sources, commercial and free, rather than reinvent the wheel and start from scratch as you advocate. One of the often stated goals of the NSS library is to support this SSL protocol, for the now-defunct Netscape client, the Mozilla client, some other AOL clients, the Sun/iPlanet servers, and incidently anyone else who wants a free source implementation of that protocol. Supporting proprietary security protocols is not one of the stated goals of NSS, or of Mozilla . ___ 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 [EMAIL PROTECTED] writes: 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. And how would you propose to do this, given that every attempt at this in the past has failed? Peter. ___ 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?
Ian Grigg wrote on Wed, 10 Mar 04, 7:43 PM: 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. 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. This seems like a very narrow view of the world. By just about any reasonable metric SSL is hardly a failure compaired to SSH. SSH will not be a wide success outside a few technically competant people because it is not easy to use. The argument that quick and dirty and we will fix it later is an extention of the adage weak security is better than no security. The fact is weak security or quick and dirty security is *worse* then no security in many contexts. Weak security tells attackers here's something worth attacking and give users a false sense that they are secure. People who know that what they have is not secure do not devolge sensitive information in those systems. The cost of learning how to include SSL is no harder than the cost of learning UI API's. You could always start your app with some simple line drawing, and let it develope as people hand draw buttons, etc. The problem is your app will not be able to play in the existing infrastructures. In the long run your app will take more time to develop, have weird bugs, but hey you didn't have to learn how to use the Microsoft Windows system, or Motif widgets, or Mac Interface builders. bob ___ 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?
Peter Gutmann wrote: 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. NSS has SSL and SMIME (actually CMS) shared libs, which are layered over the core NSS shared lib (which provides cert functions and fairly high level crypto functions), which is layered over PKCS11. PKCS11 allows NSS to use any PKCS11 device for the actual crypto, from tiny smart cards to big crypto accelerator boxes. NSS's softoken DLL is a pure-software PKCS11 module and token, which in turn is layered over blapi, a raw crypto API, of which freebl is NSS's implementation. On some platforms, such as sparc/ultrasparc, where one OS supports both a 32-bit and 64-bit instruction set, NSS has separate 32-bit and 64-bit shared libs for freebl, and it dynamically loads the best one for the current platform. ___ 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?
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: 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: 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
Re: Where to find bare-bone DSA-like authenticated signatures gneration/verification code?
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). Here's a list of available libraries, I don't know how up to date it is: http://www.homeport.org/~adam/crypto/index.html 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... iang ___ 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?
Ian Grigg wrote: 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). Which is *exactly* what is wrong. Gutmann complains: 'The determined programmer can produce snake oil using any crypto tools...' and goes on and on with his theme about the design, devices, policies etc., that would make it impossible for the above to happen; i.e., no matter how ignorant the programmer, once he uses the 'right' crypto library, all his apps should be perfectly secure. Indeed, in the same paper he concludes: [crypto API should be] ...at the highest possible level, in order to prevent users (i.e., application programmers,rk) from injuring themselves... This fallacy has taken the design of crypto libraries way too far into the territory where, IMHO, they attempt to do not only more than they should, but more then they ever could. As the libraries grow ever more complex, incompetent programmers keep merrily producing apps with ever larger security holes, while treating their (application software) users as idiots, i.e., the same way Gutmann would treat them. It is therefore no wonder that application software full of security holes is nicely complemented by users who neither understand their threat/security model, nor put any effort into actively managing it. We are not getting ahead of this game. Roger K. ___ 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 on 3/5/2004, 4:34 PM: Ian Grigg wrote: 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). Which is *exactly* what is wrong. Gutmann complains: 'The determined programmer can produce snake oil using any crypto tools...' and goes on and on with his theme about the design, devices, policies etc., that would make it impossible for the above to happen; i.e., no matter how ignorant the programmer, once he uses the 'right' crypto library, all his apps should be perfectly secure. Indeed, in the same paper he concludes: [crypto API should be] ...at the highest possible level, in order to prevent users (i.e., application programmers,rk) from injuring themselves... This fallacy has taken the design of crypto libraries way too far into the territory where, IMHO, they attempt to do not only more than they should, but more then they ever could. As the libraries grow ever more complex, incompetent programmers keep merrily producing apps with ever larger security holes, while treating their (application software) users as idiots, i.e., the same way Gutmann would treat them. It is therefore no wonder that application software full of security holes is nicely complemented by users who neither understand their threat/security model, nor put any effort into actively managing it. We are not getting ahead of this game. Gutmann is talking about security holes resulting from incorrect application of cryptography. You are talking about general software security holes, most of which, such as buffer overflows, have nothing to do with cryptography. Some of the security holes resulting from improper application of cryptography are very subtle and were not obvious to even experts before they were discovered. This is why Gutmann and my colleague Nelson urge people to use high-level cryto API or security protocols. They are not treating crypto library users as idiots. They are not saying that you don't need to use good software engineering practices to eliminate other kinds of software security holes (such as buffer overflows). Wan-Teh ___ 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?
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. Roger ___ 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?
Ivan Vecerina wrote: Hello, In some application, I would like to be able to authenticate the origin of a data file (such as a new program to flash on an EPROM), to make sure it is a properly tested/validated version. It seems like a digital signature system such as DSA is what I need. But I really do not need any of the fluff (encodings of the signature, certificate management, etc). The raw crypto algorithms in NSS are in lib/freebl. Look at blapi.h for the function prototypes. NSS is designed to benefit the application of encryption in standard protocols, not at the raw use of crypto in home made protocols. 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. ___ 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?
Nelson Bolyard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ivan Vecerina wrote: It seems like a digital signature system such as DSA is what I need. But I really do not need any of the fluff (encodings of the signature, certificate management, etc). The raw crypto algorithms in NSS are in lib/freebl. Look at blapi.h for the function prototypes. NSS is designed to benefit the application of encryption in standard protocols, not at the raw use of crypto in home made protocols. The system I work on is not intended to support any network protocol or key exchange, just the serial upload of a (signed) data file. 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. Got the point - I could never be aware and careful enough about it. This said, it is not a high-security or life-supporting device I'm working on (just investigating so far...). Thank you for the helpful reference. Kind regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST - e-mail contact form ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Where to find bare-bone DSA-like authenticated signatures gneration/verification code?
Hello, In some application, I would like to be able to authenticate the origin of a data file (such as a new program to flash on an EPROM), to make sure it is a properly tested/validated version. It seems like a digital signature system such as DSA is what I need. But I really do not need any of the fluff (encodings of the signature, certificate management, etc). In the end, I am looking for a minimalist API looking like (with each parameter being something like a buffer ptr+size): void generateSignature( in data, in privateKey, out signature); bool verifySignature ( in data, in publicKey, in signature ); /* and something to generate a private+public key pair in binary form, which I will embed in the SW */ I assume that a corresponding functionality can be found in NSS. But where? (I may have to extract the required source code, as this is eventually to be used on an embedded system). Thanks in advance for any assistance, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST - e-mail contact form ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
