On 10/25/17 11:23, H. S. Teoh wrote:
> On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via Digitalmars-d wrote:
>> On Wednesday, October 25, 2017 13:22:46 Kagamin via Digitalmars-d wrote:
>>> On Tuesday, 24 October 2017 at 16:37:10 UTC, H. S. Teoh wrote:
>>>> (Having said all that, though, D is probably a far better language
>>>> for implementing crypto algorithms -- built-in bounds checking
>>>> would have prevented some of the worst security holes that have
>>>> come to light recently, like Heartbleed and Cloudbleed.
>>>
>>> Those were buffer overflows in parsers, not in cryptographic
>>> algorithms.
>>
>> The point still stands though that you have to be _very_ careful when
>> implementing anything security related, and it's shockingly easy to do
>> something that actually leaks information even if it's not outright
>> buggy (e.g. the timing of the code indicates something about success
>> or failure to an observer), and someone who isn't an expert in the
>> area is bound to screw something up - and since this is a security
>> issue, it matters that much more than it would with other code.
> [...]
>
> Yeah.  There have been timing attacks against otherwise-secure crypto
> algorithms that allow extraction of the decryption key.  And other
> side-channel attacks along the lines of CRIME or BREACH.  Even CPU
> instruction timing attacks have been discovered that can leak which path
> a branch in a crypto algorithm took, which in turn can reveal
> information about the decryption key.  And voltage variations to deduce
> which bit(s) are 1's and which are 0's.  Many of these remain
> theoretical attacks, but the point is that these weaknesses can come
> from things you wouldn't even know existed in your code. Crypto code
> must be subject to a LOT of scrutiny before it can be trusted. And not
> just cursory scrutiny like we do with the PR queue on github; we're
> talking about possibly instruction-by-instruction scrutiny of the kind
> that can discover vulnerabilities to timing or voltage.
>
> I would not be comfortable entrusting any important data to D crypto
> algorithms if they have not been thoroughly reviewed.
>
>
> T
>

I am one-hundred-ten percent in agreement with Mr. Teoh here. 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.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

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.

On Wednesday, 25 October 2017 at 22:36:32 UTC, Adam Wilson wrote:
> TBH, the attitudes around here towards Windows devs can be more than a little snobbish.
>

Towards the Windows devs themselves, or the innate tendency (that unfortunately comes with using Windows) to blindly use proprietary tool chains (and all the accompanying rubbish that gets imposed along with it)?

I tend to think it's the latter. I don't think it's personal (and it better not be!)

And such philosophical snobbery (from either end of the spectrum) will not disappear anytime soon...

Move on.... find the middle ground...get rid of Windows and Linux..

...and use FreeBSD ;-)

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.

