On Mon, 19 Feb 2001 hal at finney.org wrote: > Oskar wrote: > > Hal, if you have time I would still appreciate some comments on the > > announcement proposal: > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/docs/announcement.txt?rev=1.1&content-type=text/plain&cvsroot=freenet > > I need to think about it some more, but I did see one possible attack. > Alice and Bob1 can collude to control some portion of her initial key > value (the x in the protocol), perhaps 20 bits or so. Luckily the fix > is easy. <> > Actually there's a really easy fix for this. You just use concatenation > rather than addition for the hash chaining. That is, instead of doing > CommitValue = hash(xi + CommitValue) as now, instead do CommitValue = > hash(xi || CommitValue) where || is concatenation. Hash functions like > SHA can take any size buffer as input, so there is no difficulty in giving > it a 320 bit input in this case (assuming the xi values are 160 bits). > > Given that the hash is one-way, this effectively commits to the 320 > bit input and therefore it commits to both xi and the old CommitValue. > In this way the final CommitValue is a true commitment to all the xi > values, which is what you want.
It's an artifact of coding too much java - I use + as concat when referring to arrays. I was actually quite aware that using a mathematical operation that was not one way would lead to this sort of problem - though a specific example as above is an interesting testiment to why. Sorry for my sloppy notation. > I'll let you know if I have any other comments - > > Hal > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://www.uprizer.com/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl at freenetproject.org http://www.uprizer.com/mailman/listinfo/devl
