[bisq-network/bisq] Sign account usage (#2768)

[sqrrm]

sqrrm commented on this pull request.



> +    public Set<SignedWitness> getTrustedPeerSignedWitnessSet(AccountAgeWitness accountAgeWitness) {
+        return signedWitnessMap.values().stream()
+                .filter(e -> !e.isSignedByArbitrator())
+                .filter(e -> Arrays.equals(e.getWitnessHash(), accountAgeWitness.getHash()))
+                .collect(Collectors.toSet());
+    }
+
+    // We go one level up by using the signer Key to lookup for SignedWitness objects which contain the signerKey as
+    // witnessOwnerPubKey
+    public Set<SignedWitness> getSignedWitnessSetBySignerPubKey(byte[] signerPubKey) {
+        return signedWitnessMap.values().stream()
+                .filter(e -> Arrays.equals(e.getWitnessOwnerPubKey(), signerPubKey))
+                .collect(Collectors.toSet());
+    }
+
+    public boolean isValidAccountAgeWitness(AccountAgeWitness accountAgeWitness) {

Alice signs Bob's witness and Bob signs Alice's witness.

First level, trying to validaty Bob's witness, we find that it was signed by Alice. We then try to validate Alice's witness and during the second recursion we find that it's signed by Bob and will then try to validate it. Back to where we started in an infinite recursion.

Some leeway has to be given to the time stamps so an attack could be to create this pair and set the same date for both signedWitnesses.

I might well be missing something, and I don't think that's a risk during normal operation, just good to be safe and not add any attack vectors.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/2768#discussion_r277849971
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190423/f1309820/attachment.html>