Oskar writes: > The DataLength includes all the control characters and alike. This is for > abstractions sake, DataLength is used by the connection layer to know how much > to read of the socket, it shouldn't have to deal with control bytes and alike > (except for being able to interrupted) when things go bad.
That makes sense. I think Adam may need to clarify the SVK/KSK section where he said, "The data is in one large part DataLength bytes long and followed a single control byte." This makes it sound like DataLength does not count the control byte in this case, which is probably not right. > > If there are fewer than 21 bytes left in the last block, that would be > > malformed. I guess you should just pass the data through and then send > > a 1 to indicate bad data. > > There is no hash following the last block, of course. But if the total length > of data should run out while you are reading a hash (less then 21 bytes after > and end of part), then it is indeed broken and you should send a 1. Yes, I was wrong about this. As I count it, at the beginning of each block, there should either be >= PartSize+23 bytes left, or <= PartSize+1 bytes left, never anything in between. In the second case we are on the last block. (The reason for ">= PartSize+23" is, PartSize+21 for the next-to-last block, plus at least 1 data byte in the last block, plus 1 control byte for that block.) We can actually do this calculation as a "sanity check" on the DataLength before beginning transmission. Datalength % (PartSize+21) should be >=2 and <=PartSize+1. If it's not we can abort right there. We don't need to actually check it on each block. (Of course if the stream closes early we need to do something about that, too.) > BTW, Hal, as you noticed I decided to go with your second proposed model for a > hash that can be verified part by part. Adam called it a "progressive hash", > is > that the official name? The authors don't seem to give it a name; they just call it their "offline scheme" (meaning that the signature is computed offline ahead of time). The paper is called "How to Sign Digital Streams" so you might call it a "stream hash", but "progressive hash" sounds OK. As a courtesy we should probably put the following reference in the code comments and/or spec docs: Gennaro, R and Rohatgi, P; "How to Sign Digital Streams", Advances in Cryptology - CRYPTO '97, 1997. Hal _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
