GitHub user jacobwil opened a pull request:
https://github.com/apache/incubator-pirk/pull/111
[PIRK-74] Close Hash Key information leak
From the [JIRA issue](https://issues.apache.org/jira/browse/PIRK-74):
> Given that âIf we have hash collisions over our selector set, we will
append integers to the key starting with 0 until we no longer have
collisionsâ if an attacker sees that the hash key is one with integers on the
end and the space for selectors is well defined (or the attacker has a hunch
about what the actually-selected selector space looks like) they could feed
either all or subsets of their probable-selector pool into the keyed hash
function given keys with lower integers and look for collisions. The higher the
key has been incremented the more leaks possible (itâs unlikely the same two
selectors caused collisions with different hash keys).
Also uncovered and fixed a bug where the replacement hash key selected
after a collision wasn't saved back to the QueryInfo object.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jacobwil/incubator-pirk PIRK-74
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-pirk/pull/111.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #111
----
commit db2e69ed5ab967da116896f8f902f0b3eaf2baf6
Author: Jacob Wilder <[email protected]>
Date: 2016-10-18T21:59:14Z
Knowledge of the final hashkey used no longer allows an attacker to attempt
to guess which selectors collided in previous hashkey attempts
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
