HOW TO handle "Cipher not supported in this libcrypto version" for :des_ecb

Please how can we replace :des_ecb, the list of supported ciphers no longer includes :des_ecb

 :crypto.supports(:ciphers) |> Enum.sort

[:aes_128_cbc, :aes_128_ccm, :aes_128_cfb128, :aes_128_cfb8, :aes_128_ctr, :aes_128_ecb, :aes_128_gcm, :aes_128_ofb, :aes_192_cbc, :aes_192_ccm, :aes_192_cfb128, :aes_192_cfb8, :aes_192_ctr, :aes_192_ecb, :aes_192_gcm, :aes_192_ofb, :aes_256_cbc, :aes_256_ccm, :aes_256_cfb128, :aes_256_cfb8, :aes_256_ctr, :aes_256_ecb, :aes_256_gcm, :aes_256_ofb, :aes_cbc, :aes_ccm, :aes_cfb128, :aes_cfb8, :aes_ctr, :aes_ecb, :aes_gcm, :chacha20, :chacha20_poly1305, :des_ede3_cbc, :des_ede3_cfb]
 :crypto.crypto_one_time(:des_ecb, <<22, 196, 241, 251, 94, 110, 73, 185>>, <<173, 40, 36, 224, 82, 88, 223, 183>>, true)

** (ErlangError) Erlang error: {:notsup, {~c"api_ng.c", 284}, ~c"Cipher not supported in this libcrypto version"}:

  * 1st argument: Cipher not supported in this libcrypto version

    (crypto 5.3) crypto.erl:965: :crypto.crypto_one_time(:des_ecb, <<22, 196, 241, 251, 94, 110, 73, 185>>, <<173, 40, 36, 224, 82, 88, 223, 183>>, true)
    iex:3: (file)

I had ported this erlang library to Elixir, it was working before updating to OTP26

You’ll likely need to adjust how OpenSSL is compiled on your system; des_cbc is in the “legacy” provider, and Erlang started tolerating that provider’s absence in OTP25.1:

1 Like

it would seem Windows Server 2019 has this version presently

λ openssl version
OpenSSL 3.1.1 30 May 2023 (Library: OpenSSL 3.1.1 30 May 2023)

are you suggesting we can set a flag to allow “legacy” providers?

Not quite - I linked to the Erlang source where it’s trying to load the legacy provider, but will ignore a failure to load. des_ecb not working tells me that provider isn’t being loaded.

The documentation suggests that, depending on how OpenSSL was compiled, you might be able to set an environment variable to allow that provider to load. On the other hand, those functions might not be compiled into the OpenSSL library at all if that option was selected at compile-time.

Another alternative would be to manually implement the needed DES functions. The usual advice of “don’t roll your own crypto” applies less here, since NTLMv1 has been deprecated for a decade+…

1 Like

Maybe downgrading to openssl 1.1 might help.

Im on a windows server, I dont know if reconfiguring openSSL would be advisable

A lot of companies still use web services that require NTLMv1
IT would be good for us to have a way to keep supporting those clients , even if we upgrade to OPT26 and beyond

Disagree, deprecation encouragement is the only way to motivate those companies to move to new secure standards.

I’ll simply roll them back to OTP25