

BitTorrent Chat - Private instant messaging via secure, distributed technology - lolololololo
http://labs.bittorrent.com/experiments/bittorrent-chat.html

======
lolololololo
If they don't release the source, like BitTorrent Sync, they might as well
just ditch this whole thing right now.

~~~
Karunamon
In any other context I would dismiss this comment as a troll, but yeah.. Any
program that passes itself off as "secure" and is closed source, in this
climate, is immediately suspect.

~~~
saurik
It is possible to analyze the behavior of a program without access to the
source code that makes it easy to recompile and distribute modified builds. I
routinely open binary files in disassemblers to read through their behavior.
Yes, it is possible to obfuscate the hell out of parts of binary code, and
_that_ would certainly throw up a red flag for me, but concentrating on the
source code seems to miss the point that source code can also be obfuscated,
if the source code looks "too weird" we probably aren't going to trust it
either, and it is also possible to hide a bunch of behaviors across wide areas
of "open" "clear" code (so nothing looks "too weird" at any given place in the
code).

To be very explicit about this, as I think this is a very subtle problem that
people tend to totally misunderstand: if I wanted to distribute a chat program
and have it be "evil" I would not distribute a binary with hidden behavior (if
nothing else, when you find this code in my binary I'm pretty damn well
screwed ;P): I'd instead distribute an open source program that involved a
threaded work queue for handling multiple socket connections to peers and
which had a few very subtle use-after-free race conditions that would only
come up under nearly impossible timing scenarios that I knew how to trigger
and exploit, giving me complete control of your client whenever I wanted.

These are the kinds of bugs people use to attack open source "secure" web
browsers like Chrome year after year at Pwn2Own because people are simply bad
at concurrency. In this sense, I'd thereby trust a closed source web browser
that had no threads or which was implemented in a type-safe garbage collected
language (executed on a simply-engineered runtime from someone separate that I
trusted, which could also be closed source for all I care) a lot more than I'd
trust Chrome. I'd even probably have an easier time understanding what it is
doing disassembling it than reading Chrome's code. (To be clear, such a
browser doesn't exist: probably you should use Chrome.)

~~~
StavrosK
Your argument is a bit disingenuous. You say you'd trust simple closed-source
software more than complicated open-source counterparts. That's a false
dichotomy. Open source X is always more easily auditable than closed source X.

I don't think many people are worried that BT will be evil. I think many more
people are worried that they'll be incompetent, and it's very hard to be
competent at cryptography. That's why we want the source.

~~~
bigiain
From a "non US person" perspective, I go to BitTorrent's website and read:

    
    
      Company Overview
      
      BitTorrent Inc. is an Internet technology company based in San Francisco. 
    

And immediately I've got _two_ things to worry about - 1) "will BT be
evil/incompetent?", and 2) "will BT be leaned on by the NSA and be coerced
into being evil?"

If you're a US company (or individual, or a company with US based management,
developers, investors, or infrastructure) who are promoting security-related
products in the post-Snowden era – many of us outside the US now have very
good reasons to apply extra scrutiny to those products. Opening your source
will make a _big_ difference in how readily suspicions of evilness can be
allayed. As saurik points out upthread, having the source available doesn't
guarantee the rest of the open source community will find and fix any
carefully-enough-crafted backdoors, but keeping the source closed sends a
strong message…

~~~
Avshalom
From a US perspective: The NSA doesn't lean on non-US companies because it is
fully authorized to just hack them directly. Your data kept in foreign
countries don't even have the _nominal_ legal protection that US data does.

Unless you've got unbreakable security the NSA is well funded enough that it's
irrelevant where you do business.

~~~
morkbot
Except that in the case of non-US companies NSA has to do the actual hacking.
In case of US ones they simply need to "ask" a company to, say, handle them
their master keys - much easier.

------
nly
BitTorrent was never designed with downloader privacy in mind (and not just
because of the trackers, the DHT, PEX and the core protocol are all leaky as
hell). Just because something is decentralised, it doesn't follow that privacy
is somehow intrinsic.

Why do we have any reason to trust BitTorrent, Inc. over any other
organisation? At best all these self-centered attempts are going to fragment
the messaging market and make make even more unlikely we'll see an open,
federated chat protocol reach popular use.

