[
https://issues.apache.org/jira/browse/PIRK-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592564#comment-15592564
]
ASF GitHub Bot commented on PIRK-74:
------------------------------------
Github user jacobwil commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/111#discussion_r84345174
--- Diff:
src/main/java/org/apache/pirk/querier/wideskies/encrypt/EncryptQuery.java ---
@@ -178,11 +217,14 @@ public Querier encrypt(int numThreads) throws
InterruptedException, PIRException
{
// Hash collision
selectorQueryVecMapping.clear();
- hashKey = queryInfo.getHashKey() + ++keyCounter;
+ hashKey = hashKeyBase + getRandByteString(10);
logger.debug("index = " + index + "selector = " + selector + "
hash collision = " + hash + " new key = " + hashKey);
index = -1;
}
}
+
+ // Save off the final hashKey that we ended up using
+ queryInfo.setHashKey(hashKey);
--- End diff --
I don't think there's any plausible situation in which the `QueryInfo`
object is used more than once in a single run of Pirk. Therefore, editing the
`QueryInfo` shouldn't be a problem. More than one operation on the same
parameters would be performed using multiple runs of the JAR with the same
backing properties files.
> 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)
