IBM has already done this in creating it's FIPS certified crypto. code which is layered on top of OpenSSL.
In our case we can guarantee that IBM code only uses our restricted subset of the OpenSSL API.
Unfortunately you'll need to support the older API's to support legacy applications and in won't be possible to ensure that everyone writing new code restricts themselves to the sanitized API's.
If you can live with that then the only problem will be getting the necessary changes made to provide a clean API. I'm not claiming that'll be trivial, but we already know it is possible.
Peter
| "Dr. Stephen Henson"
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 30/06/2005 08:14 AM
|
|
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]
