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

greenify <greeenify@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greeenify@gmail.com

--- Comment #1 from greenify <greeenify@gmail.com> ---
There are a couple of DUB libraries that do implement RSA, e.g the botan library: https://github.com/etcimon/botan

However it still would be nice to have it in std.digest

--

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

--- Comment #2 from Andre <andre@s-e-a-p.de> ---
As far as I know there is no native library available (not depending on e.g. openssl dll) which works for dmd OMF.

Unfortunately even botan only works with x86 / x64 coff.

--

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

Andre <andre@s-e-a-p.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Andre <andre@s-e-a-p.de> ---
Superseded by https://issues.dlang.org/show_bug.cgi?id=17958

*** This issue has been marked as a duplicate of issue 17958 ***

--

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

Carsten Blüggel <chilli@posteo.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chilli@posteo.net

--- Comment #4 from Carsten Blüggel <chilli@posteo.net> ---
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

--

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

--- Comment #5 from anonymous4 <dfj1esp02@sneakemail.com> ---
Signature validation uses only public key, there's no need for any secret access.

--

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

--- Comment #6 from Carsten Blüggel <chilli@posteo.net> ---
(In reply to anonymous4 from comment #5)
> Signature validation uses only public key

Wikipedia is helpful.

> there's no need for any secret access.

I didn't claim that for Signature validation. Again, consider all of my reply beginning with "All of the discussion in ... " referring to https://issues.dlang.org/show_bug.cgi?id=17958. It's hard for me to see what is capable of being misunderstood in my reply.

--

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

--- Comment #7 from Andre <andre@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)

--