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.
#Who runs bitmessage 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.
#Who runs bitmessage 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)
