[ 
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 <jacobwil...@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)

Reply via email to