[
https://issues.apache.org/jira/browse/PIRK-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15588197#comment-15588197
]
ASF GitHub Bot commented on PIRK-74:
------------------------------------
Github user tellison commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/111#discussion_r84031817
--- 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 think this should be a separate field in ```Query```, e.g.
```setEncryptionHashKey()```. At present, I can repeatedly create
```EncryptQuery(QueryInfo, List<String>, Paillier)```, and it is
non-destructive on the ```Query```, just recalculating the expTable etc.
However, with this change the hashKey is overwritten, and extended on each
encryption of the query info, so repeated calls cause longer and longer hash
keys.
> 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)
