Clarification on MD5 Usage in System.Security.Cryptography.Native.Android and PII Handling

[lesterbotello]

Hello .NET Runtime maintainers,

We are seeking clarification regarding the purpose and usage of the MD5 implementation within the System.Security.Cryptography.Native.Android library.

Background

One of our applications indirectly references this library as part of the .NET runtime stack. During a recent security assessment, our security scanning tools identified the presence of MD5-related functionality within the library and flagged it as a potential vulnerability.

Here's one example

To be clear:

• Our application does not intentionally use MD5 for cryptographic operations.
• We do not use MD5 for encrypting, hashing, storing, or otherwise processing personally identifiable information (PII).
• The concern stems solely from the library being present in our dependency chain and the scanner detecting references to MD5-related code.

Question

Could a maintainer help clarify:

1. What is the purpose of the MD5 implementation within System.Security.Cryptography.Native.Android?
2. Is the MD5 functionality simply exposed as part of the platform cryptography provider support, or is it actively used internally by the runtime for processing application data?
3. Are there any scenarios in which the runtime itself would use MD5 to handle application-provided data, including PII, without explicit developer use of the MD5 APIs?
4. If an application does not directly call MD5 APIs, is it reasonable to conclude that the presence of this library alone does not imply that PII or other application data is being processed using MD5?

We are looking for authoritative clarification from the maintainers so that we can accurately document the purpose of the library and address the findings raised by our Security team.

Any guidance, references to runtime implementation details, or links to relevant documentation would be greatly appreciated.

Thank you for your time and assistance.

[bartonjs]

1. Compatibility with previous versions and supported OSes of .NET
2. Just support, it's never a default option.
3. "Mostly no." Things like SignedCms can load a document that says it was built using MD5 as the digest, and they'll therefore use MD5 when running verify. So "it's not used without explicit gestures", either API call or loading a document that says to use it.
4. Aside from container documents like SignedCms, where they can say they were created with MD5 as an option.

.NET is a platform. We offer choices, and we rarely take choices away. So, yes, banned cryptographic algorithms will turn up inside our platform.

[lesterbotello]

Thank you, this is enough.