[Bug 3005] Use high-level EVP PKEY API instead of low-level algorithm specific calls + separate digesting in the every backend

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3005

--- Comment #3 from Jakub Jelen <jjelen at redhat.com> ---
> This patch is only of benefit for signature algorithms that are
> supported by OpenSSL. The last two that we added (ed25519 and XMSS)
> weren't, and I don't think it's likely that future signature algorithm
> additions will land in OpenSSL before they land in OpenSSH either.

The ed25519 curves are already implemented in OpenSSL so it should be
possible to cover this also in OpenSSL, but that is different issue to
solve. Moreover the ed25519 curves do not need to digest of the data
separately, which also simplifies things. I did not have a better look
into the XMSS yet though.

> Many (most?) versions of OpenSSL invoke a full ASN.1 parser in the RSA
> signature verification path. Our implementation avoids that massive
> attack surface for something much smaller and easy to audit.

You are probably right. The DigestInfo in OpenSSL is added in
encode_pkcs1() function by calling ASN.1 encoder on openssl (digest)
and openssh (hash algorithm) provided data. But I do not see how this
is a huge attack surface since there is really no variable data
provided by user to these functions.

On the other hand, implementation in OpenSSL is also audited, which
removes the critical code duplication.

Similarly the d2i_*() functions operate on the signature data provided
by the OpenSSL code (the signatures).

Indeed the changeset can be limited to the signatures leaving the RSA,
ECDSA and DSA structures stored in the sshkey structure, which would be
significantly smaller and touching significantly less code, if that
would be more acceptable.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.