------
utnick
There has been a lot of interesting development on the secure chat front
lately ( secure circle, textsecure, heml.is, cryptocat etc ).

Not sure if bittorrent chat will be very interesting. Most secure chat clients
encrypt on the client side so the server won't be able to read your messages,
so not sure if not having a server is that big of a win here. I'm also
guessing metadata would be exposed to various people on the bittorrent chat
p2p net.

The one I'm most excited about right now is bitmessage. It is the only chat
protocol that I feel is really revolutionary. It is also a p2p network, but
the interesting thing about it is that everyone on the network gets every
message ( obviously you have to have the correct keys to decrypt the messages
that were meant for you ). So its impossible for an observer to tell even who
is talking to who. Also they have the concept of public chans , which I think
are a good mechanism to draw users. Bittorrent could do the same thing here.

~~~
egeozcan
I must say, I have very limited knowledge on encryption, but, can't an
observer possibly encrypt many possible and likely short messages (like,
"hey!" or "lol") with the public keys of some users of value and sniff the
network for matches? I mean it would take a while, maybe a week, to get some
results but hey, I think it's a possibility.

~~~
y0ghur7_xxx
_can 't an observer possibly encrypt many possible and likely short messages
(like, "hey!" or "lol") with the public keys of some users of value and sniff
the network for matches?_

no. the same message does "never" encrypt to the same cypher:

    
    
        $ echo lol | gpg -e -r F8669BB7 --armor
        -----BEGIN PGP MESSAGE-----
        Version: GnuPG v1.4.11 (GNU/Linux)
        
        hQEMA2gTLr1USDZGAQf/YbbnzHvNfdqbs6hmdmIaaiZOSfW9P6Bc8tdF4MG/JbP+
        RTxbLpi4W+vXs+WrD9jdik8KuDdZV54O1mb6Ido3xrYeEPBo0Vje2eVpgUy01VUa
        2RM76NvsX1VN9rap6KvHuO/h7IFwDuAtvUUcDyFH+qK2UEHordFi+mWKqICocQt0
        WWgpCk5BVgM/1q2c2ruWxVuZs/IMh9LQGZ1i7hpkJHAYqovhghROmGarUuJYXGDi
        s6rSMpjxbXDhPMYbbhbBI4pRhgKtN2FMlKyI3XoH+LCFHsOyBmazroVYWFu+gafH
        6LU2Z65OQyJWqX5CLdwab4qpUQdht6lqkUHRJB9xdtI/AfTFF7BbRP8PR+q9GVAe
        r4I812VmBn3hwBHJzNiFDEGVkt/IDpd6M/X2Vi0xJx0LUaICL+swPVudenPuvlnt
        =zeUd
        -----END PGP MESSAGE-----
        
        
        
        $ echo lol | gpg -e -r F8669BB7 --armor
        -----BEGIN PGP MESSAGE-----
        Version: GnuPG v1.4.11 (GNU/Linux)
        
        hQEMA2gTLr1USDZGAQgAo4ZEHGWKSgwVmbC7crACvTXVtlgP4n8J/3oSohct9zrM
        SqPd4L5TWsjOh+2LlG7WQbPnpn4Tcv9c4RyPNb+1C/fWRmGhV+a3QhuC+rrus5c6
        /FPwsHTjO30N0AnCMzoXAaqDRRGw859BKazEZyxIHherU+o7wNRKrW6U1ikRd/Pu
        BwHChUZHBRmZhomrtYPbQ5cNAJQtPMj94Z8OuZeCEzPNBr3opevoMs2j+9ysOtkF
        7Cam3jTKLM3GwHSm4c7WzhdJJsXbnOn8ODYRBf++4oJChPIqeT2EssigAQuuhHlk
        pDhM40zB7hAd6MJM52cZpM3UqTe/iI4vHSrQ+pw/otI/AWY6s4aIlF5AAzoM0wAR
        FzobJ5Vbp7fBgA1SiOhEhSAdT/U2yy2jQcQN53yyX9Vqtunh3dNmCGaNNavszK8+
        =YDLc
        -----END PGP MESSAGE-----
        $

~~~
IanCal
As someone who doesn't know the structure of the output, what's the
significance of:

    
    
        hQEMA2gTLr1USDZGAQ
    
    

