Skip to content
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

Make storage::HashMap aware of its keys #347

Closed
Robbepop opened this issue Mar 12, 2020 · 1 comment
Closed

Make storage::HashMap aware of its keys #347

Robbepop opened this issue Mar 12, 2020 · 1 comment
Labels
A-ink_storage [ink_storage] Work Item

Comments

@Robbepop
Copy link
Collaborator

Robbepop commented Mar 12, 2020

The current storage::HashMap implementation is rather simple.
It is basically a structure spanning a whole chunk of storage cells that indexes into those cells using a given hash function in an open addressing scheme.

This has several problems:

  1. It is attackable since the real hashes are only 32-bit wide.
  2. The hashmap is not aware of which storage cells or the whole chunk are actually in use and thus cannot do important clean-up operations that are required due to storage fees.
  3. Due to the problem stated in 2. the hash map also cannot iterate over its elements.

We need an improved version of the storage::HashMap that fixes all of the above problems. The problems listed as 2. and 3. can easily fixed by introducing an internal storage::Vec that keeps track of all used keys of the hash map. This way the hash map keeps track of its keys and thus also track of its used storage cells since its can easily map from those keys to the actual cells.

The hard part is how we can fix 1 and we have not yet come up with a proper way of doing that. The real source of the problem lies in that our hashes are only 32-bit wide. An attacker can easily compute 32-bit hashes and attack the open addressing based probing of the hash map. Without fixing this the storage::HashMap can only be used in situations where callers cannot control the keys.

Maybe there exist some other probing mechanisms that are more robust against attacks than the currently used quadratic open addressing probing mechanism.

Proposal

struct HashMap<K, V> {
    /// Vector storing the keys of the hash map.
    keys: storage::Vec<K>,
    /// The distributed values of the hash map.
    values: storage::SyncChunk<Entry<V>>,
}

struct Entry<V> {
    /// Index of the hash maps `keys` array.
    key_id: u32,
    /// The actual value.
    value: V,
}
@Robbepop
Copy link
Collaborator Author

Implemented by #311. Closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ink_storage [ink_storage] Work Item
Projects
None yet
Development

No branches or pull requests

2 participants