Subject: [Cfrg] IUF and Schnorr

From: Watson Ladd <[email-masked]>
Date: Fri, 12 Jun 2015 12:32:25 -0700

Dear all,

It turns out that PKCS #11 will not work with Schnorr signatures: the
message is presented in parts, and only at the end is the signature
presented to the verifier. As a result we will have to hash the messages
for signing.

Is anyone using PKCS #11 for verification? I think the answer will turn out
to be yes unfortunately.

Sincerely,
Watson Ladd

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 12 Jun 2015 14:21:16 -0700

On Fri, Jun 12, 2015 at 12:32 PM, Watson Ladd <[email-masked]> wrote:

> Is anyone using PKCS #11 for verification? I think the answer will turn
> out to be yes unfortunately.
>

Perhaps this is orthogonal, but I went to the W3C WebCrypto Workshop on
hardware tokens, identity, and authentication last year. What I concluded
was while PKCS#11 has wide, somewhat enthusiastic support from hardware
vendors, it's both unsuitable and untenable to the challenges of providing
users with access to hardware tokens from web browsers.

This is where I look to standard like U2F/UAF as alternatives. The former
presently uses ECDSA, but supports hardware tokens generating unique ECC
keypairs per site/origin, and can also be used for the use case of users
interactively authenticating documents. U2F has tokens act as USB HID
devices, from which browsers can access them directly.

Anyway, my two cents on PCKS#11...

-- 
Tony Arcieri

---

From: Adam Langley <[email-masked]>
Date: Fri, 12 Jun 2015 14:58:21 -0700

On Fri, Jun 12, 2015 at 12:32 PM, Watson Ladd <[email-masked]> wrote:
> presented to the verifier. As a result we will have to hash the messages for
> signing.

I believe the WG has concluded that we will have, at least, an IUF
mode in constant-space. One possibility might be signing Hash(message)
with Ed25519. Is that not a Schnorr(ish) signature that would work
with PKCS#11?

To be clear, I care little for PKCS#11 but I don't see the problem
here. (I know that NSS had a real problem with AES-GCM because of
PKCS#11 but that didn't seem to be fatal for AES-GCM.)

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Watson Ladd <[email-masked]>
Date: Fri, 12 Jun 2015 17:04:09 -0700

On Fri, Jun 12, 2015 at 2:58 PM, Adam Langley <[email-masked]>
wrote:

> for

That's a signature scheme that would work, however, I had initially thought
that verification of schemes with H(r||M) would fit IUP APIs. And it would,
if the API took the signature in the initialization, but it doesn't. So it
seems that we have to sign Hash(message) as a hard requirement.

> PKCS#11 but that didn't seem to be fatal for AES-GCM.)

That's because NIST demanded it: whatever problems particular
implementations had got solved to accommodate that request.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 12 Jun 2015 17:31:11 -0700

On 06/12/2015 12:32 PM, Watson Ladd wrote:
> presented to the verifier. As a result we will have to hash the 
> messages for signing.
>
> Is anyone using PKCS #11 for verification? I think the answer will 
> turn out to be yes unfortunately.
>
>

PKCS#11 has a single-call C_Verify(CK_SESSION_HANDLE hSession, 
CK_BYTE_PTR pData, CK_ULONG ulDataLen, CK_BYTE_PTR pSignature, CK_ULONG 
ulSignatureLen).

There is also a single-call C_Sign.

I expect that the existing code is more likely to call C_Sign and not 
C_SignUpdate, C_SignUpdate, ... C_SignFinal for public key signing, 
because ulDataLen <= 64 bytes for OpenPGP, SMIME/CMS, TLS, IPSec, X.509, 
SSH, .... This means that there is other code that does the hashing and 
that higher-level features may depend on IUF behavior in that hashing code.

( C_SignUpdate is more likely be used for MAC. The PKCS#11 spec gives an 
example of CKM_DES_MAC mechanism used with C_SignUpdate )

Same applies to C_Verify v.s. C_VerifyUpdate, but it's less likely to be 
used than signing functions.

---

From: David Jacobson <[email-masked]>
Date: Fri, 12 Jun 2015 19:18:37 -0700

On 6/12/15 12:32 PM, Watson Ladd wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

To you only.

Oracle (which acquired the dying Sun Microsystems) supports PKCS#11.

According to 
http://docs.oracle.com/cd/E23824_01/html/819-2145/chapter1-1.html, they 
have a crypto framework that uses PKCS#11, and I would presume that 
people are using it for verification.

(FWIW, back when I worked at Sun Microsystems, I wrote significant parts 
of the predecessor to that, before there was the framework.)

    --David

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Jun 2015 11:33:48 -0500

> presented to the verifier. As a result we will have to hash the messages

Right, only C_VerifyFinal() gets the signature, but the signature is
needed to get started, so it ought to have been in C_VerifyInit().

Note that no matter what, in order to use a new signature algorithm with
PKCS#11 one needs at the very least new CK_MECHANISM_TYPE codepoint
assignments.  This means that this can get fixed when that codepoint
assignment is requested.  There could be several ways to fix it, from
adding new functions to prefixing the signature to the message in the
EdDSA case.  (IIUC, adding new functions is harder than abusing existing
ones.)

I wouldn't get too exercised about this.  It doesn't seem to be anything
more than a special case of the need to deploy new code in order to
deploy new crypto.

> Is anyone using PKCS #11 for verification? I think the answer will turn out

There's no needed for PKCS#11 to verify signatures, of course, since
there's no need for a token to be involved (the verification key is
generally public, though it doesn't have to be).  But PKSC#11 can be
used for more than just an interface to tokens: it can also be used as a
generic interface to crypto algorithm implementations.

Solaris uses (or used to) PKCS#11 in that very manner as the basis for
its cryptographic framework, with a "metaslot token" and builtin
softtoken that provide software implementations of algorithms not
provided by actual hard and soft tokens.

Nico
--