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.
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.
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.