GB2622761A

GB2622761A - Methods of Transmitting and Receiving Files

Info

Publication number: GB2622761A
Application number: GB2207283.9A
Authority: GB
Inventors: John Ellis Timothy; David Thornewill John
Original assignee: Zappaty Ltd
Current assignee: Zappaty Ltd
Priority date: 2022-05-18
Filing date: 2022-05-18
Publication date: 2024-04-03
Also published as: GB202207283D0

Abstract

A method of transmitting a file archive 102 across a network, the method comprising: transmitting a series of sections 104a, 104b, 104c, 104d, 104e, 104f of the file archive and transmitting a corresponding series of calculable identifiers, each of the calculable identifiers being for verifying a respective one of the sections, wherein each calculable identifier is formed by a method comprising performing an operation (e.g. hash or checksum) on all of the sections in the series that precede the identifier’s respective section. A method of receiving a file archive over a network, the method comprising: receiving a series of sections of the file archive and receiving a corresponding series of calculable identifiers, each of the calculable identifiers being for verifying a respective one of the sections, and verifying each one of the sections by comparing the respective calculable identifier with a blockchain value formed by a method involving performing an operation on all of the sections in the series that precede the respective section. The file archive may be encrypted with a key wherein the key is generated by: accessing a stored number sequence; selecting a number from the number sequence; and optionally hashing the number to form the key.

Description

METHODS OF TRANSMITTING AND RECEIVING FILES

Technical Field

The present disclosure relates to transmitting and receiving files over a network, and particularly, but not exclusively, a file sharing system.

Background

Many modern applications generate very large files and these pose significant issues when several users collaborate to modify the files or the files need to be sent across the internet. In some cases, the files are so large that the only reasonable option for transmission is to copy them onto a removeable hard drive and to use a courier to physically transport the drive to the destination. Further difficulties occur when such files need to be transmitted across an unreliable, insecure or slow internet connection. Further, files are at risk of tampering and/or errors being introduced when in transit across the internet.

Therefore, a more reliable and secure method of transmitting files is desired. 20 Summary There is provided a method of transmitting a file archive across a network, the method comprising: transmitting a series of sections of the file archive and transmitting a corresponding series of calculable identifiers, each of the calculable identifiers being for verifying a respective one of the sections, wherein each calculable identifier is formed by a method comprising performing an operation on all of the sections in the series that precede the identifier's respective section.

The operation may be a cryptographic operation. The operation may be a one-way operation, such as a checksum or hash. In this way, the security is increased as the sections cannot be recreated from the calculable identifiers. The operation may be a cryptographic, one-way operation, such as a hash.

The calculable identifiers may each be a verification hash and performing an operation may comprise hashing. The following examples, optional features and embodiments described in the specification describe the use of verification hashes as calculable identifiers and hashing as performing the operation and a hash as a result of performing the operation.

Each described example, embodiment and optional feature is not limited to its use in combination with verification hashes, hashing and/or hashes. Instead, each described example, embodiment and optional feature also applies broadly to calculable identifiers, performing an operation, and/or the result of said operation.

Each of the verification hashes may be formed by hashing a combination of a hash of the respective section and the previous section's verification hash. In this way, because the verification hash is cumulatively changed by including the hash of each section in the series, each verification hash is formed using input from the hashes of all preceding sections in the series and a hash of its own contents.

In other words, each of the calculable identifiers may be formed by performing the operation on a combination of a result of the operation of the respective section and a result of the operation on the previous section. In this way, because the calculable identifier is cumulatively changed by including the result of the operation of each section in the series, each calculable identifier is formed using input from the results of performing the operation on all preceding sections in the series and the result of performing the operation on its own contents.

For example, the verification hash for section n may be formed by hashing a combination of the verification hash for section n-1 and a hash of section n. The verification hash for the first section in the series may comprise a hash of the first section.

In this application, adding or combining may refer to any method of combining.

In other embodiments, each of the verification hashes may be formed by hashing a combination of all the sections in the series preceding the respective section. In other embodiments, each of the verification hashes may be formed by hashing a combination of all the sections in the series preceding the respective section and the respective section.

The verification hashes may be used by a receiver of the file archive to verify that the file archive has been transmitted without interruption or alteration.

