NextGen Peer to Peer - Progetto per un P2P anonimo

[spv42]

Io conosco poco C#, ma mi piacerebbe imparare!

Imparare sempre e comunque!

[aldonation]

Originariamente inviato da 71104

prima dovete riuscire a farmi capire qual'è il vantaggio nell'usare questo programma anziché eMule o DC++ perché vi giuro che leggendo il postone sborone (il primo) non l'ho capito

Il vantaggio è che le comunicazioni sono anonime...si utilizzerebbe I2P come layer anonimo sopra al quale costruire un P2P emule-like...dentro I2P invece di mandare messaggi ad un IP si mandano ad un ID crittograficamente sicuro passando attraverso altri computer...quindi diventa indistinguibile un semplice router da un client P2P, anche perchè I2P è una rete su cui passano anche richieste HTTP, SMTP, ecc...

[aldonation]

Originariamente inviato da spv42

Io conosco poco C#, ma mi piacerebbe imparare!

Imparare sempre e comunque!

In questo progetto cose da imparare ce ne sono moltissime...siamo sempre in cerca di gente disposta ad imparare e lavorare con noi...se sei disponibile manda un PM

[spv42]

Scusa l'ignoranza, ma cosa è un PM?

[aldonation]

Originariamente inviato da spv42

Scusa l'ignoranza, ma cosa è un PM?

Private Message -> Messaggio Privato

Oppure contattami su MSN...

[71104]

Originariamente inviato da aldonation

Il vantaggio è che le comunicazioni sono anonime...si utilizzerebbe I2P come layer anonimo sopra al quale costruire un P2P emule-like...dentro I2P invece di mandare messaggi ad un IP si mandano ad un ID crittograficamente sicuro passando attraverso altri computer...quindi diventa indistinguibile un semplice router da un client P2P, anche perchè I2P è una rete su cui passano anche richieste HTTP, SMTP, ecc...

aldilà di ogni cosa ricordati che il router a cui sei direttamente collegato quando ti connetti ad Internet (il primo della rete del tuo provider) invia e riceve esattamente quello che invii e ricevi tu; e se anziché un semplice router fosse un computer vero e proprio dotato di uno stack TCP/IP completo e con su il software necessario per interpretare tutti i protocolli necessari a ricostruire le tue operazioni di filesharing? il provider sa tutto di te, non c'è niente da fare.

l'unica cosa veramente utile a rendere mooolto difficile la ricostruzione del tuo "raw stream" di dati sarebbe un network driver che permette al pc di comunicare con l'esterno attraverso connessioni multiple contemporaneamente; non so se la cosa è teoricamente possibile in base all'attuale architettura TCP/IP, ma essere collegato a più router già al primo "livello di connessione" (chiamiamolo così) vorrebbe dire che per effettuare la ricostruzione sarebbe necessario analizzare N raw streams e fonderli in base ai timestamp dei singoli pacchetti, ed è una cosa praticamente impossibile perché farebbe nascere una marea di "e se..."

esempi:

e se il network driver di cui sopra scrive timestamp a cavolo?
(i router loggano aggiungendo i loro timestamp)

e se i router hanno gli orologi di sistema non perfettamente sincronizzati?
(si sincronizzano con un server del provider)

e se il network driver di cui sopra sfrutta connessioni a providers diversi?
(e mo te ce voglio )

c'è da dire che connessioni multiple significherebbero N accounts presso uno o più providers, e che non si può certo pretendere che l'utente abbia risorse finanziarie illimitate; ma si potrebbe organizzare il sistema in modo da condividere spese e connessioni tra N utenti. in tal caso tutta la questione assumerebbe la seguente forma: suddividere il flusso di dati in entrata e uscita con la connessione di un altro utente.

[aldonation]

Originariamente inviato da 71104

aldilà di ogni cosa ricordati che il router a cui sei direttamente collegato quando ti connetti ad Internet (il primo della rete del tuo provider) invia e riceve esattamente quello che invii e ricevi tu; e se anziché un semplice router fosse un computer vero e proprio dotato di uno stack TCP/IP completo e con su il software necessario per interpretare tutti i protocolli necessari a ricostruire le tue operazioni di filesharing? il provider sa tutto di te, non c'è niente da fare.

l'unica cosa veramente utile a rendere mooolto difficile la ricostruzione del tuo "raw stream" di dati sarebbe un network driver che permette al pc di comunicare con l'esterno attraverso connessioni multiple contemporaneamente; ma non so se è teoricamente possibile in base all'attuale architettura TCP/IP

Beh...chiaramente tutto il traffico viene crittografato proprio per questo motivo...dopo il key agreement non si vede + nulla...il provider se il traffico è crittografato non sa nulla...altrimenti basterebbe che qualche furbo dentro ad un ISP si mettesse a sniffare i numeri di carta di credito delle transazioni che vengono fatte online per racimolare milioni di euro...

Se vuoi documentarti sulla rete che useremo trovi tutto qua: http://www.i2p.net/how

[71104]

Originariamente inviato da aldonation

Beh...chiaramente tutto il traffico viene crittografato proprio per questo motivo...dopo il key agreement non si vede + nulla...il provider se il traffico è crittografato non sa nulla...

è tutta una questione di protocolli e loro interpretazione: se il tuo computer può decifrare quella roba può farlo anche il "router" attraverso il quale passa quella roba. "dopo il key agreement non si vede più nulla"? e perché, il tuo provider non lo vede il key agreement?

altrimenti basterebbe che qualche furbo dentro ad un ISP si mettesse a sniffare i numeri di carta di credito delle transazioni che vengono fatte online per racimolare milioni di euro...

mazza come la fai facile sai che una volta io sono entrato nei computers della NASA e della CIA e sono riuscito ad ottenere informazioni segretissime e hanno pagato fior di miliardi il mio silenzio?
infatti sono ricco

Se vuoi documentarti sulla rete che useremo trovi tutto qua: http://www.i2p.net/how

ti ringrazio, ci ero già arrivato tramite Wikipedia

[aldonation]

Originariamente inviato da 71104

è tutta una questione di protocolli e loro interpretazione: se il tuo computer può decifrare quella roba può farlo anche il "router" attraverso il quale passa quella roba. "dopo il key agreement non si vede più nulla"? e perché, il tuo provider non lo vede il key agreement?

Se ti metto un link per favore leggilo prima di postare di nuovo...

TCP connections are currently negotiated with a 2048 Diffie-Hellman implementation, using the router's identity to proceed with a station to station agreement, followed by some encrypted protocol specific fields, with all subsequent data encrypted with AES (as above).

Cmq non vedo come mai - visto che continui a ridicolizzare questo network - non vai sul loro forum a dir loro di cambiar mestiere. Una persona non dovrebbe mai ridicolizzare il lavoro altrui...

mazza come la fai facile sai che una volta io sono entrato nei computers della NASA e della CIA e sono riuscito ad ottenere informazioni segretissime e hanno pagato fior di miliardi il mio silenzio?
infatti sono ricco

Certo, ma questo non vuol dire che tu sia capace di craccare una connessione SSL...

ti ringrazio, ci ero già arrivato tramite Wikipedia

Ok...la prossima volta non mi sforzo...

Se poi devi postare tanto per il piacere di dare addosso a qualcuno, senza prima documentarti e senza la necessaria serietà e apertura mentale, ti invito a cambiare atteggiamento...sono disposto a discutere solo con persone civili ed educate che non mi guardino dall'alto in basso...grazie...

Ciao

[71104]

Originariamente inviato da aldonation

Se ti metto un link per favore leggilo prima di postare di nuovo...

bla bla bla... hai presente il nostro fatidico router, quello che sta dall'altra parte della tua linea telefonica, quello che viene subito dopo di te, quello che si interpone tra te e la rete del provider, qualunque esso sia? fai finta che al posto suo ci sei tu: non cambia nulla.

il tuo programma può usare gli algoritmi più intelligenti della Terra progettati di fresco da John Nash, ma finché si appoggia su TCP/IP e finché si suppone che un'altra stazione debba essere in grado di interpretare la comunicazione non esisterà modo di impossibilitare in maniera assoluta l'interpretazione da parte del provider.

sai contraddirmi nei miei stessi termini? i tuoi link no.

- visto che continui a ridicolizzare questo network -

ma io non ridicolizzo nulla, sei tu che ti fai i film; io suppongo che gli autori sappiano bene cosa hanno fatto, il dubbio è se lo sai anche tu (o se non capisci cosa sto dicendo)

Cmq non vedo come mai non vai sul loro forum a dir loro di cambiar mestiere.

nel tuo film lo farò

Una persona non dovrebbe mai ridicolizzare il lavoro altrui...

nel tuo film si, altrimenti non viene a crearsi lo spannung

Certo, ma questo non vuol dire che tu sia capace di craccare una connessione SSL...

come no, non te l'ho detto? le informazioni segrete sono riuscito ad ottenerle perché un loro agente che si trovava in Asia le stava comunicando al server centrale tramite SSL; solo che non sapevano che io avrei assistito anche all'handshaking

Se poi devi postare tanto per il piacere di dare addosso a qualcuno, senza prima documentarti e senza la necessaria serietà e apertura mentale, ti invito a cambiare atteggiamento... sono disposto a discutere solo con persone civili ed educate che non mi guardino dall'alto in basso...

abbè, sto film ha rotto dai, è un trionfo di luoghi comuni...

grazie...

quando vuoi

[71104]

di solito adesso arriva la parte in cui perdo io la flamewar perché l'altro si decide finalmente a rispondermi nei miei termini; vediamo che succede stavolta...

[VICIUS]

Se dovete discutere fatelo da persone civili. Niente flame per favore o sospendo qualcuno

ciao

[aldonation]

