Method and system for non-algorithmic encryption

Abstract

A method of combining arbitrarily defined replacement maps 100, 1102, 1103 for substituting byte values 101, 205 of input to produce ciphertext 1105. Each byte of plaintext is encrypted by a unique se

Description

TECHNICAL FIELD

[0001] The present disclosure relates to symmetrical encryption method with ciphertext that is insusceptible to cryptanalysis. BACKGROUND

[0002] Algorithm-based methods of encryption are potentially susceptible to breaking with enough computing power or by undiscovered flaws, which could be derived in the near future with the help of Al powered by Quantum Computers. In time, governments, private enterprises and rouge actors across the globe will gain access to increasingly vast amounts of computing power and ever more advanced tools for cryptanalysis.

[0003] Scientists work to develop encryption mechanisms with use of Quantum Computing to counter potential cracking by Quantum Computers. Costs of implementing such inventions will be inflated by: • limited access to knowledge and intellectual property; • small pool of qualified workforce; • materials and maintenance; • power consumption; • environmental impact.

[0004] The need arises for encryption method that can be trusted to be impenetrable by its sole properties. The solution is to abstain from using encryption algorithms altogether and instead create a method of efficient storage and processing of non-algorithmic replacement maps. SUMMARY

[0005] The present disclosure addresses the problem of storing an exponential number of replacement maps in a relatively small and composite encryption key, for the purpose of having non-algorithmic encryption method.

[0006] A ciphertext encrypted with the disclosed method is impossible to break without access to the encryption key, because the encryption is not based on any algorithm. There is no logic to be discovered by analysing the ciphertext. The replacement maps have to be known to decrypt the file.

[0007] Addressable maps materialise at runtime by combining different elements of the encryption key. Each byte of plaintext is replaced using a different combination of replacement maps.

[0008] The properties of the method allow to use multiple CPU threads concurrently, making the invention scalable. The method is future proof, voiding all attempts to store encrypted files today, hoping to break them in the future.

[0009] The method is easy to understand, cheap and quick to implement. It has a great potential for providing lasting security, no matter the technological advances. It would offer an exit from the cost-inflating race to beat increasingly advanced Al in the advent of Quantum Computing.

[0010] The present disclosure also includes a system for convenient use of the method, including multi-device sharing of the same encryption key, and automated or semi-automated key renewals.

[0011] Another aspect of the present disclosure provides optional automation of encryption-decryption by synchronising directories, while using third-party software for sharing and synchronising encrypted content over the unsecure network.

[0012] Additional aspects, features and advantages of the present disclosure are delineated on the drawings and in the detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The drawings predominantly refer to logical concepts and processes. When referring to physical objects, drawings are not to scale, which will be understood by knowledgeable in the field.

[0014] Whenever possible, the same elements on different drawings are indicated by the same numbers.

[0015] Throughout the present disclosure, both in drawings and detailed description, a simplification was made to use a range of values from 0 to 4 instead of from 0 to 255, to make the drawings more compact and easier to comprehend. In every case a range of values from 0 to 4 is referring to all possible values of a byte, that is a range from 0 to 255.

[0016] The terms “plaintext” and “ciphertext” are common terms in cryptography and are often used throughout the present disclosure. These terms refer to “not encrypted” and “encrypted” computer data respectively. The aforementioned data doesn’t have to be textual, but can be binary as well, for example image, video, audio, compiled software or compressed archives. All types of computer files can be encrypted using the method.

[0017] Embodiments of the present disclosure are described, by the way of example only, with reference to the following diagrams wherein: FIG. 1 is an exemplary replacement map where every possible byte value has one respective replacement value, in accordance with embodiments of the present systems and methods. FIG. 2 is an exemplary set of three consecutive replacements maps, where each is applicable to a different byte, in accordance with embodiments of the present systems and methods. FIG. 3 is an exemplary high-level encryption flow, in accordance with embodiments of the present systems and methods. FIG. 4 is an exemplary encryption key and its components, in accordance with embodiments of the present systems and methods. FIG. 5 is an exemplary archive file comprising ciphertext and encryption metadata, in accordance with embodiments of the present systems and methods. FIG. 6 is an exemplary high-level flow of a claiming method with a local storage for claims, in accordance with embodiments of the present systems and methods. FIG. 7 is an exemplary high-level flow of a claiming method with external storage for claims in online mode, in accordance with embodiments of the present systems and methods. FIG. 8 is an exemplary high-level flow of a claiming method with external storage for claims in offline mode, in accordance with embodiments of the present systems and methods. FIG. 9 is a schematic view of exemplary replacement maps stored in a file, shown separated for demonstration purposes and in accordance with embodiments of the present systems and methods. FIG. 10 is a schematic view of exemplary replacement maps stored in a file, shown as a unified sequence of bytes as they are actually stored, in accordance with embodiments of the present systems and methods. FIG. 11 is an exemplary byte encryption flow in a dynamic replacement map composed of combined encryption key components, in accordance with embodiments of the present systems and methods. FIG. 12 is an exemplary byte decryption flow in a dynamic replacement map composed of combined encryption key components, in accordance with embodiments of the present systems and methods. FIG. 13 is an exemplary component of the encryption key in a state with the first element active and other elements inactive as dynamic replacement map components, in accordance with embodiments of the present systems and methods. FIG. 14 is an exemplary component of the encryption key in a state with the second element active and other elements inactive as dynamic replacement map components, in accordance with embodiments of the present systems and methods. FIG. 15 is an exemplary byte encryption flow in a dynamic replacement map composed of combined encryption key components, where one of the dynamic elements was updated, in accordance with embodiments of the present systems and methods. FIG. 16 is an exemplary component of the encryption key before in-memory elements shift, which enforces method integrity between encryptions of different files, in accordance with embodiments of the present systems and methods. FIG. 17 is an exemplary component of the encryption key after in-memory elements shift, which enforces method integrity between encryptions of different files, in accordance with embodiments of the present systems and methods. FIG. 18 is a schematic view of an exemplary runtime object serving a purpose of concurrent operations, in accordance with embodiments of the present systems and methods. FIG. 19 is an exemplary flowchart of encryption process with local software steps delineated, in accordance with embodiments of the present systems and methods. FIG. 20 is an exemplary flowchart of decryption process with local software steps delineated, in accordance with embodiments of the present systems and methods. FIG. 21 is an exemplary flowchart of encryption process with claiming method using external storage for claims in online mode, in accordance with embodiments of the present systems and methods. FIG. 22 is an exemplary flowchart of encryption process with claiming method using external storage for claims in online mode, while triggering and performing a key renewal, in accordance with embodiments of the present systems and methods. FIG. 23 is an exemplary optional method of generating encryption key components by using input files instead of random generator, enabling creating of identical keys in different places without sharing a complete key, in accordance with embodiments of the present systems and methods. FIG. 24 is an exemplary automated encryption and decryption by a background process while synchronising directories, in accordance with embodiments of the present systems and methods. DETAILED DESCRIPTION

[0018] Throughout the present disclosure a convention is used for names describing functional software embodiments and logical concepts or processes.

