On 11/30/12 6:28 AM, "Emilia Kasper" <[email protected]> wrote:
>On Fri, Nov 30, 2012 at 3:17 PM, Ben Laurie <[email protected]> wrote: >> On 29 November 2012 15:55, Paul Lambert <[email protected]> wrote: >>> >>> >>> >>>>Structure of the Merkle audit proof: >>>> >>>> struct { >>>> opaque sha256_hash[32]; >>>> } MerkleNode; >>>> >>>> struct { >>>> Version version; >>>> LogID id; >>>> uint64 tree_size; >>>> uint64 timestamp; <------------------------------ not >>>>necessary >>>> uint64 leaf_index; >>>> MerkleNode audit_path<0..2^16-1>; >>>> TreeHeadSignature tree_head_signature; <--- contains >>>>timestamp >>>> } MerkleAuditProof; >> >> Not sure why you think the timestamp is not needed? > >I'm glad to see people verifying the sanity of the structures! > >I think I know where the confusion is - in TLS notation, >digitally-signed struct { } is a signature on the data in the struct; >it does not include the data itself. So TreeHeadSignature is a >signature over timestamp and other bits, but you need to include all >bits needed for verification separately. Thanks! Yes, I was confused by the struct usage as a definition of "input" to the signature Š just need to read the text an not just the code :-) Paul PS - seems like we should have better ways to define protocols Š PPS - still don't see that the audit path algorithm is correct, should be: k = k1 + largestPower2(k2-k1) PATH(m, D[n]) = PATH(m, D[k1:k]) : MTH(D[k:k2]) for m < k; and PATH(m, D[n]) = PATH(m, D[k:k2]) : MTH(D[k1:k]) for m >= k, > >>>> >>>> >>> >> _______________________________________________ >> therightkey mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