Transmitting the files in sections utilising the verification hashes including information from all preceding sections ensures that if any single bit of data in a section of the file archive is changed during transmission, then the verification hash of that section and all subsequent sections will be affected. This means that all subsequent sections will not be verifiable using the verification hashes and the receiver can accurately identify changes and tampering of the file sections and take appropriate action. Further, this method of transmitting files in sections means that if any one section fails due to connectivity issues then only that section needs to be re-transmitted. This enables the safe and secure transmission of very large files.

The method may further comprise: splitting the file archive into the series of sections.

The sections may each have a size of over 1000 bytes. The series of sections may comprise more than three sections.

Each of the hashes may have a size of less than 100 characters, preferably 64 characters and/or 512 bit or 256 bit. The hashes may be SHA-256 hashes, for example, or any other types of hash or checksum. Alternatively, other SHA-2 or SHA-3 hash functions may be utilised.

The method may further comprise compressing the file archive. The step of compressing the file archive may be performed before the step of splitting the file archive into sections.

In this specification, a device sending the file archive may be referred to as the sender device. A device receiving the file archive may be referred to as the receiver device.

Optionally, the method may further comprise encrypting each communication from a sender device transmitting the file archive to a receiver device receiving the file archive and decrypting each communication from the receiver device to the sender device. The encrypting and decrypting steps may utilise an end-to-end encryption technique.

Encrypting and decrypting may each comprise: generating a key, wherein generating the key comprises: accessing a number sequence, selecting a number from the number sequence, and optionally, hashing the number to form the key.

Selecting the number may comprise: when the communication to be encrypted is the first communication between a sender device transmitting the file archive and a receiver device, accessing sub-set parameters indicating a sub-set of numbers of the number sequence, forming a sub-set sequence consisting of the sub-set of numbers of the number sequence, and selecting the first number of the sub-set, and when the communication to be encrypted is not the first communication between a sender device and a receiver device: selecting a number at the subsequent position of the sub-set sequence from the number used in the preceding communication between the sender and receiver device.

The first number in the sub-set, may be considered as subsequent to the last number in the sub-set. In this way, the sub-set is reused until the sub-set parameters are updated.

The number sequence may be stored at the sender and at the receiver device. Alternatively, the number sequence may be generatable at the sender and at the receiver device. Rules for creating the number sequence may be stored at the receiver and sender device and/or included in the sub-set parameters. The sub-set parameters may be generated at a server which may be either the sender device or the receiver device and the sub-set parameters may be sent by the server to the other of the sender or receiver device. In this way, the sender and receiver encrypt each communication between the two devices with a new key, based on a sub-set of a number sequence stored at the sender and at the receiver. In this way, security of the communication is improved.

The number sequence may be any sequence of numbers as long as both the sender and receiver device have the same number sequence. For example, the number sequence could be the prime numbers.

The sub-set parameters may comprise a start parameter indicating the number index of the number sequence at which the sub-set starts. The sub-set parameters may comprise a length parameter indicating the amount of numbers of the sub-set. The sub-set parameters may comprise an end parameter indicating the number index of the number sequence at which the sub-set ends.

Communications from the sender device to the receiver device may comprise: sending one of the sections of the file archive, sending the manifest, sending a verification check signal asking the receiver for verification of one of the sections, sending an initiation signal to begin a communication session, and/or sending a connection check signal to check the connection between the sender and receiver device.

Optionally, the network may be the internet.

Optionally, the method may further comprise sending one or more hashes of device and/or user identifiers. The device and/or user identifiers may include a user ID code, of the device, a device ID code, and/or a unique signature stored on the device. Optionally, the method may further comprise forming the one or more hashes of device and/or user identifiers.

Optionally, the method may further comprise receiving one or more hashes of device and/or user identifiers. The device and/or user identifiers may include a user ID code, a Dynamic Link Library of a software component of the device, DLL, a device ID code, and/or a unique signature stored on the device. Optionally, the method may further comprise verifying a source device by verifying the one or more hashes of device and/or user identifiers. The verification may be performed by comparing the hash(es] with a stored table of device and/or user identifiers.

