On Wed, Jun 29, 2005, Banginwar, Rajesh wrote: > As part of LSB standardization process, we look at the interfaces and > corresponding data types and make it part of the specification. If the > data types are expected to change and the interfaces do not hide them, > then that part of the library may not be a candidate for LSB. > > Given this, I am just wondering (as I do not know enough details yet) if > it makes sense to partially include the crypto library in LSB. I assume > at least parts of this library may be stable and not expected to change > much. E.g. some of the crypto algorithms. > > Is that a possibility? From our current analysis of some of the existing > OSS applications, function sets like EVP*, RSA*, DSA* etc are quite > commonly used. It may be a good idea to identfy some of the "stable" > interfaces from crypto library for inclusion in LSB. Any > thoughts/comments? >
Well some of the low level crypto APIs haven't changed for some time but their use is discouraged because it ties an application down to a specific algorithm and a specific implementation. EVP is the preferred interface for accessing crypto algorithms and digests. Both these however commonly use the construct I mentioned which causes binary compatibility issues. That doesn't mean that EVP can't be used in a way that pretty much guarantees binary compatibility: its just that existing applications don't often use it in that way. So its certainly feasible to say that "if you use EVP like *this*" it wont cause problems. Similar comments apply to RSA and DSA: there are ways to use the APIs that avoid structure access and possible future incompatibilities. There are however some areas where the API is lacking: for example there isn't currently an easy way to populate an RSA structure with its key components. That is there isn't a function: RSA_set_PublicKey(rsa, n, e); but that's not hard to fix. That all applies to applications that use existing algorithms that are part of OpenSSL (or which have been loaded in via an ENGINE). Applications which extend OpenSSL by defining new cryptographic algorithms currently need to access internal structures directly. APIs can of course be developed that remedy that situation, but again existing applications wont use them. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
