[Mixminion-it] Un nuovo iscritto ed una notizia
Tommaso Gagliardoni
tommaso a gagliardoni.net
Ven 12 Nov 2010 16:14:01 CET
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ciao a tutti, eccomi qui :) premetto che sono stato iscritto a questa
lista con l'inganno e la coercizione quindi non fate troppo affidamento
su di me :P e non vorrei vi siate fatti grosse aspettative, non e' molto
"sensazionale" come notizia.
Comunque, brevemente: e' da un po' di tempo che mi ronza in testa l'idea
di provare a implementare mixminion come plugin per Freenet, per ragioni
varie delle quali ebbi anche modo di discutere con un paio di voi
all'ultimo convegno e-privacy a Firenze. La questione e' abbastanza
tecnica perche' Freenet e' incasinato come pezzo di software e io per
primo non ci sono dentro al 100%. Ma un paio di giorni fa si sono
verificate condizioni di tempo/voglia/orgone favorevoli e sono andato
nel canale IRC degli sviluppatori di Freenet a tastare un po' il
terreno. Il risultato e' che sono al momento impegnato in uno scambio di
textwall con Matthew Toseland (l'autore di Freenet) per discutere la
fattibilita' della cosa. Sembra molto interessato, e la tesi che si sta
delineando e' che probabilmente e' fattibile, almeno in una certa
misura, una volta risolti alcuni problemi di cui Freenet al momento soffre.
Chiaramente se anche la cosa andasse in porto servirebbe comunque
qualcuno che scriva questo mitologico plugin, e se non sbaglio
attualmente siete voi che sviluppate ufficialmente il progetto Mixminion <.<
Vi allego alcuni tratti salienti del discorso per spiegarmi meglio, ma
serve di avere piu' o meno l'idea di cosa sono Freenet e Freemail:
http://freenetproject.org/freemail.html
Vi tengo aggiornati se ci sono novita' degne di nota.
Ciaps e buon lavoro!
On 11/09/2010 05:15 PM, Tommaso "Sanata" Gagliardoni wrote:
> On 11/05/2010 08:59 PM, Matthew Toseland wrote:
>> Hi, you were talking about Freenet and next generation email
>> remailers. I wonder what your thoughts are?
>>
>> [...]
>
> [...]
>
> It would work more or less this way: a Freenet user installs both
> Freemail and this hypothetical plugin - let's call it PLUG for
> convenience - on her node and configures PLUG either as:
>
> - a local node
> - an exit node
> - both
>
>
>
> In "local mode", PLUG offers an email-client-like interface where a
> user who wants to send an anonymous email to a public, outside world
> address inserts:
>
> . the public address
> . the message/attachments
> . an (optional) freemail address for a reply
> . (optional) other cypherpunk-like options like manual time delays
> etc.
>
> When this is done, PLUG just forwards this informations to the
> Freemail address of a randomly chosen exit node through Freenet (read
> more for a possible idea on how to randomly select an exit node).
>
>
>
> In "exit mode", PLUG acts basically as a Freemail-SMTP bridge,
> fetching emails from a Freemail account and delivering them towards
> standard "outside world" email accounts. This means that PLUG checks
> a local Freemail address, and when it receives a message formatted as
> above, it relays the message to the outside world via a local SMTP
> server.
>
>
>
> To select randomly a PLUG exit node we could employ many different
> strategies, but the following avoids the need for a public address
> list (which can be used to pre-emptively blacklist exit nodes, as in
> the case of Tor):
>
> . every PLUG exit node creates a local, temporary Freemail account,
> something like exitnode@[lot-of-unique-alphanumeric-stuff].freemail)
> . then it publishes that address in a list on a public freesite
> . a PLUG local node in need for an exit node address just picks up
> one from that list at random and uses that
> . the exit node "revokes" that Freemail address and generates another
> one after a certain time (or even after a single use maybe, but
> one-time addresses would probably be unreliable due to high
> latency)
> . every exit node can simultaneously publish more than one address,
> according, i.e. to the available bandwidth and/or the owner's
> preferences. It would suffice to scramble the addresses by
> inserting them in random positions of the list at different times
> (so to avoid "clustering" correlations).
>
> Note that an attacker could always create a list of known exit nodes
> by observing the origin of the anonymous emails, but at no given time
> a complete, public, Tor-like list would be available.
>
>
>
> BENEFITS:
>
> - fully automatic, more practical than managing a Mixminion node
> - less code to write from scratches
> - no central directory servers
> - most importantly, we would merge together the two distinct pool of
> users (Freenet users and remailers users) to grow a bigger network
> ( = Good)
> - I think it would also be possible to implement a way to allow
> communication in the other way, that is, writing from the
> "outside world" to a Freemail address, but this would probably imply
> to devise also an "entry mode" for PLUG
>
>
>
> DISADVANTAGES:
>
> - risks for the owner of an exit node would be the same as running a
> Mixminion node (big warning here), except maybe for a slightly
> lesser chance to be blacklisted
> - same spam issues as Mixmaster/Mixminion: it would probably be
> necessary to delegate spam blacklisting to single exit nodes
> (except that, by imposing limits on the number of temporary
> address created per hour, it would be impractical to do spam with
> PLUG, but it would always be possible to consume available
> addresses very fast in a DoS attack)
> - probably slightly less secure than Mixminion in regard to traffic
> analysis (but more than Tor-like solutions I guess)
On 11/09/2010 07:44 PM, Matthew Toseland wrote:
> Well, a non-scalable approach has some clear advantages too: You can
> do onion routing, and given enough traffic, this means it works
> unless all 3 nodes are compromised. The main threats are: -
> Insufficient capacity for the traffic levels. - Taking out or
> blocking individual nodes. - Taking over the directory servers. -
> Sybil attacks: if an attacker is able to submit a large number of
> nodes, without the clients knowing that they are connected, then he
> can compromise a large proportion of routes. So security comes down
> to whether you can trust and validate the servers, or make it hard
> for an attacker to do Sybil successfully.
>
> Attacks on Tor generally rely on traffic analysis (which doesn't
> apply to Mixmaster because of delays for mixing and ideally cover
> traffic), and route selection / Sybil attacks (the last item). Or on
> blocking the whole system by blocking each node, as some countries
> do.
>
> [...]
>
> IMHO it would be possible. It might be less secure than Mixmaster -
> but the issues I've listed suggest that the situation may mean that
> Mixmaster's theoretical security may not be practical security.
>
> [...]
>
> Okay so your proposal is to implement the mixnet layer over Freenet?
> Interesting idea - the nodes doing the anonymous remailing would
> themselves be anonymous. However it does not solve Sybil: Any
> announcement protocol would be vulnerable. You can use the Web of
> Trust plugin for discovery, but countermeasures to Sybil are going to
> be difficult, probably even more difficult on Freenet than in the
> open - since we don't have access to e.g. IP address.
>
> [...]
>
> Any such system would be spammable. We have not solved the problems
> of announcing stuff safely and in a spamproof way - except for the
> Web of Trust plugin and Freetalk. You are probably going to have to
> use the Web of Trust for discovery, or some independant
> hashcash/thinkcash based announcement system (or even bitcoin-based,
> but note that bitcoin is not itself strongly anonymous even when run
> over Tor).
>
> [...]
>
> The main advantage as I see it is that the middle-nodes are
> invisible. They look like plain Freenet nodes.
>
> [...]
>
> Right, unless you protect address creation with a hashcash/thinkcash
> challenge. The catch being that you then have a round-trip before
> your message is sent, at least in the worst case. The upside is if
> you have a two way address you need this anyway.
>
> [...]
>
> Seems very interesting.
On 11/10/2010 12:45 AM, Matthew Toseland wrote:
> On Tuesday 09 November 2010 23:11:49 Tommaso Gagliardoni wrote:
>> [...]
>> Would a possible idea be to make exit nodes publish, together with
>> their temporary freemail addresses, also some kind of "certificate"
>> from which a local PLUG node could extrapolate a trust measure, so
>> to select only the most trusted nodes when sending emails? This
>> would make Sybil difficult, because inserting each malicious node
>> would imply a certain effort to build a web of trust before nodes
>> actually begin to trust it.
>
> Yes, you could bootstrap them directly from the Web of Trust.
> However, trust is limited to what is observable from behaviour...
>>
>> [...]
>>
>> Or perhaps using a Web of Trust approach to select the exit node,
>> and using instead a hashcash approach to allow the sending of
>> emails (i.e.: the PLUG sender must prove to the selected exit PLUG
>> that the hashcash has been paid).
- --
Tommaso Gagliardoni
GnuPG Key ID: 51D8DEB8
Fingerprint: DC10 0D2F 8F07 238D C5DB 63B8 0AEF 48C5 51D8 DEB8
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJM3VmvAAoJEArvSMVR2N64C7sP/2sdf0qre46mF2tsDaYpRY+s
wjWDoPIUSEsdDC21vPdH8Vr70zXaSyasO3pMQ1haYNz9qkVIzekmKrh4edLzN4RR
ktFOBvd5f88m739WFPx2Ru97kNFF5j2C6LA0EXwbgXb67QATRD1WAUIEnQWVGn4C
9G0zRhNSDKCi2R6b816DlB9bC4ye4Usl3XSWhUwAj1tglgjx9pqtHY9p0mLcGamp
K11/BOyTqbv/a2bSiGEYII/tR71Yo9z2WP/62zQFIvXoq8q+xQhsCd3f6K2RniwZ
6ALGNdkcF8oRRbGyy5cklb4i+wN2+6e55+ffFQ59ZU5Rvj+ATLBGed6RoKIJI1+B
8xGh7A5huWQAnd0W9kjpA3tjFzCGJgdOELYKvoXBrxYbJUalbLp719S0lkVBAe0T
xa+tzYxsenRtPfkfUHSNDbPhvRcaQZNx0QlsMx4Oj/8fgf6myUPL1w4oiJy/PNsi
CQgxT7ML42htTXsQmKTMFCGwo8idxAqSc04z+rG7wtCyOVjRmvgmfeJK6Dk/iJnp
EyvmDM4ARjS0QZeuurK1Q+JyKWO03wLQYkjXKEMVedvcaJXeudb4qqCGpgudBuPq
S6OHpBRTRL9vYN1gF1nen7Ky7cFJKsaI1K1MvHcusY+NQFfJ/+9oU2Y1xiPyvrb1
5IWSFlcHfJwuoyw2nWPv
=Tl0K
-----END PGP SIGNATURE-----
More information about the Mixminion-it
mailing list