[Proposal] Crypto module wrapper

[Griffin Byatt]

I know the “wrap the Erlang module” proposals are not particularly popular,  and the general consensus is, “make it into a library if you want it”. However, I think in this case it would be a useful addition to the Elixir language. Here is my reasoning:

The Erlang crypto module is not particularly user-friendly, and the supported ciphers are foot-guns with potentially severe failure modes. There are a number of libraries that attempt to address this issue, but they are largely insufficient for general use — i.e offering ECB mode, unauthenticated CBC, static secrets/IVs, non-constant-time comparisons, etc. Considering the importance of the subject (and the ease of misuse), I think a *somewhat* opinionated wrapper could save a lot of heartache.

Here are some initial ideas:

* `Crypto.equals(string1, string2)`  for constant-time comparisons.
* `Crypto.encrypt(message, secret)` for a default authenticated encryption - this could also be future-proofed to allow for better ciphers with something like `Crypto.auth_encrypt_cbc(message, secret)`.
* `Crypto.decrypt(ciphertext, secret)` for decryption.
* `Crypto.sign(message, secret)` for a default symmetric signature. Same as encryption - for example, `Crypto.sign_sha256` or something like that.
* `Crypto.verify(signed, secret)` for verification.

Basically, only offer semi-opinionated wrapper functions that will be closer to default-secure. Like, if you want md5, or ECB, you can go to the Erlang module, but this way more people will start with the secure choices.

Would love to hear thoughts on this. Thanks!

[Griffin Byatt]

Also, to clarify:

My suggestion with `Crypto.encrypt/2` or `Crypto.sign/2` is that if that naming isn't future-proof enough, more specific names like `Crypto.auth_encrypt_cbc/2` could be used.

[Louis Pilfold]

Hiya

If Erlang crypo module could be improved or superseded I'd like for those improvements implemented in Erlang so all languages on the BEAM can make use of them, rather than just Elixir.

Cheers,
Louis

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e2592402-3095-40c4-862d-a58d273d4420%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Griffin Byatt]

The proposal is largely to drop the baggage of insecure or complex functionality that Erlang has to keep for legacy reasons. Where Erlang has a `block_encrypt` function that accepts insecure block ciphers like ECB, Elixir could expose a single `encrypt` (or `auth_encrypt` or whatever) which would only use a secure function. Or a `Crypto.hash` function that only exposes sha-2 hashes. Certainly there are crypto changes that could be made in Erlang (like maybe adding `Crypto.equals?`), but I think Elixir is in a nice position to provide nice APIs to only the most modern, secure Cryptography the BEAM has to offer.

[Tallak Tveide]

Why shouldnt it start out as a library, then if it proves useful discuss whether to include in elixir core?

My feeling is that this belongs outside a language, Erlang has too much stuff included. This was probably the right call back when Erlang didnt have package managers, but elixir has great package support...

[Griffin Byatt]

My concern with leaving it as a library is primarily that the onus is still on the developer to figure out which library to choose, so it doesn't really alleviate the issue. As it stands, developers already have out-of-the-box crypto tools when they are using Elixir, but they aren't the easiest or most secure to use.

I *do* think that keeping it minimal is important. Non-basic features could absolutely be relegated to a library. But I don't know of any languages without some crypto support, and, as a secure/modern language, I think Elixir is in a good position to offer a saner API. 

(Only somewhat related) I also think that any non-core crypto library would do better to wrap libsodium than Erlang's crypto module. 

On Mon, May 14, 2018 at 1:02 PM Tallak Tveide <tal...@gmail.com> wrote:

Why shouldnt it start out as a library, then if it proves useful discuss whether to include in elixir core?

My feeling is that this belongs outside a language, Erlang has too much stuff included. This was probably the right call back when Erlang didnt have package managers, but elixir has great package support...

--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/J-Idvs6ije8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/018f200b-6586-4c53-b3c9-2addc069a73b%40googlegroups.com.

[Paul Schoenfelder]

