[p2p-hackers] Homomorphic hashing and fountain codes - implementation question

[Nick Johnson]

Hal Finney wrote:

>So you'd first AONT transform the file, which would randomize the values;
>then you'd use this q for the coding, which could overflow in principle
>but not in practice.  In the end, after reconstructing the file, you'd
>reverse the AONT transform.
>  
>
Interesting idea - thanks for suggesting it. I'd have to consider 
further to decide if the extra complexity in the protocol is worth the 
size and computation relieved by not having to store the 257th bit.

>I would suggest a p of more like 2048 bits, with a 256 bit q.  There have
>been a number of proposals for theoretical factoring machines, most
>of which could be adapted at somewhat greater cost to finding discrete
>logs.  Many people today are worried that 1024 bit keys can no longer be
>considered extremely safe.  Particularly if you use the same p throughout
>the system, it would be wise to use something a little bigger.
>  
>
This could be a problem: 1024 bit hashes are already pretty large, 2048 
bit would be substantially worse. I was, in fact, hoping it would be 
practical to use a smaller prime!

Should someone successfully break the 1024 bit hash, what would the 
consequences be? Could they compute collisions for a single block (a 
break that is meaningless, since using the per-publisher model the only 
one setting blocks is the publisher, who can compute collisions with 
ease anyway - a backup file-wide SHA-1 hash will act to prevent this), 
could they conduct a preimage attack against a single block, or could 
they create collisions and preimage attacks for any file published with 
that K? Worse, could they compute collisions for every file published 
using that p?

Thanks,

Nick Johnson