[
https://issues.apache.org/jira/browse/PIRK-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15612008#comment-15612008
]
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_r85344830
--- Diff:
src/main/java/org/apache/pirk/querier/wideskies/encrypt/EncryptQuery.java ---
@@ -156,10 +149,23 @@ public Querier encrypt(int numThreads) throws
InterruptedException, PIRException
return new Querier(selectors, paillier, query, embedSelectorMap);
}
+ /**
+ * Use this method to get a securely generated, random string of
2*numBytes length
+ *
+ * @param numBytes How many bytes of random data to return.
+ * @return Random hex string of 2*numBytes length
+ */
+ private String getRandByteString(int numBytes)
+ {
+ byte[] randomData = new byte[numBytes];
+ RandomProvider.SECURE_RANDOM.nextBytes(randomData);
+ return Hex.encodeHexString(randomData);
+ }
+
private Map<Integer,Integer> computeSelectorQueryVecMap()
{
- String hashKey = queryInfo.getHashKey();
- int keyCounter = 0;
+ String hashKeyBase = queryInfo.getHashKey();
+ String hashKey = hashKeyBase + getRandByteString(10);
--- End diff --
I will swear up and down that I already made this change and then wiped it
out with a `git checkout` after I massively broke the codebase with an
ill-fated IntelliJ assisted refactor. Putting it back now.
> 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
> Fix For: 0.3.0
>
>
> 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)
