Use encrypted messages on peers pools

[piranna]

As suggested on the P2P-Hackers mail list, use encripted messages with the SDP data on open peers pools (one-to-many instead of direct messages) using the destination UUID as encription key (could be used public keys as identifiers?), so all peers can receive it but only can decode it the correct destinatary, preventing hijacking of the session. Presence messages to request others to connect to us can be send open as usual without problems.

[piranna]

Using UUIDs and symetric encryption would allow other (malicious) peers to decypher the offer/answer messages and get the peer IP and port and other data. The best solution for this is to use asymetric encription using public keys as identifiers, so only the correct destinatary with the private key can decypher it and stablish the connection.

[piranna]

Send messages using ArrayBuffers, maybe directly or packed using MessagePack. Proposed format:

MTU - Max Transmission Units

• PubNub: 1800 bytes
• DataChannels: 1280 bytes (assumed by Chrome)

Length of a public-key

• 1024 bits = 128 bytes
• 2048 bits = 256 bytes

Presence message

• ttl: [4 bits] = '0x0'
• method: [4 bits] = '0x0' (presence)
• from: [sessionID] = session public-key

Total size: 1+256 = 257 bytes

Regular message

• ttl: [4 bits]
• method: [4 bits] = error|offer|answer|authenticate|candidate
• dest: [sessionID] = session public-key
• id: [1 byte] = message ID
• data: [encrypted data]

Total size: 1+256+1 = 258 bytes; max data field size: 1280-258 = 1022 bytes

Errors are defined by negative numbers (0x8-0xF) in the 'method' field

Message ID is generated on a per-destination basis, so this way it can be more constrained.

'data' field is encrypted with the destination peer session public-key (sessionID), so only it can decode the message using its session private-key. This can be a problem for routing since we don't have the destination peer session ID, this need to be studied if adding a 'dest' field would be not only a problem for message size but also a security issue.

data field

Error

• sdp: [4*256-2=1022]

Offer

• from: [sessionID] = session public-key
• sdp: [3*256-2=766]

Total size: 256+766=1022 bytes

Answer

• sdp: [4*256-2=1022]

Authenticate

• timestamp: [8 bytes]
• sign: [256 bytes] = signature with userID over timestamp (digest-like) to identify & authenticate

Total size: 8+256 = 264 bytes

Candidate

• sdp: [4*256-2=1022]