[0019] Functional objects: double quoted in pascal case i.e. every word starting with a capital letter, without spaces, e.g. “FunctionalObject”. Logical concepts or processes: double quoted in lowercase with spaces, e.g. “logical concept”. Conventional names known in the field are written without special formatting e.g. zip, json, tar etc.

[0020] A convention for lists in the present disclosure is that where order needs to be noted, points are marked by letters in alphabetical order, and where nested, by Roman numerals in lowercase. In lists where order is insubstantial the points are marked by bullet points.

[0021] Referring to FIG. 1, illustrated is a diagram of an exemplary “replacement map” 100, which is a logical concept referring to mapping of byte values to arbitrary integers. Each potential value of a byte has a corresponding replacement value. 101 is a “list of potential input byte values”. 102 is an exemplary “list of replacement values”. The 101 is of the same length as the 102. Every 101 and every 102 is a list of 256 integers, shown simplified for the demonstration in FIG. 1 as lists of 5 integers in range from 0 to 4.

[0022] The integers in both 101 and 102 are in a range starting from 0 and ending at 255 - which covers all possible values any byte can have. Values in 101 are sorted in ascending order, i.e. from the lowest to the highest. Values in 102 are positioned arbitrarily and their placement can be generated randomly.

[0023] The 101 is simply an index of 102, i.e. 101 is a list of addresses in which numbers indicate locations of elements in 102, where the first element of 102 has an index of 0, and every next element has index value incremented by one. The important consequence is that for every 100 only 102 requires storage.

[0024] In the exemplary “replacement map” 100, if byte value is 0 it will be replaced with 4. If byte value is 1, it will become 0, etc.

[0025] Referring to FIG. 2, illustrated is a logical view of “Nucleus” 200, which is a component of an encryption key, later referred on FIG. 4 as 400. The 200 is a set of “replacement maps” 100, 201 and 202. Every consecutive byte in a sequence to encrypt is initially replaced by next “replacement map” in 200. The demonstrated sequence of byte values 2 (205), 3 (207), 1 (209) is replaced with a sequence of 1 (206), 4 (208), 4 (210).

[0026] Referring to FIG. 3, illustrated is a high-level encryption flow 300. In the first step 301 the size of the plaintext file is assessed, which determines the number of “dynamic replacement maps” that are needed to encrypt the file. The “dynamic replacement maps” are combinations of “replacement maps” from different key components, and are explained later in FIGS. 11-12 and 15. The number of bytes in the plaintext file equals the number of “dynamic replacement maps” needed for encryption.

[0027] In the 302 step a claim is made to obtain a range of addresses to “dynamic replacement maps” from an encryption key 400. The purpose of the claim is to establish what range of “dynamic replacement maps” has not been used yet, and block that range from use by any future encryption with the same 400. Each “dynamic replacement map” has a unique address number allowing to find and recreate the “dynamic replacement map” from the encryption key 400 components. That address number is an integer and is later referred to as “global position” throughout the current disclosure. The number of “global positions” defines the encryption key 400 capacity.

[0028] In FIG. 3, the claiming method is abstracted away and will be later described in different variants in FIGS. 6-8, and as part of a wider system in FIGS. 21-22.

[0029] The 303 step is the actual encryption process, and 304 produces an archive file with two components explained later in FIG. 5: ciphertext 501 and “encrypted file metadata” 502.

[0030] Referring to FIG. 4, illustrated is a logical view of an exemplary encryption key 400 with its components. Functional components (407 and 408) and “encryption key metadata” 401 are stored in the same archive file, which is referred to throughout the present disclosure as the encryption key 400. The type of 400 file can be zip, tar or any other conventional type of computer file archive which permits to store and manipulate multiple files inside.

[0031] The 401 is the “encryption key metadata” comprising of: • 402 a version of the software used for creating 400, stored for verifying compatibility of 400 with software it is opened with, and also fortroubleshooting and debugging; • 403 Universally Unique Identifier (UUID) of 400, which will be also embedded in “encrypted file metadata” 502 as shown on FIG. 5. Alternative identification systems can be used e.g. Globally Unique Identifier (GUID) or similar conventional systems for unique labelling; • 404 “encryption key iteration” number - an identifier of the current key iteration, which will also be embedded in “encrypted file metadata” 502 as shown later on FIG. 5. The “encryption key” 400 can be renewed, which will produce another 400 file with the same 403 but with incremented 404 and new functional components 407 and 408. Each individual instance of 400 with the same 403 but different 404 is later called the “encryption key iteration” throughout the present disclosure. The key renewals are described later in the present disclosure by FIG. 22; • 405 is an “encryption key capacity”, i.e. the number of bytes the 400 can encrypt, each by a unique “dynamic replacement map”. Equals to the number of “global positions” in the key; • 406 are optional properties that are not necessary for the method and system to work, for example a timestamp when the key was generated.

[0032] The 407 is the “Nucleus”, which is a set of “replacement maps” like 100, example of which is shown on FIG 2 as 200, but written to file in a compact way. The 407 is stored in a file as a unified sequence of bytes, called a “ByteMapChain” throughout the present disclosure and explained on FIGS. 9-10. The “ByteMapChain” is composed only of “lists of replacement values” like 102.

[0033] The 408 is a set of arbitrary number of “Rotors”. “Rotors” are also sets of “replacement maps” 100 stored in “ByteMapChains” and composed of “lists of replacement values” 102. The 408 is combined with 407 at runtime to compose “dynamic replacement maps” i.e. runtime combinations of 102 from the “Nucleus” and one 102 from each “Rotor”, to create addressable “dynamic replacement maps”, each dedicated to only one byte of plaintext. The logic of mapping bytes through “dynamic replacement maps” is explained in detail on FIGS. 11-12.

[0034] Referring to FIG. 5, illustrated is a diagram of an exemplary archive file 500, generated as a result of the encryption step 303 on FIG. 3. The type of 500 file can be zip, tar or any other conventional type of computer file archive that can store and manipulate multiple files inside. The 501 is the ciphertext and 502 is the “encrypted file metadata”. The 502 is not sensitive, but it can be optionally encrypted with other conventional method like asymmetric RSA algorithm.

[0035] The 502 contains information necessary for a successful decryption: • 402 a version of the software used for encrypting 501, as described for FIG. 4; • 403 identifier of the key 400 used for encrypting 501, as described for FIG. 4; • 404 iteration number of the key 400 used for encrypting 501, as described for FIG. 4; • 503 address of the beginning of the “global positions” range used for encrypting 501; • 504 address of the end of the “global positions” range used for encrypting 501. Alternatively, 504 can be removed from 502 and be derived at runtime from 503 and number of bytes in 501; • 505 optional properties that are not necessary for the present disclosure to work, for example timestamp of the encryption.

[0036] Referring to FIG. 6, illustrated is a high-level flowchart of 600 the claiming method variant with a local storage of claims. Such variant can be used when there is only one encrypting device, while other devices sharing the same encryption key 400 use it only for decrypting.

