Better description of chain hash in stream signatures spec.

Reorder paragraphs (signing first, verification after), mention hash-by-hash
comparison of injections.

Author: ivilata

doc/arch-drafts/http-roll-sigs-1.md

@@ -98,17 +98,17 @@ The signature string for each block covers the following values (separated by nu
 
   - A **chain hash** (binary) computed from the chain hash of the previous block and the **data hash** of the block itself: for the i-th block, `DHASH[i]=SHA2-512(BLOCK[i])` and `CHASH[i]=SHA2-512(SIG[i-1] CHASH[i-1] DHASH[i])`, with `CHASH[0]=SHA2-512(DHASH[0])`.
 
-    Signing the hash instead of block data itself spares the signer from keeping the whole block in memory for producing the signature (the hash algorithm can be fed as data comes in from the origin).
+    The chaining precludes an attacker client from reordering correctly signed blocks for this injection.  SHA2-512 is used as a compromise between security and speed on 64-bit platforms; although the hash is longer than the slower SHA2-256, it will be seldom transmitted (e.g. for range requests as indicated below).
 
-    Using the data block hash instead of its data allows to independently verify the signatures without needing to be in possession of the data itself, just the hashes.
+    Signing the chain hash instead of block data itself spares the signer from keeping the whole block in memory for producing the signature (the hash algorithm can be fed as data comes in from the origin).
 
-    Including the previous signature in the hash allows to transitively verify the signatures of previous blocks by verifying the last signature, for example if signatures and hashes are processed before data itself (e.g. retrieved separatedly beforehand).
+    Including the previous signature in the hash allows the receiver to transitively verify the signatures of previous blocks by verifying the last signature, for example if signatures and hashes are processed before data itself (e.g. retrieved separatedly beforehand).
 
-    The chaining precludes the attacker from reordering correctly signed blocks for this injection.  SHA2-512 is used as a compromise between security and speed on 64-bit platforms; although the hash is longer than the slower SHA2-256, it will be seldom transmitted (e.g. for range requests as indicated below).
+    Using the data block hash instead of its data allows the receiver to independently verify the signatures without needing to be in possession of the data itself, just the hashes and signatures (e.g. retrieved separatedly beforehand).  It also allows comparing data of different injections by comparing data block hashes (previously verified).
 
 Please note that this inlining of signatures also binds the stream representation of the body to this particular injection.  Storage that keeps signatures inline with block data should take this into account when trying to reuse body data.
 
-Common parameters to all block signatures are kept the same and factored out to `X-Ouinet-BSigs` for simplicity and bandwidth efficiency.  Even if each block size could be inferred from the presence of a chunk extension, having the signer commit to a fixed and explicit size up front (with the exception of the last block) helps the consumer of the signed response to easily validate chunk boundaries and discard responses with too big blocks.  In the example, chunks are equivalent to blocks; this is the simplest implementation but it is not compulsory: blocks could be splitted in several chunks if needed (to save injector memory, since otherwise it cannot start sending a chunk as its size comes before data, and the last chunk may be shorter).  However, for the sake of simplicity, chunks should be aligned to block boundaries (i.e. blocks should consist of a natural number of chunks).
+Common parameters to all block signatures are kept the same and factored out to `X-Ouinet-BSigs` for simplicity and bandwidth efficiency.  Even if each block size could be inferred from the presence of a chunk extension, having the signer commit to a fixed and explicit size up front (with the exception of the last block) helps the receiver of the signed response to easily validate chunk boundaries and discard responses with too big blocks.  In the example, chunks are equivalent to blocks; this is the simplest implementation but it is not compulsory: blocks could be splitted in several chunks if needed (to save injector memory, since otherwise it cannot start sending a chunk as its size comes before data, and the last chunk may be shorter).  However, for the sake of simplicity, chunks should be aligned to block boundaries (i.e. blocks should consist of a natural number of chunks).
 
 If a client got to get and save a complete response from the injector, it may send to other clients the final response head straight away (i.e. skipping the initial signature or a trailer).