Quindi stai dicendo che se io faccio una transazione https il provider può vedere che cosa sto mandando - in chiaro - al server? Se hanno un bel computer quantistico lo possono fare...ma per ora non mi sembra così semplice rompere AES...se invece stai sostenendo che il provider può leggere i dati grezzi che passano tramite i loro router hai ragione...ma che può fare se è tutto criptato? un attacco man-in-the-middle durante il key agreement? La rete è fatta apposta per non soffrire di questi problemi...il provider si troverà solo un sacco di dati completamente inutili...
E poi se devi dire che il provider può fare un attacco, dì almeno di che tipo...se sei troppo vago non ci si capisce...

[71104]

Originariamente inviato da aldonation

Quindi stai dicendo che se io faccio una transazione https il provider può vedere che cosa sto mandando - in chiaro - al server?

no; ma può decifrarlo perché conosce tutti i metodi di cifratura e le chiavi che state usando; li conosce perché li ha letti in chiaro quando ve li siete spediti (e perché conosce i protocolli che state usando).

Se hanno un bel computer quantistico lo possono fare...

sempre nel tuo film, che però ormai ha assunto tutto l'aspetto di uno di quei filmetti americani di serie B coi ragazzini undicenni geniali che programmano sistemi operativi grafici in Assembly e gli danno i nomi più sboroni

se invece stai sostenendo che il provider può leggere i dati grezzi che passano tramite i loro router hai ragione...ma che può fare se è tutto criptato?

decriptare?

un attacco man-in-the-middle durante il key agreement? La rete è fatta apposta per non soffrire di questi problemi...

e come farebbe?

E poi se devi dire che il provider può fare un attacco, dì almeno di che tipo...se sei troppo vago non ci si capisce...

secondo me tu non leggi quello che scrivo... avrò anche omesso la denominazione tecnica del tipo di attacco, ma a che ti serve quando te l'ho descritto per intero?

PS: sei un maniaco dei puntini di sospensione: sei peggio di cionci quando scrivi

[roby1483]

Originariamente inviato da 71104

no; ma può decifrarlo perché conosce tutti i metodi di cifratura e le chiavi che state usando; li conosce perché li ha letti in chiaro quando ve li siete spediti (e perché conosce i protocolli che state usando).

Il provider non conosce le chiavi, quando viene fatto l'handshake il client codifica la chiave simmetrica scelta per tutta la sessione con la chiave pubblica del server così che solo il server con la sua chiave privata possa decifrarla. Il provider può conoscere la chiave pubblica del server, come tutti del resto, ma non non può usarla per decifrare il messaggio.

Il progetto non mi sembra niente male anche se al momento non so se potrò unirmi, seguo comunque il thread ed eventualmente mi aggregherò in seguito se posso.

[71104]

Originariamente inviato da roby1483

Il provider non conosce le chiavi, quando viene fatto l'handshake il client codifica la chiave simmetrica scelta per tutta la sessione con la chiave pubblica del server così che solo il server con la sua chiave privata possa decifrarla. Il provider può conoscere la chiave pubblica del server, come tutti del resto, ma non non può usarla per decifrare il messaggio.

in che modo il client crea una chiave di codifica e di decodifica partendo dalla chiave pubblica fornita dal server? la stessa cosa che fa lui non può farla il software del provider?

[roby1483]

Originariamente inviato da 71104

in che modo il client crea una chiave di codifica e di decodifica partendo dalla chiave pubblica fornita dal server? la stessa cosa che fa lui non può farla il software del provider?

Si ma visto che il processo è basato su numeri "casuali" è molto improbabile che il provider generi la stessa chiave che genera il client.

[71104]

Originariamente inviato da roby1483

Si ma visto che il processo è basato su numeri "casuali" è molto improbabile che il provider generi la stessa chiave che genera il client.

e l'altra parte in comunicazione invece 'sti numeri casuali come fa a saperli? non deve generare anch'esso una chiave per codificare e decodificare?

[k0nt3]

secondo me ha ragione 71104 (stavolta ) il provider può benissimo intercettare tutte richieste di connessioni cifrate e fare da ponte tra il server e il client (facendo da client per il server e da server per il client). e con i tempi che corrono può essere che già lo fanno
l'unica speranza che avete per essere certi dell'anonimità è utilizzare una rete che non passa dal provider.. come potrebbe essere una grossa rete wifi decentralizzata (al momento poco proponibile) e/o una rete appositamente creata come può essere questa (forse ancora meno proponibile ma spero che verrà proposta )

so che esistono algoritmi che usano il concetto di chiavi pubbliche e private, e algritmi di codifica/decodifica asimmetrici (primo fra tutti rsa). quindi un client genera chiavi private, che servono a decrittare, e una chiave pubblica, per crittare. quindi il provider trasmetterà all'altro client la chiave pubblica, ma nè lui ne l'altro client potranno decrittare ciò che hanno crittato conla chive pubblica, finchè le chiavi private non le sanno.

[SOFFIARE_SUL_FUOCO_MODE_ON]
nervosetto eh, 71104?
[SOFFIARE_SUL_FUOCO_MODE_OFF]