[0037] With setup consisting of a single encrypting device, the claims don’t have to be synchronised across devices to prevent reusing the same “dynamic replacement maps”, hence the claims can be stored in the encrypting device locally.

[0038] In the first step 601 the method reads the state of current claims from the local device. The information can be stored in a conventional way like json file, database or included as optional data 406 in the “encryption key metadata” 401.

[0039] The 602 step evaluates the requested claim against remaining capacity of 400. In case when there is not enough capacity left, the process will fail 605. In case when there is enough capacity left, the process will continue to 603 claiming of the new range of “global positions” by updating the claims information, preventing the use of the same range for any future encryptions.

[0040] The final step 604 returns the claimed range from the claiming method to the subsequent encryption flow.

[0041] Referring to FIG. 7, illustrated is a high-level flowchart of 700 the claiming method variant with external storage for making claims in online mode. Such variant is used when there are multiple devices using the same 400 for encryptions. The storage has to be external, so all devices can access it in the same way and delegate the claims conflict resolution and synchronisation to a device with external storage holding the information about the claims. The logic of connecting to the external storage and resolving the conflicts is abstracted away in FIG. 7, and will be illustrated in more detail in FIG. 21.

[0042] The first step 701 is to connect to the external storage and read the information on the existing claims. The 702 step evaluates the size of requested claim against remaining capacity of 400. In case when there is not enough capacity left, the process will fail 705. In case when there is enough capacity left, the process will continue to 703 which is claiming of a range of “global positions” by updating the claims information in the external storage, which will prevent the current requesting device and all other devices using the same 400 from reusing the claimed range in the future.

[0043] Finally, the 704 step returns the claimed range from the claiming method to the subsequent encryption flow.

[0044] Referring to FIG. 8, illustrated is a high-level flowchart 800 of the claiming method variant with external storage for making claims similarly to 700 on FIG. 7, however showing an alternative flow in case when encrypting device is not able to connect to the external storage.

[0045] The 800 instead of connecting to external device like 701 on FIG. 7, will work entirely on the encrypting device, by fetching the information about claims from an auxiliary local storage, later called throughout the present disclosure as “offline pool of claimed positions”. The “global positions” in the “offline pool of claimed positions” were claimed from the external storage in advance, so they could be used in the future whenever 800 flow is necessary.

[0046] The “offline pool of claimed positions” can store data about claims in a conventional way similarly to 600 flow, for example in a json file, database or included as optional data 406 in the “encryption key metadata” 401.

[0047] The 801 step extracts the data about previous claims made against the “offline pool of claimed positions”.

[0048] The 802 will assess if the remaining capacity in the “offline pool of claimed positions” is sufficient for the requested encryption. In case when there is not enough capacity left, the process will fail 805. In case when there is enough capacity left, the process will continue to 803 which is claiming of the new range by updating the claims information in the local “offline pool of claimed positions”, which will prevent the requesting device from reusing the same positions in the future.

[0049] The external storage doesn’t have to be updated during or after 800, because all “global positions” in the local “offline pool of claimed positions” were already claimed in the past from the external storage.

[0050] The 804 step returns the claimed range from the claiming method to the subsequent encryption flow.

[0051] Referring to FIG. 9, illustrated is a schematic view 900 of exemplary “ByteMapChain” with individual “lists of replacement values” 102, 203, 204, 901 shown separated on FIG. 9 for demonstration purposes. 900 is a file consisting of unified, not separated sequences of bytes, where every byte belongs to one of “replacement maps”. When 900 is split at runtime to 256-long chunks, it produces the “lists of replacement values” 102, 203, 204, 901.

[0052] Referring to FIG. 10, illustrated is a schematic view 1000 of the same exemplary “ByteMapChain” as in FIG. 9, but with bytes shown in plain unified sequence without any separators, which is how “lists of replacement values” are actually stored.

[0053] Referring to FIG. 11, it illustrates how a byte is encrypted through a “dynamic replacement map” 1100. Firstly, the input byte 205 is replaced by a “replacement map” 100 from the “Nucleus” 407. Next, the 206 value is mapped through a “RotorsSetting” 1101, which is a set of “replacement maps” (1102 and 1103), one from each "Rotor" 408 of the encryption key 400. The order of events for a single byte encryption is: a) Use the plaintext byte value 205 as index value of 102 from the “Nucleus” 407. Obtain 206 as a result; b) Use 206 as index value of “list of replacement values” 1104 from the first “replacement map” 1102 of the first “Rotor”. Obtain 1106 as a result; c) Use 1106 as index value of “list of replacement values” 1105 from the first “replacement map” 1103 of the second “Rotor”. Obtain 1107 as a result.

[0054] In the example FIG. 11 two “Rotors” are used. The number of “Rotors” is arbitrary and can be configured while creating the encryption key 400. The byte mapping process goes from the first to the last “Rotor”, where value coming out from the last mapping is the final ciphertext byte value. As there is no more “Rotors” in FIG. 11 example, the 1107 becomes the final ciphertext byte value. Hence, the plaintext byte value 2 becomes a ciphertext byte value 0.

[0055] The FIG. 11 illustrates encrypting of the first byte from a sequence to encrypt. Every next byte of the plaintext will be replaced by next “replacement map” of the “Nucleus” 407. The “RotorsSetting” 1101 remains static until the process uses the last “replacement map” of the “Nucleus” 407. After reaching such stage, one of the “Rotors” 408 will “rotate”. The “rotation” process is described in FIGS. 13-15.

[0056] Referring to FIG. 12, illustrated is a reversed process from the FIG. 11, so the decryption of the aforementioned ciphertext byte value 1107 back to the plaintext byte value 205.

[0057] The order of events for a single byte decryption is: a) Find the index of the 1107 value in the “list of replacement values” 1105 from the first “replacement map” 1103 of the last “Rotor”. Obtain 1106 as a result; b) Find the index of the 1106 value in the “list of replacement values” 1104 from the first “replacement map” 1102 of the first “Rotor”. Obtain 206 as a result; c) Find the index of the 206 value in the “list of replacement values” 102 from the first “replacement map” 100 from the “Nucleus” 407. Obtain 205 as a result, which is the plaintext byte value.

[0058] The number of “Rotors” in FIG. 12 is exemplary. The byte decryption process goes through all the “Rotors” in reverse order comparing to encryption, and the number of “Rotors” is arbitrarily decided upon creation of the encryption key 400.

[0059] Referring to FIG. 13, illustrated is an exemplary “Rotor” 1300 before the “rotation”. The figure shows a schematic view of a “ByteMapChain” of the first “Rotor” 1300, from which the first “list of replacement values” 1104 is shown in FIGS. 11-12.

[0060] The 1104 is marked as currently active 1301 in the “dynamic replacement map”, meaning that it’s a part for “RotorsSetting” and actively takes part in replacing bytes, as shown by the way of example on FIG. 11.

[0061] On FIG. 13 the “lists of replacement values” 1302 and 1303, are dormant which corresponds to the state of the “dynamic replacement map” 1100 in FIGS. 11-12 where 1302 and 1303 are not present.

[0062] Referring to FIG. 14, illustrated is an exemplary “Rotor” 1400 which represents 1300 “Rotor” after the “rotation”. The figure shows a schematic view of a “ByteMapChain”, where the second “list of replacement values” 1302 is marked as currently active 1301, which corresponds to a state after the “rotation”, i.e. replacing one “Rotor’s” “replacement map” with subsequent “replacement map”, as a component of a “dynamic replacement map”. On FIG. 14 the 1104 and 1303 are dormant, i.e. they are currently not used as part of a “dynamic replacement map”.

[0063] Referring to FIG. 15, illustrated is a byte encryption flow through a “dynamic replacement map” 1500 after “rotation” of the first “Rotor” as shown on FIG. 14, i.e. where 1104 is replaced by 1302 as an element of the “dynamic replacement map”, changing the result of the encryption for the plaintext byte of the same value.

[0064] For the purpose of demonstrating the “rotation” impact on the mapping on FIG. 15, the same “replacement map” 100 from the “Nucleus” 407 is used, and the input plaintext byte value 1504 has the same value as the input plaintext value 205 on the FIG. 11. However, the “dynamic replacement map” 1500 is different from 1100, because of the new “RotorsSetting” 1501, where 1502 replaced the 1102 in comparison of FIG. 15 to FIG. 11. In FIG. 15, the plaintext byte value 2 becomes a ciphertext byte value 4.

[0065] The order of events in the “rotation” while using the examples from FIG. 11 and FIG. 15 with two “Rotors”, is as follows: a) Encryption or decryption progresses using subsequent “Nucleus” 407 “replacement maps” for each byte, with the same static “RotorsSetting” 1101; b) The last “replacement map” of the “Nucleus” 407 is used, and there is still a next pending byte to encrypt or decrypt; c) The first “replacement map” 1102 of the first “Rotor” 409 is replaced in the “dynamic replacement map” with the second “replacement map” 1502 of the first “Rotor” 409. Therefore, the “list of replacement values” 1104 from the first “Rotor” 409, is replaced by the second “list of replacement values” 1302 of the first “Rotor” 409; d) The first “replacement map” 100 of “Nucleus” 407 is used again for the pending byte, with the new “RotorsSetting” 1501.

[0066] After all “replacement maps” of the first “Rotor” 409 are used, the second “Rotor” 410 will “rotate”, which will allow reusing all “replacement maps” of the first “Rotor” 409 again.

[0067] The “Rotors” 408 will continue to “rotate” until all possible combinations of “Nucleus's” and “Rotors’” 408 “replacement maps” are used. Exhausting all combinations marks the end of the encryption key capacity 405, which means that the key 400 can no longer guarantee a different dedicated “dynamic replacement map” for every next byte of plaintext.

[0068] The number of bytes that can be encrypted with an encryption key 400, by dedicated “dynamic replacement map” for each byte, is equal to a product of counts of “replacement maps” in the “Nucleus” 407 and all “Rotors” 408. Hence, the number of “dynamic replacement maps” in an encryption key 400 equals the Cartesian product of counts of “replacement maps” in a “Nucleus” 407 and “Rotors” 408. N- number of “replacement maps” in a “Nucleus” 407 RI - number of “replacement maps” in the first “Rotor” 409 R2- number of “replacement maps” in the second “Rotor” 410 ... - placeholder for arbitrary number of “Rotors” 411 Rn - number of “replacement maps” in the last “Rotor" C - key capacity 405 i.e. a total number of “dynamic replacement maps” in an encryption key 400, which equals the number of “global positions” in the key 400. C = N * RI * R2 *... * Rn

[0069] An encryption key 400 as small as 3 megabytes, can contain “dynamic replacement maps” for 60 gigabytes of data, assuming one-megabyte “Nucleus” plus two “Rotors”, one-megabyte each. By adding one more “Rotor”, the capacity 405 increases to over 200 terabytes. Furthermore, by extending the “Nucleus” from one to two megabytes, the capacity doubles to over 400 terabytes, while the size of 400 is only 5 megabytes.

[0070] Thanks to the exponential nature of combining “Nucleus” 407 with “Rotors” 408, the key capacity 405 is substantial for size of the key 400. Without “Rotors” 408, the “Nucleus” 407 would have to be 256 times longer than the sequence to encrypt, to ensure that every byte is replaced with a dedicated map.

[0071] The size of the key 400 and performance of encryption-decryption can be manipulated by changing the number of “Rotors” 408, their size, and the size of the “Nucleus” 407, as well as utilised hardware. The performance of encryption and decryption is driven by concurrent processing on multiple CPUs. The method enables splitting a file to chunks and encrypting or decrypting them in isolation, then putting together again once all chunks are processed.

[0072] Each “dynamic replacement map” is addressable by a “global position”, which is represented by an integer and is relative to 400 capacity. The first “global position” of 400 points to the first “dynamic replacement map”, while the last “global position” of 400 points to the last “dynamic replacement map” in 400. The number of “global positions” equals the number of bytes that can be encrypted by 400.

[0073] To make sure that the “dynamic replacement maps” are not reused, their utilisation has to be tracked. If the same key 400 is used to encrypt two different files, every byte across both files will be replaced using a different “dynamic replacement map”.

[0074] For example, if a new key 400 is used to encrypt file A of size 8 bytes, the method will use from the first to the eighth “global positions”. If the same 400 is later used to encrypt file B, the file B will be encrypted using “dynamic replacement maps” starting from the ninth “global position”. Therefore, the ninth “dynamic replacement map” will be used for encrypting-decrypting the first byte of the file B.

[0075] The encryption method in the present disclosure relies on claiming a range of “global positions” for every encryption, then storing and accessing that information to prevent reusing the same “global positions” by subsequent encryption processes.

[0076] To decrypt a ciphertext created with the method of the current disclosure, the “global positions” used for creating the ciphertext have to be known, hence their “from-to” range is stored inside the “encrypted file metadata” 502 as explained on the example of FIG. 5 where the first and last “global positions” used for encrypting the file are indicated by 503 and 504 respectively.

[0077] Referring to FIGS. 16-17, illustrated is a schematic view of “lists of replacement values” 102 of exemplary “Nucleus” 407, before (1600) and after (1700) an in-memory shift. The highlighted “list of replacement values” 1602, belongs to the last “replacement map” used for encrypting a previous file. On FIG. 16 “lists of replacement values” 1601, 1602, 1603 and 1604 are in the original order, as stored in the “ByteMapChain” 900 of a “Nucleus” 407. On FIG. 17, the “Iists of replacement values” are shifted, where maps to the right of 1602 were moved to the beginning of 1700, making the 1602 the last “list of replacement values” of the in-memory “Nucleus” 407.

[0078] The reason for the in-memory shift illustrated on FIGS. 16-17 is that every encryption ends on “replacement map” from a “Nucleus” 407 corresponding to the last byte of the plaintext file. Hence, it can be any “replacement map” of the “Nucleus” 407. If encrypting of every next file would start with the first “replacement map” 100 of the “Nucleus” 407, there would be an overlap where the first bytes of the next file would be mapped with the same “dynamic replacement maps” as the last bytes of the previous file.

[0079] To avoid potential security implications the “Nucleus” 407 has to be shifted in-memory relatively to the last encryption. The “Nucleus” 407 is shifted in-memory before starting the encryption or decryption process. The shift can be omitted only if the encryption of the previous file finished exactly on the last “replacement map” of the “Nucleus” 407. Every decryption also does the shift when necessary, in order to properly map the bytes.

[0080] The “Nucleus” 407 will stay shifted in-memory for the duration of the encryption or decryption process for a given plaintext or ciphertext.

[0081] The “ByteMapChain” 900 of the “Nucleus” 407 in the encryption key 400 is not affected by the in-memory shifting. The shift is performed only in the computer memory at runtime.

[0082] Referring to FIG. 18, illustrated is a schematic view of exemplary “Runtimeinstruction” 1800, an in-memory object created during the processes of encrypting or decrypting. One 1800 is created for each “RotorsSetting” (e.g. 1101 or 1501) involved in a given encryption or decryption. “Runtimeinstructions” 1800 are a used for setting up and executing concurrent program threads over multiple CPUs, where each CPU processes a different part of plaintext or ciphertext. The exemplary 1800 contains: • 1801 order number of the 1800 relative to the plaintext or ciphertext, so the first “RotorsSetting” used for the file has the first order number; • 1802 addresses of “replacement maps” from the “Rotors” 408, for the “RotorsSetting” relevant to 1800. Alternatively, the relevant “replacement maps” could be included themselves in 1800 instead of addresses pointing to them; • 1803 the range of bytes in the plaintext or ciphertext for which the 1800 applies to.

[0083] Referring to FIG. 19, illustrated is an exemplary encryption flowchart 1900 with a claiming method 1903 abstracted away, for demonstrating the process from perspective of a local computer device performing the encryption. The 1900 processes a sequence of plaintext bytes of predefined length, e.g. a computer file.

[0084] The present disclosure comprises of a software component performing the encryption or decryption. This software component is used locally, i.e. on a device where a file needs to be encrypted or decrypted, and where keys 400 are created and stored. This software component is later called throughout the present disclosure as a “local client”, and can be installed or alternatively used as a portable program that doesn’t require installation. An interface of the “local client” and technology in which it is created are not part of the current disclosure, and can be created with conventional software programming languages and frameworks. However, the functionalities performed by the “local client” which are described in the current disclosure, are part of the system which is the subject of this disclosure.

[0085] The process 1900 is performed by the “local client”. The order of evens in 1900 is as follows: a) 1901 read the encryption key file 400 and load it into the computer memory; b) 1902 read the plaintext file and assess its size; c) 1903 use one of the claiming methods 600, 700 or 800 to receive a range of “global positions” of the key 400 that will be used for encrypting the file; d) 1904 create all “RotorsSettings” required for completing the 1900. The “RotorsSettings” are relative to “global positions” obtained from 1903. Hence, the “RotorsSettings” are created using 400 and claimed “global positions” obtained from 1903; e) 1905 evaluate whether the in-memory shift of the “Nucleus” 407 is necessary, as described on FIGS. 16-17; f) 1906 if condition evaluated in previous step was met, perform the in-memory shift of the “Nucleus” 407, as described on FIGS. 16-17; g) 1907 create the “encrypted file metadata” 502, which is later needed to decrypt the file; h) 1908 create one “Runtimeinstruction” 1800 for each “RotorsSetting” created in 1904, for the purpose of concurrent CPUs utilisation, to speed up the process; i) 1909 assess the number of CPUs available for 1900. The number can be statically preconfigured or dynamically determined using conventional third-party libraries; j) 1910 distribute “Runtimeinstructions” to a number of groups equalling the number of available CPUs, as determined in 1909. The FIG. 19 proceeds to demonstrate examplegroups using 1911, 1912 and 1913; k) 1914 create as many CPU threads as groups created in 1910. The FIG. 19 proceeds to demonstrate example threads using 1915, 1916, 1917; I) 1918 assign groups created in 1910 to CPU threads created in 1914, and execute the threads concurrently. Each thread executes one group created in 1910, processing one “Runtimeinstruction” 1800 at a time. Each byte of plaintext is encrypted using the method described on FIG. 11; m) 1919 collect ciphertext results of every 1800 execution, along with the order number 1801, which will be used to put all results together in the correct order; n) 1920 once all threads are finished, collate the results into a single ciphertext using order numbers 1801; o) 1921 create an archive file 500 with ciphertext 501 and “encrypted file metadata” 502.

[0086] The order of the events in 1900 and their implementations leading to the same outcome may vary.

[0087] Referring to FIG. 20, illustrated is an exemplary decryption flowchart 2000 from a perspective of a computer device that performs the decryption. The 2000 processes a sequence of ciphertext bytes of predefined length, e.g. an encrypted computer file.

[0088] The process 2000 is performed by the “local client” i.e. software handling the file encryption or decryption. The order of evens in 2000 is as follows: a) 2001 read the encryption key file 400 and load it into the computer memory; b) 2002 read an archive file 500 comprising of ciphertext 501 and “encrypted file metadata” 502; c) 2003 create all “RotorsSettings” required for completing the 2000. The “RotorsSettings” correspond to the “global positions” used for creating 501. Required “global positions” range (from 503 to 504) is obtained from the “encrypted file metadata” 502; d) 2004 evaluate whether the in-memory shift of the “Nucleus” 407 is necessary, as described on FIGS. 16-17; e) 2005 if condition evaluated at previous step was met, perform the in-memory shift of the “Nucleus” 407, as described on FIGS. 16-17; f) 2006 create one “Runtimeinstruction” 1800 for each “RotorsSetting” created in 2003, for the purpose of concurrent CPUs utilisation, to speed up the process; g) 2007 assess the number of CPUs available for 2000. The number can be statically preconfigured or dynamically determined using conventional third-party libraries; h) 2008 distribute “Runtimeinstructions” to a number of groups equalling the number of available CPUs, as determined in 2007. The FIG. 20 proceeds to demonstrate example groups using 2009, 2010 and 2011; i) 2012 create as many CPU threads as groups created in 2008. The FIG. 20 proceeds to demonstrate example threads using 2013, 2014, 2015; j) 2016 assign groups created in 2008 to CPU threads created in 2012, and execute the threads concurrently. Each thread executes one group created in 2008, processing one “Runtimeinstruction” 1800 at a time. Each byte is decrypted using the method described on FIG. 12; k) 2017 collect plaintext results of every 1800 execution, along with the order number 1801, which will be used to collate the results in correct order; I) 2018 once all threads are finished, collate the results into a single plaintext using order numbers 1801; m) 2019 create a computer file and write the plaintext data into it.

[0089] The order of the events in 2000 and their implementations leading to the same outcome may vary.

[0090] The roles of the “local client” within the present disclosure comprise of, but are not limited to: • Generating the encryption key. The software takes parameters such as requested sizes of “Nucleus” 407 and “Rotors” 408, and the number of “Rotors” 408. It generates the “Nucleus” 407 and “Rotors” 408, then creates “ByteMapChains” 900 forthem. Next, the “local client” generates the “encryption key metadata” 401, and puts 401,407, 408 into the encryption key file 400. • Encryption key management. The “local client” manages multiple keys 400. When launching the program, it can read and display available keys 400 and their properties like total capacity and remaining capacity for each key. The “local client” can also import and export keys for sharing purposes; • Handling encryption and decryption on demand. The “local client” allows pointing to a plaintext file that needs to be encrypted, process it, and output 500 - the archive file with ciphertext 501 and “encrypted file metadata” 502. The “local client” can also reverse the operation by taking 500 as input, decrypting the ciphertext 501 and creating the plaintext file matching the origin file. For encrypting, the “local client” employs one of the claiming methods: 600, 700 or 800; • Directory synchronisation process. The “local client” can have an optional process running in the background and automatically monitoring files or directories for changes, and synchronise by encrypting-decrypting with another files or directories, whenever a change is detected. The synchronisation is explained later on FIG. 24.

[0091] Referring to FIG. 21, illustrated is an exemplary encryption flow 2100 with the server-based claiming method, which was abstracted away on FIG. 7. A local device 2101 which is performing the encryption, connects to a server 2102 which returns the claimed positions, allowing the “local client” on 2101 to finish the encryption process.

[0092] Decryption is always performed offline by the “local client”, because it doesn’t require making a claim. Hence, it also doesn’t require connection to 2102.

[0093] The exemplary order of evens in 2100 is as follows: a) 2101 is a local device where the process begins and the “local client” preforms the encryption; b) 301 the plaintext file size is evaluated as described on the simplified flowchart on FIG. 3; c) 2103 the “local client” prepares a conventional HTTP request to get a claim for a range of “global positions” that matches the file size. A size of the requested range, i.e. size of the file, is included in the request; d) 2104 a conventional HTTP request is made over the network to 2102; e) 2105 a conventional web server listens for the HTTP requests and receives them; f) 2106 the request is processed by a sever application connected to a data store, including a transactional mechanism preventing an overlap of simultaneous requests e.g. a conventional transactional mechanism in a database. The application handles the queue of requests 2107, reads current state of the key capacity 2108, and checks whether requested encryption does not exceed the available capacity 2109; g) 2110 on the event of insufficient capacity, an HTTP response is prepared with a failure status and: I. 2111 response is sent back over the network to the “local client”; ii. 2112 failure response is received by the “local client”; iii. 2113 the failure is subsequently handled by the “local client”; h) 2114 on the event of sufficient capacity the data storage is updated to claim new positions and: I. 2115 the newly claimed range is then returned; II. 2116 an HTTP response is prepared with a success status and including the claimed range in payload; iii. 2111 response is sent back over the network to the “local client”; iv. 2117 success response including the claimed range is received by the “local client”; v. 2118 the “local client” uses claimed positions to perform the requested encryption.

[0094] The purpose of 2100 is the ability to use the same encryption key 400 by multiple devices, for the purpose of encryption, while ensuring that “dynamic replacement maps” are never reused for encrypting globally. For such use case, the claiming method needs to ensure synchronisation and centralised management of claims. This can be achieved by synchronising claimed positions across devices by conventional HTTP request-based procedure and a server 2102 connected to a data store.

[0095] The encryption keys 400, are referenced in the data store by keys’ UUlDs 403 and “encryption keys iteration” numbers 404. The data on the server-side is minimalistic, and used only for the purpose of claims synchronisation, not holding any information about the encrypted plaintext

[0096] The data held on the server per each 400 is the “encryption key metadata” 401 and the last claimed “global position” for that key. Every new claim updates that number by summing existing number with the size of the new claim. oldjcgp - the number representing the last claimed “global position” before the new claim. newjcgp - the number representing the last claimed “global position” after the new claim. file_size - size in bytes of the file that needs to be encrypted newjcgp - oldjcgp + fHe_size

[0097] The server application on 2102 tracks utilisation of keys, raising an exception when the key capacity ends. Optionally, warnings can be returned when the end of the key capacity is near. The warning can be included as part of the success response 2116 and such response can have a dedicated HTTP status code.

[0098] Conventional transaction protocols in 2106 lock records until update or insert is completed, preventing the overlap between different requests and ensuring that particular “global positions” are issued only once.

[0099] To use an encryption key 400 with the server-based solution 2100, the key will have to be registered on the server 2102 first, to begin tracking of its capacity. Registration is a one time process, to enable issuance of claims for the given key 400. The registration HTTP request is made from the “local client” and sends the “encryption key metadata” 401 of the selected key 400 to the server 2102.

[0100] The server-based solution 2100 supports offline encryption in the “local client”, as indicated on FIG. 8, which is useful in the event of the server 2102 being unreachable due to: • unavailability of the network connection on the local device 2101 side; • unavailability of the network connection on the server 2102 side; • purposeful avoidance of the network connection; • maintenance or issue with the server 2102.

[0101] A local device 2101 can make a claim in advance, before the encryption process is needed, and before the content to encrypt is known. The size of the range claimed in advance can be arbitrary for the purpose of the future offline use. The information about the range of “global positions” claimed in advance is stored in the “offline pool of claimed positions” located on 2101 in some conventional form e.g. in a file or database, and when the “local client” is in the offline mode, the “offline pool of claimed positions” issues sub-ranges of “global positions” claimed in advance, accordingly to the needs of each encryption.

[0102] The “global positions” claimed in advance are used automatically when the server 2102 or the network connection 2104 are unavailable. The “local client” can also be set to explicit offline mode, and use the “offline pool of claimed positions” regardless of the server availability. FIG. 8 shows the general flow of the claiming method during encryption for offline use.

[0103] The “offline pool of claimed positions” is technically a pair of properties: the range of “global positions” claimed in advance and the next available “global position” in the “offline pool of claimed positions”.

[0104] Information about “global positions” claimed in advance can be held locally in the “encryption key metadata” 401 as one of the optional properties 406, or in another conventional method of storing computer information. From the server 2102 perspective there is no difference between claims made in advance or on demand.

[0105] The in-advance claim will require connection to the server and can be triggered for example when creating or importing the key 400 for the first time.

[0106] A predefined size of the “offline pool of claimed positions” can be maintained by an automated process. For example, the instruction can be set to create and maintain an “offline pool of claimed positions” of 20GB capacity. This means that 20GB of files can be encrypted without the need to connect to the server 2102. As the “offline pool of claimed positions” gets used overtime, the “local client” ensures the pool will be replenished when the capacity for offline encryption drops below a certain level e.g. 1GB.

[0107] Whenever the range of available “global positions” in the “offline pool of claimed positions” falls below 1GB, the next time the “local client” detects server connectivity, it will replenish the pool by a new in-advance claim for 20GB. The old “offline pool of claimed positions” will become discarded or joined into the new pool on such event. The size of the pool and the size of the minimal threshold triggering replenishment can have predefined defaults, with ability to modify them by the use of the “local client” interface. The provided sizes are exemplary for the purpose of the demonstration and can be set to any other value.

[0108] In case when a request is made to encrypt content larger than available range in the “offline pool of claimed positions”, and “local client” will be in the “offline mode”, then process will return a failure and offer an attempt to connect to the server 2102 and utilize the online claiming method 700.

[0109] Referring to FIG. 22, illustrated is an exemplary server-based encryption key 400 renewal flowchart 2200. With the server-based encryption flow 2100 on FIG. 21, the end of the key capacity can be managed in an automated or semi-automated way. The 2200 shows updated 2100 flow, where a process is forked from the point of successful claim 2201, for the purpose of the encryption key 400 renewal.

[0110] The first “encryption key iteration” with a given UUID 403 has been created and distributed by ways outside of the scope of the present disclosure. When the first “encryption key iteration” gets close to running out of capacity, the second and following iterations of the key 400 with the same UUID 403 can be created and shared in a simplified way, because the next “encryption key iteration” can be encrypted by the previous one, before being shared. The iteration number 404 is referenced in the “encryption key metadata” 401.

[0111] After the successful claim 2201, while the successful HTTP response is being prepared 2116, the server application starts another parallel process 2202 which checks whether the capacity of the current “encryption key iteration” is nearing the end. The size of the remaining capacity threshold that triggers the condition can be determined arbitrarily with a default or by a configured value.

[0112] If the 2202 finds that the condition doesn’t indicate that capacity is close to the end, the forked process goes no further. However, if the condition is met, a signal is created 2203 and transmitted 2204 towards a key maintainer or a renewal device 2205. The signal 2203 and its transmission method 2204 can take many forms like push notification, email, HTTP request or SSH command. The exact types of 2203 and 2204 are not specified in the current disclosure, and can take any conventional form. The role of 2203 and 2204 is to transmit the information that a renewal is needed for a key 400 with specific UUID 403.

[0113] The renewal device or a key maintainer 2205, will receive the signal 2206, create the next “encryption key iteration” 2207, encrypt it with the remaining capacity of the preceding “encryption key iteration” 2208 and upload it to the server 2209.

[0114] Once the new “encryption key iteration” is encrypted and transmitted back to the server 2102 by unspecified conventional method 2204, the server will receive 2210 the new “encryption key iteration”, then update the claims data 2211, and expose the new “encryption key iteration” for download 2212 by authenticated users with proper permissions.

[0115] In a semi-automated flow, the maintainer of the key will have to manually act after receiving the signal, by: a) creating the next “encryption key iteration”; b) encrypting it with remaining capacity from the preceding “encryption key iteration”; c) submitting the new encrypted “encryption key iteration” to the server.

[0116] In a fully automated flow, a designated device holding the latest “encryption key iteration”, could listen to and receive the signal from the server 2102 and act on it automatically.

[0117] Alternatively, a renewal device 2205 could proactively check the key(s) 400 remaining capacity by requesting that from the server 2102 on schedule.

[0118] By having a frequent and automated renewal, a concession can be made on the key capacity, to increase encryption and decryption performance, by decreasing the size of “Nucleus” 407 or the size and number of “Rotors” 408. Moreover, the users would gain a convenient system for maintaining continuity of their processes by sharing the next “encryption key iterations” safely and automatically.

[0119] Users or devices who have access to a key 400 with a given UUID 403 will be able to download the new “encryption key iteration” and decrypt it locally. The process can be automated within the “local client” during claim request, without any additional manual steps needed from the requesting side. The new “encryption key iteration” can be pulled automatically when “local client” needs to decrypt a file which was encrypted by second or later “encryption key iteration” of the key 400, if that iteration is not yet available to the “local client” on the local device.

[0120] To decrypt a file encrypted with second or later “encryption key iteration”, the “local client” will have to have the first “encryption key iteration” locally in an unencrypted form, then pull and decrypt all subsequent “encryption key iterations” up to the iteration that was used for file that needs to be decrypted.

[0121] All “encryption key iterations” held on 2102 are encrypted, each with a preceding “encryption key iteration” of the key with the same UUID 403, except the first “encryption key iteration” which is never held on the server.

[0122] Access management to the server and claiming of “global positions” for particular keys 400 is done through conventional methods. For example, users may need to register an account using their email addresses used as usernames and having the email ownership confirmed by email verification or Single Sing-On.

[0123] Other common authentication and authorization mechanisms can be employed like OAuth for automating the key management or distributed access to nonuser related devices.

[0124] Roles granted per key UUID 403 can be for example: “owner” and “user”. The “owner” role can be automatically granted to the entity that registers the key.

[0125] “Owner” permissions can be for example: • grant roles per the encryption key UUID 403 for other users or devices; • revoke access to the encryption key UUID 403 or to particular “encryption key iteration”; • delete all encryption key 400 references from the server 2102; • produce and upload next “encryption key iterations” of a key 400 for given UUID 403.

[0126] One of “user” permissions can be for example: can encrypt using the key i.e. can request claims for given key UUID 403 from the server 2102.

[0127] Actions related to the given roles and permissions can be triggered by conventional HTTP requests to the server 2102. HTTP requests are implemented in the “local client”.

[0128] Decrypting files doesn’t require access to the server 2102, defined role or making HTTP requests. The only pre-requisite is an access of the “local client” to a relevant “encryption key iteration” on the local device 2101.

[0129] Referring to FIG. 23, illustrated is an alternative method 2300 of creating a new “ByteMapChain” 900 for a new key component (“Nucleus” 407 or one of the “Rotors” 408) by using an input file 2301 instead of an arbitrary generation, as in the default process.

[0130] The purpose of 2300 is to improve security of sharing the first “encryption key iteration”, by sending instructions rather than complete key 400, and diversifying the channels of transmissions for these instructions. The “Nucleus” 407 and each of the “Rotors” 408 can be created by using a different input file, and instruction for each of the key components can be transmitted by using different means.

[0131] The input file can be of any type, and exemplary instruction could simply be a pointer to a file available for download on the internet, and indication for which key component it should be used. One additional instruction would have to be sent to indicate what UUID 403 the new encryption key 400 should use, and optionally add remaining nonsensitive properties of the “encryption key metadata” 401.

[0132] The “local client” can come with an optional tool that can generate the same key on two different devices, while taking exactly the same files as input.

[0133] The procedure extracts subsequent bytes from the input file 2301, skipping all non-unique bytes per each “replacement map” (e.g. 100) that is currently being created. The FIG. 23 uses simplified byte ranges from 0 to 4 for the purpose of the demonstration.

[0134] The procedure of creating a “ByteMapChain” 900 for a key component 2307 from the input file 2301 is as follows: a) 2301 file is chosen as input for creation of a key component 2307, where 2301 is shown as a list of byte values; b) 2302 is a programmatic loop that performs a function to evaluate each byte value of the input file 2301, to determine if the byte value can be used for 2307 creation. The loop operations are as follows: I. 2303 a byte value enters the function; ii. 2304 the byte value is evaluated if it’s not already in the “list of replacement values" that is currently being created. If the byte value is not yet in the currently built “list of replacement values” (2305) then the value is appended to the “ByteMapChain” 900 of 2307. If the byte value is already present (2306) in the currently built “list of replacement values” then the value is skipped and the loop continues to the next byte value of the input file 2301; c) 2307 is a completed “ByteMapChain” 900 of the encryption key 400 component, i.e. either a “Nucleus” 407 or one of the “Rotors” 408. Individual “lists of replacement values” are separated on the diagram for clarity of the demonstration, similarly as on FIG. 9.

[0135] Referring to FIG. 24, illustrated is a process of synchronising directories’ (or folders’, as terminology depends on the Operating System) 2400, with automated encryption-decryption. 2400 is part of the “local client”, and it is an ongoing process running in the background.

[0136] By implementing 2400, a user experience is improved by removing the need to wait for processing the files during on-demand encryption-decryption. Instead, the files can be encrypted-decrypted automatically when arriving to a specific directory.

[0137] Directory with encrypted content 2402, can be shared by a third-party cloud software, and 2400 allows users to automatically send and receive the encrypted files, by placing plaintext files in a monitored directory with unencrypted content 2401.

[0138] Users with access to the shared directory with encrypted content 2402 will receive the file and have it decrypted in the background automatically. The “local client” can implement various types of notifications by using relevant Operating System interfaces, to inform user when a file was received and decrypted.

[0139] The automated flow of encryption in 2400 is as follows: a) 2404 a plaintextfile is put from unspecified location into the monitored directory with the plaintext content 2401. The ongoing monitoring process 2400 detects the change in the contents of 2401 and identifies the new file; b) 1900 the methods described in the current disclosure perform encryption of the file, creating the encrypted file archive 500; c) 2405 the encrypted file archive 500 is placed in the final destination directory, which can be shared further by conventional methods or third-party cloud service. Any methods of sharing the file 500 after it is put in 2402, are outside of the scope of the current disclosure.

[0140] The automated flow of decryption in 2400 is as follows: a) 500 encrypted archive file is put from unspecified location into the monitored directory with encrypted content 2402. The ongoing monitoring process 2400 detects the change in the contents of 2402 and identifies the new file; b) 2000 the methods described in the current disclosure perform decryption of the file, creating a plaintext file; c) 2403 the plaintext file is placed in the final destination directory with decrypted content 2401. EXAMPLES OF USE CASES

[0141] The use cases for the current disclosure include, but are not limited to: • On-demand file encryption and decryption. The most fundamental use case is encrypting files before and decrypting after transferring or storing them by means exposed to security threats. User can manually encrypt or decrypt a file on demand by using the “local client”. Both sender and receiver must possess the same encryption key 400. • Sharing and backing up files with a third-party cloud storage synchronisation. The automated encryption-decryption for synchronised directories feature shown on FIG. 24 can be used in conjunction with a conventional third-party cloud storage provider. The files can be encrypted and decrypted locally by automated synchronisation process 2400, while the directory with encrypted files 2402 can be synchronised automatically with the cloud storage. A third-party software can be used for maintaining synchronisation with the cloud and sharing the files with other users and devices. Alternatively, the 2402 can be synchronised with a network drive, SFTP server or other conventional means of sharing files between users and devices. A variant of the current disclosure without using any claiming methods of “global positions” can be employed in situations when there is only one device encrypting and distributing the files, while multiple other devices need only to receive and decrypt it. Alternatively, where each device has a designated encryption key 400, which it can use for encrypting, while other devices hold the same key but are allowed only to decrypt with it. In such system each device could hold all the keys of devices it needs to communicate with, while being able to encrypt with only one designated encryption key 400. In such case a conflict would not occur hence claiming method is not necessary. Alternative renewal system could be employed for synchronising “encryption key iterations”.

Claims

1. A computer-implemented method for encrypting and decrypting sequences of bytes by using arbitrarily defined replacement maps, wherein:- the replacement maps comprise of 256 unique values, one for every potential input byte value, where each replacement value is an integer in range from 0 to 255, and is addressable by its position in the replacement map;- to perform the mapping an input byte value is used as a position of a replacement value in the replacement map;- a value resulting from the mapping by one replacement map is subsequently used in another replacement map as a position of a replacement value to perform the further mapping;- any unique combinations of two or more replacement maps are used to encrypt only one byte globally;- the input bytes are mapped to unique combinations of replacement maps, by the order in which the bytes are encrypted.

2. The computer-implemented method of claim 1, wherein replacement values of replacement maps are stored in uniform byte sequences, and are extracted as individual replacement maps at runtime in computer memory, by splitting the uniform byte sequences to fix-length sub-sequences composed of 256 values each.

3. The computer-implemented method of claim 2, wherein an encryption key is comprised of two or more separate files containing uniform byte sequences storing the replacement maps.

4. The computer-implemented method of claims 1-3, wherein the encryption key components containing the replacement maps are rotated while used for encrypting or decrypting subsequent bytes, so that all combinations of replacement maps are available for encryption and decryption, where each combination is composed of one replacement map from each component.

5. The computer-implemented method of claims 1-4, wherein used combinations are tracked and recorded allowing to uniquely identify any possible combination of replacement maps.

6. The computer-implemented method of claims 1-5, wherein processed plaintext or ciphertext sequences of bytes are split to sub-sequences at runtime and processed concurrently in parallel threads on multiple CPUs.

7. The computer-implemented method of claims 1-6, wherein unique combinations of replacement maps are claimed for each encryption, preventing another encryption process with the same encryption key from reusing them.

8. The computer-implemented method of claim 7, where the information on claimed combinations of replacement maps is stored locally on the encrypting device.

9. The computer-implemented method of claim 7, where the information on claimed combinations of replacement maps is stored externally to the encrypting device.

10. The computer-implemented method of claim 9, where the auxiliary local storage of information about combinations of replacement maps claimed in advance, is used instead of the external storage, when use case scenarios prevent access to the external storage.

11. The system of claims 9 or 10, wherein the external storage of claimed combinations of replacement maps, is server-based comprising:- HTTP request-based procedure for obtaining claims on combinations of replacement maps;- conventional conflict resolution system for queueing the requests and preventing issuance of claims for the same combinations of replacement maps more than once;- tracking of encryption key usage by the server-side application;- successful HTTP response containing the issued claims on combinations of replacement maps;- failure HTTP response for cases when successful issuance of claims was not possible.

12. The system of claim 11, wherein a condition is set to check a predefined minimal encryption key capacity threshold, which triggers a procedure for the encryption key renewal.

13. The system of claim 12, wherein the encryption key renewal device or maintainer of the key, receives a conventional signal requesting the key renewal from the server application.

14. The system of claim 13, wherein a new key iteration is created then encrypted by using a preceding key iteration, and sent to the server application, where it is made available for download.

15. The system of any of the preceding claims, wherein a computer program product performs a synchronisation and encryption-decryption between directories, by setup of two directories, one with encrypted content, and another with decrypted content, where both directories are monitored for changes and depending on directory where a change occurred, encryption or decryption is triggered automatically and an output file is written to the respective paired directory.

Images