Re: [liberationtech] New Anonymity Network for Short Messages

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/06/13 16:52, Sean Cassidy wrote:
>> * 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.

It would be good to see some back-of-an-envelope calculations of the
anonymity set size (or any other anonymity metric) as a function of
the number of clients and the number of fake prefixes each client
subscribes to. My intuition is that there will be lots of pairs of
clients who subscribe to the same fake prefix, fewer trios, even fewer
quartets, etc. So large groups who subscribe to the same prefix will
still stand out.

The control channel suggestion is interesting, but if the adversary
can monitor the control channel, won't real subscriptions stand out as
they won't have been arranged using the control channel?

Choosing an appropriate lifetime for fake subscriptions seems like a
difficult job. Presumably clients will want to join and leave
conversations, so their real subscriptions will change. The dynamics
of fake subscriptions will have to resemble the dynamics of real
subscriptions to avoid revealing the real subscriptions to a long-term
passive observer.

> 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.

If the attacker can flip bits, surely she can also replace the hash in
the packet with a new hash calculated after flipping the bits?

> 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.

That sounds like a useful check, but it doesn't require the hash to be
included in the packet - clients can store the hashes of the messages
they send, calculate the hashes of the messages they receive, and
check that they receive all the messages they send.

So it still seems to me that the checksum field is redundant.

Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRuKs6AAoJEBEET9GfxSfMgJkH/jn0cSbr+iQmeOlTR3C35WFZ
whnq/fsr0Vls/DNk8tHmK3sC+WNQa4bFPwUoEzAluFa1N/ENxIkcArZyAANyAB8+
Ar/xFBWM7yD1MbIJkY+ljyrFE5DIe3u/P4olvvzDvhiBQr4SPPDCLlKV+7YGC6lS
lxM/x8p2iYpAx6qh1TwlsDXfF20/45RgK50fFoB9vegylQCJ5pSlProm9Es9/YEX
c07+ab9LdV59M86yaPBQflniz7UH68dctoCGoKfihbtei4ic+AIv6sFAViti2tzj
b89fO1aNE5lMHutXkYRAmtaxTkuXIU+4Rz3+v3rZy4cYL30yVXIlipSG9TJvZ7g=
=IMVC
-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

[Lucas Gonze]

"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 wrote:

> Sean Cassidy  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

[Sean Cassidy]

On Wed, Jun 12, 2013 at 6:34 AM, Michael Rogers
 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

[Michael Rogers]

-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

[Steve Weis]

CTR is okay if:
1. You authenticate ciphertext. Sean does HMAC it. But as you point out,
they have a weak CRC outside the HMAC. If that's checked before the HMAC,
then someone can manipulate the protocol.

2. You do not repeat IVs. Sean's using a message ID concatenated a random
nonce. This can be okay, but it depends how the ID is generated and how big
the nonce is.

For CBC, #1 still applies, but #2 is less severe.

I'd probably just recommend using GCM for authenticated encryption.

On Tue, Jun 11, 2013 at 2:38 PM, Mike Perry wrote:

> 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
>
--
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

[Mike Perry]

Steve Weis:
> Comments inline...
> 
> On Tue, Jun 11, 2013 at 10:47 AM, Sean Cassidy 
> wrote:
> 
> > > - 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

Re: [liberationtech] New Anonymity Network for Short Messages

[Sean Cassidy]

On Tue, Jun 11, 2013 at 11:13 AM, Gregory Maxwell  wrote:
> On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy  
> 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

[Sean Cassidy]

On Tue, Jun 11, 2013 at 11:42 AM, Griffin Boyce  wrote:
> Sean Cassidy  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

[Gregory Maxwell]

On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy  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

See also the unrelated 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

[Griffin Boyce]

Sean Cassidy  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

[Gregory Maxwell]

On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy  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

[Steve Weis]

Comments inline...

On Tue, Jun 11, 2013 at 10:47 AM, Sean Cassidy wrote:

> > - 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) -
blen"?
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
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

[Tom Ritter]

On 11 June 2013 13:42, Sean Cassidy  wrote:
> On Tue, Jun 11, 2013 at 10:10 AM, Griffin Boyce  
> 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

[Sean Cassidy]

On Tue, Jun 11, 2013 at 10:29 AM, Steve Weis  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 
> 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

[Sean Cassidy]

On Tue, Jun 11, 2013 at 10:10 AM, Griffin Boyce  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

[Steve Weis]

Hi. I took a quick look while procrastinating at work and found a few
potential issues:

- What's up with this hard-coded
salt
?
- Any specific reason you picked
CTR
?
- Use 
mlock
here?
I don't think that will help you if you run within a guest VM though.
- Buffer 
overflowon
password input
- Is this safe for non-terminated
strings
?
- Why do you have this
checksumif
you just HMACed the ciphertext?
- HMAC verification is vulnerable to a timing
attack.
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 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

Re: [liberationtech] New Anonymity Network for Short Messages

[Griffin Boyce]

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