-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Murmur3
should not be cryptographic hash algorithm
#3668
Murmur3
should not be cryptographic hash algorithm
#3668
Conversation
Murmur3
should not no cryptographic hash algorithmMurmur3
should not be cryptographic hash algorithm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the problem?
The Hash functions are fundamental to modern cryptography. These functions map binary strings of an arbitrary length to small binary strings of a fixed length, known as hash values. A cryptographic hash function has the property that it is computationally infeasible to find two distinct inputs that hash to the same value. Hash functions are commonly used with digital signatures and for data integrity. The hash is used as a unique value of fixed size representing a large amount of data. Hashes of two sets of data should match if the corresponding data also matches. Small changes to the data result in large unpredictable changes in the hash. Dictionary: the art of writing or solving codes. |
Great explanation. But:
These hash functions refer to the secure hash functions in cryptography(SHA -> Secure Hash Algorithm). However, murmur32(as well as murmur128) is a It is wrong to implement murmur32 as |
Explained above. |
src/Neo/Cryptography/Murmur32.cs
Outdated
/// Append data to murmur computation | ||
/// </summary> | ||
/// <param name="source">Source</param> | ||
public void Append(ReadOnlySpan<byte> source) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a problem with the implementation of murmur3 in neo.
So append
is not supported yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we can remove also Initialize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we can remove also Initialize
Yes. Initialize
can be removed.
I keep Initialize
because ComputeHash
can be called multiple times for a Murmur3
instance.
Co-authored-by: Shargon <[email protected]>
/// </summary> | ||
public sealed class Murmur32 : System.Security.Cryptography.HashAlgorithm | ||
public sealed class Murmur32 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use NonCryptographicHashAlgorithm
as inherit class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More updates are needed, because Append
not supported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? You can still use append
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? You can still use
append
.
The current murmur32 impl in neo doesn’t support multiple Append operations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you can't use it in NonCryptographicHashAlgorithm
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the current logic does not allow this interface, feel free to create a new PR for this purpose
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well then I don't find this as a fix. Using these interfaces makes the hash a lot faster to process data. I want to see a benchmark of this new implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic is the same, should be faster but never slower, why do you think it will be slower?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic is the same, should be faster but never slower, why do you think it will be slower?
Because of the class
interfaces use an engine for fast hashing for huge amounts of data up to 2GB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well then I don't find this as a fix. Using these interfaces makes the hash a lot faster to process data. I want to see a benchmark of this new implementation.
No significant performance difference.
* master: (43 commits) Fix `GetAndChange` warnings (neo-project#3702) `Murmur3` should not be cryptographic hash algorithm (neo-project#3668) Test: add tests for native contract id (neo-project#3697) Update nugets (neo-project#3692) [Core P2P] fix the bug (neo-project#3695) Add hardfork HF_Echidna (neo-project#3454) Fix: add lock for RocksDbStore.Snapshot to keep same behavior as MemoryStore and LevelDbStore (neo-project#3689) Nullable rocks db (neo-project#3686) Nullable leveldb (neo-project#3685) Enforcement Compiler Warnings (neo-project#3687) [`Update`] Dotnet & Compiler Version (neo-project#3684) [`Add`]: LevelDB Benchmarks (neo-project#3667) [`Fix`]: Behavior when `keyPrefix` is null in different `IStore.Seek` impls. (neo-project#3682) Improve calculatenetworkfee (neo-project#3674) more 2025 (neo-project#3678) Nullable in Storage classes (neo-project#3670) readonly (neo-project#3676) [Fix] Set max entries for `VerifyProof` in `statePlugin` (neo-project#3675) Neo.json.benchmarks (neo-project#3673) Happy new year 2025 (neo-project#3677) ... # Conflicts: # src/Neo/Neo.csproj # src/Neo/ProtocolSettings.cs # src/Neo/SmartContract/ApplicationEngine.cs # src/Neo/SmartContract/Native/NeoToken.cs # src/Neo/SmartContract/Native/RoleManagement.cs # tests/Neo.UnitTests/SmartContract/Native/UT_NativeContract.cs
Description
Murmur3
is not a secure hash algorithm, so it should not implementSystem.Security.Cryptography.HashAlgorithm
, as this can lead to misunderstanding and misuse.Murmur3 probably shouldn't be under the namespace
Neo.Cryptography
, but this PR doesn't change that.Type of change
Checklist: