[rc5] Blocks

Kevin van Haaren KvanHaaren at HNTB.com
Thu Oct 9 22:05:38 EDT 1997


Could probably hack a buff-out report file to contain false negatives.
Than submit via the same batch that grabbed the blocks.  easy.

Kevin

> -----Original Message-----
> From:	wooledge at kellnet.com [SMTP:wooledge at kellnet.com]
> Sent:	Thursday, October 09, 1997 8:34 PM
> To:	rc5 at llamas.net
> Subject:	Re: Re[2]: [rc5] Blocks
> 
> Eric Gindrup wrote:
> 
> >      It's not clear that the delay will be trivial.  Let's posit a 
> >      request-only client that requests 5 blocks per second.
> Currently, the 
> >      entire effort is completing ~20 blocks per second.  So this
> client can 
> >      tie up 20% of the outstanding keyspace.
> 
> One of us misunderstands the key recycling issue; I think it's you.
> (At least I hope it's not me. ;-)
> 
> When the keys have all been handed out, my understanding is that the
> main keyserver will then:
> 
>   1) Assemble a new keyspace of all the unchecked blocks (which are
> all
>      "outstanding"); and then
> 
>   2) Start handing them out randomly.
> 
> The only delay that will be introduced by an "attacker" who requests
> large numbers of blocks is the extra burden placed on the key servers.
> The clients will still get their keys and/or generate random ones;
> most
> of them probably won't even notice any problem (depending on how long
> it takes for the new keyspace to become ready).
> 
> >      the malignant 
> >      client can (possibly) request the block containing the key
> (~20%) and 
> >      make it appear that no block contains the key (because there
> are no 
> >      blocks that are neither reported nor assigned).  This will
> necessitate 
> >      re-searching the entire keyspace.
> 
> This is a different issue.  An attacker who *falsely reports checked
> blocks* is very different (and much more serious) than one who simply
> fetches blocks and never returns results for them.
> 
> Anyone can fetch blocks in large numbers, simply by running the client
> in a shell/batch loop.  It doesn't take any hacking skills whatsoever.
> 
> Reporting false negative results requires knowledge of the
> client-server
> protocol (not published).  That would require some sort of reverse
> engineering, and/or programming skills.
> 
> -- 
> ------------                  Greg Wooledge
> -------------
> -------                   wooledge at kellnet.com
> -------
> ---              http://kellnet.com/wooledge/main.html
> ---
> ----
> To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe
> rc5' in the body.
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list