In that case, you'd need to participate in the network by connecting to as many nodes as possible.Īnother thing to keep in mind is that public keys are sent onto the network. If peer to peer connections were encrypted, it wouldn't be possible to do this passively.
This only goes for someone who has significant insight into all the nodes on the network. Do this for several messages going in both directions and you know exactly who is talking to who.īut like I said at the start. Should a uniqe ack message be generated by one of the nodes that just received your message, then the probability that it's the recipient increases.
An ack is basically a short message with a random sequence that's part of the sender's encrypted message. They see it propagate and every node that receives it can potentially send an ack msg. So now they can 'follow' that message through the network. They still don't have any way of decrypting it, but they do know that it came from you. If the NSA were to track your machine's participation on the bitmessage network, and they saw a unique hash coming out of your machine, but not going in, then it's obvious that you are the source of that message. So when a message is first introduced to the network, it's unique hash is sent out in an inventory message. These inventory messages contain hashes to objects. Sorry, not total coverage of 'all messages sent' but total coverage of the network, or at least a significant part of it.Īs you can see in the protocol specification, Objects are introduced onto the network with inventory messages. This can be prevented by turning off acknowledgements in the client. However, if you're having a conversation with someone and are exchanging multiple messages, then it's completely invisible to the recipient that someone is trying to track him down. It's also quite obvious to the recipient that this is happening since he'll be receiving duplicate messages from the sender. This only identifies the recipient of the message, not the content or the sender (unless you are the sender, in which case you now know who you're talking to). If you receive a new, previously unknown ack message (content is shorter than an ordinary encrypted message) from that node before any others, then you've found the recipient node. Taking any message of interest, changing the timestamp and redoing the proof of work (resulting in a new message hash) and sending it to a single node. The way this can be done is quite simple. If it has been demonstrated that acks actually allow an attacker to identify recipients, I'd like to see a link to a discussion about it. Some steps you can take to further harden the client include: (1) encrypt the local installation when the program is not in use, (2) connect using tor, (3) encrypt highly sensitive message content using pgp, (4) use many different identities, and (5) regularly retire old identities and replace them w/ new ones.
#Bitmessage ios download
If ppl want bloatware they can download i2p or freenet.Īll that having been said, it is still a work in progress and one that has not been thoroughly tested or analyzed by security experts. Personally, I would prefer to see the scope of the core bitmessage project remain limited to an email/newsgroup-type protocol.
#Bitmessage ios software
It could be used in some kind of additional chat program but I don't really see the need for such software as other solutions already exist. OTR is an instant messaging protocol, so I doubt it will ever be a part of the existing project.
It's also clear that sending messages using any traditional email service means you've already given up the fight to protect your meta-data, so it's hard to see how bitmessage can be a worse option.
Additionally, as of version 4, new addresses are no longer broadcast, removing the problem where addresses could be harvested by monitoring the network.įurther, I have yet to see anyone demonstrate an actual flaw with the cryptography used to encode the messages. Several proposals have been discussed for further addressing the issue and one assumes we will see one of them implemented before bitmessage reaches a 1.x version. Scalability is a known issue and after this attack, the protocol was improved to reduce the effect flooding has on the existing network. The referenced attempt at de-anonymization was 100% a social engineering attack which did not reveal any weakness in the protocol itself. The messages themselves are encrypted along with all their meta-data. Although I agree with the general response that it shouldn't be trusted, I think some of the concerns as stated make it sound worse than it is.
0 kommentar(er)
