[liberationtech] Twister: P2P Decentralized Microblogging
Found this via Slashdot: twister is the fully decentralized P2P microblogging platform leveraging from the free software implementations of Bitcoin and BitTorrent protocols. http://twister.net.co/ Sean -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] New Anonymity Network for Short Messages
On Wed, Jun 12, 2013 at 6:34 AM, Michael Rogers
mich...@briarproject.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/13 17:52, Sean Cassidy wrote:
I have created a simple anonymity network that broadcasts all
messages to participants so that you cannot associate chatters.
Hi Sean,
A few quick questions:
* Do routers subscribe to prefixes, or is it only clients that do so?
If routers subscribe to prefixes, how do you ensure that all routers
subscribed to a given prefix form a connected subgraph?
ZeroMQ (the library I used to connect routers) allows for filtering
based on messages, but the software as implemented does not support
this. There is actually a bigger issue in ensuring a fully connected
network: the links are not automatically bidirectional. The network
operators must ensure that the graph is connected properly. I did this
to make the routing algorithm (if you can even call it that) simple
and straightforward.
* A passive observer can pretty quickly tell which prefixes a client
subscribes to by seeing which messages routers send her - her outgoing
messages can be ignored. So can't a global passive observer identify a
group of clients who all subscribe to the same prefix?
Prefixes are intended to be small in order to get a large amount of
messages. Clients can (and should) connect to multiple endpoints and
get messages for multiple prefixes, as well as respond on those
prefixes. Perhaps there could be a control channel on the network to
set up random pairs (or groups) of people in order to correspond their
fake prefixes.
struct dinet_packet { uint8_t id[16]; // prefix + random in the
default client uint8_t data[1024]; uint8_t checksum[32]; // SHA-256
checksum of the previous two fields, to avoid flooding the network
with duplicate packets };
* Why is the checksum included in the packet? Each router can
calculate the hash of the previous two fields itself, and discard the
packet if the hash matches a previously seen hash. If the router
trusts the hash included in the packet, it's possible to poison a
router's duplicate detection cache by sending it a packet that has the
same checksum field as another packet but different data.
The router does not trust the hash, but instead recomputes it and
checks it against the given checksum. It was intended to discourage
attacks that just flipped a bit and flooded the network, but this is
sort of a weak protection.
I also had envisioned that clients could monitor their messages from
multiple endpoints (subscribe to themselves) and check that the
checksum is still the same one that was sent. If they never receive
that checksum, either the network is not connected properly, or there
is some destructive tampering going on.
Sean
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRuHkBAAoJEBEET9GfxSfMygkH/i7iLj0IhYRqP0Ux6DPjyyK8
zljvmL1cft8uhd3CTOz3sYGzJIiduQuDHG1UEEsNKNMJxETSgQXylQRKPodqPa5Z
a7XLjtyp2Y6Tx/5PC3CU7vtaXvnG+ZLrIsfXsjatQx6sEVoN7dMGPTP3jyaSJl4f
3fp2ZhT0CAFpzXrGnGfOdttoNaKo9KSFTcYIsp/jVdC1YCmaexHpF5j2QjQ8cX83
WEhSZAuhpAUzAwutFpC9H8rpxbcZstucq4TsbjlVsgV0v/UbdYB5Th0UGn6fTISY
z78PK+HU+Co/HXw7VQpd3CZq3Ng03/09na0ZvEbEZqpIwwJrzyZOffNnObd648k=
=SLCZ
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by
emailing moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing
moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] New Anonymity Network for Short Messages
Hello all, I have created a simple anonymity network that broadcasts all messages to participants so that you cannot associate chatters. https://bitbucket.org/scassidy/dinet There is a simple sample client available, but you could write your own client to build your own features atop the network. http://projects.existentialize.com/dinet/client.html Please let me know if you have any comments. Sean -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 10:10 AM, Griffin Boyce griffinbo...@gmail.com wrote: It would be a fairly simple task to review all of the chat information and correlate call and response for all of the conversations. I disagree for several reasons. First is that if the load on the network is high enough, conversations can hide in the noise. This is helped by dummy message generation either by clients or servers (preferably clients to protect against attackers that can monitor every node). Second is that this protocol is not necessarily one-to-one. It naturally supports one-to-many, many-to-one, and many-to-many messages. As these are not distinguished at the message layer, but rather at the application layer, it would take some more sophisticated analysis to determine the nature of the conversation. Third is that prefix selection logic is entirely up to the client. They can choose prefixes that vary with an encrypted pattern, or some variant of that idea, to obfuscate where they are sending their messages. Sean ~Griffin -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 10:29 AM, Steve Weis stevew...@gmail.com wrote: Hi. I took a quick look while procrastinating at work and found a few potential issues: Thanks for taking a look. I'll be sure to incorporate your feedback. - What's up with this hard-coded salt? Lack of love for the text client. I should just delete that code. The primary user interface is the HTTP endpoint. - Any specific reason you picked CTR? CTR is widely recommended. Cryptography Engineering specifically recommends it. - Use mlock here? I don't think that will help you if you run within a guest VM though. - Buffer overflow on password input Absolutely true. - Is this safe for non-terminated strings? Gah, must have missed that in my review. - Why do you have this checksum if you just HMACed the ciphertext? This checksum is an important part of DiNet. Each packet comes with a checksum that each router uses to verify the message integrity (not authenticate, mind you) and to make sure it hasn't seen this message before. As each router sends every packet it hasn't seen recently to every machine that is connected to it, it is important to not re-send data. - HMAC verification is vulnerable to a timing attack. Since you're using CTR, it's that much easier to forge messages. I will have to look into this in my Javascript client as well. Do you have any recommendations? - There's no forward security. I am aware. This is a feature I would love to add to the Javascript client. This is by no means comprehensive. I've only been looking at a couple files. Thanks for looking! I appreciate the feedback. Sean On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.com wrote: Hello all, I have created a simple anonymity network that broadcasts all messages to participants so that you cannot associate chatters. https://bitbucket.org/scassidy/dinet There is a simple sample client available, but you could write your own client to build your own features atop the network. http://projects.existentialize.com/dinet/client.html Please let me know if you have any comments. Sean -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 11:42 AM, Griffin Boyce griffinbo...@gmail.com wrote: Sean Cassidy sean.a.cass...@gmail.com wrote: First is that if the load on the network is high enough, conversations can hide in the noise. This is helped by dummy message generation either by clients or servers (preferably clients to protect against attackers that can monitor every node). Unless I'm missing something (entirely possible): From your standpoint, the ideal would be to hit a high enough rate that it makes real-time analysis of content (by a human) impossible. By the time the service hit that rate of chats, it will be nigh-unusable by people. This is more or less why chat channels (eg, IRC) were created in the first place. And that doesn't preclude outside observers from storing and correlating the chats. This is mitigated (somewhat) by allowing the users to filter the amount of messages they can receive by the length of the prefix they specify. The shorter the prefix, the more messages and more anonymous it becomes, but if bandwidth is a concern you can increase your prefix length to lower your bandwidth consumption. The fixed message size addresses this somewhat as well. Sean ~Griffin -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 11:13 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.com
wrote:
I have created a simple anonymity network that broadcasts all messages
to participants so that you cannot associate chatters.
https://bitbucket.org/scassidy/dinet
See also: https://bitmessage.org/wiki/Main_Page
(I have some reservations about the design-as-of-last-I-looked: The
round trip required to obtain the far-end's public key significantly
degrades the security properties— but they've been actively developing
it, so that may well have been fixed by now).
A friend of mine sent me this as well when I told him about it. My
main concern with Bitmessage is the size and complexity of the
protocol. My protocol is just a struct:
struct dinet_packet {
uint8_t id[16]; // prefix + random in the default client
uint8_t data[1024];
uint8_t checksum[32]; // SHA-256 checksum of the previous two
fields, to avoid flooding the network with duplicate packets
};
Should be easier to analyze and study, I would think.
Sean
--
Too many emails? Unsubscribe, change to digest, or change password by
emailing moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing
moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
