#11220 closed defect (invalid)
Remove Blowfish Cipher from FFmpeg Source Code
Reported by: | agni | Owned by: | |
---|---|---|---|
Priority: | wish | Component: | ffmpeg |
Version: | git-master | Keywords: | |
Cc: | MasterQuestionable | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | yes |
Description (last modified by )
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.
Change History (9)
comment:1 by , 3 months ago
Cc: | removed |
---|---|
Component: | undetermined → ffmpeg |
Priority: | normal → important |
Version: | unspecified → 7.1 |
comment:2 by , 3 months ago
Description: | modified (diff) |
---|
comment:3 by , 3 months ago
Analyzed by developer: | set |
---|---|
Cc: | added |
comment:5 by , 3 days ago
Cc: | removed |
---|---|
Priority: | important → wish |
Resolution: | → invalid |
Status: | new → closed |
Version: | 7.1 → git-master |
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.
comment:6 by , 22 hours ago
Cc: | added |
---|
͏ I rely the CC status for overall management.
͏ (Trac seems have no search input for "involved")
follow-up: 9 comment:7 by , 17 hours ago
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.
comment:8 by , 17 hours ago
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.
͏ 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.