I think despite that Erlang has to keep some APIs for legacy reasons, it doesn't change the fact that both its documentation and the handling of invalid arguments should be improved, and that should happen _in_ Erlang, not anywhere else. A lot of the issues you have mentioned could be solved simply by improving the documentation to be explicit about what represents "good" selections vs "bad", what gotchas to be aware of, etc. Erlang has also evolved APIs in the past by introducing new modules, and slowly deprecating the old (see `rand` and `random`); I see no reason why the OTP team wouldn't be amenable to a new crypto interface which is safer and easier to use, or at least open to discussion about it. I just don't think this is a good fit for the Elixir standard library, or even a third-party library - this is a prime case of where contributing things upstream to OTP benefits everyone, even if its a slower process. I would try opening an issue there first, getting some discussion going, and if it fails to gain traction, reviving this thread to see what people think.

Paul

On Mon, May 14, 2018 at 1:40 PM, Griffin Byatt <byatt....@gmail.com> wrote:

My concern with leaving it as a library is primarily that the onus is still on the developer to figure out which library to choose, so it doesn't really alleviate the issue. As it stands, developers already have out-of-the-box crypto tools when they are using Elixir, but they aren't the easiest or most secure to use.

I *do* think that keeping it minimal is important. Non-basic features could absolutely be relegated to a library. But I don't know of any languages without some crypto support, and, as a secure/modern language, I think Elixir is in a good position to offer a saner API. 

(Only somewhat related) I also think that any non-core crypto library would do better to wrap libsodium than Erlang's crypto module. 

On Mon, May 14, 2018 at 1:02 PM Tallak Tveide <tal...@gmail.com> wrote:

Why shouldnt it start out as a library, then if it proves useful discuss whether to include in elixir core?

My feeling is that this belongs outside a language, Erlang has too much stuff included. This was probably the right call back when Erlang didnt have package managers, but elixir has great package support...

--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/J-Idvs6ije8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to elixir-lang-core+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/018f200b-6586-4c53-b3c9-2addc069a73b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAMURSkG0bMQ48%2BKncciXdj7ugrmCSe4pur%2BCTGWh7JhHvofYZA%40mail.gmail.com.

[Griffin Byatt]

>  it doesn't change the fact that both its documentation and the handling of invalid arguments should be improved, and that should happen _in_ Erlang, not anywhere else. A lot of the issues you have mentioned could be solved simply by improving the documentation to be explicit about what represents "good" selections vs "bad", what gotchas to be aware of, etc

Agreed that documentation improvements and argument handling should happen in Erlang. I disagree that documentation improvements and best practices would solve these problems. In practice, I definitely haven't seen that to be the case. 

> I see no reason why the OTP team wouldn't be amenable to a new crypto interface which is safer and easier to use, or at least open to discussion about it.

Perhaps that is the best solution. Although, unfortunately, a new interface doesn't really solve the problem of the developer still needing to figure out which interface to use.

Anyway, I appreciate the input :) I'll start poking around for potential solutions elsewhere.

On Monday, May 14, 2018 at 2:02:29 PM UTC-4, Paul Schoenfelder wrote:

I think despite that Erlang has to keep some APIs for legacy reasons, it doesn't change the fact that both its documentation and the handling of invalid arguments should be improved, and that should happen _in_ Erlang, not anywhere else. A lot of the issues you have mentioned could be solved simply by improving the documentation to be explicit about what represents "good" selections vs "bad", what gotchas to be aware of, etc. Erlang has also evolved APIs in the past by introducing new modules, and slowly deprecating the old (see `rand` and `random`); I see no reason why the OTP team wouldn't be amenable to a new crypto interface which is safer and easier to use, or at least open to discussion about it. I just don't think this is a good fit for the Elixir standard library, or even a third-party library - this is a prime case of where contributing things upstream to OTP benefits everyone, even if its a slower process. I would try opening an issue there first, getting some discussion going, and if it fails to gain traction, reviving this thread to see what people think.

Paul

On Mon, May 14, 2018 at 1:40 PM, Griffin Byatt <byatt....@gmail.com> wrote:

My concern with leaving it as a library is primarily that the onus is still on the developer to figure out which library to choose, so it doesn't really alleviate the issue. As it stands, developers already have out-of-the-box crypto tools when they are using Elixir, but they aren't the easiest or most secure to use.

I *do* think that keeping it minimal is important. Non-basic features could absolutely be relegated to a library. But I don't know of any languages without some crypto support, and, as a secure/modern language, I think Elixir is in a good position to offer a saner API. 

(Only somewhat related) I also think that any non-core crypto library would do better to wrap libsodium than Erlang's crypto module. 

On Mon, May 14, 2018 at 1:02 PM Tallak Tveide <tal...@gmail.com> wrote:

Why shouldnt it start out as a library, then if it proves useful discuss whether to include in elixir core?

My feeling is that this belongs outside a language, Erlang has too much stuff included. This was probably the right call back when Erlang didnt have package managers, but elixir has great package support...

--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/J-Idvs6ije8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/018f200b-6586-4c53-b3c9-2addc069a73b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

[Paul Schoenfelder]

> I disagree that documentation improvements and best practices would solve these problems. In practice, I definitely haven't seen that to be the case.

In my own experience, the primary issue I ran into with `crypto` was the inability to understand why certain arguments would result in `badarg` - I had to go fishing around in the C source to figure it out. These are the kind of things documentation absolutely can solve. I would agree that people ignoring recommendations in the documentation, or ignoring the docs completely, is something we can't solve with more documentation, but the crypto module in particular is not one you can just use blindly without at least skimming the docs, it is not an easy module to use. Warnings are very clearly presented in the Erlang manual, and along with specific recommendations in function docs (say for example `encrypt`), I suspect few would be able to dive in without having read one or the other, if not both. I don't think it should be a goal to prevent people from using old encryption/hashing algorithms, simply for compatibility reasons, so if people want to ignore recommendations, I think you have to assume that it's for a reason. In my experience I haven't encountered any cases where people were using crypto incorrectly, but that may just be luck on my part. Regardless, if nothing else I think documentation is the first effort that should be undertaken - the existing docs are barely useful.

> Although, unfortunately, a new interface doesn't really solve the problem of the developer still needing to figure out which interface to use.

With `rand` and `random`, there is a compiler warning when you use the deprecations, the same would apply with a new crypto module, which effectively guides you to the right interface. Likewise, the documentation would need to state at the top that the module is deprecated and to refer to the new interface moving forward. I think the issue of developers trying to figure out which interface to use is only a problem when you either introduce a third-party library, or an extension to Elixir core, as compiler warnings can't be used to drive people towards the "new" module.

> I'll start poking around for potential solutions elsewhere.

I hope this means you'll take the discussion to the OTP team! They don't bite! I suspect the primary reason it hasn't gotten as much attention is simply time and priorities, having someone interested in driving improvements forward would likely be very welcome indeed.

Paul

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ab2aec1a-1e2c-4be7-84e1-8862cf011fa7%40googlegroups.com.

[Griffin Byatt]

> These are the kind of things documentation absolutely can solve. I would agree that people ignoring recommendations in the documentation, or ignoring the docs completely, is something we can't solve with more documentation

Ah, yes - I was only referring to the latter concern. But (from looking through proposals) it seems like there are a lot of general usability issues that could be addressed through documentation.

> In my experience I haven't encountered any cases where people were using crypto incorrectly, but that may just be luck on my part. 

Or bad luck on my part? Outside of Plug, I'm not sure I've seen it used securely :P

> I hope this means you'll take the discussion to the OTP team! 

Yes! Though, if I'm going to the OTP team my proposal will probably be a lot different. So I probably won't start the discussion there until I've had time to think about the best way to approach the issue in Erlang itself. 

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ab2aec1a-1e2c-4be7-84e1-8862cf011fa7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/J-Idvs6ije8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TsQnAoJ68V2jxjdMafbNkF%3DuMdk4H3GSqn0787EcYE%2B6Q%40mail.gmail.com.