Hello DLang,

I wanted to announce that I have completed the bulk of the work on my Cryptography library for D, SecureD. I was inspired to do this project by Stan Drapkin and his Inferno.NET project, however, the two projects NOT compatible.

GitHub: https://github.com/LightBender/SecureD
DUB: https://code.dlang.org/packages/secured

Design Philosophy

Developer-Friendly Misuse-Resistant API:
One of the largest problems with most cryptography libraries available today is that their API's practically encourage broken implementations.

Safe by design:
Use only safe algorithms with safe modes. Make conservative choices in the implementation

Do no re-implement cryptography algorithms:
Use industry standard libraries instead. SecureD is based on OpenSSL.

Minimal Code:
Keep the code to a minimum. This ensures high-maintainability and eases understanding of the code.

Unittesting:
All API's are unittested using D's built in unittests. Any developer can verify the implementation with a simple 'dub test' command. This ensures that the library will perform as advertised.


Algorithms

HASH:				SHA2-384
HMAC:				SHA2-384
KDF:				PBKDF2 (HMAC/SHA2-384)
AEAD Symmetric: 		AES-256-CTR-HMAC384
Asymmetric:			ECC-P384 (Key Derivation + Sign/Verify with SHA2-384)
RNG: 				System RNG on POSIX and Windows
OTHER: 				Constant Time Equality

Why these Algorithms?

SHA2-384 is as fast as SHA2-512 but it's truncated design serves as an effective defense against length extensions attacks.

AES-256-CTR is an alternative for GCM that offers greater security for cold-stored data when paired with a strong HMAC. GCM use a 96-bit authentication tag where the HMAC tag is a full 384 bits.

Let me know what you think!

Adam Wilson
IRC: LightBender
//quiet.dlang.dev

Is its possible to make its wrap on botan instead of openssl? Some of developers have problems with openssl because it's require openssl lib. But botan is more native but much more lowlevel.  So its hard to use.

Suliman wrote:
> Is its possible to make its wrap on botan instead of openssl? Some of
> developers have problems with openssl because it's require openssl lib.
> But botan is more native but much more lowlevel.  So its hard to use.

It might be possible. But it would not be without difficulties. It would take some research, but the native Botan library makes heavy use of C++ templates. Additionally, I have a strong aversion to ports of Cryptography libraries, it is far to easy for a port to miss or break a subtle implementation detail and the compiler itself could cause a leak of information.

I choose OpenSSL because it's a well respected, highly trusted, and it is available everywhere. I despise the license and the API. Sadly, those are not primary concerns when dealing with Cryptograpy libraries.

Personally, I actually prefer Botan. Two years ago I started a project to attempt to wrap Botan in a similar manner as this but I ran headlong into the template meat-grinder and found it almost impossible to make it work. It might be possible now with DLang's C++ template support.

That said, if we want to talk about developing a common Cryptography interface for D that would allow us to use the same interface for supporting multiple underlying cryptography libraries I would *LOVE* to have that conversation.

-- 
Adam Wilson
IRC: LightBender
//quiet.dlang.dev

>It would take some research, but the native Botan library makes heavy use of C++ templates
There is native lib https://github.com/etcimon/botan

Some people with whom I talked said that botan is too low level for them and it's hard for them to use it. So your lib maybe very good wrap on top of it.

Suliman wrote:
>> It would take some research, but the native Botan library makes heavy
>> use of C++ templates
> There is native lib https://github.com/etcimon/botan
>
> Some people with whom I talked said that botan is too low level for them
> and it's hard for them to use it. So your lib maybe very good wrap on
> top of it.


I know of that work. I even looked at it. But it is a port and not an interface, that makes me very skeptical. Even though it's the same codebase, you basically have to restart the trust building and code verification process all over again. It's Botan the code, but not Botan the library.

I also agree that Botan is too low level. If you want too, I'd be happy to review a PR that integrates Botan instead of OpenSSL.

My goal is the simple interface, not the underlying implementation.

-- 
Adam Wilson
IRC: LightBender
//quiet.dlang.dev

On 2016-11-12 21:50, Adam Wilson wrote:

> I choose OpenSSL because it's a well respected, highly trusted, and it
> is available everywhere. I despise the license and the API. Sadly, those
> are not primary concerns when dealing with Cryptograpy libraries.

Well, Apple abandoned it years ago because it was difficult to upgrade without breaking applications that are using it. There are also very few core developers working on it, as I understand it.

