Share-o-matic technical description
What kind of encryption does Share-o-matic have?
Share-o-matic uses asymmetric cryptography. Public keys are exchanged securely via steam, and the private keys never leave your computer, thus making all transfers secure and private. After the key exchange, all network messages are encrypted with AES.
Do you store any of my data?
No. Your data never goes through our servers. Our servers are contacted just to provide network punchtrough functionalities, and we have no way of knowing who is sending data to who.
What if I don't like the idea of contacting your servers anyways?
After early access, we'll be releasing a minimal, open-source, version of the punch-through server code so that you can deploy your own server.
Ok, can you walk me through the protocol?
Sure! The identity authorithy is Steam itself, de-coupling our punch-through role from the identity authority role. Both the sender and the receiver must be using Steam (duh!) and have Share-o-matic installed. Whenever you want to send a file to a Steam user, the Steam API are used on a reliable channel to send command messages (e.g. imagine a "I would like to send you this file" message between you and your friend). All messages, also on the reliable channel are encrypted using asymmetric cryptography. Let's say that Alice (A) wants to send Bob (B) a file: the protocol can be summarized in:
- Alice generates her public and private keys
- Bob generates his public and private keys
- Alice and Bob exchange their public keys using the Steam networking API.
- From now on, all control messages are encrypted using the public keys. Only Alice and Bob can now know the content of the network messages as to decrypt the message, the private key is needed.
- Alice sends a "Start transfer" encrypted request to Bob using the reliable, encrypted, Steam connection
- Bob acknowledges the "Start transfer" encrypted request to Alice using the reliable, encrypted, Steam channel
- Alice contacts our server on an UDP connection. The server replies with Alice's IP address and port.
- Bob contacts our server on an UDP connection. The server replies with Bob's IP address and port.
- Now that both Alice and Bob know their own public IP address and the open port, they exchange such information to each other via the reliable, encrypted, channel. The direct punch-through connection is now estabilshed. All messages from A to B are encrypted using B's public key, so that only B can decrypt it with B's private key. The same happens for A.
- The reliable connection is still used for command messages (e.g. "I am sending you chunk 1 of 100" or "please resend chunk 1 of 100") while the UDP connection is used to deliver fast data transfer, directly across the sender and the receiver. Both channels are always encrypted.
Why does Steam have to be the identity authority?
It is important that someone is the identity authorithy, as otherwise that would pose security and impersonation risks. Being a software distributed on steam, it's the natural choice. We don't want you to create another account to use Share-o-matic. You already have a Steam account, and that is all that is needed to use Share-o-matic. That said, always be careful! We can't protect you on what content you receive!
Does this mean that the identity authorithy knows what files we send to each other?
No, even if whoever is the Identity Authority (in this case, Valve) were to attempt a man in the middle attack, they would only be able to observe that network messages are being exchanged between A and B. They would have no way to decrypt the data just by intercepting the network traffic as Steam is used only for "command" messages, not the file itself. Even if they inferred that A was attempting to send a file to B based on metadata the file transfer always happen over a dedicated, encrypted, direct UDP channel only between you and the recipient, and is entirely separate from the identity authority.
Do you know what files are we sending?
We only see the initial punch-through connection request, so we have no way of knowing who is contacting who. To clarify even further: the only message you send us is necessary for us to tell you what are your IP address and port, so that your client relay such information to the whoever is sending/receiving a file, and viceversa, providing network-punchtrough capabilities. We temporarily store only your IP address to provide the functionality and for security purposes (to prevent-abuse such as a DoS attack). We will open-source the server after the Early access period, so that users that want to deploy their own punch-through server, can do so.