crypto: sig - Prepare for algorithms with variable signature size

The callers of crypto_sig_sign() assume that the signature size is
always equivalent to the key size.

This happens to be true for R

crypto: sig - Prepare for algorithms with variable signature size

The callers of crypto_sig_sign() assume that the signature size is
always equivalent to the key size.

This happens to be true for RSA, which is currently the only algorithm
implementing the ->sign() callback. But it is false e.g. for X9.62
encoded ECDSA signatures because they have variable length.

Prepare for addition of a ->sign() callback to such algorithms by
letting the callback return the signature size (or a negative integer
on error). When testing the ->sign() callback in test_sig_one(),
use crypto_sig_maxsize() instead of crypto_sig_keysize() to verify that
the test vector's signature does not exceed an algorithm's maximum
signature size.

There has been a relatively recent effort to upstream ECDSA signature
generation support which may benefit from this change:

https://lore.kernel.org/linux-crypto/[email protected]/

However the main motivation for this commit is to reduce the number of
crypto_sig_keysize() callers: This function is about to be changed to
return the size in bits instead of bytes and that will require amending
most callers to divide the return value by 8.

Signed-off-by: Lukas Wunner <[email protected]>
Reviewed-by: Stefan Berger <[email protected]>
Cc: Ignat Korchagin <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: ecdsa - Move X9.62 signature size calculation into template

software_key_query() returns the maximum signature and digest size for a
given key to user space. When it only supported RSA keys

crypto: ecdsa - Move X9.62 signature size calculation into template

software_key_query() returns the maximum signature and digest size for a
given key to user space. When it only supported RSA keys, calculating
those sizes was trivial as they were always equivalent to the key size.

However when ECDSA was added, the function grew somewhat complicated
calculations which take the ASN.1 encoding and curve into account.
This doesn't scale well and adjusting the calculations is easily
forgotten when adding support for new encodings or curves. In fact,
when NIST P521 support was recently added, the function was initially
not amended:

https://lore.kernel.org/all/[email protected]/

Introduce a ->max_size() callback to struct sig_alg and take advantage
of it to move the signature size calculations to ecdsa-x962.c.

Introduce a ->digest_size() callback to struct sig_alg and move the
maximum ECDSA digest size to ecdsa.c. It is common across ecdsa-x962.c
and the upcoming ecdsa-p1363.c and thus inherited by both of them.

For all other algorithms, continue using the key size as maximum
signature and digest size.

Signed-off-by: Lukas Wunner <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: sig - Rename crypto_sig_maxsize() to crypto_sig_keysize()

crypto_sig_maxsize() is a bit of a misnomer as it doesn't return the
maximum signature size, but rather the key size.

Rename it as

crypto: sig - Rename crypto_sig_maxsize() to crypto_sig_keysize()

crypto_sig_maxsize() is a bit of a misnomer as it doesn't return the
maximum signature size, but rather the key size.

Rename it as well as all implementations of the ->max_size callback.
A subsequent commit introduces a crypto_sig_maxsize() function which
returns the actual maximum signature size.

While at it, change the return type of crypto_sig_keysize() from int to
unsigned int for consistency with crypto_akcipher_maxsize(). None of
the callers checks for a negative return value and an error condition
can always be indicated by returning zero.

Signed-off-by: Lukas Wunner <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: sig - Move crypto_sig_*() API calls to include file

The crypto_sig_*() API calls lived in sig.c so far because they needed
access to struct crypto_sig_type: This was necessary to differenti

crypto: sig - Move crypto_sig_*() API calls to include file

The crypto_sig_*() API calls lived in sig.c so far because they needed
access to struct crypto_sig_type: This was necessary to differentiate
between signature algorithms that had already been migrated from
crypto_akcipher to crypto_sig and those that hadn't yet.

Now that all algorithms have been migrated, the API calls can become
static inlines in <crypto/sig.h> to mimic what <crypto/akcipher.h> is
doing.

Signed-off-by: Lukas Wunner <[email protected]>
Reviewed-by: Stefan Berger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: sig - Introduce sig_alg backend

Commit 6cb8815f41a9 ("crypto: sig - Add interface for sign/verify")
began a transition of asymmetric sign/verify operations from
crypto_akcipher to a new cryp

crypto: sig - Introduce sig_alg backend

Commit 6cb8815f41a9 ("crypto: sig - Add interface for sign/verify")
began a transition of asymmetric sign/verify operations from
crypto_akcipher to a new crypto_sig frontend.

Internally, the crypto_sig frontend still uses akcipher_alg as backend,
however:

"The link between sig and akcipher is meant to be temporary. The
plan is to create a new low-level API for sig and then migrate
the signature code over to that from akcipher."
https://lore.kernel.org/r/[email protected]/

"having a separate alg for sig is definitely where we want to
be since there is very little that the two types actually share."
https://lore.kernel.org/r/[email protected]/

Take the next step of that migration and augment the crypto_sig frontend
with a sig_alg backend to which all algorithms can be moved.

During the migration, there will briefly be signature algorithms that
are still based on crypto_akcipher, whilst others are already based on
crypto_sig. Allow for that by building a fork into crypto_sig_*() API
calls (i.e. crypto_sig_maxsize() and friends) such that one of the two
backends is selected based on the transform's cra_type.

Signed-off-by: Lukas Wunner <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: sig - fix kernel-doc typo

Correct typo of "destination".

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <davem@daveml

crypto: sig - fix kernel-doc typo

Correct typo of "destination".

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: [email protected]
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: sig - Add interface for sign/verify

Split out the sign/verify functionality from the existing akcipher
interface. Most algorithms in akcipher either support encryption
and decryption, or si

crypto: sig - Add interface for sign/verify

Split out the sign/verify functionality from the existing akcipher
interface. Most algorithms in akcipher either support encryption
and decryption, or signing and verify. Only one supports both.

As a signature algorithm may not support encryption at all, these
two should be spearated.

For now sig is simply a wrapper around akcipher as all algorithms
remain unchanged. This is a first step and allows users to start
allocating sig instead of akcipher.

Signed-off-by: Herbert Xu <[email protected]>

show more ...