Other companies/organizations have abandoned it as well in favor of other implementations like libressl due to various reasons.

Perhaps, if possible, a common API on top of whatever is the "native" cryptographic library on each supported platform.

-- 
/Jacob Carlborg

Jacob Carlborg wrote:
> On 2016-11-12 21:50, Adam Wilson wrote:
>
>> I choose OpenSSL because it's a well respected, highly trusted, and it
>> is available everywhere. I despise the license and the API. Sadly, those
>> are not primary concerns when dealing with Cryptograpy libraries.
>
> Well, Apple abandoned it years ago because it was difficult to upgrade
> without breaking applications that are using it. There are also very few
> core developers working on it, as I understand it.
>
> Other companies/organizations have abandoned it as well in favor of
> other implementations like libressl due to various reasons.
>
> Perhaps, if possible, a common API on top of whatever is the "native"
> cryptographic library on each supported platform.
>

What if we did something with DUB build configurations. You can build the default OpenSSL configuration or build a Botan configuration based on the Botan D port depending on your needs. They would use the same cryptographic primitives and produces the same results, just using different libraries.

Would that work?

-- 
Adam Wilson
IRC: LightBender
//quiet.dlang.dev

On 14/11/2016 9:31 AM, Adam Wilson wrote:
> Jacob Carlborg wrote:
>> On 2016-11-12 21:50, Adam Wilson wrote:
>>
>>> I choose OpenSSL because it's a well respected, highly trusted, and it
>>> is available everywhere. I despise the license and the API. Sadly, those
>>> are not primary concerns when dealing with Cryptograpy libraries.
>>
>> Well, Apple abandoned it years ago because it was difficult to upgrade
>> without breaking applications that are using it. There are also very few
>> core developers working on it, as I understand it.
>>
>> Other companies/organizations have abandoned it as well in favor of
>> other implementations like libressl due to various reasons.
>>
>> Perhaps, if possible, a common API on top of whatever is the "native"
>> cryptographic library on each supported platform.
>>
>
> What if we did something with DUB build configurations. You can build
> the default OpenSSL configuration or build a Botan configuration based
> on the Botan D port depending on your needs. They would use the same
> cryptographic primitives and produces the same results, just using
> different libraries.
>
> Would that work?

Yup, simple set of versions should do it.

On 11/12/16 8:15 PM, Adam Wilson wrote:
> Hello DLang,
>
> I wanted to announce that I have completed the bulk of the work on my
> Cryptography library for D, SecureD. I was inspired to do this project
> by Stan Drapkin and his Inferno.NET project, however, the two projects
> NOT compatible.
>
[snip]
>
> Let me know what you think!

I'm not a crypto guru or even a casual user. But I think it's very important that we have something like this for D, thanks for your work!

I know vibe.d uses crypto for https usage. Any ideas/comparison with that? Would the code look better with your lib instead? Would it be more secure? Having vibe.d as a consumer would be a huge boost to testing/usage.

-Steve

Steven Schveighoffer wrote:
> On 11/12/16 8:15 PM, Adam Wilson wrote:
>> Hello DLang,
>>
>> I wanted to announce that I have completed the bulk of the work on my
>> Cryptography library for D, SecureD. I was inspired to do this project
>> by Stan Drapkin and his Inferno.NET project, however, the two projects
>> NOT compatible.
>>
> [snip]
>>
>> Let me know what you think!
>
> I'm not a crypto guru or even a casual user. But I think it's very
> important that we have something like this for D, thanks for your work!
>

You're welcome. There are more goodies in the pipe. :)

> I know vibe.d uses crypto for https usage. Any ideas/comparison with
> that? Would the code look better with your lib instead? Would it be more
> secure? Having vibe.d as a consumer would be a huge boost to testing/usage.
>

vibe.d uses OpenSSL for HTTPS streaming, I use OpenSSL for the cryptographic primitives it supports. A benefit is that you only have to link one library. And vibe.d's code absolutely would look cleaner. Unfortunately, my library targeted for long-term storage scenarios, and SSL is a streaming scenario.

To my mind, you would use OpenSSL for HTTPS as part of an HTTP or web library like vibe.d. Anything I implement would be lower level and not very useful outside of that scenario. It's not a bad idea, but I think it's outside the scope of what my library is trying to accomplish.

My apologies for not more clearly noting that I was targeting long-term storage scenarios, I meant to in the write-up and it must've slipped through the edits.

> -Steve
>

-- 
Adam Wilson
IRC: LightBender
//quiet.dlang.dev