[Issue 16510] Request: RSA digital signature validation in phobos

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=16510

--- Comment #7 from Andre <andre at s-e-a-p.de> ---
(In reply to Carsten Blüggel from comment #4)
> I'm replying to this and deliberately not to
> https://issues.dlang.org/show_bug.cgi?id=17958, because this is more
> specific:
> RSA digital signature validation
> 
> This operation is quite easy to implement and there are no security concerns
> I can see here; all it requires are publicly available information: The
> digital signature, the public RSA key, the plain message that was signed,
> some math/en-/decoding operations applied
> [https://tools.ietf.org/html/rfc8017], a base64 decoder and digest functions
> (present in phobos already) and a simplified ASN1-decoder (for DigestInfo;
> no full-fledged one required for this case). If there are plans to
> incorporate some more crypto in phobos, I will gladly contribute/share
> implementations, some is already on https://github.com/carblue, a lot still
> on my ssd.
> 
> All of the discussion in
> https://forum.dlang.org/thread/osnema$d5s$1@digitalmars.com is pointless
> referring to this one operation "RSA digital signature validation", though
> the discussion is absolutely valid and great care must be applied (leave it
> to experts!) concerning cryptography in general (i.e. when e.g.
> secret/private key material is involved; that's why the general case of 
> https://issues.dlang.org/show_bug.cgi?id=17958 is different and not really a
> duplicate of this).
> 
> My take on aforementioned security discussion is also differing in that I
> would rely on specialized hardware like smart cards or USB tokens only (both
> based on small crypto chips) to store secrets and perform security related
> operations, and use a widely-used, platform-independant API like
> PKCS#11/Cryptoki, now
> http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html,
> thus there would be no need to implement AES (precisely a frame function
> calling e.g. intel's dedicated asm instructions), RSA and alike: An
> affordable USB crypto token (17-50 €; smart cards even less) has all that
> implemented already. The only dependency (for some operations only) would be
> on a library that implements PKCS#11 API, either specific for the hardware
> from it's vendor or the multi-platform one from the OpenSC project, which
> supports a lot of smart cards/USB tokens, itself depending on openssl.
> Thus the Crypto interface in phobos would be a smart D wrapper around the
> PKCS#11 API + some code for cases when there is no secret/private key
> involved and no PKCS#11 library support available or necessary like for "RSA
> digital signature validation".
> For the sake of fairness, it should be mentioned, that even some crypto
> chips aren't abolutely secure, free of vulnerability notes like
> https://www.kb.cert.org/vuls/id/307015. But they are the best choice I can
> think of, far better than file based secrets.
> 
> I assume You are the donor, referred to in
> https://forum.dlang.org/thread/osnema$d5s$1@digitalmars.com. Then I propose,
> You ask Andrei Alexandrescu about his and Walter's plans concerning more
> crypto in phobos, because what I read from the discussion (not all as it got
> somewhat lost in prevalent dll discussion) was prevalently expressing fear
> to touch crypto at all. It's not justified to be scary here following the
> route I proposed. In principle, even the "RSA digital signature validation"
> can completely be done by the crypto chip, but as this is a slow bottle neck
> for large messages to be hashed, it's usually done by the PKCS#11 library or
> future D code.
> 
> 'Bindings' to the PKCS#11 API are available.
> There is also the expertise of Cryptography in D - Amaury Séchet | DConf2017
> https://www.youtube.com/watch?v=CoibdYFM53U

My gut feeling is, enhancement to Phobos comes from the community. If there is
a champion with a good enhancement and the community agrees than Walter and
Andrei are likely willing to include these enhancement.

As a starting point, the signature validation could be build as independent dub
package (Boost license would be great)

--