On Wednesday, 25 October 2017 at 23:37:37 UTC, codephantom wrote:
On Wednesday, 25 October 2017 at 22:46:27 UTC, Adam Wilson
wrote:
Even .NET Framework and Core forward to the highly vetted
system crypto API's (SChannel on Windows and OpenSSL on
Linux/macOS). If you need RSA crypto in D, pull in OpenSSL.
Period. Everything else is a good way to run afoul of a
security audit, and potentially expose yourself.
Phobos could forward to these system provided API's like .NET
does and provide an idiomatic D interface, but Phobos itself
should absolutely and 110% stay out of the crypto
implementation business.
I agree. D just needs an interface to Encryption providers.
I cannot see how anyone would consider anything other than a
provider model, for something that is so highly complex and
specialised.
While I agree that we are nowhere near being able to safely
integrate crypto in phobos it is definitely no that specialized.
Most communicating programs I can think of use crypto in some
form or another: data encryption of course, but also secure
random numbers (which we sorely lack atm), signature verification
(which was the point here), secure communications (I'm talking
protocol, not encryption here)...
What communicating program doesn't need to guarantee at least the
integrity of its data not to talk about confidentiality?
We do have some elements in phobos right now (base hashing
algorithms for example) and I think we could add more without
falling into crypto hell. Something as simple as a standard
interface to the system's cryptographically secure random number
generator (such as /dev/urandom on linux) would be a valuable
addition.
While there definitely value in not playing with fire we
shouldn't be dismissing all crypto operations as a whole just
because we fear the word.
