www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - SecureD - A simple cryptography library for D

reply Adam Wilson <flyboynw gmail.com> writes:
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
Nov 12 2016
next sibling parent reply Suliman <evermind live.ru> writes:
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.
Nov 12 2016
parent reply Adam Wilson <flyboynw gmail.com> writes:
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
Nov 12 2016
next sibling parent reply Suliman <evermind live.ru> writes:
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.
Nov 13 2016
parent Adam Wilson <flyboynw gmail.com> writes:
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
Nov 13 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 13 2016
parent reply Adam Wilson <flyboynw gmail.com> writes:
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
Nov 13 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Nov 13 2016
parent reply Adam Wilson <flyboynw gmail.com> writes:
rikki cattermole wrote:
 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.
I'll take a look at it. Botan should be easier to work with than OpenSSL. -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Nov 13 2016
parent reply Adam Wilson <flyboynw gmail.com> writes:
Adam Wilson wrote:
 rikki cattermole wrote:
 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.
I'll take a look at it. Botan should be easier to work with than OpenSSL.
This is going to have to wait. The Botan port currently does not build with 2.072.0 due to the removal of std.stream. I've filed a bug here: https://github.com/etcimon/botan/issues/24 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Nov 13 2016
parent reply Adam Wilson <flyboynw gmail.com> writes:
Adam Wilson wrote:
 Adam Wilson wrote:
 rikki cattermole wrote:
 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.
I'll take a look at it. Botan should be easier to work with than OpenSSL.
This is going to have to wait. The Botan port currently does not build with 2.072.0 due to the removal of std.stream. I've filed a bug here: https://github.com/etcimon/botan/issues/24
The std.stream deprecation has been fixed and I've pushed the code to implement Botan, but the tests fail on a SegFault inside Botan in the PEM export functions. AES/Hash/HMAC/PBKDF2/RNG work. On OSX you need to use LDC or the linker will fail. Tracking issue for the segfault: https://github.com/etcimon/botan/issues/25 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Dec 11 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-12-12 08:07, Adam Wilson wrote:

 On OSX you need to  use LDC or the linker will fail.
What linker errors do you get using DMD? -- /Jacob Carlborg
Dec 12 2016
parent reply Adam Wilson <flyboynw gmail.com> writes:
Jacob Carlborg wrote:
 On 2016-12-12 08:07, Adam Wilson wrote:

 On OSX you need to  use LDC or the linker will fail.
What linker errors do you get using DMD?
ld: in ../../.dub/packages/botan-1.12.8/botan/.dub/build/full-unittest-posix.osx-x86_64-dmd_2072-0D593375D53C36354213ADF6E4F6A036/libbotan_base.a unique_40d1_3b6.o), in section __TEXT,__textcoal_nt reloc 2: symbol index out of range for architecture x86_64 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Dec 13 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-12-13 09:20, Adam Wilson wrote:

 ld: in
 ../../.dub/packages/botan-1.12.8/botan/.dub/build/full-unittest-posix.osx-x86_64-dmd_2072-0D593375D53C36354213ADF6E4F6A036/libbotan_base.a(unique_40d1_3b6.o),
 in section __TEXT,__textcoal_nt reloc 2: symbol index out of range for
 architecture x86_64
Hmm, interesting. -- /Jacob Carlborg
Dec 13 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 13 2016
parent Adam Wilson <flyboynw gmail.com> writes:
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
Nov 13 2016