Re: [liberationtech] New Anonymity Network for Short Messages
-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?
* 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?
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.
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
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
Re: [liberationtech] New Anonymity Network for Short Messages
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. Every client could broadcast a message on a timer. Sometimes the message would be wheat and sometimes chaff. Then the downsides would be: 1) Additional latency between composing the message and the next timer pulse. In terms of UX, slower sends. 2) A bigger buffer, flushing more often. Problem #2 could be ameliorated with something like sharding. If there were S shards and M messages total, a peer would buffer M/S messages. On Tue, Jun 11, 2013 at 11:42 AM, Griffin Boyce griffinbo...@gmail.comwrote: 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. ~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
It would be a fairly simple task to review all of the chat information and correlate call and response for all of the conversations. ~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
Re: [liberationtech] New Anonymity Network for Short Messages
Hi. I took a quick look while procrastinating at work and found a few potential issues: - What's up with this hard-coded salthttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-16 ? - Any specific reason you picked CTRhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-88 ? - Use mlockhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-238 here? I don't think that will help you if you run within a guest VM though. - Buffer overflowhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-241on password input - Is this safe for non-terminated stringshttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/common.c?at=master#cl-41 ? - Why do you have this checksumhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-112if you just HMACed the ciphertext? - HMAC verification is vulnerable to a timing attackhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-129. Since you're using CTR, it's that much easier to forge messages. - There's no forward security. This is by no means comprehensive. I've only been looking at a couple files. On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.comwrote: 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
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 11 June 2013 13:42, Sean Cassidy sean.a.cass...@gmail.com wrote: 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. I haven't looked at your project much (sorry, I've added it to my list though ;) ) - but Griffin is right to be paranoid first. Depending on the metadata available*, it is often possible to correlate messages with some good amount of probability, even when it seems like a flood of random messages. I like the idea of shared inboxes, for all their faults, and will be talking about faults and these types of correlation attacks at Defcon this summer, targeting perhaps the largest shared inbox-based anonymity project deployed: https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Ritter -tom *It's amusing that the focus of this (and my) analysis completely discards looking at actual content, and focuses entirely on metadata. Metadata, Metadata, Metadata. ;) -- 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
Comments inline... On Tue, Jun 11, 2013 at 10:47 AM, Sean Cassidy sean.a.cass...@gmail.comwrote: - Any specific reason you picked CTR? CTR is widely recommended. Cryptography Engineering specifically recommends it. The reason I ask is that this makes your IV-generation more critical than, say, CBC, XTS, or other modes. If you have an IV collision, you'll leak some message bits. How big is the random nonce here, i.e. sizeof(dp.id.id) - blenhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-84? How are message IDs generated? - 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? Use a timing-independent array comparisonhttp://rdist.root.org/2010/01/07/timing-independent-array-comparison/. It's an easy fix. I've made the same mistake before, which is why I always look for it now. -- 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 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). -- 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
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. ~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
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
Re: [liberationtech] New Anonymity Network for Short Messages
Steve Weis: Comments inline... On Tue, Jun 11, 2013 at 10:47 AM, Sean Cassidy sean.a.cass...@gmail.comwrote: - Any specific reason you picked CTR? CTR is widely recommended. Cryptography Engineering specifically recommends it. I was puzzled by this recommendation. CTR has several bad propeties that can surprise you, and have bitten Tor as well. The reason I ask is that this makes your IV-generation more critical than, say, CBC, XTS, or other modes. If you have an IV collision, you'll leak some message bits. Additionally to this, CTR allows bit-level maleability of the cleartext: a bit flipped in a CTR cipherstream translates into a bit flipped in the cleartext. In fact, if there are regions of known cleartext (such as zeroes) the adversary can do things like encode the originating IP in the cleartext simply by XORing it into the cipherstream. This property can cause problems if you perform any operations before checking the MAC (like evaluating a weak CRC to decide to forward the message or not). CBC on the other hand causes a single ciphertext bitflip to scramble a block of cleartext (16 or 32 bytes for 128bit vs 256bit) in an unpredictable and key-dependent way. -- Mike Perry -- 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
