This document summarizes a research paper presented at a conference from February 27-March 2, 2012 in San Francisco. The paper introduces a new efficient transitive signature scheme for directed trees. It builds on previous work on transitive signatures and proposes a new primitive called Hashing with Common Prefix Proofs (HCPP) to avoid recomputing signatures when elements are inserted. The construction provides a balance between the time to compute and verify signatures and proofs. Some open problems are also identified, such as improving the tradeoff and developing stateless transitive signatures for directed trees.
11. Pre/Post Order Tree Traversal
a
b
h
d
i j k
c
e f g
Pre order: a b c d e f g h i j k
Post order: c e f g d b i j k h a
12. Property of Pre/Post order Traversal
• Proposition [Dietz82]
a
b
h
d
c i j k
e f g
Pre order: a b c d e f g h i j k
Post order: c e f g d b i j k h a
13. Idea
a
b
h
d
c i j k
e f g
How do we avoid
Position 1 2 3 4 5 6 7 8 9 10 11 recomputing a lot of
Pre a b c d e f g h
h i i
j j
k k signatures when an
element is inserted?
Post c e f g
d d
b b
i i
j j
k k h
h a a
15. Trivial Order Data Structure
A Toy Example
Elements
-∞ d a e b c +∞
0 250 1000
500 675 750 875
Labels
16. a
b
d
c
Pre
a b c d +∞
-∞
0 500 750 875 937 1000
Post
c d b a +∞
-∞
0 125 187 250 500 1000
17. Trivial Order Data Structure
-∞ d a b c +∞
0 250 500 750 875 1000
New CRHF! It allows to:
• compress the strings
• efficiently compare them from their hashes
33. Conclusion and Open Problems
• Efficient transitive signature scheme
for directed trees
• Possible to balance the time to compute
and to verify the proof
• Based on a general new primitive HCPP
• New constructions / applications for HCPP
• Can we improve the trade off?
• Stateless transitive signatures for directed trees
Notes de l'éditeur
IDEAThisisjointworkwith Alejandro HeviaTODODetailsintroDetailsResultsDetailsTradeoffDetails IDEA (construction, slide 13)
IdeasSign a graphGraphishugeGraphisdynamic
IDEASExplore trivial solutions (usingstandard digital signatures)1st solutionThesignersignseachedge => O(nk) bits => OK forsignerbutunefficientforverifier2nd solutionSignersignseachpath => worst case mayhaveto compute $n$ signatureswhenadding a node (think of a treewith a new root)OK forverifierbutunefficientforthesignerCan we do better?
IDEAYes we canMicali / Rivest introducedthe concept of transitivesignaturesCombine edgesignaturewithoutsecretBest of bothworldsSignersignsonlytheedgesPathsignatureremain of constantsizethankstotheCombiner
IDEAWhat can we do?Give upTrytotackle a simplerproblemlikesigning a directedtreeWhy? Stillinteresting (theory) and can lead tosomeapplicationsmilitarychain of command: provesomeofficerisundertheorders of a general
IDEAFirstworkbyYiSize of signature: n log (n log n) bits =>improves trivial solutionsSecurity basedonspecial RSA relatedassumptionNevenReduces thesizeto n log n bitsSimplersolution and complexityassumption
IDEAAdversaryasksthesignertoinsert and signdynamically new edgeonthegraphExampleAdversarywinsif he can output a validsignaturefor a paththatisoutsidethetransitiveclosureHerethetransitiveclosureis in blue (edge in plain and dots). A winsif (B,E) has a validsignaturebecause (B,E) isoutside G*
OJO! DIFICILOurconstructionreliesonthe pre/post ordertreetraversal. In a preodertreetraversalwevisitfirsttherootthenwetraverserecursivelythefirstchild, and thenwetraversetheotherchildren. In a post ordertreetraversalwetraversethefirstchild, thentheotherchildren and finallywevisittheroot at theend.IDEADepthfirsttraversalFirstgodownthetree, thenvisitthesiblingsSeveralways of doingthat: pre order / post orderDepthfirsttraversal pre ordertraversalVisittheroot and thenrecursively, traversethefirstchild, secondchild and so onDepthfirsttraversalbutwritedownthenodewhenvisitedforthefirst timeDepthfirsttraversak post orderTraverse (recursively) thefirstchild, thesecondchild and so on and thenvisittherootDepthfirsttraversalbutwritedownthenodewhenvisitedforthelast timeExample
IDEADietzpropertycharacterizestheexistence of a path in thetreegiventhe pre/post orderlistEg: b <(pre) g and g<(post) b
Notes(O) So thepreviouspropertymaygiveusan idea(1) Whynotconsiderthe pre and post orderlist as tocheckfortheexistence of a pathForexamplewecouldsign a messageformedbythename of thenode, its position in the pre-orderlist and its position in the post orderlist. Thenwepublishthesesignervalues and a verifierwillconvinceherselfthatindeedthereis a pathifthesignature are valid and Dietzconditionissatisfied.Howeversomethingbadhappenswhenweinsert a new edge (2). A lot of positions forthenodeshavechanged. (3) This mean thesigner has still a lot of work and thismayalsoraisesomesecurityissues as thecombinercould replay someoldmessages.Theotherremainingoperations (4) (lookingforsignedmessage) , (5) checkingsignatures and Dietzcondition are fineSo howtoweavoidrecomputing a lot of signatureswhenanelementisinserted?
NotesThepreviousissueissolvedbywhatwecallanorder data structureThe idea of such data structureissimplytoallowdynamicinsertion of elements and efficientcomparison of thoseelementsItwasalsoproposedbyDietz in thesamepaper.Assumethereis a total orderontheelementsthere are twooperationsODInsert(X,Y) thatreturnsanelement Z whichlies in between X and YCompare(X,Y) returs True iff X islowerthan Y wrtthe total order.
NotesExampleInsert a right in the middle of –inf and +infInsert b between a and +inf…N successive insertions may lead to cut size of the universe by a half each time. Our universe must be of size 2^n => n bits to encode each label for an element
NotesGiventhis simple ODDatastructurewe are readyto describe thebasicconstruction…
NotesTosummarizeWestill use standard digital signaturesWeimprovedNeven’ssignaturesizefor a pathby a factor of (log n)In thefollowingwewillseehowtoshrinkthesize of thesignatureusing a new CRHF whichwillallowusto compare efficientlystringsthroughtheir hashes
Thisiswhat I will describe next: hash functionsthatenableproofsforcommonprefix
Hereisthe ideaA and B share a commonprefixuntil position 4Alice wantstocheckifthisis true (1)Butfirstthestrings are hashed (2)So whatwewantis (3)A CRHF withproof so thatbysendingthe hash values and somecertificate (4) Alice can be convincedthat A and B are equal up to position 4 (5) byrunning a verificationalgorithm
Thesecuritydefinitionis quite straightforwardAdvisgiventhepublickeywhichcorrespondsto a randomrepresentant of the hash familyAdvwinsif he can compute strings A,B anindex i and a proof Pi suchthattheverificationpassesdespitethat A and B are differentuntil position i.Observe thisdefinitionimpliescollisionresistance: just set i=n in thedefinition.
Ourconstruction uses bilinearmaps and itssecurityreliesonthe n-BDHI assumptionintroducedbyBoneh and Boyen.Thisassumptionsaysthatgiven (g,g^s, g^(s^2),…,g^(s^n)) where g is a generator of group G and s israndom in Z_p, it’shardto compute e(g,g)^(1/s).
Let’s describe our hash functionSetup => generatestheparameterforthe n-BDHIassumption. Thisparameteristhepublickey (implicitdescription of our hash function)Evaluatingthe hash function of a binarystring M consists of multiplyingallthe g^(s^i) wherethereis a one in theith position of string ME.g: M = 1001 then H(M) = g^s g^{s^4}
Let’sseehowto compute and checkproofsAssumestrings A and B are equal up to position 5.Firstwe compute Delta, thequotient of H(A) and H(B). We note thatthe factor until s^5 cancelsout so we can interpret Delta as theproduct of theg^s^jC[j] where C isanarrayfilledbyzeros, 1s and -1s and suchthatthefivefirstvalues are zeros.
So hereisour Delta againThe idea to compute theproofistoshiftthisarraybackwards in $i$ positionsConcretelywe do itbycomputing Delta^{s^{i+1}} whcih can be done withoutthesecret $s$ becausethe $i$ firstvalues of $C$ are $0$.So in thisexamplewehave Pi = ….Tochecktheproofweshift forwards Pi usingthebilinearmap and checkthatweobtain back Delta
I’llgivesomeintuitionaboutthesecurityproofAssumeAdvmanagestoprove A,B share a commonprefixuntil position 3, althoughthesestringsdiffer at thissame position. As theproofgivenbytheadversary leads to a successfulverificationthismeansimplicitlythat Pi isequalto Delta^(1/s^4). We can seethatfromthisvalue g^{-1/s}g^sg^{s^2} we can break the n-BDHI assumption.
This hashfunction has anadditionalinterestingproperty: itis incremental. Thismeanswe can updateefficiently hash valueswithouthavingto hash thewholepreimage. Forexampleifwehave A=1000 and B=10001, I can compute H(B) using H(A) and a groupmultplication.
Recallthatwewantto be ableto compare stringsorvaluesthroughtheir hashes. So howtowe compare strings once we are abletocheckthewhethertwostrings share a commonprefixuntil a given position? Simplybyobservingthat A<B …..E.g.: …
Solet’sseenowhowwe can makeeverythingworktogether.
Indeedwe are almost done, butthereisstill a technicaldetail. Ifwe use the trivial orderdatastructurewiththe new hash function, the time thesignerwillneedwheninserting a new nodewill be O(n). Thereasonisthatthe new labelreturnedbytheODDatastructurewill be quite differentfromalreadycomputedones.So in ordertosolvethisissuewe are goingto use a new orderdatastructure so that a new label Z correspondingtoaninsertionbetween X and Y will share every bit exceptonewith X or Y.ARG!!!
HereishowthisODStructureworks. We use a binarytreewiththefollowingconvention. Given a node, allthenodesbelongingtotheleftsubtree are smallerthan X and allthenodesbelongingtotherightsubtree are biggerthan X. Thenweassociatethe symbol $0$ for a leftedge and $1$ for a rightedge. And a labelfor a nodewill be theconcatenation of the 0 and 1 fromroottothenode. Comparingtwolabelswillconsistssimply in comparingthemthroughthelexicographicalorder.Hereisanexample.You can convinceyourselfitis incremental
Justtoclarify a bit let’sseethe full construction at work.
BeforeconcludingI’llgive a fewwordsaboutthetradeoff.First idea: use analphabet of size 2^k instead of $0,1$. Reduce thenumber of cryptographicoperationsby a factor of kDivide initialstring in chunks of size (n/k)^(1/lambda).Hash thesechunks, obtain a new symbol foreachchunk => new stringreducedby a factor of (n/k)^(1/lambda) (symbols). After lambda levelsweget a constantsize hash value.Provingcommonprefixonlyinvolves a chunk of size (n/k)^(1/lambda) at eachlevelbecausethepreviouschunks are implicitlyequals.Do notmentiondetailsAlphabetChunksOnlyneedto compute theproofforonechunk