Clarify Threshold Fingerprint Generation

[sappenin]

Issue by sappenin
Monday Jul 24, 2017 at 15:52 GMT
Originally opened as interledger-deprecated/java-crypto-conditions#63

---

While investing the Java test failures, I noticed that some of the ThresholdCondition's fingerprint generation results don't line-up with the TestVectors published in the CryptoCondition RFC project.

For example, looking at the fingerprintContents binary in 0008_test-basic-threshold.json, I see the following:

308184800102A17FA12B8020451FE15F16299D495993FE692DB989E56A5230A90476F77392A3CD3213C0733F810302040382020308A32780204DD2EA7F85B3EACB8F19058E8360955C32E74C124392A1F44660739709C539C38103040000A4278020799239ABA8FC4FF7EABFBC4C44E69E8BDFED993324E12ED64792ABE289CF1D5F8103020000

However, in the Java code, the following call...

BaseEncoding.base16().encode(CryptoConditionReader .readFulfillment(BaseEncoding.base16().decode(testVector.getFulfillment())).getCondition().getFingerprint());

yields the only following fingerprint value:

31AF10E168BA56AB38BEBF27065413C76896A6683C53D746F15A6438FD2A6C66

I think the source of the problem is that method ThresholdSha256Condition.getFingerprintContents() only looks at the subconditions when computing the fingerprint. When CryptoConditionsReader reads the binary of the fulfillment in the test vector, it yields a ThresholdFulfillment with one subcondition and two subfulfillments (one RsaSha256Condition and then one PrefixSha256Fulfillment and a Ed25519Fulfillment).

Is it possible that the implementation is wrong, and should somehow be considering the genrated Condition of each subfulfillment, too?

As it stands, the fingerprint in the TestVector seems to have much more data than anything I can generate using the Java library.

[sappenin]

See more discussions here:

• [crypto-conditions] Clarify Threshold Fingerprint Generation hyperledger-archives/quilt#4
• Threshold Cryptoconditions Clarifications rfcs/crypto-conditions#34