05.07.2016, 08:16, "Ronald S. Bultje" <rsbul...@gmail.com>: [...] >> > [..] >> > >> >> 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. > > I don't know if we can be held responsible for what clients do. The intent > of 6 is for our software, not client software, right?
It is a subtle point, taking your argument, openssl and libgcrypt don't need to provide the option. It is needed for them, if for nothing else, for FIPS requirements. A client could maintain their own patchset, but it is useful to do it there. > > We can add an option to httpauth to allow disabling md5 encryption in the > list of supported encryption protocols (if such an option doesn't already > exist). But I certainly wouldn't go beyond that. > >> 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. > > This is known as "FUD" (Google it if that sounds new). Don't make such > claims unless you have done research, the issue is that people will link to > your email in the mailinglist archives and then claim that "ffmpeg is > fundamentally insecure" - which is utterly untrue. I am aware of the term "FUD". You have done this repeatedly in the past, accusing me of making claims when there is no claim made. There was a basic "Unless..." qualifier. Anyone with a working knowledge of English who pulls the mail will realize that there is no such accusation about FFmpeg. > > And yes, like in our tests, the sha1s in matroska are simply internal > checksums, they are not security-related. And yes, I'm extremely familiar > with matroska. Matroska was given as a single example. I doubt you could make the claim of familiarity for everything in FFmpeg. Nevertheless, to a reasonable degree, this is fine. > > As for reimplementing crypto, AES encryption is done in lavf/srtp.c. >> We thus do not meet 4, though this is not a "must" requirement. > > So there still isn't really an issue. Let's stick to issues for now. Ok, there are a number of others in the original post. > > Ronald > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
