Update ConstantTimeUtility.cs

[kov072299]

• Fix typo

Description

Typo in ConstantTimeEq meant method only worked as intended for inputs qword aligned (8 byte-aligned).

Type of change

• Bug fix (non-breaking change which fixes an issue)

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

[cschuchardt88]

Can you add a test?

[vncoelho]

@txhsl, what do you think?
@doubiliu

[vncoelho]

I believe that the change is correct because this line is intended to compare corresponding bytes from a_bytes and b_bytes and accumulate any differences into the f variable. The use of XOR (^) will result in a non-zero value for any byte that differs between a_bytes and b_bytes, and the f variable accumulates these differences. If f ends up being 0, it means the two byte arrays are equal.

In this sense, without this change we just compare each byte of a_bytes with itself, which would always result in 0, effectively rendering the check meaningless and always producing a result of true for equality, which looks like to be incorrect.

Please double check before merging.

[vncoelho]

During test it would be good to ensure that the ConstantTimeEq method behaves as expected in all cases, particularly for various data types.

If we can design some UTs based on that it would be great.

[roman-khimov]

But why do we have ConstantTimeEq at all in our code? Isn't something like this provided by standard libraries? Like https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.cryptographicoperations.fixedtimeequals?view=net-8.0?

[shargon]

The change seems good for me

[Jim8y]

But why do we have ConstantTimeEq at all in our code? Isn't something like this provided by standard libraries? Like https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.cryptographicoperations.fixedtimeequals?view=net-8.0?

it was converted from rust lib from file to file, but i agree with you, @cschuchardt88 @vncoelho @shargon do you think we should adopt dotnet lib method?

[shargon]

Let's fix this, and create an issue for the native one

[txhsl]

@txhsl, what do you think?

At the beginning, I was thinking about how things like this passed tests, so I checked the context. :)

So first, it is not a transfer from Rust. If we are talking about https://github.com/zkcrypto/bls12_381, the codes are different.

Second, this method is checking two same-type inputs, so it skips the length check.

Third, is this line really used? If a_u64.Length * sizeof(ulong) always equals a_bytes.Length, then that line is never reached.

neo/src/Neo.Cryptography.BLS12_381/ConstantTimeUtility.cs

Lines 28 to 29 in 90fbbe1

	for (int i = a_u64.Length * sizeof(ulong); i < a_bytes.Length; i++)
	f |= (ulong)a_bytes[i] ^ b_bytes[i];

If what we need is a universal helper, then we should use std lib if there is one.

If what we need is a crypto thing, then the usage of .AsBytes and .Cast on <T> are risky.

[AnnaShaleva]

If a_u64.Length * sizeof(ulong) always equals a_bytes.Length

It's true in case if a's length in serialized representation is even to ulong size. And if it's not the case, then this code compares the remaining tail of a's with the remaining tail of b's in bytes representation (or may be I'm wrong). As documentation says:

A type is an unmanaged type if it's any of the following types:

• sbyte, byte, short, ushort, int, uint, long, ulong, nint, nuint, char, float, double, decimal, or bool
• Any enum type
• Any pointer type
• A tuple whose members are all of an unmanaged type
• Any user-defined struct type that contains fields of unmanaged types only.

So technically it's possible that both a and b take more than k*ulong number of bytes, but less than (k+1)*ulong number of bytes (e.g. a tuple or some user-defined struct consisting of several fields).

Second, this method is checking two same-type inputs, so it skips the length check.

Agree, so my question isn't relevant anymore. And given this fact the fix presented in the PR is valid.

I was thinking about how things like this passed tests,

I think that somehow it just happened than no one tried to call this helper for a large tuple or struct. Whereas all int-like cases are handled correctly by this helper, thanks to the first part of this method.

Though it would be good to add a unit-test that calls this method not only for int-ilke types, but also for big unmanaged tuple or struct.

[AnnaShaleva]

It's true in case if a's length in serialized representation is even to ulong size.

OK, I'm wrong about it, and @txhsl is right, a_u64.Length * sizeof(ulong) always equals to a_bytes.Length. So it's just a piece of dead code. Ref. Cast doc:

Remarks

Neither TFrom nor TTo can contain managed object references. The Cast method performs this check at runtime and throws ArgumentException if the check fails.

If the sizes of the two types are different, the cast combines or splits values, which leads to a change in length.

For example, if TFrom is Int64, the ReadOnlySpan contains a single value, 0x0100001111110F0F, and TTo is Int32, the resulting ReadOnlySpan contains two values. The values are 0x11110F0F and 0x01000011 on a little-endian architecture, such as x86. On a big-endian architecture, the order of the two values is reversed, i.e. 0x01000011, followed by 0x11110F0F.

As another example, if TFrom is Int32, the ReadOnlySpan contains the values of 1, 2 and 3, and TTo is Int64, the resulting ReadOnlySpan contains a single value: 0x0000000200000001 on a little-endian architecture and 0x0000000100000002 on a big-endian architecture.

[cschuchardt88]

This PR patch is correct. unmanaged keyword allows upto 2GB~ of data to be passed.

Example:

a_bytes = // is a struct of ulong(s) (Like UInt160, UInt256)
b_bytes = // is a struct of ulong(s) (Like UInt160, UInt256)
a_u64 =  // is an array of ulong(s)
b_u64 = // is an array of ulong(s)