Re: ECC vs RSA, and Similar Conflicts

On Wed, May 30, 2012 at 12:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Wed, May 30, 2012 at 12:06 PM, Da Cruz Pinto, Juan M
> <juan.m.da.cruz.pinto@intel.com> wrote:
> > Keep in mind that PKCS#11 defines an API for accessing crypto
> operations, one which does not require the caller to have direct access to
> key material. For instance, most HSM (Hardware Security Modules) vendors
> provide a PKCS#11 library for developers to integrate with.
> >
> > This means that if you are using a PKCS#11 module, then you don't really
> need to have safe/unsafe sections of the API when using ,e.g., RSA.
> Moreover, if you are using a smartcard thru a PKCS#11 module, then you most
> probably will not be able to access the key material at all.
>
> This is only true because PKCS #11 has been adjusted to provide a number of
> specialized pieces of keying material manipulation as required by
> current protocols.
> If, for instance, I decided to invent a new KDF for use with DH (as
> SSL/TLS did)
> I would not be able to use it with existing PKCS #11.
>
> -Ekr
>
>
Isn't this true for most modern general purpose/low-level cryptography APIs?

PKCS#11 requires new mechanisms for new protocols that do new and novel and
hiterto unsupported key transformations.

CryptoAPI (Windows APIs from 95/IE 3.0 -> XP) and CNG (Vista+) both follow
a similar model of using key handles, defining arbitrary mechanisms, and
then allowing arbitrary crypto providers to decide what functionality to
actually implement for the key handles they expose to applications. CNG
goes a step further, and has an entire protocol-specific layer for TLS, so
that TLS-bits don't even have to be exposed via the 'generic' NCrypt/BCrypt
interface. If you want to use some new novel/unsupported key
transformation, the CryptoAPI/CNG API needs to declare some new
transformation type before it can be used (but this declaration is near
zero-cost)

Similarly, this is seen within CDSA/CSSM (HP/Intel, but in practice Apple
prior to Lion) and SecTransform (Lion+), and the RSA BSafe
Crypto-C/Crypto-J libraries. All of which have explicit lists of
mechanisms/transformations that can be used with keys, and any new
cryptographic algorithms/transformations/protocol specific hacks require
new entries in the list of tables. Of these three, SecTransform is the
closest to zero cost - Crypto-C/CDSA are a bit more complicated).

OpenSSL is a bit more... complicated... due to the intersection between
EVP_PKEY (the opaque key type) and the ENGINE interfaces (the opaque
provider types), but my understanding is that as of 1.0.x, this has been
streamlined and the SSL-specific logic has been abstracted similar to the
above. I'll admit, I haven't checked, but if anything, OpenSSL did seem
like the odd one out in that regard.

For PKCS#11, vendor mechanisms/attributes exist to allow early
implementations of interesting, potentially protocol-specific, algorithms.
Yes, it means you can't use transform X with all keys of type Y, but that
seems to be a well-understood design limitation for all modern crypto APIs.

Further, as to the security concerns you raised, for all of those APIs,
there admittedly have existed both direct and indirect call sequences that
may be used to obtain keying material. That's something intrinsic in the
APIs, as they're designed to support both opaque and non-opaque keys. For
systems which are truly meant to protect keying material (eg: FIPS
implementations, hardware-backed implementations, etc), the operations (or
sequence of operations) that can be used to extract said keying material
are often explicitly prohibited/non-implemented by the cryptographic
provider.

I don't see why this cannot be the case with a JS Crypto API.

For all of the above APIs, if I want to use some (insert method here -
whether KDF or cipher or alg), typically the flow is
- Implement it in software first (ergo: no key protection, but you can ship
it)
- Standardize the interface/API for the new algorithm
- Add dynamic checking to see if the API/provider supports the new
algorithm. If so, use that implementation, if not, fall back to software
- Eventually, remove the software fallback