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.
On Sunday, May 13, 2018 at 7:31:42 PM UTC-4, Louis Pop wrote: > > 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 > > On Mon, 14 May 2018, 00:09 Griffin Byatt, <[email protected] > <javascript:>> wrote: > >> 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! >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/e2592402-3095-40c4-862d-a58d273d4420%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/e2592402-3095-40c4-862d-a58d273d4420%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/8bd1f445-9241-4b83-97b2-4f80d66bae6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
