Re: 128bit RSA public key - time to break?

From: Peter Fairbrother (zenadsl6186@zen.co.uk)
Date: 02/24/03 

Date: Mon, 24 Feb 2003 01:49:02 +0000
From: Peter Fairbrother <zenadsl6186@zen.co.uk>

shane wrote
 
> In a P2P environment, currently each client generates a random 128bit
> number upon installation and uses that as its ID every session.

So it's just an identifier, and the data is sent unencrypted?

> Other clients that encounter this client keep a record of how much
> they have downloaded from this client and give it priority to upload
> to them if they encounter them again. Problem is, people just take the
> IDs of people that have uploaded a lot and use that to get preference
> over others.
>
> I was considering using this 128 bit number as a public key, so that
> file requests would need to be signed. (Note that various challenge
> request models are vulnerable to a man in the middle attack, and
> diffie-hellman would probably be too much overhead). I was also
> thinking about introducing some kind of micro-payment type scheme, but
> the details aren't clear.

128-bit ECC should be okay for identification, as the value of the
identification isn't that great. Is anyone going to bother spending
machine-years cracking a key just to get priority downloading files? It
shouldn't be too hard to implement, while retaining backwards compatibility.

You might give extra priority to those who use sig's, in order to get people
to use them.

Perhaps not ECC for a micro-payment system tho', depends on the value of the
payments. Is the system open to the public?

There's a lot of legal and investigative pressure on P2P networks, after
DMCA and it's equivalents outside the US. If you are sending legit data
unencrypted that doesn't matter too much.

Longer-term you might want encryption of the data in transit, better
identification and data integrity, and forward secrecy (by using ephemeral
keys). Is it worthwhile to build a system that doesn't do that? Modern boxes
can handle the crypto easily.

> Its still vulnerable to a man in the middle attack, and possibly
> replay attacks, but only by people that want to request the same
> file...
>
> But having read some of these comments, and read a couple papers on
> P2P reputation systems, I realise theres a little more to it :P

There is! :)

But there are some free open systems already, and it's an area of active
development. Might not one of those be better? Certainly easier. 

-- 
Peter Fairbrother

Relevant Pages

  • Re: breaking the model
    ... > The forms data then is in the Request object. ... HTTP Request; in this case, the form POST Request from the Page. ... client and server. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Resolving record with enumerated type
    ... In a CPU BFM package, ... because data goes in two directions (request from the ... from the server to the client), you'll need some way to orchestrate ...
    (comp.lang.vhdl)
  • Re: WSE 3.0 + UserNameToken without X.509 Cert/Kerberos + Signing + Encryption How?
    ... I still think that there is a lot of benefit for Secure Conversation ... message security and thefore it does not encrypt the message. ... between client and server using a UserNameToken that passes the UserName ... assuming the client request adds a proper UserNameToken... ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • RE: Problems with wsdl-generated proxy clients
    ... the client gets the same error on my xp ... meaning that the request was malformed. ... Microsoft MSDN Online Support Lead ... Looking at the IIS logs, I didn't even see the request in the log. ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: Performance Issue with Runtime Image
    ... >> the client, closes the connection, then dies. ... request before even accepting the next incoming connection. ... The client program is unaffected so presumably the server is ...
    (comp.lang.smalltalk.dolphin)
Loading