For example, where a server is the receiver/sender device and a user device is the sender/receiver device, the server may receive the device and/or user identifiers from the user device and the server may use the device and/or user identifiers to verify the user device.

The method may comprise producing a hash of the file archive. The step of producing a hash of the file archive may be performed before or after compressing the file archive. The step of producing a hash of the file archive may be performed before splitting the file archive into sections.

The method may further comprise transmitting the hash of the file archive. The method may comprise transmitting the hashes of each of the sections. The method may comprise transmitting a manifest comprising the hash of the file archive and/or the verification hashes of each of the sections and/or the hash of the device and/or user identifier(s).

The verification hashes and/or hash of the file archive may be formed before transmitting the sections. The manifest may be transmitted before transmitting the sections. In some embodiments, each section in the series is transmitted after a sender device receives a verification signal from the receiver device for the preceding section in the series, indicating that the preceding section was verified. If the sender device receives an unverified signal from the receiver device, no further sections are transmitted. In this way, if any section is damaged or tampered with during transmission, the transmission of the sections is stopped. The system and/or user may then begin the process of transmitting the file archive again. In this way, time and resource is not wasted in transmitting sections after the damaged/altered section as the verification of the sections happens during the transmission process. As soon as a potential security issue arises, the process is stopped.

However, if a connection issue arises meaning that one of the sections does not arrive at the server, then no unverified signal is received by the sender device. The sender device may transmit the undelivered section again and the transmission of sections may continue. This advantageously means that if connection issue arise, the process need not begin again. All of the already-verified sections are retained at the receiver device and the sender can continue the transmission of the remaining sections.

There is further provided a method of transmitting a plurality of files, the method comprising: compiling a file archive from the plurality of files, and transmitting the file archive according to a method of transmitting a file archive as described above. Alternatively, the file archive may comprise only one file.

The file(s) may comprise software, for example, gaming software, such as Unity® files. The files may comprise medical images, CAD files, Al software and/or Al models.

There is further provided a method of receiving a file archive over a network, the method comprising: receiving a series of sections of the file archive and receiving a corresponding series of calculable identifiers, each of the calculable identifiers being for verifying a respective one of the sections, and verifying each one of the sections by comparing the respective calculable identifiers with a blockchain value formed by a method comprising performing an operation on all of the sections in the series that precede the respective section.

The examples, optional features and embodiments described in the specification describe the use of verification hashes as calculable identifiers, and hashing as performing the operation and hash as a result of performing the operation. It will be understood that each example, embodiment and optional feature is also applicable to any form of calculable identifier and corresponding operation and the result of said operation.

For example, the operation may be a cryptographic operation. The operation may be a one-way operation, such as a checksum or hash. In this way, the security is increased as the sections cannot be recreated from the calculable identifiers. The operation may be a cryptographic, one-way operation, such as a hash.

The calculable identifiers may each be a verification hash and performing an operation may comprise hashing. The blockchain value for each of the sections may be formed by hashing a combination of a hash of the respective section and the previous section's verification hash/blockchain value. In this way, because the blockchain value is cumulatively changed by including the hash of each received section in the series, and each blockchain value is formed using input from the hashes of all preceding sections in the series and a hash of its own contents.

For example, the blockchain value for section n may be formed by hashing a combination of the blockchain value for section n-1 and a hash of section n. The blockchain value for the first section in the series may comprise a hash of the first section.

In other embodiments, each of the blockchain values may be formed by hashing a combination of all the sections in the series preceding the respective section. In other embodiments, each of the blockchain values may be formed by hashing a combination of all the sections in the series preceding the respective section and the respective section.

When the calculated blockchain value matches the verification hash for a section, the section is verified and a verification signal may be sent to a sender device. In some embodiments, each section in the series is received after the sender device received the verification signal for the preceding section in the series.

When the calculated blockchain value does not match the verification hash for a section, the section is unverified and an unverified signal may be sent to a sender device. If the sender device receives the unverified signal from the receiver device, no further sections are transmitted. In this way, if any section is damaged or tampered with during transmission, the transmission of the sections is stopped. The system and/or user may then begin the process of transmitting the file archive again. In this way, time and resource is not wasted in transmitting sections after the damaged/altered section as the verification of the sections happens during the transmission process. As soon as a potential security issue arises, the process is stopped.

However, if a connection issue arises meaning that one of the sections does not arrive at the server, then no unverified signal is received by the sender device. The sender device may transmit the undelivered section again and the transmission of sections may continue. This advantageously means that if connection issue arise, the process need not begin again.

All of the already-verified sections are retained at the receiver device and the sender can continue the transmission of the remaining sections.

The manifest may be received before receiving the sections Utilising the blockchain value concept for verification hashes ensures that if any single bit of data in a section of the file archive is changed during transmission, then the blockchain value calculated for that section and all subsequent sections will be affected. This means that all subsequent sections will not be verifiable using the verification hashes and the receiver can accurately identify changes and tampering of the file sections and take appropriate action. Further, if any one section fails due to connectivity issues then only that section needs to be re-transmitted. This enables the safe and secure transmission of very large files.

The verification hashes may be stored in a manifest The sections may each have a size of over 1000 bytes. The series of sections may comprise more than three sections.

Each of the hashes may have a size of less than 100 characters, preferably 64 characters and/or 512 bit or 256 bit. The hashes may be SHA-256 hashes, for example. Alternatively, other SHA-2 or SHA-3 hash functions may be utilised.

Optionally, the method may further comprise decrypting each section. The decrypting step may utilise an end-to-end decryption technique.

Optionally, the method may further comprise encrypting each communication from a receiver device receiving the file archive to a sender device transmitting the file archive and decrypting each communication from the sender device to the receiver device. The encrypting and decrypting steps may utilise an end-to-end encryption technique, such as the encryption techniques described above.

Communications from the receiver device to the sender device may comprise: sending a request for one of the sections of the file archive, sending a request for the manifest, sending a verification signal confirming verification of one of the sections, sending an initiation signal to begin a communication session, and/or sending a connection check signal to check the connection between the sender and receiver device.

Optionally, the method may further comprise receiving one or more hashes of device and/or user identifiers. The device and/or user identifiers may include a user ID code, a Dynamic Link Library of a software component of the device, DLL, a device ID code, and/or a unique signature stored on the device.

Optionally, the method may further comprise verifying a source device by verifying the one or more hashes of device and/or user identifiers. The verification may be performed by comparing the hash(es) with a stored table of device and/or user identifiers.

The method of receiving a file archive may further comprise reconstituting the file archive from the series of sections. Reconstituting the file archive may comprise adding each section to a partial file archive when it is verified, until all sections in the series have been added to complete the file archive.

The method of receiving a file archive may further comprise decompressing the file archive. The step of decompressing the file archive may be performed after the step of reconstituting the file archive from the sections.

The method of receiving a file archive may comprise verifying the file archive. Verifying the file archive may comprise: calculating a hash of the file archive and comparing the calculated hash of the file archive with the stored hash of the file archive. The step of verifying the file archive may be performed after reconstituting the file archive. The step of verifying the file archive may be performed before or after decompressing the file archive.

The method of receiving a file archive may further comprise receiving the hash of the file archive. The method may comprise receiving a manifest comprising the hash of the file archive and/or the verification hashes of each of the sections and/or the hash of the device and/or user identifier(s).

The method of receiving a file archive may comprise receiving all sections in the series. The method of receiving may further comprise, checking that all sections in the series have been received.

The method of receiving the file archive may comprise storing the file archive in a memory.

The memory may be a server-based and/or cloud-based memory.

There is further provided a method of receiving a plurality of files, the method comprising: receiving the file archive according to a method of receiving a file archive as described above, and decompiling the rile archive into the plurality of files. The method of receiving the plurality of files may comprise storing the plurality of files in memory.

There is provided a method of transferring a file archive from a first device to a second device, the method of transferring comprising: transmitting, by The first device, the file archive according to a method of transmitting a file archive described above, and receiving, by the second device, the file archive according to a method of receiving a file archive described above.

There is provided a method of transferring a plurality of files from a first device to a second device, the method of transferring comprising: transmitting, by the first device, the plurality of files according to a method of transmitting a plurality of files described above, and receiving, by the second device, the plurality of files according to a method of receiving a plurality of files described above.

The above-described methods of transferring may further comprise encrypting, by the first device, the file archive or plurality of files using an end-to-end encryption technique, and decrypting by the second device, the file archive or plurality of files.

The first device and the second device may each be any of: a computer, a tablet, a smartphone, a server-based system, a cloud-based system.

There is further provided a device configured to perform a method of transmitting a file archive or plurality of files as described above. There is further provided a device configured to perform a method of receiving a file archive or plurality of files as described above. There is further provided a device configured to perform a method of transmitting a file archive or plurality of files as described above and a method of receiving a file archive or plurality of files as described above There is further provided a system comprising a first device and a second device, the system being configured to perform a method of transferring a file archive or plurality of files described above.

A file sharing system configured to: store files, transmit the files according to a method of transmitting described above, and receive the files according to a method of receiving described above.

The file sharing system may be cloud-based and/or server-based.

The methods described above may be computer-implemented methods.

There is further provided a computer-readable medium having computer-executable instructions adapted to carry out any one of the methods described above.

The methods, devices and systems described above may be combined in any possible combination. The optional features described above are equally applicable to all of the described methods, devices and systems and are not limited to the particular method/device/system with which they are described here. The essential features of any of the methods/devices/systems described may be optional features of any other method/device/system described.

Further features and advantages of the aspects of the present disclosure will become apparent from the claims and the following description.

Brief Description of Drawings

Embodiments of the present disclosure will now be described by way of example only, with reference to the following diagrams, in which:-Fig. 1 is a diagrammatic representation of a method of transmitting a plurality of files; Fig. 2 is a flow chart illustrating part of the method of transmitting a plurality of files of Fig. 1; Fig. 3 is a flow chart illustrating part of the method of transmitting a plurality of files of Fig. 1; Fig. 4 is a flow chart illustrating a method of receiving the plurality of files transmitted in Fig. 2 and Fig 3.

Detailed Description

A number of different embodiments of the disclosure are described subsequently. In order to minimise repetition, similar features of the different embodiments are numbered with a common two-digit reference numeral and are differentiated by a third digit placed before the two common digits. Such features are structured similarly, operate similarly, and/or have similar functions unless otherwise indicated.

In this example, a computer is described transmitting a plurality of files to a server-based device which receives the plurality of files. However, it will be appreciated that, in use, the server-based device is also configured to transmit the files to the computer which will then receive the files and further, the server-based device is configured to receive/transmit files from/to other devices. In this way, the transmission and receipt methods can be utilised in a file sharing/storage system.

Fig. 1 shows a diagram of a plurality of files 100, 101 being transmitted. The files 100, 101 are gaming software files, for example, Unity® files. The files 100 and 101 are compiled into a compressed file archive 102. The file archive 102 is encrypted to form encrypted archive 103. The key for the encrypted file archive 103 is generated by hashing file archive 102.

The encrypted compressed file archive 103 is then split into a plurality of sections 104a, 104b, 104c, 104d, 104e, 104E Sections 104a-f are then encrypted and transmitted as encrypted sections 105a-E The encryption process is described in more detail with reference to Figs. 2 and 3.

The process 200 shown in the flow chart of Fig. 2 generates sections 104a-104f and the verification hashes to be used as encryption keys for each encrypted section 105a-E In this example, this process is carried out by a computer.

In steps 201 and 202, the plurality of files 100, 101 are compiled into file archive 102. Where only one file is to be transmitted, step 201 may be omitted and the file simply becomes the file archive which is then compressed in step 202. Steps 201 and 202 may be combined by adding files directly into a compressed archive.

S

In step 203, a hash is calculated for compressed file archive 102. The file archive hash is stored in a manifest file. The file archive 102 is encrypted using the file archive hash as the key. This adds a further level of security to the transmission.

The method also includes calculating a hash of device and/or user identifiers and storing the hashes of device and/or user identifiers in the manifest file. The device and/or user identifiers include a user ID code, a Dynamic Link Library, of a software component of the device, DLL, a device ID code, and a unique signature stored on the computer. Each of the hashes have a size of less than or equal to 64 characters.

At step 204, the compressed file archive 103 is split into sections 104a-f. Six sections are illustrated in Fig. 1, but it will be understood that many more sections could be formed for large file archives. Each section has a size of over 1000 bytes and less than 1,048,576 bytes. In other embodiments, the sections may be of any size.

At step 205, the first section is hashed to form the verification hash for section 105a. The first verification hash is stored in the manifest file. The first verification hash also becomes the first blockchain value which will be used in generating verification hashes for subsequent sections at step 206.

Then, following steps 207, 208, 209 and 210, verification hashes are generated for the remaining sections 104b-f to be used as keys for encrypted sections 105b-f.

At step 207, the next section 104b is hashed. At step 208, this hash is added to the blockchain value and the combination is hashed to form the verification hash for section 105b. The verification hash is added to the manifest At step 209, the verification hash is set as the blockchain value and at step 210, the process is moved onto the next section. By using the blockchain value, each verification hash is based on the contents of the current section and all preceding sections in the series.

The manifest and the sections are then transmitted over the network to the server-based device.

The method also includes calculating a hash of device and/or user identifiers and storing the hashes of device and/or user identifiers in the manifest file. The device and/or user identifiers include a user ID code, a Dynamic Link Library of a software component of the device, DLL, a device ID code, and a unique signature stored on the computer. Each of the hashes have a size of less than or equal to 64 characters. These device and/or user identifiers are used by the receiver device to verify the sender device or the sender device to verify the receiver device. For example, where a server is the receiver/sender device and a user device is the sender/receiver device, the server uses the device and/or user identifiers to verify the user device.

Each section and the manifest are transmitted using end-to-end encryption. This process is described in more detail in relation to Fig. 3 and process 300.

At step 301, the manifest is encrypted and transmitted to the receiver device. Then, following steps 302 to 306, each of the sections is encrypted and transmitted to the receiver device.

At step 302, the system starts at the first section 104a and encrypts the section 104a at step 303, using the first verification hash, generated in process 200. At step 304, the encrypted section 105a is transmitted to the receiver device The process of transmitting sections is then paused to wait for a verification signal from the receiver device confirming that the section has been received and verified. If an unverified signal is received from the receiver device, no further sections are transmitted. In this way, if any section is damaged or tampered with during transmission, the transmission of the sections is stopped. The system and/or user may then begin the process 200 and 300 of generating hashes and transmitting the file archive again. In this way, time and resource is not wasted in transmitting sections after the damaged/altered section as the verification of the sections happens during the transmission process. As soon as a potential security issue arises, the process is stopped.

However, if a connection issue arises meaning that one of the sections does not arrive at the server, then no unverified signal is received. The sender device may transmit the undelivered section again at step 304, then receive the verified signal and the transmission of sections may continue. This advantageously means that if connection issue arise, the process need not begin again. All of the already-verified sections are retained at the receiver device and the sender can continue the transmission of the remaining sections.

The process of verification at the receiver device will be described in more detail later with reference to Fig. 4.

When the receiver device receives verification that the first section was received and verified, at step 305, the process moves on to the next section at step 306 and begins the encryption of the next section at step 303.

The process 400 of receiving the file archive at the receiver device begins with receiving the manifest file at step 401. The manifest is decrypted and the sender device is then verified by comparing the hashes of the device and/or user identifiers with a stored table of device and/or user identifiers. When the sender device is authenticated, the receiver device is able to receive the first section at step 402.

The first section is received, decrypted and then hashed at step 402. The blockchain value at the receiver device is then set to the hash of the first section.

At step 403, the blockchain value is compared with the verification hash of the first section which is stored in the manifest to verify the first section. If the verification is successful, a verification signal is sent to the sender device. This triggers the sender device to begin encrypting and sending the next section.

The receiver device then moves to the next section at step 404 and receives the section at step 405. The received section is decrypted and hashed and the hash is added to the previous blockchain value and hashed to form the new blockchain value.

S

At step 403 the current section is verified against its verification hash, stored in the manifest and verification is sent to the sender device if the verification is successful.

If the verification is not successful, an unverified signal is sent to the sender device and the transmission of section of file archive is stopped.

The process in steps 403, 404 and 405 continues until all section have been received and verified.

Received sections may be stored in a partial archive as they are received. Once the partial archive contains all of the sections and so becomes the received file archive, the file archive is decrypted using the file archive hash stored in the manifest at step 406.

The file archive is then optionally decompressed at step 407 and stored at step 408.

The encryption of communications between the sender and receiver devices will now be described.

Each communication from a sender device transmitting the file archive to a receiver device receiving the file archive is encrypted by the sender device and decrypted upon receipt at the receiver device. Each communication from the receiver device receiving the file archive to the sender device transmitting the file archive is encrypted by the receiver device and decrypted upon receipt at the sender device.

The encrypting and decrypting steps utilise an end-to-end encryption technique.

The sender and receiver devices each have access to a number sequence. Each communication is encrypted using a generated a key. The key is generated by accessing the stored number sequence, selecting a number from the number sequence, and hashing the number to form the key. The sender and receiver devices have access to the same number sequence and each know the rules for generating the key and so each device is able to know the key without directly sharing the key.

When the communication to be encrypted is the first communication between a sender device and a receiver device, the server (which forms either the sender or receiver device in each file transfer) generates sub-set parameters which indicate a sub-set of numbers of the number sequence. The sub-set parameters include a start parameter indicating the number index of the number sequence at which the sub-set starts. The sub-set parameters also include a length parameter indicating the amount of numbers of the sub-set or an end parameter indicating the number index of the number sequence at which the sub-set ends.

The sender device and the receiver device each access the sub-set parameters and form a sub-set sequence consisting of the sub-set of numbers of the number sequence.

The sender device then selects the first number of the sub-set and hashes the number to form the key for the first communication.

After the first communication, the device sending the communication selects a number at the subsequent position of the sub-set sequence from the number used in the preceding communication between the sender and receiver device. The first number in the sub-set, is considered as subsequent to the last number in the sub-set so that the sub-set is reused until the sub-set parameters are updated.

The number sequence may be stored at the sender and at the receiver device. Alternatively, rules for creating the number sequence may be stored at the receiver and sender device and/or sent with the sub set parameters. The number sequence may be any sequence of numbers as long as both the sender and receiver device have the same number sequence. In this example, the number sequence is the prime numbers.

Communications from the sender device to the receiver device include: sending an initiation signal to begin a communication session, sending the manifest, sending one of the sections of the file archive, sending a verification check signal asking the receiver for verification of one of the sections, and/or sending a connection check signal to check the connection between the sender and receiver device.

Although particular embodiments of the disclosure have been disclosed herein in detail, this has been done by way of example and for the purposes of illustration only. The aforementioned embodiments are not intended to be limiting with respect to the scope of the appended claims.

It is contemplated by the inventors that various substitutions, alterations, and modifications may be made to the invention without departing from the scope of the invention as defined by the claims.

Claims

CLAIMS1. A method of transmitting a file archive across a network, the method comprising: transmitting a series of sections of the file archive and transmitting a corresponding series of calculable identifiers, each of the calculable identifiers being for verifying a respective one of the sections, wherein each calculable identifier is formed by a method comprising performing an operation on all of the sections in the series that precede the identifier's respective section.
2. A method of transmitting a file archive according to claim 1, wherein each of the calculable identifiers are formed by performing the operation on a combination of a result of performing the operation on the respective section and a result of performing the operation on the previous section.
3. A method according to claim 1 or claim 2, wherein each of the calculable identifiers are verification hashes, and performing the operation comprises hashing.
4. A method of transmitting a file archive according to any preceding claim, the method further comprising: encrypting each communication from a sender device transmitting the file archive to a receiver device receiving the file archive and decrypting each communication from the receiver device to the sender device.
5. A method of transmitting a file archive according to claim 4, wherein encrypting and decrypting each comprise: generating a key, wherein generating the key comprises: accessing a stored number sequence, selecting a number from the number sequence, and optionally, hashing the number to form the key.
6. A method of transmitting a file archive according to claim 5, wherein selecting the number comprises: when the communication to be encrypted is the first communication between a sender device transmitting the file archive and a receiver device, accessing sub-set parameters indicating a sub-set of numbers of the number sequence, forming a sub-set sequence consisting of the sub-set of numbers of the number sequence, and selecting the first number of the sub-set, and when the communication to be encrypted is not the first communication between a sender device and a receiver device: selecting a number at the subsequent position of the sub-set sequence from the number used in the preceding communication between the sender and receiver device.
7. A method of transmitting a file archive according to any preceding claim, the method further comprising: sending one or more hashes of device and/or user identifiers, wherein the device and/or user identifiers include a user ID code, a device ID code, and/or a unique signature stored on the device.
8. A method of transmitting a file archive according to any preceding claim, the method further comprising: transmitting a manifest file comprising the hash of the file archive and/or the calculable identifiers of each of the sections and/or the hash of the device and/or user identifier(s).
9. A method of transmitting a file archive according to any preceding claim, wherein each section in the series is transmitted after a sender device transmitting the file archive to a receiver device, receives a verification signal from a receiver device for the preceding section in the series, indicating that the preceding section was verified.
10. A method of transmitting a plurality of files, the method comprising: compiling a file archive from the plurality of files, and transmitting the file archive according to the method of any preceding claim.
11. A method according to claim 10, wherein the files are Unit y® files.
12. A method of receiving a file archive over a network, the method comprising: receiving a series of sections of the file archive and receiving a corresponding series of calculable identifiers, each of the calculable identifiers being for verifying a respective one of the sections, and verifying each one of the sections by comparing the respective calculable identifier with a blockchain value formed by a method comprising: performing an operation on all of the sections in the series that precede the respective section.
13. A method according to claim 12, wherein the blockchain value for each of the sections is formed by performing the operation on a combination of a result of performing the operation on the respective section and the previous section's calculable identifier or blockchain value.
14. A method according to claim 12 or 13, wherein when the calculated blockchain value matches the calculable identifier for a section, the section is verified and a verification signal is sent to a sender device.
15. A method according to any one of claims 12 to 14, wherein when the calculated blockchain value does not match the calculable identifier for a section, the section is unverified and an unverified signal is sent to a sender device.
16. A method according to any one of claims 12 to 15, the method further comprising: receiving a manifest comprising: a hash of the file archive and/or the calculable identifier of each of the sections and/or the hash of the device and/or user identifier(s).
17. A method according to any one of claims 1 to 16, the method further comprising encrypting each communication from a receiver device receiving the file archive to a sender device transmitting the file archive and decrypting each communication from the sender device to the receiver device.
18. A method according to claim 17, wherein encrypting and decrypting each comprise: generating a key, wherein generating the key comprises: accessing a stored number sequence, selecting a number from the number sequence, and optionally, hashing the number to form the key.
19. A method according to claim 18, wherein selecting the number comprises: when the communication to be encrypted is the first communication between a sender device transmitting the file archive and a receiver device, accessing sub-set parameters indicating a sub-set of numbers of the number sequence, forming a sub-set sequence consisting of the sub-set of numbers of the number sequence, and selecting the first number of the sub-set, and when the communication to be encrypted is not the first communication between a sender device and a receiver device: selecting a number at the subsequent position of the sub-set sequence from the number used in the preceding communication between the sender and receiver device.
20. A method according to any of claims 12 to 19, wherein each of the calculable identifiers are verification hashes, and performing the operation comprises hashing.
21. A method of receiving a plurality of files, the method comprising: receiving a file archive according to a method of receiving a file archive according to any of claims 12 to 20, and decompiling the file archive into the plurality of files.
22. A method of transferring a file archive from a first device to a second device, the method of transferring comprising: transmitting, by the first device, the file archive according to the method of any of claims 1 to 9, and receiving, by the second device, the file archive according to the method of any of claims 12 to 20.S
23. A device configured to perform a method of transmitting a file archive according to the method of any of claims 1 to 9.
24. A device configured to perform a method of receiving a file archive according to the method of any of claims 12 to 20.
25. A device configured to perform a method of transmitting a file archive according to the method of any of claims 1 to 9, and a method of receiving a file archive according to the method of any of claims 12 to 20.
26. A system comprising a first device and a second device, the system being configured to perform a method of transferring a file archive according to claim 22.
27. A file sharing system configured to: store files, transmit files in a file archive according to the method of any of claims 1 to 9, and receive files in a file archive according to the method of any of claims 12 to 20.