Maggot wrote:
> Hi, > > I have been using CryptLib > (http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html) for some of the > stuff I've been working on in Delphi. However, I find it lacking in features > when compared to OpenSSL and NSS. I would like to use NSS over OpenSSL, due > to the lack of PKCS#11 interfaces. > > I would like to use NSS on Delphi, but NSPR tends to make it impossible. I > want to use NSS directly because of the PKI functionality and PKCS#11 & 12 > it provides. NSS need a subset of NSS functions to run. Basically it needs: Memory allocation (which can usually just be replace with malloc. Thread synchronization (create, destroy, lock, and unlock threads). Arena allocation (which is an NSPR library which can be linked in without pulling the rest of NSPR in. NSS 3.4 also uses NSPR Hash tables (similiar library to Arena). You can look at the link stub files and linking in fortcrypt and ckfw, where NSPR has been stubbed out so that these PKCS #11 modules can be linked with applications with have variant versions of NSPR or which have no version of NSPR. The final issue, which is thornier, is the NSPR I/O model. You will need to present NSPR I/O abstractions to SSL if you want to use SSL. (This is not necessary if you are just using the PKI, S/MIME, or crypto functionality. Most applications, however, just want the SSL functionality, which is why the point is always highligted). A number of applications deployed today use this tactic. > Is there an easier way to implement NSS on non C/C++ like > languages? Are there any interests in providing a wrapper for Delphi/Kylix > or Object Pascal? Probably the best way to do this is to use some sort of external wrappers. Most operating systems standardize their calling format so that it's possible to call between functions in various languages. The exception seems to be object oriented languages, which have to standardize on an object layout that meets the needs of all flavors of OO languages. NSS is a C library. This decision was based on the fact that C was the least common denominator in our customer set (C++ can call C directly, Java can access C through JNI). Anyway your best bet is wrapping NSS. You need to face this issue at some level anyway if you plan on using PKCS #11, which is a C API itself. > > I would look at the possibility of porting JSS JNI functions to work with > Delphi. But is it advisable? I have been looking around for a suitable PKI > library. So far, I have found that NSS suits my needs best. > Could you recommend me a PKI library in the same vein as NSS that would work > with Delphi? I'm not familiar with Delphi. As long as delphi can load external JSS classes, and is OK with those classes loading non-java binary libraries, then I would think this should work. Jamie might have a better feel for this, though. bob > > > I would like to thank you in advance for your comments. > > -Sri > > >
