fix: sensitive data compare should use constant time compare to avoid timing attack

[nan01ab]

Description

RpcServer.CheckAuth use direct compare to determine two strings equal or not, but sensitive data compare should use constant time compare to avoid timing attack

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[vncoelho]

I understand this timing attack. It looks correct and the XOR is quite efficient.
Although it does not look much critical to me in this specific case.

[Jim8y]

side-channel attack is sort of hot in the research area~~~~ but not sure how industry see it.

[shargon]

This is no constant, maybe we should do a dummy for for the maxLength string

[nan01ab]

This is no constant, maybe we should do a dummy for for the maxLength string

Implementations in Rust subtle and Golang crypto/subtle are similar to this one. Length is not sensitive.

[shargon]

This is no constant, maybe we should do a dummy for for the maxLength string

Implementations in Rust subtle and Golang crypto/subtle are similar to this one. Length is not sensitive.

Then these implementations are wrong 🙃

[roman-khimov]

Can we please not introduce yet another constant time comparison function? This was discussed already in #3472 (review), there are standard solutions to this that should be used.

[nan01ab]

Can we please not introduce yet another constant time comparison function? This was discussed already in #3472 (review), there are standard solutions to this that should be used.

The implementation in ConstantTimeUtility has some limits.
For example:
public static bool ConstantTimeEq<T>(in T a, in T b) **where T : unmanaged**

[shargon]

        string string1 = "hello";
        string string2 = "hello";

        // Convert to bytes
        byte[] bytes1 = Encoding.UTF8.GetBytes(string1);
        byte[] bytes2 = Encoding.UTF8.GetBytes(string2);

        // Use FixedTimeEquals
        bool result = CryptographicOperations.FixedTimeEquals(bytes1, bytes2);

That's not working?

[nan01ab]

        string string1 = "hello";
        string string2 = "hello";

        // Convert to bytes
        byte[] bytes1 = Encoding.UTF8.GetBytes(string1);
        byte[] bytes2 = Encoding.UTF8.GetBytes(string2);

        // Use FixedTimeEquals
        bool result = CryptographicOperations.FixedTimeEquals(bytes1, bytes2);

That's not working?

This needs extra data copies?

[shargon]

First rule of cryptography, don't write your own cryptography. I'm with @roman-khimov, better to use the official one

[nan01ab]

First rule of cryptography, don't write your own cryptography. I'm with @roman-khimov, better to use the official one

Has changed to CryptographicOperations.FixedTimeEquals, and also eliminated the two memory allocations(Encoding.UTF8.GetString(Convert.FromBase64String(reqauth.Replace("Basic ", "").Trim())); and authstring.Split), so it should have better performance.