You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pirk.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/10/18 23:26:58 UTC
[jira] [Commented] (PIRK-74) Information leakage through
predictable failed hash keys
[ https://issues.apache.org/jira/browse/PIRK-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15587011#comment-15587011 ]
ASF GitHub Bot commented on PIRK-74:
------------------------------------
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 <ja...@apache.org>
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
----
> Information leakage through predictable failed hash keys
> --------------------------------------------------------
>
> Key: PIRK-74
> URL: https://issues.apache.org/jira/browse/PIRK-74
> Project: PIRK
> Issue Type: Bug
> Reporter: Jacob Wilder
> Assignee: Jacob Wilder
> Labels: security
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)