Static topic IDs = censorship and filtering

annabelleannabelle Member Posts: 3
edited December 2014 in Whisper
Static topic IDs in Whisper make censorship easy - just block all whisper traffic containing blacklisted topic ids.

To minimise ISP or Government filtering by topic ID, would it be better if the protocol to enforced a channel hopping strategy all the time?

Comments

  • annabelleannabelle Member Posts: 3
    edited December 2014
    Further, optional encryption of the payload presents additional problems. I can see the desire to keep whisper as simple as possible, however a minor modification would stop of surveillance and censorship of Whisper data, and strengthen the security of all Dapps using it:

    Each topics ID currently consists of the first four bytes of:
    a) the SHA3 of the topic - broadcast message
    or
    b) recipient's public key hashed with some session nonce or application-identity - private message

    The message in the envelope contains:
    a) broadcast message - unencrypted data (payload and optional unencrypted signature)
    or
    b) private message - optionally encrypted data using the recipient's public key containing
    i. the payload
    ii. an optional signature of the payload

    What about the following change:

    Each topics ID could instead consist of the first four bytes of:
    a) the SHA3 of (the topic hashed with a seed value that is periodically incremented) - broadcast message
    or
    b) recipient's public key hashed with some session nonce or application-identity that is periodically incremented - private message

    The message in the envelope could instead contain:
    a) broadcast message - payload and optional signature always AES encrypted using SHA3 of (topic + hashed with the same periodically incremented seed value) as key
    or
    b) private message - optionally encrypted data using the recipient's public key containing
    i. the payload
    ii. an optional signature of the payload

    It would be up to the application how to generate the topic hash seed value, For example it could be generated from the date and time, allowing an application to start broadcasting and receiving public data immediately. Or an application could require a private message to be sent and the seed value returned in a private message.

    The simplest implementation of the increment could be after a fixed period of time, for example 5 minutes. Alternatively the increment interval could be after a certain number of messages - with a single message before hopping implementing Whisper's Silent Operation mode.

    This would have the following advantages:
    -minimal change required
    -all data in whisper is unintelligible unless authorised to read
    -4 byte topic id does not reveal topic or encryption key
    -eliminates mass surveillance of unencrypted Whisper data
    -no key exchange required for apps that don't need private messaging
    -content censorship by inspecting content impossible
    -content censorship by blocking topics impossible
    -more resistant to attack
    -improves security of all apps unit Whisper
    -DoS attack flooding a topic has limited lifespan before next hop
    -next topic id value is known so can advertise early, providing seamless handover to next topic id
    -prevents spam directed at 4 byte topic ID unless topic is known (could only last until next hop)

    Frequency hopping in radio data protocols similarly helps avoid interference and improves security.

    What do you think?
  • annabelleannabelle Member Posts: 3
    gavofyork said:

    All message passing between nodes is encrypted, so "blanket" content censorship and/or inspecting isn't a problem.

    OK, so ÐΞVp2p provides the encryption that prevents the existence of content filters. Excellent.
Sign In or Register to comment.