Remove Blowfish Cipher from FFmpeg Source Code

[agni]

I would like to request the removal of the Blowfish cipher from the FFmpeg source code.

Reason:
Blowfish is an outdated encryption algorithm with several known weaknesses, making it less secure compared to modern cryptographic algorithms. With the increasing need for stronger security practices, continuing to use Blowfish can expose projects that rely on FFmpeg to potential vulnerabilities.
In our project, which uses FFmpeg libraries extensively, we are in the process of removing Blowfish-related components due to these security concerns. However, it has come to our attention that Blowfish is still present within FFmpeg, specifically as part of the libavutil public API/ABI and used internally in rtmpcrypt. Removing Blowfish cleanly from the FFmpeg codebase will not only enhance the overall security of the library but also support projects like ours in avoiding reliance on deprecated or insecure encryption methods.

Affected Areas:
Public API/ABI of libavutil: The av_blowfish* functions are part of libavutil, and their removal could break compatibility for projects using these APIs. A careful approach is needed to ensure compatibility for downstream projects.
Internal Usage in rtmpcrypt: Blowfish is used for RTMP encryption within the rtmpcrypt module. This dependency requires modification or replacement with a more modern encryption algorithm to maintain functionality.

References:
Relevant Files and Modules:
libavutil/blowfish.c
libavutil/blowfish.h
libavformat/rtmpcrypt.c
Related Discussions: Communication with FFmpeg developers highlighted that Blowfish is part of the public API and that its removal could impact backward compatibility. It was noted that removing it without careful coordination could lead to breaking changes for any application linked with libavutil.
I request a thorough review of the Blowfish cipher's usage across FFmpeg and a coordinated plan for its clean removal or replacement with a more secure algorithm. This will ensure continued stability, maintain public API compatibility, and align FFmpeg with modern security standards.

Additional Consideration:
Would it be feasible to introduce a compile-time configuration option that makes Blowfish support optional within FFmpeg? This would allow projects with stricter security requirements to exclude Blowfish while preserving backward compatibility for others.
Thank you for considering this request to improve the security, maintainability, and performance of FFmpeg.

[MasterQuestionable]

͏    This just feels like requesting removal of "http://" support in browsers in sake of "security":
͏    Somewhat overdone..?

͏    And sincerely I don't recommend relying on FF-*'s handling for network parts for security-critical applications:
͏    FF-* is not the appropriate networking tool.
͏    Though it did support some networking functionalities, for the convenience.

[compn]

this encryption is used in rtmp protocol. ffmpeg cant change the rtmp protocol spec. most people arent using rtmp anymore and rtmp is likely to be EOL soon.

[MasterQuestionable]

͏    I rely the CC status for overall management.
͏    (Trac seems have no search input for "involved")

[Balling]

most people arent using rtmp anymore and rtmp is likely to be EOL soon.

Erm, what? All SIP uses rtmp (all phones, landlines and mobile) and youtube too.

[Timo R.]

SIP uses RTP, not RTMP.
RTMP is very much alive in the streaming world, and there is even a big patchset on the ML to implement the latest enhancements.

[MasterQuestionable]

͏    I believe YouTube primarily uses HTTP..?

[Balling]

No, youtube does not support HTTP, only HLS and RTMP(s). ​https://support.google.com/youtube/answer/10265272?hl=en#zippy=%2Cobs

"You can use RTMP(S) or HLS to stream in HDR. Note that you’ll need to keep the “Turn on manual resolution” setting unchecked.

To create a HDR stream via HLS, you’ll need to set your stream key’s protocol to HLS. Learn how to set up an HLS stream."

P.S. technically HLS is http live streaming.