[FFmpeg-devel] [PATCH 2/2] configure: libbsd support for arc4random()

Ganesh Ajjanagadde gajjanag at mit.edu
Wed Dec 9 15:16:34 CET 2015


On Wed, Dec 9, 2015 at 8:54 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Dec 08, 2015 at 09:12:42AM -0500, Ganesh Ajjanagadde wrote:
>> On Tue, Dec 8, 2015 at 9:01 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>> > On Tue, Dec 8, 2015 at 8:16 AM, Clément Bœsch <u at pkh.me> wrote:
>> >> On Tue, Dec 08, 2015 at 07:34:51AM -0500, Ganesh Ajjanagadde wrote:
>> >>> On Tue, Dec 8, 2015 at 7:27 AM, wm4 <nfxjfg at googlemail.com> wrote:
>> >>> > On Sun,  6 Dec 2015 22:56:33 -0500
>> >>> > Ganesh Ajjanagadde <gajjanagadde at gmail.com> wrote:
>> >>> >
>> >>> >> On non-BSD machines, there exists a package libbsd for providing BSD
>> >>> >> functionality. This can be used to get support for arc4random.
>> >>> >>
>> >>> >> Thus, an opt-in --enable-libbsd is added to configure for this
>> >>> >> functionality.
>> >>> >>
>> >>> >> Tested on GNU/Linux.
>> >>> >>
>> >>> >
>> >>> > This doesn't seem worth the trouble at all. Who is even going to use
>> >>> > it, and why, and what additional hidden bugs will it cause?
>> >>>
>> >>> arc4random is a far superior interface, in that it can never fail. See
>> >>> http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt for
>> >>> details.
>> >>> As for hidden bugs, apart from configuration/detection issues, I see none.
>> >>> If anything, it is easier to use /dev/urandom incorrectly.
>> >>> Ultimately any code change is a tradeoff, with different people
>> >>> feeling differently about various things.
>> >>> I still feel that it is worth inclusion due to its technical merits.
>> >>>
>> >>
>> >> Note that the behaviour of arc4random differs between implementations.
>> >>
>> >> http://insanecoding.blogspot.gr/2014/05/libressl-porting-update.html
>> >
>> > That is for libressl, not libbsd, though the remark may still apply.
>> > And there is no real fundamental issue: FFmpeg's seeding code anyway
>> > varies between platforms, in the worst case using time.
>>
>> To clarify above: the seed is not meant for security anyway, since if
>> that was the case FFmpeg's seeding is fundamentally broken, falling
>> down to time is not safe. But this is clarified in the docs.
>
> its not intended for security no, but its also not intended to be
> intentionally insecure.

arc4random is not intentionally insecure; else the API has defeated
its own purpose.

> That said, i would be quite interrested in any statistical or
> security flaws in its output (if all platform specific high quality
> functions are disabled)

This is an interesting question, but one that has been studied in
various forms endlesslessly since FFmpeg's idea here is by no means
unique. The short summary is that: it should not be too bad, but can
by no means match dedicated generators like /dev/urandom or
arc4random.

A longer answer with relevance here is: analysis shows that
quality: arc4random (native) = /dev/urandom ~= /dev/random >
arc4random (libbsd/libressl) >>> fallback.
speed: arc4random (native) > arc4random (libbsd/libressl) > fallback >
/dev/urandom >>> /dev/random.

Thus, using arc4random native variant is unambiguously clear to me
(1/2), 2/2 (preferring arc4random libbsd over /dev/urandom) is
subjective as it is not Pareto optimal.

>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Its not that you shouldnt use gotos but rather that you should write
> readable code and code with gotos often but not always is less readable
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list