At the start of each output? Is that 'lol' encrypted then followed by random
bytes, or does it contain header information?

~~~
Zash
It's a header with a version number and the ID of the receivers key that the
message was encrypted with. Base64-decode and hexdump those messages and look
for 54483646 (one of the subkeys of F8669BB7). The encrypted message is after
that and would look random. The format is defined in
[http://tools.ietf.org/html/rfc4880](http://tools.ietf.org/html/rfc4880)

edit: It's not encrypted with the primary key, but one of the subkeys.

~~~
IanCal
Interesting, thanks for the overview. I'll have a poke around the doc :) I've
been meaning to look into more about how these things work. I understand the
very high level stuff and the very low level (how to use the tools roughly and
some of the maths behind it all) but not so much in-between.

------
Ellipsis753
A little disappointing that there's no Linux version and that clicking "Other
Platforms + Betas" just takes you to the Windows download. Also it's closed
source.

Just telling people this so they can save signing up if it's not for them.

~~~
D9u
My sentiments, exactly.

I feel like I just signed up for a bunch of spam.

------
plg
I remember the old days when one person on a unix machine could chat with
another person on a unix machine using the unix talk command, (piped over ssh
for security)

I had many a conversation with my thesis supervisor this way, once when I was
in France and he was in Japan.

PS no third party server involved, obviously. Just my box and the recipient
box. I suppose one could do a man in the middle attack but we would always
start the conversation with some pleasant banter anyway so it's unlikely that
a third party masquerading as one of us could last long before detection.

<sarcasm>Too bad this technology no longer works, it was so simple and
useful</sarcasm>

~~~
StavrosK
A MITM would relay your chats, MITM isn't impersonation.

------
PhearTheCeal
Sounds similar to already existing Open-Source projects, like Tox[1] (which
was discussed on HN a couple months ago[2].)

Questions for both projects still remain though: What sort of metadata can be
collected from users of these programs? How can that metadata be used? Are
there any security vulnerabilities that have been overlooked?

We are still a ways from having truly secure chat as the mainstream
communication medium, but I'm glad Bittorent and others are helping move it in
the right direction.

[1] [https://github.com/irungentoo/ProjectTox-
Core](https://github.com/irungentoo/ProjectTox-Core) [2]
[https://news.ycombinator.com/item?id=6121225](https://news.ycombinator.com/item?id=6121225)

~~~
Sir_Cmpwn
The problem I have with Tox is that it's 90% hype and 10% product. They spent
all their time working on a nice website and building hype. That "screenshot"
on the front page is a mockup, the Tox project isn't even close to that degree
of completion.

I'd love to see them succeed, but I doubt it will. Especially with the recent
falling-out among their primary developers.

~~~
vezzy-fnord
Development is actually going fairly well. It's just that there's a whole
bunch of changes that haven't been pulled to the main repository, but there's
definite progress with streaming media and other aspects.

~~~
kozikow
[http://www.tox-chat.com/2013/08/tox-developer-fed-up-
quits.h...](http://www.tox-chat.com/2013/08/tox-developer-fed-up-
quits.html#comment-form) \- in this rant he sounded like there are some
security issues that are irrecoverable. Have something changed since his rant?

------
blake8086
Wouldn't this still allow an adversary to build a social network of all
participants?

They would know:

Who talked to who

How often they talk

When they talk

How much information they exchange

Their IP addresses

In fact, the only they wouldn't know is precisely what was said, but that's
often a very small, non-critical piece of the puzzle.

~~~
mahyarm
Still a far greater improvement to knowing the content of your conversations!
If your design removes performance in exchange for removing metadata, and
nobody uses it, it might as well not exist then.

~~~
XorNot
This seems pointless when we have things like Off-the-Record messaging, which
for all intents and purposes solves the content and trust problem, and even
includes a legal defence against encryption cracking (cracking a message gives
you everything you would've needed to forge the message in the first place,
meaning it can't be mathematically proven to have come from you - something
GPG and X509 do not).

Distributed chat systems only are advantageous because you get away from
having centralized servers, but you still have a bootstrap problem to get
everything up and running.

~~~
mahyarm
You are right, OTR already provides all of this.

The only 'unique' thing that Bittorrent can provide although is execution,
delivery & a tendency to open source their work. They have shown they can
deliver by implementing usable bittorrent sync clients for the major 4 OSs
(Windows, OSX, iOS, Android). That usability alone would increase the amount
of the internet using encrypted communications significantly, putting a major
hinderance on dragnet surveillance.

Hell we might find out that bittorrent chat uses libOTR once your in an actual
conversation, since they did all the hard crypto stuff already. They'll just
be adding a P2P discovery layer, since that is what they are actually
specialized in. That is what I would do if I were them.

There are no usable open source OTR or PGP clients for all 4 OSs still.
ChatSecure for iOS still crashes a lot. Adium/Pidgin is pretty much the only
usable OTR client I know of, and they are desktop clients.

------
TheCraiggers
I like that this and Tox are tackling this issue, but they seem to be missing
a huge piece of the puzzle: the so-called metadata.

If you can hide who the messages are being sent to, you can protect yourself
against them spying on who your friends are, which to me, is just as
important. Also, if you don't know who the recipient of an encrypted block of
text is, it makes it near-impossible to brute force the private key(s) of all
encrypted text coming out of a single IP.

~~~
Shish2k
> they seem to be missing a huge piece of the puzzle: the so-called metadata.

I wonder if the broadcast approach would help there? Be constantly throwing
out GPG encrypted data to the entire network, anyone with the private key can
pick it up. No "to" or "from" headers, and traffic analysis is hard since the
flow of traffic is constant:

[https://github.com/shish/firehose](https://github.com/shish/firehose) (Very
alpha)

The main downside there is that bandwidth requirements are huge, you can only
have a few thousand people on each shard :<

~~~
TheCraiggers
I don't know how bad the bandwidth requirements would actually be. A few
thousand bytes a second is an awful lot of text. Granted, you won't be able to
do anything else like VOIP.

I've been thinking of ways to combat this as well, and I admit it's an
interesting problem. You either have to do some kind of Tor-like onion
protocol (which has its own problems), or send every message to every client
in the world. Sending your message to [your friend] + X random people would
still allow an attacker to eventually gather a very detailed map of your
friends by looking at which come up most often.

~~~
Shish2k
> send every message to every client in the world

That's what I do, as I can't think of any alternative that is equally
analysis-resistant

> A few thousand bytes a second is an awful lot of text

I was planning for ~500 bytes / sec so that traffic spikes wouldn't block up
the send queue, but now that I think about it you're probably right -- even at
50 bytes/sec, the network speed cap would still be a fairly small factor
compared to the amount of time spent typing...

------
bluedevmonkey
What's with [RetroShare](retroshare.sourceforge.net)? Another question: What's
the sense of a tool that nobody of your friends uses, especially in social
networking? The will not migrate until Facebook etc. shut down

~~~
entropyneur
AFAIK every successful IM platform out there is successful _because of this
effect_. Users push their peers to adopt the new IM because without their
friends it's not very useful to them.

Of course there should be a good reason for the "seed" users to get on the new
platform in the first place.

~~~
bluedevmonkey
apparently there is no reason for them.

even with PRISM and others, people are too lazy for that.

------
sturadnidge
I love the way BitTorrent Labs are evolving - first with Sync, now Chat.
What's next... BitTorrentBook?

~~~
devx
Making these technologies open source would be a good improvement.

~~~
sturadnidge
True - not being a user, I must admit I assumed they already were :(

------
Sami_Lehtinen
Where is the detailed technical documentation? I would really like to read it.
I've read all documentation for other projects, making false claims without
any facts is way too easy.

Just finished reading all this:
[http://code.google.com/p/phantom/](http://code.google.com/p/phantom/)
boringly Tor-like project.

------
chroem
A friend who was writing a bittorrent client in x86 asm was actually going to
have something like this as one of its features. Hopefully this will motivate
him to start working on it again since it was such a cool project...

------
shacharz
Do you think a secured chat solution using WebRTC, can fall short from this?

------
shmerl
What protocol is it? If it's not open, then no, thanks.

------
adamnemecek
Waiting for the Cryptocat switches to BitTorrent chat announcement.

------
bsullivan01
_Private instant messaging via secure_

I would not use this for anything that could send me to jail, maybe after a
few years of being vetted.

