Attached are sample programs that facilitate sending a file over the WAN (Wide Area Network) fully encrypted.
Transferring a file unencrypted over the Internet using SimpleSock is usually quite straight forward. You connect to the receiving machine and transfer data to the Winsock buffer in blocks less than the size of the outgoing buffer (usually 65,536 bytes). Winsock sends packets of data to the receiver at a rate that is dependent on the network being used (WiFi uses a lower packet size than hard wired). When the outgoing buffer is full, it halts the sending of data to the buffer until the buffer is able to handle more data. On the receiving end, the Winsock buffer receives data until it cannot accept any more. Once the incoming buffer is able to process more data, it will accept more data. This is all accomplished on the boundary of a packet. Winsock is buffered and the file system is buffered. We simply need to know the file length.
That is all fine and dandy as long as the receiver is able to receive data at approximately the same rate as the sender. But when you introduce encryption to the mix, it becomes a whole different ball game. Data can only be processed as a complete record, and the header defines the record length, not the file length. That outgoing record must be encrypted before it can be processed. Therefore we must halt the sending of a new record until the present record has been completely sent, so it can be received as a complete record to be decrypted. That is accomplished by using the SimpleSock SendComplete routine. Using a fixed maximum record length, anything less than that length will be considered the last record for the file. But what if the last record exactly coincides with a record boundary. In this remote case, the sender sends one more record of zero length along with just the header.
So what is the appropriate length for a record. A record size too large places an excessive load on the encryption/decryption routines and slows things down. A record size too small places an excessive load on the network system. Gmail sends attachment files using a record size of 1,408 bytes and it is painfully slow sending larger attachments. So Gmail offers a secondary system to receive those larger files when using a browser. TLS 1.3 uses a maximum record size of 2^14 (16,384 bytes), and this is what I have chosen to use in this sample program.
The encryption protocol I have chosen to use in this sample program is RC4. It is fast and its limitations are overcome by using a 256 bit key and relatively large record sizes. The current sample uses a fixed 32 byte key, but the intention is to use TLS 1.3 to establish the network connection in the next version. The Agreed Secret calculated by each party would be used as the key for each file transfer, as the connection is terminated after each file. This results in a different key being used for each file transfer.
To receive a file, start the "RecvFile" program. I have arbitrarily chosen port 1159 to listen on, and "C:\Temp" to store the file. When the file starts to download, the file name will appear in a text box and the text box will be made visible. If the file already exists in the chosen path, an addendum by way of "(x)" will be added to the filename when it is saved.
To send a file, start the "SendFile" program. Enter the location of the receiving program as either an IP address or a domain name. A domain name must be DNS hosted or configured in the "HOSTS" file. Click the "Connect" button, and if successful the status will be reflected in the status bar. Unsuccessful attempts will eventually time out and display an error in the status bar. Next, click on the 3 dots in the upper right corner. This activate a Common Dialog which you can use to navigate and select the file you want to send. Then click the "SendFile" button. There are ample debug messages to visualize the progress and a timer message to tell you how many ms the transfer took.
J.A. Coutts
Transferring a file unencrypted over the Internet using SimpleSock is usually quite straight forward. You connect to the receiving machine and transfer data to the Winsock buffer in blocks less than the size of the outgoing buffer (usually 65,536 bytes). Winsock sends packets of data to the receiver at a rate that is dependent on the network being used (WiFi uses a lower packet size than hard wired). When the outgoing buffer is full, it halts the sending of data to the buffer until the buffer is able to handle more data. On the receiving end, the Winsock buffer receives data until it cannot accept any more. Once the incoming buffer is able to process more data, it will accept more data. This is all accomplished on the boundary of a packet. Winsock is buffered and the file system is buffered. We simply need to know the file length.
That is all fine and dandy as long as the receiver is able to receive data at approximately the same rate as the sender. But when you introduce encryption to the mix, it becomes a whole different ball game. Data can only be processed as a complete record, and the header defines the record length, not the file length. That outgoing record must be encrypted before it can be processed. Therefore we must halt the sending of a new record until the present record has been completely sent, so it can be received as a complete record to be decrypted. That is accomplished by using the SimpleSock SendComplete routine. Using a fixed maximum record length, anything less than that length will be considered the last record for the file. But what if the last record exactly coincides with a record boundary. In this remote case, the sender sends one more record of zero length along with just the header.
So what is the appropriate length for a record. A record size too large places an excessive load on the encryption/decryption routines and slows things down. A record size too small places an excessive load on the network system. Gmail sends attachment files using a record size of 1,408 bytes and it is painfully slow sending larger attachments. So Gmail offers a secondary system to receive those larger files when using a browser. TLS 1.3 uses a maximum record size of 2^14 (16,384 bytes), and this is what I have chosen to use in this sample program.
The encryption protocol I have chosen to use in this sample program is RC4. It is fast and its limitations are overcome by using a 256 bit key and relatively large record sizes. The current sample uses a fixed 32 byte key, but the intention is to use TLS 1.3 to establish the network connection in the next version. The Agreed Secret calculated by each party would be used as the key for each file transfer, as the connection is terminated after each file. This results in a different key being used for each file transfer.
To receive a file, start the "RecvFile" program. I have arbitrarily chosen port 1159 to listen on, and "C:\Temp" to store the file. When the file starts to download, the file name will appear in a text box and the text box will be made visible. If the file already exists in the chosen path, an addendum by way of "(x)" will be added to the filename when it is saved.
To send a file, start the "SendFile" program. Enter the location of the receiving program as either an IP address or a domain name. A domain name must be DNS hosted or configured in the "HOSTS" file. Click the "Connect" button, and if successful the status will be reflected in the status bar. Unsuccessful attempts will eventually time out and display an error in the status bar. Next, click on the 3 dots in the upper right corner. This activate a Common Dialog which you can use to navigate and select the file you want to send. Then click the "SendFile" button. There are ample debug messages to visualize the progress and a timer message to tell you how many ms the transfer took.
J.A. Coutts