Security Working Group Minutes

The Security WG has a recurring virtual meeting once every four weeks. Meeting minutes and the time and date of the next meeting will be published in this thread.

Meetings are open to EEF members: the meeting link is published to the #security channel on EEF Slack one hour prior to each meeting.


April 3, 2024

Participants: Holden Oullette, @maennchen, @max-au, Paul Swartz, @peerst, @voltone


  • Ongoing (Holden)
  • Try to add to automated test suite for web servers
  • Code review of three handlers (HTTP 2.0, HTTP 1.1 and Websocket)

GitHub org 2FA

  • Needs some preparation, to avoid locking out users without 2FA
  • Send out email, and heads-up in Slack (@max-au)

OCSP stapling client

OIDC client

Positioning Erlang ecosystem as “secure”

  • See Whitehouse paper on memory safe languages
  • Counter FUD
  • Collaborate on a doc, targeting blog post or white paper
    • To be shared with Marketing WG for distribution

Supply chain, SBoM of OTP

  • EU funded project (@peerst)
  • SBoM tooling upgrades

Meeting notes

  • Should be publish to Erlang Forums

Next meeting

2nd May 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST


Small Correction: it’s FAPI 2.0.

Spec: FAPI 2.0 Security Profile


This is now enforced, all erlef repo members must have 2FA enabled. Please ping me or infra@ if you are accidentally locked out.


May 1, 2024

(Oops, sorry: previous notes erroneously said the next meeting would be on May 2nd)

Participants: @maennchen, @max-au, Paul Swartz, @varnerac, @voltone

OIDC Client: FAPI compliance

  • Implementation done
  • Conformance test passed
  • Stipend requested for certification

Vulnerability Disclosure Guide proposal

ICANN funding

  • Checking to see if EEF can apply for funding
  • Considering submitting a proposal around SCITT
  • Question: is it not too early, considering work on the spec is still in progress?
  • Reminder: supply chain work should also consider Erlang/OTP itself

SAFE disclosures

  • Several vulnerabilities in commonly used packages
  • Disclosure planned for mid-May
  • Role for EEF SecWG?
    • After disclosure, review how community handled it
    • Check if there is a need to improve processes, tooling, etc.

EEF SecWG GH repo

  • Lots of outdated issues and PRs
  • Have a look in coming weeks
  • Review status during next call

Hex “Trusted Publishers” proposal

  • Stipend is ready
  • Hex team is positive about the proposal
  • Check with Holden about someone who might pick up the work

Hex vulnerability sync

  • Informal proposal discussed with Hex team
  • Automatically retire packages with known vulnerabilities
  • Question: are “retired” and “mentioned in a vulnerability report” not two orthogonal things?
  • Revisit after “Trusted Publishers” collaboration with Hex team

OCSP stapling

Next meeting

Wed 29 May 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST


May 29, 2024

Participants: @maennchen, @max-au, Paul Swartz, @ingela, @rickard, @voltone

Marvin attack and OTP 27 deprecations

  • Background: The Marvin Attack
  • OTP 27 deprecates asymmetrical encryption/decryption functions in crypto and public_key
    • RSA key exchange, which uses these functions, was already disabled by default due to the ROBOT attack; it is now actively discouraged
    • Fixing or deprecating these functions was pushed for by the researchers behind the Marvin attack
    • Practically not possible for OTP team to guarantee these functions are safe, as it depends on libcrypto dependency
  • No plans to remove these functions, likely to stick around for quite a while
    • At least until RSA key exchange, as a compatibility option, is completely removed
    • If/when there is a plan for removal, it will be announced well in advance
  • Could other use-cases, in 3rd party apps/libraries, be safe?
    • Depends on the threat model: can an attacker attempt many decryptions and measure the runtime?
    • What alternative do authors have? Adding custom libcrypto bindings adds complexity and could introduce new vulnerabilities
  • Plan: improve documentation, warn about risks, explain what plans OTP team have with these functions

Next meeting

Wed 26 June 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST


June 27, 2024

Participants: @maennchen, @peerst, @varnerac , Alistair Woodman, Michael Lubas, @voltone

OIDC Client

  • Funding for FAPI certification approved

Vulnerability disclosure guide

  • Feedback incorporated, ready for release
  • Reach out to Marketing WG for visibility

ICANN funding

  • Deadline has passed
  • Similar opportunities likely to pop up, consider submitting

SAFE disclosures

  • Privately disclosed to some projects
  • No public statements or fixes seen yet

Hex trusted publisher

  • Stalled, need someone who can do the work

EU Cyber Resilience Act (CRA)

  • Bunch of consultations scheduled; would be good if some of us could attend at least some of them
  • Chronological list in our Slack channel, for convenience; first five already happened
  • Registration (using the above link) required
  • @maennchen and @voltone will try to register, attend and report back
  • @peerst will check if he can send a delegate too

Next meeting

Wed 24 July 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST


If I understood correctly, the Marvin Attack can only be performed when RSA is used. Why did the whole API got deprecated, not just RSA part of it? Is there currently any way to perform asymmetric encryption/decryption in Erlang without using deprecated API?

Why did the whole API got deprecated, not just RSA part of it?

The API is only defined for RSA. To encrypt with an EC key you’d generate an ephemeral key pair with public_key:generate_key/1 and use public_key:compute_key/2 to derive a secret for use with symmetrical encryption. See for example ECIES variants.

Is there currently any way to perform asymmetric encryption/decryption in Erlang without using deprecated API?

Not out of the box, no. You can build ECIES using primitives provided by crypto and public_key, or you could consider using a library that provides proven abstractions like NaCl/libsodium.

But if you know what you’re doing you can continue to use the deprecated APIs, they can be used safely, depending on the exact variant used and the underlying libcrypto version, as well as the threat model of your application.

1 Like

That’s correct, I was probably looking some other function’s type specs…

That would help, but I’d like to avoid generating a key pair on the other side of my communication channel.

Thanks for the answer!

It achieves exactly the same thing as RSA encryption, just using slightly different primitives.

With RSA you would typically generate a symmetrical encryption key (e.g. with crypto:strong_rand_bytes), encrypt that key with the RSA public key of the recipient, then send the RSA-encrypted symmetrical key along with the symmetrically encrypted payload. The recipient decrypts the symmetrical encryption key with their RSA private key, and is then able to decrypt the payload.

With ECIES you generate an ephemeral EC key pair, you then combine the ephemeral private key with the recipient’s public key to derive the symmetrical encryption key. You send the ephemeral public key along with the symmetrically encrypted payload. You can then throw away the ephemeral key pair. The recipient combines the ephemeral public key with their private key, which results in exactly the same symmetrical encryption key, so they can decrypt the payload.

In both cases the recipient has a private key for which they have shared a public key, and the message is encrypted in a way that only the recipient’s private key can decrypt. Semantically they achieve the same thing, just with slightly different primitives. ECIES eliminates the need for “asymmetrical encrypt/decrypt” primitives by using the (arguably simpler) key agreement primitive.

1 Like