[FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

05.07.2016, 08:22, "Hendrik Leppkes" <h.leppkes at gmail.com>:
> On Tue, Jul 5, 2016 at 1:40 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
[...]
>>>
>>>  [..]
>>>
>>>>   4. If the project software is an application or library, and its primary
>>>>   purpose is not to implement cryptography,
>>>>   then it SHOULD only call on software specifically designed to implement
>>>>   cryptographic functions;
>>>>   it SHOULD NOT re-implement its own.
>>>>   Note: This is one where I am personally interested as to why we fail; is
>>>>   it for performance reasons that we reimplement crypto?
>>>>   Suggestion: No idea until I understand the above.
>>>>
>>>>   5. The project security mechanisms MUST use default keylengths that at
>>>>   least meet the NIST minimum requirements through the year 2030 (as stated
>>>>   in 2012).
>>>>   Suggestion: add --enable-unsafe-crypt to configure, and by default not
>>>>   enable it.
>>>>   Change API's and functions accordingly, document it.
>>>>   Note: strictly speaking, per the sentence above, it is ok as we do not
>>>>   really have "default" keylengths.
>>>>   But the extended rationale shows why we fail.
>>>>
>>>>   6. The default project security mechanisms MUST NOT depend on
>>>>   cryptographic algorithms that are broken
>>>>   (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
>>>>   Suggestion: same as 5 above.
>>>
>>>  We don't use any of these for security purposes, we only use them for
>>>  checking frame hashes in automated tests. That should be totally fine.
>>
>>  We do export them though. Just because the FFmpeg CLI progs don't use them for security,
>>  does not mean a client does not, or that a client can be easily configured to not use them.
>>  See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
>>  for what I believe the intent of this requirement is.
>>
>>  Second, are you sure about your claim?
>>  md5 is used in httpauth per RFC 2617.
>>  Now this is fixed by the RFC, but it does not mean FFmpeg needs to support it by default.
>>  In particular, I don't see how this honestly takes care of 6.
>
> This is a rather bad example. The alternative to md5 password digests
> is not using digests at all and only use base64 "encoded" passwords.
> Would that be better? Certainly not. Its like calling every browser
> insecure because it supports md5 digests in the HTTP auth protocol.
> There just isn't a better variant, and disabling it would result in
> either incompat with HTTP servers using it, or fallback to even worse
> variants.
>
>>  In matroskaenc, mov, 160 bit SHA-1 is used.
>>  Unless someone who knows the code well, audits the codebase, and checks
>>  that the SHA-1 and the like are not really for security here (similar to the git model),
>>  5 also has problems IMHO.
>
> sha1 in matroskaenc is used to derive a hash as a bitexact fileuid -
> the alternative is a randomuid (which wouldnt result in bitexact
> files), it has no security implications whatsoever, its just a random
> identifier.
> mov uses sha1 for AAX keys (Audible files), which is mandated by the
> specification.
>
> This is really the general pattern of hash usage in avformat and
> avcodec - its used when the specification asks for it.
>
> As for re-implementing AES or hash algorithms - well those are rather
> trivial, aren't they. Its not like we re-implement TLS.
> The reasoning here is that some of those are strictly required for
> some media formats, and having a dependency on an external library for
> key features of some media formats is rather restrictive. Is there
> even a simple library that offers simple AES/SHA implementations
> without being something huge like openssl?

Note that libgcrypt is substantially smaller than openssl.
I would still not call it simple, only relatively simpler, so no issue with your point.

Thanks for the explanations. 

Most of it boils down to the restrictive wording in the badge app,
there are other instances where I was not too happy (redundancy, slightly conflicting reqs,
imprecision, etc as detailed in the original message).
As you point out, per their strict criteria no standard browser under default config can meet their target.

I will update the crypto stuff later tonight.

>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel