Mobile message & behavior bitfield support #808

2015-07-30T18:19:25+02:00

kyucrane commented

2015-07-30 18:19:25 +02:00

(Migrated from github.com)

This patch implements the behavior bitfields described at https://bitmessage.org/wiki/Protocol_specification#Pubkey_bitfield_features .

A checkbox is added to address creation allowing the creation of mobile addresses.
When sending to mobile addresses, toRipe.lstrip('\x00') is prefixed to the encrypted message.

Two config options are added per address: needripe, indicating a mobile address, and notsendack, indicating an address that will not send acknowledgements. Code is implemented to honor these options.

This patch implements the behavior bitfields described at https://bitmessage.org/wiki/Protocol_specification#Pubkey_bitfield_features . A checkbox is added to address creation allowing the creation of mobile addresses. When sending to mobile addresses, toRipe.lstrip('\x00') is prefixed to the encrypted message. Two config options are added per address: needripe, indicating a mobile address, and notsendack, indicating an address that will not send acknowledgements. Code is implemented to honor these options.

ishbir commented

2015-07-30 18:40:02 +02:00

(Migrated from github.com)

I thought support for sending to mobile addresses was going to be removed by @Atheros1 (see https://www.reddit.com/r/bitmessage/comments/32tbve/questions_about_source/cqqogpb) Also, it would be better to send messages with the tag of the address rather than the ripe (to prevent address harvesting).

Atheros1 commented

2015-07-30 19:00:41 +02:00

(Migrated from github.com)

Indeed, I would be more interested in taking this feature out. It diminishes privacy and wouldn't be very functional anyway as senders would all need to check a box to "willingly include unencrypted destination address when sending to a mobile client". People don't ever change the default for this type of option. I currently feel that it was a perfectly fair possible solution to better support mobile clients but that it wasn't good enough and that the feature should be retired.

kyucrane commented

2015-07-30 19:05:04 +02:00

(Migrated from github.com)

I finished the basic implementation of what is specified in the sources and documentation. This allows working mobile clients to be created.

I agree that this is not the best implementation, but it is what is currently described in the specification in the wiki, and hence how other existing clients may be expected to behave.

I finished the basic implementation of what is specified in the sources and documentation. This allows working mobile clients to be created. I agree that this is not the best implementation, but it is what is currently described in the specification in the wiki, and hence how other existing clients may be expected to behave.

kyucrane commented

2015-07-30 19:10:19 +02:00

(Migrated from github.com)

Atheros1, understood. I guess somebody should update the wiki.

Atheros1 commented

2015-07-30 19:15:04 +02:00

(Migrated from github.com)

Do you mean the API Reference page? Or a different page?

ishbir commented

2015-07-31 05:13:24 +02:00

(Migrated from github.com)

I think he means the Protocol specifications page (https://bitmessage.org/wiki/Protocol_specification).

kyucrane commented

2015-07-31 21:32:53 +02:00

(Migrated from github.com)

Yes, the Protocol specification page. I can't create a wiki account because I use Tor.

I'm interested in adding support for mobile clients in some way. Has there been any accepted solution to the problem that a patch would be accepted for?

Here are two possible ideas:

Mobile pubkeys could include a reference to a secondary pubkey that messages must be sent to as acknowledgement data. Then a high-power server with pubkey 2 can safely forward messages to a low-power client with pubkey 1.
Objects created by mobile clients could include random data that must be hashed and tagged to messages sent to these clients. The data can be incremented to create new prefixes, or additionally generated from acknowledgements, such that tags are not reused for multiple messages. When a tag is only available from a public source to send a message, the sender is issued a warning that others with access to that tag will be able to identify that a message has been sent to this recipient.

(2 could be extended later to provide forward secrecy with per-message keys)

Yes, the Protocol specification page. I can't create a wiki account because I use Tor. I'm interested in adding support for mobile clients in some way. Has there been any accepted solution to the problem that a patch would be accepted for? Here are two possible ideas: 1. Mobile pubkeys could include a reference to a secondary pubkey that messages must be sent to as acknowledgement data. Then a high-power server with pubkey 2 can safely forward messages to a low-power client with pubkey 1. 2. Objects created by mobile clients could include random data that must be hashed and tagged to messages sent to these clients. The data can be incremented to create new prefixes, or additionally generated from acknowledgements, such that tags are not reused for multiple messages. When a tag is only available from a public source to send a message, the sender is issued a warning that others with access to that tag will be able to identify that a message has been sent to this recipient. (2 could be extended later to provide forward secrecy with per-message keys)

PeterSurda commented

2015-11-10 12:32:54 +01:00

(Migrated from github.com)

I'm undecided on this one. I think I will leave it open and revisit it once there is actually some development for mobile clients.

The fixes for the German translation were included in de67b9f0c6 and 0fe6562440 and are already in the master branch.

I'm undecided on this one. I think I will leave it open and revisit it once there is actually some development for mobile clients. The fixes for the German translation were included in de67b9f0c668d058deca6c31f8735ee1c5b7b879 and 0fe65624401ea0dcd7298b43d277810c6ea64036 and are already in the master branch.

kyucrane commented

2015-11-10 15:05:26 +01:00

(Migrated from github.com)

This patch isn't exactly refined -- it has a number of UI errors (for which there are no mobile clients to expose). But it moves in the direction of making it possible to implement a mobile client by implementing the network interface.

The basic problem here is how to identify that a message is for you without having to decrypt every message, which would drain the battery of a mobile device.

There's a thread called "Recognizing senders of metadata-hidden messages" at https://moderncrypto.org/mail-archive/messaging/2015/thread.html#1763 which mentions some techniques, but it's rather dense.

The big question is what kind of changes the bitmessage project will accept. It's hard to write a mobile client if doing so would violate the current network protocol.

This patch isn't exactly refined -- it has a number of UI errors (for which there are no mobile clients to expose). But it moves in the direction of making it possible to implement a mobile client by implementing the network interface. The basic problem here is how to identify that a message is for you without having to decrypt every message, which would drain the battery of a mobile device. There's a thread called "Recognizing senders of metadata-hidden messages" at https://moderncrypto.org/mail-archive/messaging/2015/thread.html#1763 which mentions some techniques, but it's rather dense. The big question is what kind of changes the bitmessage project will accept. It's hard to write a mobile client if doing so would violate the current network protocol.

PeterSurda commented

2015-11-10 17:01:39 +01:00

(Migrated from github.com)

Thank you for this info. From my perspective, mobile clients are an open question, I would like to have them, but I don't know how to write them well. After 0.6, I will look at these:
https://github.com/mailchuck/PyBitmessage/issues/45
https://github.com/mailchuck/PyBitmessage/issues/42
and see if I can build an android/ios version, even if it isn't practically usable yet. That will give me feedback on whether a mobile version is viable at all, and then I can revisit this pull request as well.

Thank you for this info. From my perspective, mobile clients are an open question, I would like to have them, but I don't know how to write them well. After 0.6, I will look at these: https://github.com/mailchuck/PyBitmessage/issues/45 https://github.com/mailchuck/PyBitmessage/issues/42 and see if I can build an android/ios version, even if it isn't practically usable yet. That will give me feedback on whether a mobile version is viable at all, and then I can revisit this pull request as well.

ghost commented

2016-01-09 05:07:32 +01:00

(Migrated from github.com)

I think we can do much better than including the ripe/tag.

Instead we prepend two values to the start of msg, called public message key and hash. The message key is a new keypair generated for each message. A shared ECDH secret is derived using the recipient's encryption key and the message key. This secret is then hashed using SHA-512 to produce the hash.

When we receive a message we compute the hash as above and check if it matches. This would be much faster than trying to decrypt the entire message, but not as fast as including a ripe/tag of course.

I think this scheme is secure, and that it would not expose the recipient's identity in any way, but I'm not totally sure.

I think we can do much better than including the ripe/tag. Instead we prepend two values to the start of msg, called `public message key` and `hash`. The `message key` is a new keypair generated for each message. A shared ECDH secret is derived using the recipient's `encryption key` and the `message key`. This secret is then hashed using SHA-512 to produce the `hash`. When we receive a message we compute the `hash` as above and check if it matches. This would be much faster than trying to decrypt the entire message, but not as fast as including a ripe/tag of course. I _think_ this scheme is secure, and that it would not expose the recipient's identity in any way, but I'm not totally sure.

PeterSurda commented

2016-05-31 12:50:36 +02:00

(Migrated from github.com)

@mirrorwish Let's see if I understand your proposal correctly. It would allow a mobile client to download only a part of all the messages (let's call it headers for a better analogy) and then they can see which one is for them and which one isn't. They still need to perform a cryptographic operation to check whether the header is a part of a message for them or not, but it requires less computational resources than decrypting the whole message, and it also reduces the bandwidth they require. The recipient would be a little less anonymous, because the node will see it only requests some objects in full, but it wouldn't know his bitmessage address unless it compromised the sender as well (i.e. more-or-less same as it is now).

The node protocol could then be upgraded to v4 to add the getheaders command, or use a node bitfield to indicate this. We cannot easily determine dynamically whether getheaders is supported or not, because there is no error feedback implemented (if I send getheaders to a node now, it will ignore it, and this is difficult to interpret correctly).

As for the objects, the "encrypted" field of the encrypted payload would simply be prepended by these two variables. Due to how it's implemented in PyBitmessage, full nodes will think that the encrypted data also includes these two variables and graciously fail to decrypt it. This makes backwards compatibility very easy.

The sender would also not require any configuration options, because they would see in the pubkey object the bitfield flags, and can still use the old format when sending messages to people who run their client as a full node.

This sounds good. I'd then recommend to change the bitfield 30 from "include_destination" to "simple_recipient_verification" (SRV) and implement it like this.

To be nice, a SRV node could also indicate to the connected node that it's a SRV node and will not relay data, so that the connecting node can optimise (otherwise, a full node could end up only being connected to SRV nodes and cause a network split, while thinking all is ok). In the future, a full node could also offer delegated PoW services to SRV nodes.

In the GUI, we could have a global setting for SRV mode, and also a per-address flag (for example if you share private keys, it needs to send the same pubkey object from both devices and if one has the bitfield on and the other one off, it creates problems). SRV mode should be indicated, for example in the window title, and/or in the lightbulb color or next to it, and also in the desktop notifications (e.g. "Bitmessage connected in SRV mode").

@mirrorwish Let's see if I understand your proposal correctly. It would allow a mobile client to download only a part of all the messages (let's call it headers for a better analogy) and then they can see which one is for them and which one isn't. They still need to perform a cryptographic operation to check whether the header is a part of a message for them or not, but it requires less computational resources than decrypting the whole message, and it also reduces the bandwidth they require. The recipient would be a little less anonymous, because the node will see it only requests some objects in full, but it wouldn't know his bitmessage address unless it compromised the sender as well (i.e. more-or-less same as it is now). The node protocol could then be upgraded to v4 to add the getheaders command, or use a node bitfield to indicate this. We cannot easily determine dynamically whether getheaders is supported or not, because there is no error feedback implemented (if I send getheaders to a node now, it will ignore it, and this is difficult to interpret correctly). As for the objects, the "encrypted" field of the encrypted payload would simply be prepended by these two variables. Due to how it's implemented in PyBitmessage, full nodes will think that the encrypted data also includes these two variables and graciously fail to decrypt it. This makes backwards compatibility very easy. The sender would also not require any configuration options, because they would see in the pubkey object the bitfield flags, and can still use the old format when sending messages to people who run their client as a full node. This sounds good. I'd then recommend to change the bitfield 30 from "include_destination" to "simple_recipient_verification" (SRV) and implement it like this. To be nice, a SRV node could also indicate to the connected node that it's a SRV node and will not relay data, so that the connecting node can optimise (otherwise, a full node could end up only being connected to SRV nodes and cause a network split, while thinking all is ok). In the future, a full node could also offer delegated PoW services to SRV nodes. In the GUI, we could have a global setting for SRV mode, and also a per-address flag (for example if you share private keys, it needs to send the same pubkey object from both devices and if one has the bitfield on and the other one off, it creates problems). SRV mode should be indicated, for example in the window title, and/or in the lightbulb color or next to it, and also in the desktop notifications (e.g. "Bitmessage connected in SRV mode").

ghost commented

2016-06-03 14:36:35 +02:00

(Migrated from github.com)

You seem to understand it correctly.

But an SRV node cannot even forward headers (as it has no way to know if they are legitimate). To do that the hash needs to be computed differently, but that would break POW in its current form.

You seem to understand it correctly. But an SRV node cannot even forward headers (as it has no way to know if they are legitimate). To do that the hash needs to be computed differently, but that would break POW in its current form.

PeterSurda commented

2016-06-03 15:06:19 +02:00

(Migrated from github.com)

You're right, I haven't thought about this. I don't think that not being able to forward headers is a problem per se, but it may allow for easy deanonymisation of originating messages. I need to look at how this is implemented in bitcoin.

This repo is archived. You cannot comment on pull requests.

No reviewers