On 25/10/2017 11:46 PM, Adam Wilson wrote:
> On 10/25/17 11:23, H. S. Teoh wrote:
>> On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via Digitalmars-d wrote:
>>> On Wednesday, October 25, 2017 13:22:46 Kagamin via Digitalmars-d wrote:
>>>> On Tuesday, 24 October 2017 at 16:37:10 UTC, H. S. Teoh wrote:
>>>>> (Having said all that, though, D is probably a far better language
>>>>> for implementing crypto algorithms -- built-in bounds checking
>>>>> would have prevented some of the worst security holes that have
>>>>> come to light recently, like Heartbleed and Cloudbleed.
>>>>
>>>> Those were buffer overflows in parsers, not in cryptographic
>>>> algorithms.
>>>
>>> The point still stands though that you have to be _very_ careful when
>>> implementing anything security related, and it's shockingly easy to do
>>> something that actually leaks information even if it's not outright
>>> buggy (e.g. the timing of the code indicates something about success
>>> or failure to an observer), and someone who isn't an expert in the
>>> area is bound to screw something up - and since this is a security
>>> issue, it matters that much more than it would with other code.
>> [...]
>>
>> Yeah.  There have been timing attacks against otherwise-secure crypto
>> algorithms that allow extraction of the decryption key.  And other
>> side-channel attacks along the lines of CRIME or BREACH.  Even CPU
>> instruction timing attacks have been discovered that can leak which path
>> a branch in a crypto algorithm took, which in turn can reveal
>> information about the decryption key.  And voltage variations to deduce
>> which bit(s) are 1's and which are 0's.  Many of these remain
>> theoretical attacks, but the point is that these weaknesses can come
>> from things you wouldn't even know existed in your code. Crypto code
>> must be subject to a LOT of scrutiny before it can be trusted. And not
>> just cursory scrutiny like we do with the PR queue on github; we're
>> talking about possibly instruction-by-instruction scrutiny of the kind
>> that can discover vulnerabilities to timing or voltage.
>>
>> I would not be comfortable entrusting any important data to D crypto
>> algorithms if they have not been thoroughly reviewed.
>>
>>
>> T
>>
> 
> I am one-hundred-ten percent in agreement with Mr. Teoh here. 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.

Or mbedtls who has also been audited (but much better and nicer code!).
Either way, you write it, you pay for auditing or no users. Hence I won't use our port of Botan.

On 2017-10-26 00:36, Adam Wilson wrote:

> Speaking from very long experience, 95%+ of Windows devs have VS+WinSDK installed as part of their default system buildout. The few that don't will have little trouble understanding why they need it and acquiring it.

IIRC, there have been people on these forums that have been asking why they need to download additional software when they already have the compiler.

Same on macOS.

-- 
/Jacob Carlborg

On Wednesday, 25 October 2017 at 04:55:16 UTC, Walter Bright wrote:
> On 10/24/2017 6:20 AM, Andrei Alexandrescu wrote:
>> * better dll support for Windows.
>
> It's been there, but it breaks repeatedly because it is not in the test suite.

Including TypeInfo? (classes, casting, all such things...)

On 10/26/17 00:32, Jacob Carlborg wrote:
> On 2017-10-26 00:36, Adam Wilson wrote:
>
>> Speaking from very long experience, 95%+ of Windows devs have
>> VS+WinSDK installed as part of their default system buildout. The few
>> that don't will have little trouble understanding why they need it and
>> acquiring it.
>
> IIRC, there have been people on these forums that have been asking why
> they need to download additional software when they already have the
> compiler.
>
> Same on macOS.
>

How many though? Also, we have to do it for macOS, why is Windows special? The macOS setup was just as hard. Download two large packages (XCode+Cmd tools), install, and done.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Tuesday, 24 October 2017 at 22:19:59 UTC, jmh530 wrote:
> I'm sympathetic to your point.
>
> I think there was/is some effort to allow LLD (the LLVM linker) as a replacement for the MSVC linker in LDC. Perhaps if LLD could be a drop-in for MSVC in DMD for Windows, then eventually it could be the default? Not sure that's possible or not.

LLD was integrated in ldc 1.3.0 https://github.com/ldc-developers/ldc/pull/2142 but currently has conflicting command line options. I suppose you can still run it separately, for me even ld works.

On Thursday, 26 October 2017 at 10:16:27 UTC, Adam Wilson wrote:
> On 10/26/17 00:32, Jacob Carlborg wrote:

>>
>> IIRC, there have been people on these forums that have been asking why
>> they need to download additional software when they already have the
>> compiler.
>>
>> Same on macOS.
>>
>
> How many though? Also, we have to do it for macOS, why is Windows special? The macOS setup was just as hard. Download two large packages (XCode+Cmd tools), install, and done.

There definitely has been an uptick in that sort of complaint. The question should be, how many aren't coming here to complain?

My initial internal reaction has always been, "just download and install -- how hard is it?". But one day I stopped and asked myself, what if I were coming to D today? I got by just fine for years without having VS installed. Once the 6.0 days were behind me, I neither needed nor wanted VS. I was content with mingw for my C stuff. When I first came to D, I came with the full knowledge that there was no ecosystem, things were rough, and I'd have to do a lot by hand. I stuck around because the language was worth it. If I came in today and saw that I needed to install VS just to get 64-bit binaries, I doubt I'd stick around long enough to discover how great the language is.

I also didn't like that I had to install the Xcode tools on my Mac, but that's needed for any development on Mac from what I can see.