Patent Description:
There are many cryptographic algorithms known in the art. One such cryptographic algorithm is described in <CIT>("Kurdziel"). The cryptographic algorithm implements a method that generally involves: combining a cryptographic key with state initialization bits to generate first combination bits; producing a first keystream by performing a permutation function f using the first combination bits as inputs thereto; and using the first keystream to encrypt first data (e.g., authentication data or message body data) so as to produce first encrypted data (e.g., via modular arithmetic). The permutation function f comprises a round function fround that is iterated R times. The round function fround consists of (<NUM>) a substitution layer in which the first combination bits are substituted with substitute bits, (<NUM>) a permutation layer in which the substitute bits are re-arranged, (<NUM>) a mixing layer in which at least two outputs of the permutation layer are combined together, and (<NUM>) an addition layer in which a constant is added to the output of the mixing layer.

The invention is provided as defined in the independent claims. Some preferred embodiments are described in the dependent claims. Document <CIT> block cipher device for a cryptographically secured digital communication system includes a pair of first stages connected in parallel for receiving an input data block and a control data block. Each first stage defines a respective first data path and includes a sum modulo-two unit for receiving the control data block and the input data block. Each first stage also includes a first nibble swap unit downstream from the sum modulo-two unit. A key scheduler generates a random key data block based upon a received key data block. A pair of second stages is connected in parallel downstream from the first stages and receives the random key data block, the control data block and output signals from the first stages for providing an output data block. Each second stage defines a respective second data path and includes a plurality of modulo units. The block cipher device further includes a bit diffuser connected in both of the first data paths for mixing data therebetween. Document <CIT> discloses method and system for improving stream cipher encryption of data, where the data to be encrypted, called plaintext, is combined with a random sequence of digits, called key stream, to obtain the encrypted plain text called cipher text. The solution disclosed proposes a new type of synchronism of stream ciphers, where the synchronization action is produced at random intervals in an unpredictable time schedule. Document XP055953193 proposes two modes of operation for block ciphers, referred to as statistical cipher feedback (SCFB) mode and optimized cipher feedback (OCFB) mode, are investigated. Both cipher modes have the capability of self-synchronization with high efficiency. In particular, the paper studies the performance of SCFB mode and OCFB mode with respect to characteristics such as the theoretical efficiency, the synchronization recovery delay (SRD), and the error propagation factor (EPF). Document XP037019733 discloses development history of stream ciphers, classifies and summarizes the design principles of typical stream ciphers in groups, briefly discusses the advantages and weakness of various stream ciphers in terms of security and implementation. Further, sponge construction is disclosed, which uses a wide random permutation, and allows inputting and outputting any amount of data, which leads to great flexibility. Separately, as part of a different solution, document discloses duplex structure and a fixed permutation of iterative functions with SPN structure.

In some scenarios, a result from combining the plaintext with a keystream block is used as the bitrate portion of the initialization value for a cryptographic algorithm when a determination is made that the given sequence of values does not exist within the ciphertext. The cryptographic algorithm may include, but is not limited to, an adaption of a sponge construction framework. The adaptation of the sponge construction framework may include, but is not limited to, a duplex construction in which a permutation function is iteratively performed. The ciphertext may be generated by the cryptographic system in accordance with the cryptographic algorithm or received from a remote device that generated the ciphertext. The synchronized cryptographic algorithm is used to decrypt the ciphertext or to encrypt plaintext.

In some scenarios, the implementing systems comprise digital logic circuits with logic/state devices. In other scenarios, the implementing systems comprise: a processor; and a non-transitory computer-readable medium comprising programming instructions that are configured to cause the processor to implement a method for operating a cryptographic algorithm. The programming instructions comprise instructions to: obtain ciphertext by the cryptographic system; perform operations by the cryptographic system to determine whether a given sequence of values exits within the ciphertext; and synchronize the cryptographic system with another cryptographic system using the ciphertext as a bitrate portion of an initialization value for a cryptographic algorithm and zero as a capacity portion of the initialization value for the cryptographic algorithm, when a determination is made that the given sequence of values exist within the ciphertext. The programming instructions may also comprise instructions to cause the processor to use results from combining the plaintext with a keystream block as the bitrate portion of the initialization value for a cryptographic algorithm when a determination is made that the given sequence of values does not exist within the ciphertext.

The present disclosure also concerns communication devices and methods for operating the same. The communication devices comprise: a transceiver configured to transmit and receive signals including ciphertext; a cryptographic circuit configured to encrypt and decrypt information in accordance with a cryptographic algorithm; and a synchronization circuit configured to synchronize the cryptographic algorithm with a cryptographic algorithm of another communication device based on a detection of a pseudo-random event during an on-going communication session. The pseudo-random event is detected via an analysis of the ciphertext. The ciphertext is used as a bitrate portion of an initialization value for a cryptographic algorithm and zero is used as a capacity portion of the initialization value for the cryptographic algorithm, when the pseudo-random event is detected. A result from combining the plaintext with a keystream block may be used as the bitrate portion of the initialization value for the cryptographic algorithm when the pseudo-random event is not detected.

The present solution will be described with reference to the following drawing figures, in which like numerals represent like items throughout the figures.

The present solution may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the present solution is, therefore, indicated by the appended claims rather than by this detailed description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Reference throughout this specification to "one embodiment", "an embodiment", or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution.

The present solution provides system and methods for providing cryptographic systems with a self-synchronizing mode of operation. The cryptographic systems may implement block cipher based cryptographic algorithms. The self-synchronizing mode of operation enables automatic cryptographic resynchronization between transmitters and receivers, and also enables late network entry by communication devices into an already established conversation. The self-synchronizing mode of operation provides a way for a receiver to synchronize its local cryptographic algorithm when joining a conversation for which the synchronization information and initialization variable for the cryptographic algorithm has already been sent to participants. Based on pseudo-random events, the communication devices of a participant self-synchronize their cryptographic algorithms during the conversation. The pseudo-random events are based on the ciphertext being transmitted because the ciphertext appears statistically random. Every node on the network has access to the ciphertext, and is configured to detect patterns in the ciphertext. When a pattern is detected, a node will re-initialize a state of its cryptographic algorithm using the ciphertext transmitted over the channel. The channel may include, but is not limited to, a low bit error rate channel. In this way, the nodes will access uncorrupted ciphertext and concurrently synchronize states of their cryptographic algorithms.

The block cipher cryptographic algorithms can include, but are not limited to, adaptations of sponge based cryptographic algorithms. Sponge constructions will be described herein to assist the reader with understanding the present solution. A duplex construction will be described herein to assist the reader in understanding an illustrative adaptation of sponge construction. Sponge and duplex constructions provide frameworks representing new cryptographic paradigms with many advantages including processing performance and provable computational cryptographic strength. A novel cryptographic algorithm design is described herein that is based on the sponge and duplex construction frameworks. More particularly, the novel cryptographic algorithm comprises a unique permutation function f that is used with a sponge construction and/or a duplex construction. In this regard, the present solution provides the same advantages of conventional sponge and duplex constructions, as well as other additional advantages. These other additional advantages include, but are not limited to: the provision of a highly configurable and customizable cryptographic algorithm; the provision of a symmetric key algorithm that is designed against a military threat model; the provision of increased throughput suitable to support high-rate networked waveforms; and the provision of an algorithm that can be used with key lengths that are longer than the key lengths which can be used with conventional cryptographic algorithms. Longer key lengths result in a higher level of security.

For military applications, the customers desire sovereign cryptography. Sovereign cryptography provides a feature called security autonomy where the customers have their own variant of a cryptographic algorithm. One way to obtain security autonomy is for the customers to specify their own cryptographic algorithm to be implemented in the device(s). This solution is not economically feasible. As such, the present solution provides a proprietary cryptographic algorithm that can be customized in various ways. The customization capability mainly lies in two types of customization, namely factory customization and field customization.

Factory customization is more substantial in terms of changing the cryptographic algorithms structure and adding new algorithm blocks, but also requires one to have the requisite expertise. One disadvantage of factory customization is that human error can cause degradation of the cryptographic system. This disadvantage is addressed by the present solution. In this regard, the present solution employs a cryptographic (e.g., encryption and/or decryption) algorithm that can be customized without any degradation to the security thereof. Another disadvantage is that some customers do not want others (i.e., the people with the requisite expertise) to have knowledge of their own variant of a cryptographic algorithm. The present solution also addressing this disadvantage by providing a cryptographic algorithm that can be customized in the field.

Field customization allows customers to make changes to the cryptographic algorithm via a tool after the device is provided to them. All possible information that can be input into the system via the tool to provide the field customization are equally valid in terms of not degrading the cryptographic strength of the cryptographic algorithm.

Accordingly, the present solution has two levels of customization. A first Custom Crypto ("CC") capability allows customized versions of the sponge based cryptographic algorithm to be embedded in a device (e.g., a handheld radio) at the factory. There are a number of CC settings that are specified for a custom version of the sponge based cryptographic algorithm, after an analysis to ensure that it is secure. The CC settings are stored and loaded into the encryption/decryption circuitry at power-on. The CC capability can be implemented in a substitution layer, a permutation layer and/or a round constant addition layer of a permutation function f, as discussed below.

A second Custom Algorithm Modification ("CAM") capability allows a user to customize the encryption/decryption algorithm in the field after power-on (i.e., after the device employing the cryptographic algorithm has been provided to the customer). CAM settings are stored in an N-bit (e.g., <NUM> bit) register that can be changed at any time (except during encryption/decryption). All possible CAM register values must yield different, fully secure customized algorithms. CAM is implemented in a mixer layer of the permutation function f. The CC and CAM capabilities will be described in detail below.

The present solution also has the following additional advantages: increased processing performance and provable computational cryptographic strength; cost effective alternative to embedded sovereign cryptography; includes cryptographic constructs and key lengths to provide post quantum security in a reasonable hardware and software footprint; and designed against a military threat model.

Referring now to <FIG>, there is provided a schematic illustration of an illustrative architecture for a sponge construction <NUM> implementing the present solution. Notably, the sponge construction <NUM> uses a unique permutation function f (described below) to provide the traditional suite of cryptographic modes. This will become more evident as the discussion progresses.

As shown in <FIG>, the sponge construction <NUM> is generally designed to implement symmetric cryptography functionalities, namely key derivation and message encryption/decryption. The sponge construction <NUM> is a simple iterated construction for building a function F based on a unique permutation function f The function F has a variable-length input and an arbitrary output length. The unique permutation function f operates on a state of b = r + c bits, where r (e.g., <NUM> bits) is the bitrate and c (e.g., <NUM> bits) is the capacity. The capacity c determines the security level of the sponge construction.

Notably, the sponge construction <NUM> can be implemented in hardware, software or a combination of both hardware and software. As such, the operations of each functional block <NUM>-<NUM> may be implemented using hardware and/or software. The hardware can include, but is not limited to an electronic circuit. The electronic circuit can include passive components, active components and logical components.

The sponge construction <NUM> is divided into two phases. The first phase is an absorbing phase <NUM> in which the cryptographic key K or K∥N (i.e., a concatenation of the cryptographic key K and a flag N) is absorbed into a state of the sponge construction <NUM> while interleaving with applications of the underlying permutation function f. Such absorption is achieved by combining K (or K∥N) with the first r bits of the initialized state bits b. In some scenarios, the bits b (e.g., <NUM> bits) are initialized to zero. The present solution is not limited in this regard. The bits b (e.g., <NUM> bits) may alternatively be initialized to any bit value (e.g., any <NUM> bit value). As such, each user could generate its own unique value to set during the initialization phase.

The combining of K (or K∥N) with the first r bits of the initialized state can be achieved via exclusive OR ("XOR") operations <NUM>, as shown in <FIG>. XOR operations are well known in the art, and therefore will not be described in detail here. Still, it should be understood that the XOR operations are performed on a bit-by-bit basis. The result of each XOR operation is true whenever an odd number of inputs are true and false whenever an even number of inputs are true. The results of the XOR operations are then passed to permutation functional block <NUM> where the results are interleaved with applications of the unique permutation function f.

The second phase is a squeezing phase <NUM> in which keystream blocks Z<NUM>, Z<NUM>, Z<NUM> are produced by the performance of the unique permutation function f in permutation functional blocks <NUM>-<NUM>. Each keystream block Z<NUM>, Z<NUM>, Z<NUM> comprises r bits. The unique permutation function f will be described in detail below. Still, it should be understood that the permutation function f maps each possible value of the bits input thereto into a particular unique value of the output bits. Notably, permutation functional block <NUM> takes the output of the absorbing phase <NUM> as an input. Permutation functional block <NUM> takes the output of permutation functional block <NUM> as an input. Permutation functional block <NUM> takes the output of permutation functional block <NUM> as an input.

Next, the keystream blocks Z<NUM>, Z<NUM>, Z<NUM> are used to encrypt a message M. In this regard, the keystream blocks Z<NUM>, Z<NUM>, Z<NUM> can be truncated to a desired length l. Additionally or alternatively, the message M may be padded to make it a multiple of r (if it is not a multiple of r). The message M is parsed into a plurality of message blocks M<NUM>, M<NUM>, M<NUM>. Each message block M<NUM>, M<NUM>, M<NUM> comprises a plurality of bits of the message M. Each keystream block is then combined with a respective message block so as to produce an encrypted data block. The encrypted data block can include, but is not limited to, a ciphertext block C<NUM>, C<NUM> or C<NUM>. The present solution is described herein in relation to ciphertext. The present solution is not limited in this regard. The present solution can be used to encrypt any type of data (e.g., text, audio, video, etc..

In some scenarios, the combining of the keystream and message blocks is achieved using modular arithmetic. For example, each keystream block Z<NUM>, Z<NUM>, Z<NUM> is combined with a respective block of message bits M<NUM>, M<NUM>, M<NUM> via modulo <NUM> addition. The modulo <NUM> addition can be implemented using an XOR operation, as shown in <FIG>. The XOR operation is performed on a bit-by-bit basis. As such, a first bit m<NUM> of a message block M<NUM>, M<NUM> or M<NUM> is combined with a first bit z<NUM> of a respective keystream block Z<NUM>, Z<NUM> or Z<NUM> via modulo <NUM> addition. Next, a second bit m<NUM> of a message block M<NUM>, M<NUM> or M<NUM> is combined with a first bit z<NUM> of a respective keystream block Z<NUM>, Z<NUM> or Z<NUM> via modulo <NUM> addition, and so on.

Referring now to <FIG>, there is provided a schematic illustration of an illustrative architecture for a duplex construction <NUM> implementing the present solution. The duplex construction <NUM> is an adaptation of the sponge construction framework that, together with the unique permutation function f (described below), provides an additional Authenticated Encryption ("AE") cryptographic mode. This mode allows both source and integrity verification of encrypted traffic. This will become more evident as the discussion progresses.

Notably, the duplex construction <NUM> can be implemented in hardware, software or a combination of both hardware and software. As such, the operations of each component <NUM>-<NUM> may be implemented using hardware and/or software. The hardware can include, but is not limited to an electronic circuit. The electronic circuit can include passive components, active components and logical components.

In the duplex construction <NUM>, the absorbing phase and squeezing phase are combined into each of a plurality of duplex operations. Accordingly, the duplex construction <NUM> comprises a plurality of duplex objects <NUM>-<NUM>. The operations of each duplex object will be described separately below. Notably, the state of each duplex object call is preserved.

The input to duplex object <NUM> is a cryptographic key K (or optionally K∥<NUM>, i.e. a concatenation of the cryptographic key K and a flag <NUM>). The cryptographic key K (or optionally K∥<NUM>) is padded in padding functional block <NUM> to make it a multiple of r (if it is not a multiple of r). The padding can involve appending bits to the beginning or end of the cryptographic key K (or optionally K∥<NUM>). Next, the output of padding functional block <NUM> is then combined at <NUM> with the first r bits of the initialized state bits b. In some scenarios, the bits b are initialized to zero, where b = r + c. The present solution is not limited in this regard. The bits A (e.g., <NUM> bits) may alternatively be initialized to any bit value (e.g., a <NUM> bit value). As such, each user could generate its own unique value to set during the initialization phase.

The combining of the padding functional block output and the first r bits of the initialized state can be achieved via XOR operations <NUM>, as shown in <FIG>. XOR operations are well known in the art, and therefore will not be described in detail here. Still, it should be understood that the XOR operations are performed on a bit-by-bit basis. The results of the XOR operations are then passed to permutation functional block <NUM>. In permutation functional block <NUM>, the unique permutation function f is performed using the results of the XOR operations as inputs so as to generate a keystream block Z<NUM>. The keystream block Z<NUM> is then truncated to a desired length l, as shown by truncate functional block <NUM>. The value of l here can be less than r.

The input to duplex object <NUM> is authentication data A (or optionally A∥<NUM>, i.e. a concatenation of authentication data A and a flag <NUM>). The authentication data A can include but is not limited to, authenticated packet headers. The authentication data A (or optionally A∥<NUM>) is padded in padding functional block <NUM> to make it a multiple of r (if it is not a multiple of r). The padding of padding functional block <NUM> is the same as or similar to that of padding functional block <NUM>. Next, the output of padding functional block <NUM> is then combined with keystream block Z<NUM>. This combining can be achieved via XOR operations <NUM>, as shown in <FIG>. XOR operations are well known in the art, and therefore will not be described in detail here. Still, it should be understood that the XOR operations are performed on a bit-by-bit basis. The results of the XOR operations are then passed to permutation functional block <NUM>. In permutation functional block <NUM>, the unique permutation function f is performed so as to generate a keystream block Z<NUM>. The keystream block Z<NUM> is then optionally truncated to a desired length l, as shown by truncate functional block <NUM>. The value of l here can be less than r. Truncation may be performed when the number of bits contained in the message body B is less than r. In this case, the value of l equals the number of bits contained in the message body B. The truncated keystream block Z<NUM>-Trunc is output from duplex object <NUM>.

Thereafter, the truncated keystream block Z<NUM>-Trunc is combined with a message body B (or optionally B∥l, i.e. a concatenation of message body B and a flag <NUM>). The message body B can include, but is not limited to, packet payload. This combining is achieved via XOR operations <NUM>, which produces encrypted data (e.g., ciphertext) C. The XOR operations <NUM> are performed on a bit-by-bit basis.

The input to duplex object <NUM> is message body data B (or optionally B∥l). The message body data B can include but is not limited to, packet payload data. The message body data B (or optionally B∥l) is padded in padding functional block <NUM> to make it a multiple of r (if it is not a multiple of r). The padding of padding functional block <NUM> is the same as or similar to that of padding functional blocks <NUM> and <NUM>. Next, the output of padding functional block <NUM> is then combined with keystream block Z<NUM>. This combining can be achieved via XOR operations <NUM>, as shown in <FIG>. XOR operations are well known in the art, and therefore will not be described in detail here. Still, it should be understood that the XOR operations are performed on a bit-by-bit basis. The results of the XOR operations are then passed to permutation functional block <NUM>. In permutation functional block <NUM>, the unique permutation function f is performed so as to generate a keystream block Z<NUM>. The keystream block Z<NUM> is then optionally truncated to a desired length l, as shown by truncate functional block <NUM>. The value of l here can be less than r. The truncated keystream block Z<NUM>-Trunc is output from duplex object <NUM>. The truncated keystream block Z<NUM>-Trunc is then used as an authentication tag T.

In a communications scenario, the encrypted data (e.g., ciphertext) C and the authentication tag T would be transmitted from a source communication device to a destination communication device. The cryptographic key K would not be transmitted since it would be known by both devices.

The advantages of the duplex construction <NUM> are that: a single cryptographic key is required; encryption and authentication requires only a single pass; intermediate tags are supported thereby; additional authentication data (e.g., packet headers) is supported thereby; it is secure against generic attacks; and the ability to trade off speed and security by adjusting the value of r.

Referring now to <FIG>, there is provided a schematic illustration that is useful for understanding the unique permutation function f of the present solution which is employed in the sponge and duplex constructions described above in relation to <FIG>. The permutation function f supports any key size (e.g., <NUM> bits or <NUM> bits) and is bijective. Since the permutation function f is bijective, f-<NUM> (inverse of f) exists by definition. While f-<NUM> is not used in practice, it may be helpful for cryptanalysis and verification purposes. Notably, the number of bits that are input and/or output from the permutation function f is also customizable.

The permutation function f comprises a round function fround that is iterated R times, depending on the key size. The round function fround consists of the following layers: a substitution layer <NUM>; a permutation layer <NUM>; a mixing layer <NUM>; and a round constant addition layer <NUM>. In the substitution layer <NUM>, the bits input thereto are substituted with first substitute bits in accordance with a particular transformation and/or mapping algorithm. For example, input bits <NUM> are substituted with bits <NUM>. The number of bits input/output to/from the substitution layer <NUM> can be the same or different. In the permutation layer <NUM>, the bits input thereto are re-arranged. In the mixing layer <NUM>, at least two outputs of the permutation layer are combined together. In the round constant addition layer <NUM>, a constant is added to the output of the mixing layer. The manners in which the operations of each layer <NUM>-<NUM> are achieved will be discussed in detail below.

Notably, R is an integer which has a value large enough to resist differential attacks, linear attacks and other attacks depending on the cryptographic key size (e.g., R=<NUM> for a <NUM> bit key or R=<NUM> for a <NUM> bit key). In this regard, R is a customizable element of the permutation function f. In some scenarios, R is determined by (<NUM>) calculating the number of rounds needed for linear and differential cryptanalysis and (<NUM>) adding some buffer to increase the security margin.

Referring now to <FIG>, there is provided an expanded block diagram of the round function fround. The substitution layer <NUM> comprises a plurality of identical substitution boxes (or S-boxes) <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>,. , <NUM>(N-<NUM>)/<NUM>, <NUM>N/<NUM> which collectively receive N input bits (e.g., <NUM> input bits) and individually receive X bits of the N input bits (e.g., <NUM> bits of <NUM> input bits). The value of N is selected to be large enough to keep a cryptographic key secure. For example, the value of N is selected to be <NUM> bits for a cryptographic key having a size of <NUM> bits or <NUM> bits.

The purpose of the S-boxes is to perform substitution so as to obscure the relationship between the cryptographic key and encrypted data (e.g., ciphertext). S-boxes are well known in the art, and therefore will not be described in detail herein. Any known or to be known S-box can be used herein without limitation provided that the following properties are satisfied thereby.

For example, each S-box <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>,. , <NUM>(N-<NUM>)/<NUM>, <NUM>N/<NUM> comprises an X-bit-to-X-bit S-box or an X-bit-by-Y-bit S-box, where X is a customizable integer and Y is a customizable integer different from X. The S-boxes can be implemented as look-up tables or in hardware using logical gates (e.g., XOR gates and AND gates). The look-up tables can be fixed or dynamically generated using the cryptographic key.

In some scenarios, each S-box comprises a bijective <NUM>-bit-to-<NUM>-bit S-box. An illustrative architecture for such an S-box is described in Appendix C of a document entitled "<NPL>. Each S-box of the substitution layer <NUM> is computed by the following mathematical equation. <MAT> where x is a multi-bit input (e.g., a <NUM> bit input), A is a multi-bit invertible matrix (e.g., a 16x16-bit invertible matrix), and b is a multi-bit matrix (e.g., a <NUM> bit matrix). Input x is an element of a finite field GF(<NUM><NUM>)lp(x), where p(x) is the irreducible polynomial x<NUM>+x<NUM>+x<NUM>+x+<NUM>. x-<NUM> is then treated as a <NUM>-bit vector, and the affine transformation A·x-<NUM> + b is computed yielding a <NUM>-bit output S(x).

In this regard, the input to the S-box is represented as a <NUM>-bit column vector x=(x<NUM> x<NUM>. x<NUM> x<NUM>)T, x<NUM> is the most significant bit. Using this notation, the forward S-box function is re-written as follows.

The inverse of the S-box function is defined by the following mathematical equation.

The above-described S-box can be implemented in hardware using <NUM> XOR gates and <NUM> AND gates.

The S-box is customizable by changing the polynomial p(x). The polynomial can be changed by inputting a new polynomial or selecting a polynomial from a plurality of pre-programmed polynomials. In the latter case, the polynomial can be randomly selected from the plurality of pre-programmed polynomials. The random selection can be achieved in accordance with a chaotic, random or pseudo-random number algorithm. Chaotic, random and pseudo-random number algorithms are well known in the art, and therefore will not be described herein. Any known or to be known chaotic, random or pseudo-random number algorithm can be used herein without limitation.

Additionally or alternatively, the S-box is customizable by specifying values of the invertible matrix A and/or the vector b, such that the S-box meets the following criteria.

The above-listed criteria are considered to provide a relatively strong cryptographic algorithm in which standard classical attacks are unlikely to be successful. Other criteria can be considered here. However, the present inventors found through significant research that the above-listed criteria provides a cryptographic algorithm with sufficient strength for military applications. These criteria advantageously address issues with key search attacks without any knowledge of the algorithms implementation and key search attacks using knowledge of at least one feature of the implemented cryptographic algorithm.

In some scenarios, the values of the invertible matrix A and/or the vector b are selected randomly. This selection is achieved by selecting values thereof in accordance with a chaotic, random or pseudo-random number algorithm. Any known or to be known chaotic, random or pseudo-random number algorithm can be used herein without limitation.

For example, in some scenarios, a user performs a user-software interaction to select at least one of a plurality of chaotic, random or pseudo-random algorithms that is to be used to generate values for the invertible matrix A and/or the vector b. The same or different algorithm can be used to generate numbers for the invertible matrix A and the vector b. The user may also enter or select values for parameters of the selected chaotic, random or pseudo-random algorithm(s). The present solution is not limited to the particulars of this example.

The present solution is also not limited to the particulars of the above discussion. In this regard, it should be understood that any S-box configuration can be employed where there is an N bit input (e.g., <NUM> bit) to an N bit output (e.g., <NUM> bit) mapping that meets the above listed criteria. For example, in other scenarios, the present solution is implemented using four <NUM>-bit mappings, rather than one <NUM>-bit to <NUM>-bit mapping.

The permutation layer <NUM> comprises a bitwise permutation function <NUM>. The purpose of the bitwise permutation function <NUM> is to permute or change a bit position of each bit <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>,. , <NUM><NUM>, <NUM><NUM> input thereto relative to all other bits input thereto. Bitwise permutation functions are well known in the art, and therefore will not be described in detail herein. Any known or to be known bitwise permutation function can be used herein without limitation provided that the following properties are satisfied thereby.

For example, the bitwise permutation function includes a linear permutation function, an affine permutation function, or a random permutation function.

In some scenarios, the bitwise permutation function <NUM> comprises an affine function defined by the following mathematical equation. <MAT> where π(x) represents the output bit position (π(x) ≤ <NUM>), α is an integer constant (e.g., <NUM>), x represents the input bit position (<NUM> ≤ x), and β is an integer constant (e.g., <NUM>).

The bitwise permutation function <NUM> is customized by changing the permutation formula, but meeting the following criteria.

The listed criteria are considered to provide a relatively strong cryptographic algorithm in which standard classical attacks are unlikely to be successful. The strength of the algorithm is facilitated here by ensuring that (a) the output bit string is different from the input bit string and (b) that there are a relatively large number of bit changes between the input bit string and the output bit string. Other criteria can be considered here. However, the present inventors found through significant research that the above listed criteria provided a cryptographic algorithm with sufficient strength for military applications. These criteria advantageously address issues with key search attacks without any knowledge of the algorithms implementation and key search attacks using knowledge of at least one feature of the implemented.

A plurality of permutation formulas which meet the above criteria are described in a thesis document entitled "Design and Cryptoanalysis of a Customizable Authenticated Encryption Algorithm", written by Kelly. Any of the permutation functions mentioned in this thesis can be used herein without limitation. For example, the above-described permutation function is changed to one of the following permutation functions which meet the above criteria. <MAT> <MAT> <MAT> <MAT>.

Customization can be achieved by either selecting one of a plurality of predefined and/or preprogrammed permutation functions or by allowing a customer to enter their own unique permutation formula.

The present solution is not limited to the particulars of the permutation formulas referenced above. Any permutation technique can be used here provided that the above listed three criteria are met.

The mixing layer <NUM> comprises a mixing function that is implemented via a plurality of mixers <NUM><NUM>, <NUM><NUM>,. , <NUM><NUM>. In the scenario shown in <FIG>, one mixer is provided for every two S-boxes. The present solution is not limited in this regard. The particular number of S-boxes per mixer is customizable. Also, the mixing function is a customizable element of the present solution. The purpose of the mixing function is to provide local diffusion (i.e., across two words) and increase the linear and differential branch numbers of a round from two to three. In this regard, mixers based on matrix multiplication in Galois Field GF(<NUM>M) may be employed because they satisfy all of the following constraints: the matrix is invertible in GF(<NUM><NUM>)/<p(x)>; the matrix has a differential and linear branch number equal to three; and the transformation is efficiently implementable in hardware.

In some scenarios, operations performed by each mixer <NUM><NUM>, <NUM><NUM>,. , <NUM><NUM> is defined by the following mathematical equation.

The mixer takes in two words W<NUM> and W<NUM> as input and produces outputs W'<NUM> and W'<NUM> as follows.

The mixer is implementable in hardware. An illustrative hardware implementation of the mixer is provided in <FIG>. As shown in <FIG>, the mixer comprises XOR gates <NUM>, <NUM>, <NUM> and Galois field multipliers <NUM>, <NUM>. The Galois field multipliers <NUM>, <NUM> perform multiplication by x in Galois field GF(<NUM>X).

The mixing layer <NUM> is customizable based on user input. As noted above, each mixer in the mixing layer <NUM> has two <NUM>-bit input words W<NUM>, W<NUM> and two <NUM>-bit output words W'<NUM>, W'<NUM>. In the mixing layer <NUM>, arithmetic in Galois field GF(<NUM><NUM>)/p(x) is performed using a certain degree-<NUM> irreducible polynomial p(x). Each <NUM>-bit quantity is treated as a vector of coefficients of a polynomial in x, from x<NUM> down to x<NUM>. Addition and multiplication are performed on polynomials using GF(<NUM>) arithmetic on the coefficients. Every result is reduced modulo p(x). A <NUM>-bit CAM register setting is used to specify a particular irreducible polynomial p(x) used in each mixer. There are sixteen mixers <NUM><NUM>,. , <NUM><NUM> so there are eight CAM register bits per mixer. The eight CAM register bits are used to select a predefined irreducible polynomial from a given pre-programmed set of irreducible polynomials (e.g., <NUM>). In this regard, a user inputs a bit string of <NUM> bits (i.e., <NUM> bits by <NUM> mixers). The bit string is then processed to parse out sixteen segments each comprising eight bits. Each segment is converted or translated into irreducible polynomial coefficient values and/or an identifier for a particular irreducible polynomial of the pre-programmed set. The identifier can comprise (<NUM>) information identifying the particular irreducible polynomial and/or (<NUM>) information indicating where the particular irreducible polynomial of the pre-programmed set is stored in a data store (e.g., memory <NUM> of <FIG>) local to the electronic device implementing the cryptographic algorithm. A table lookup can be used here to perform the bit-to-coefficient conversion/translation and/or the bit-to-identifier conversion/translation.

Notably, there are <NUM>,<NUM> different <NUM>-degree irreducible polynomials that meet the above-listed criteria. The set of irreducible polynomials (e.g., <NUM>) is selected at the factory from the <NUM>,<NUM> different <NUM>-degree polynomials. Accordingly, a different set of irreducible polynomials (e.g., <NUM>) can be selected for each customer to achieve customization of the cryptographic algorithm, i.e., a new set of predefined irreducible polynomials (e.g., <NUM>) can be from the <NUM>,<NUM> different <NUM>-degree polynomials for each customer.

In some scenarios, at least two of the mixers use the same irreducible polynomial, but with different coefficients. Additionally or alternatively, the bit string is entered by the user in the field. The bit string includes arbitrary bits. The user has no expertise with regard to cryptography. Still, the user is able to change the encryption/decryption algorithm without causing any degradation to the security thereof.

The round constant addition layer <NUM> comprises a plurality of addition operations represented by blocks <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM>,. , <NUM>(N-<NUM>)/<NUM>, <NUM>N/<NUM>. The purpose of the addition operations is to add a constant N bit value to the state using bitwise XOR in order to disrupt symmetry and prevent slide attacks. Notably, the round constant must be fixed random N-bit values. Each round i must use a different round constant. The round constant is customizable, and should be unique for each round to prevent against slide attacks and be random, pseudorandom or highly asymmetric to reduce symmetry in the state. Accordingly, the round constant addition layer <NUM> is customizable by simply choosing different round constants, but meeting the following criteria.

In some scenarios, at least one of the following criteria may additionally be met.

A round constant can be chosen at random in accordance with a chaotic, random or pseudo-random number algorithm. Chaotic, random and pseudo-random number algorithms are well known in the art, and therefore will not be described herein. Any known or to be known chaotic, random or pseudo-random number algorithm can be used herein without limitation.

In some scenarios, the round constant RCi for round i is given by the following mathematical equation. <MAT> where ASCII(i) is a function that provides a one or two byte ASCII representation of round i and KECCAK-<NUM> is the hash function that outputs an N (e.g., <NUM>) bit message digest. The following TABLE <NUM> provides the values of the round constant RCi up to i = <NUM>.

Notably, the present solution is suitable for implementation on Field Programmable Gate Arrays ("FPGAs"). Serial and fully parallel implementations can be used to meet area or performance constraints. The S-boxes may be implemented using composite field techniques and pipelined for higher performance. Also, the present solution can be integrated into Single Chip Crypto ("SCC") systems.

Furthermore, the present solution anticipates future security requirements. Post Quantum Security ("PQS") will become a requirement for radio product customers, as well as provable computational security and quantified theoretical security metrics and analysis processes. The present solution provides a security means that satisfies all of these requirements.

As evident from the above discussion, the present algorithm is highly customizable within a security margin. This customizability is useful in cases where different users want unique, proprietary algorithms. The following features of the present solution are customizable: (<NUM>) the state initialization; (<NUM>) the number of rounds R; (<NUM>) the permutation function f; (<NUM>) the number of bits N input into the round function; (<NUM>) the type, number, parameters and mapping function of the S-boxes; (<NUM>) the bitwise permutation function; (<NUM>) the mixing function; and (<NUM>) the round constants.

Referring now to <FIG>, there is provided a flow diagram of an illustrative method <NUM> for generating encrypted data (e.g., ciphertext) that is useful for understanding the present solution. Method <NUM> begins with step <NUM> and continues with optional step <NUM>. In optional step <NUM>, a cryptographic key is concatenated with a flag value. Next in step <NUM>, the cryptographic key is combined with state initialization bits to generate the first combination bits. A multi-bit value for the state initialization bits may be selected such that it is unique for a given application.

The first combination bits are then used to produce a first keystream, as shown by step <NUM>. The first keystream may optionally be truncated to a desired length, as shown by step <NUM>. The first keystream is produced using a permutation function f. The permutation function f is performed using the first combination bits as inputs thereof. The permutation function f comprises a round function fround that is iterated R times. The round function fround consists of (<NUM>) a substitution layer in which the first combination bits are substituted with substitute bits, (<NUM>) a permutation layer in which the substitute bits are re-arranged, (<NUM>) a mixing layer in which at least two outputs of the permutation layer are combined together, and (<NUM>) an addition layer in which a constant is added to the output of the mixing layer.

After completing optional step <NUM>, method <NUM> continues with another optional step <NUM>. Step <NUM> involves padding the first data to make a total number of bits contained therein a multiple of the total number of state initialization bits prior to being encrypted. The first data is then encrypted using the first keystream, as shown by step <NUM>. In this regard, the first data may be combined with the first keystream using modular arithmetic (e.g., modulo <NUM> addition). The first data comprises, but is not limited to, authentication data and/or message body data.

If a sponge framework is employed [<NUM>:YES], then steps <NUM>-<NUM> are performed. Step <NUM> involves producing a second keystream by performing the permutation function f using the first keystream as inputs thereto. Step <NUM> involves using the second keystream to encrypt the second data so as to produce the second encrypted data (e.g., ciphertext). Upon completing step <NUM>, method <NUM> ends or other processing is performed (e.g., repeat steps <NUM>-<NUM> for a next block of message data), as shown by step <NUM>.

If a duplex framework is employed [<NUM>:NO], then steps <NUM>-<NUM> are performed. Prior to discussing steps <NUM>-<NUM>, it should be understood that in the duplex context the first encrypted data (e.g., ciphertext) is produced in previous step <NUM> by: combining the first keystream with authentication data to generate the second combination bits; producing a second keystream by performing the permutation function f using the second combination bits as inputs thereto; and combining the second keystream with the message body data so as to produce the first encrypted data (e.g., ciphertext). The second keystream is also used in step <NUM> to produce the third combination bits. The third combination bits are input into the permutation function f, as shown by step <NUM>. As a result of performing the permutation function f, a third keystream is produced. At least a portion of the third keystream is used as an authentication tag.

<FIG> is a flow diagram of an illustrative method <NUM> for customizing a permutation function f. Notably, the customization changes the permutation function f without degenerating the security of the encryption/decryption algorithm.

As shown in <FIG> includes a plurality of blocks <NUM>-<NUM> to illustrate that the permutation function f can be customized in various ways. <FIG> can be modified to eliminate any of the blocks or to show certain block as optional blocks. Also, the present solution is not limited to the order in which the blocks are shown in <FIG>. For example, block <NUM> can reside before block <NUM>.

As also shown in <FIG>, method begins with <NUM> and continues with <NUM> where a first user-software interaction is performed to customize an S-box (e.g., S-box <NUM><NUM>,. , or <NUM>N/<NUM> of <FIG>) of a substitution layer (e.g., substitution layer <NUM> of <FIG>). The customization is achieved by changing a polynomial equation and/or by changing an input-to-output bit mapping, such that the S-box (<NUM>) has input values and output values that are all different, (<NUM>) does not have an output value that is equal to the corresponding input value, (<NUM>) does not have an output value that is a bitwise complement of the corresponding input value, (<NUM>) has a maximum differential probability of <NUM>-<NUM> or smaller, and (<NUM>) has a maximum linear bias of <NUM>-<NUM> or smaller. In some scenarios, the input-to-output bit mapping is changed by specifying values of at least one of a multi-bit invertible matrix A and a multi-bit vector b for the mathematical equation S(x) = A·x-<NUM> + b, where x is a multi-bit input. The values may be randomly selected in accordance with a chaotic, random or pseudo-random number algorithm. The same or different chaotic, random or pseudo-random number algorithm can be used to specify values for the multi-bit invertible matrix A and the multi-bit vector b. The first user-software interaction can be achieved using an input device (e.g., a touch screen <NUM> of <FIG>, a keypad <NUM> of <FIG>, a mouse, a drop down menu or any other input means) provided by a computing device (such as that shown in <FIG>).

Next in <NUM>, a permutation formula is changed for a bitwise permutation function of a permutation layer (e.g., permutation layer <NUM> of <FIG>). This change can be achieved by performing a second user-software interaction to (a) select a permutation formula from a plurality of predefined permutation formulas, or (b) enter a unique permutation formula that is not included in the plurality of predefined permutation formulas. This change must be made such that the following criteria is met: (<NUM>) each output bit of a given S-box goes to a different mixer's input bit; (<NUM>) bit positions of bits input to the permutation layer are different than the positions of corresponding bits output from the permutation layer; and (<NUM>) an order of each bit position is greater than a number of rounds in a bijective function. The second user-software interaction can be achieved using a touch screen, a key pad, a mouse, a drop down menu or any other input means provided by a computing device (such as that shown in <FIG>).

In <NUM>, a third user-software interaction is performed to select a set of irreducible polynomial equations from a plurality of polynomial equations. The selected set is pre-program for possible use by mixers (e.g., mixers <NUM><NUM>,. , <NUM><NUM> of <FIG>) of a mixing layer (e.g., mixing layer <NUM> of <FIG>). In some scenarios, each of the plurality of polynomial equations comprises a degree-<NUM> irreducible polynomial equation.

A fourth user-software interaction is performed in <NUM> to select, for each mixer of the mixing layer, an irreducible polynomial p(x) from the pre-programmed set of irreducible polynomials. This selecting can be achieved by: receiving a first user-software interaction for entering a first bit string comprising a plurality of first arbitrary bits; breaking the first bit string into a plurality of equal length segments each comprising only a portion of the plurality of first bits; and converting/translating each of the equal length segments into irreducible polynomial coefficients into irreducible polynomial coefficients and/or an irreducible polynomial identifier, as described above. Thereafter, a respective mixer of the mixing layer is caused to use the irreducible polynomial coefficients and/or the identified irreducible polynomial. In some scenarios, the third user-software interaction of <NUM> is performed at the factory, while the fourth user-software interaction of <NUM> is performed in the field.

In <NUM>, a fifth user-software interaction is performed to cause the selection of a round constant to be employed in a round constant addition layer (e.g., round constant addition layer <NUM> of <FIG>). Notably, the selection is made such that (<NUM>) there is no identifiable pattern in a plurality of round constant values and (<NUM>) the round constant values are different for each round. In some scenarios, each round constant value of the plurality of round constant values has the same number of <NUM>'s and <NUM>'s, and/or is chosen at random. Subsequently, <NUM> is performed where method <NUM> ends or other processing is performed.

Referring now to <FIG>, there is provided a detailed block diagram of an illustrative architecture for a computing device <NUM>. The computing device <NUM> is generally configured to allow a cryptographic algorithm to be customized (and more particularly a permutation function f as described above). In this regard, the computing device <NUM> implements the cryptographic algorithm and/or is able to communicate with another electronic device (e.g., a communications device, such as a handheld radio) implementing the cryptographic algorithm.

The computing device <NUM> may include more or less components than those shown in <FIG>. However, the components shown are sufficient to disclose an illustrative embodiment implementing the present solution. The hardware architecture of <FIG> represents one embodiment of a representative server configured to facilitate inventory counts and management. As such, the computing device <NUM> of <FIG> implements at least a portion of a method for customizing a permutation function f.

Some or all the components of the computing device <NUM> can be implemented as hardware, software and/or a combination of hardware and software. The hardware includes, but is not limited to, one or more electronic circuits. The electronic circuits can include, but are not limited to, passive components (e.g., resistors and capacitors) and/or active components (e.g., amplifiers and/or microprocessors). The passive and/or active components can be adapted to, arranged to and/or programmed to perform one or more of the methodologies, procedures, or functions described herein.

As shown in <FIG>, the computing device <NUM> comprises a user interface <NUM>, a CPU <NUM>, a system bus <NUM>, a memory <NUM> connected to and accessible by other portions of computing device <NUM> through system bus <NUM>, and hardware entities <NUM> connected to system bus <NUM>. The user interface can include input devices (e.g., a keypad <NUM>) and output devices (e.g., speaker <NUM>, a display <NUM>, and/or light emitting diodes <NUM>), which facilitate user-software interactions for controlling operations of the computing device <NUM>.

At least some of the hardware entities <NUM> perform actions involving access to and use of memory <NUM>, which can be a RAM, a disk driver and/or a Compact Disc Read Only Memory ("CD-ROM"). Hardware entities <NUM> can include a disk drive unit <NUM> comprising a computer-readable storage medium <NUM> on which is stored one or more sets of instructions <NUM> (e.g., software code) configured to implement one or more of the methodologies, procedures, or functions described herein. The instructions <NUM> can also reside, completely or at least partially, within the memory <NUM> and/or within the CPU <NUM> during execution thereof by the computing device <NUM>. The memory <NUM> and the CPU <NUM> also can constitute machine-readable media. The term "machine-readable media", as used here, refers to a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions <NUM>. The term "machine-readable media", as used here, also refers to any medium that is capable of storing, encoding or carrying a set of instructions <NUM> for execution by the computing device <NUM> and that cause the computing device <NUM> to perform any one or more of the methodologies of the present disclosure.

In some scenarios, the hardware entities <NUM> include an electronic circuit (e.g., a processor) programmed for facilitating the customization of a cryptographic algorithm. In this regard, it should be understood that the electronic circuit can access and run a software application <NUM> installed on the computing device <NUM>. The software application <NUM> is generally operative to facilitate: a first user-software interaction to customize an S-box of a substitution layer by randomly specifying values of invertible matrix A and a vector b; a second user-software interaction to (a) select a permutation formula from a plurality of predefined permutation formulas, or (b) enter a unique permutation formula that is not included in the plurality of predefined permutation formulas; a third user-software interaction to select an irreducible polynomial p(x) from a plurality of irreducible polynomials to be used in each mixer of a mixing layer; and/or a fourth user-software interaction to cause the random selection of at least one round constant to be employed in a round constant addition layer, where each bit in the selected round constant is a <NUM> or <NUM> with probability <NUM>. Other functions of the software application <NUM> are apparent from the above discussion.

As noted above, the present solution provides a self-synchronizing mode of operation for the cryptographic systems (such as those described above in relation to <FIG>) employing block cipher based cryptographic algorithms. The self-synchronizing mode of operation enables automatic cryptographic resynchronization between transmitters and receivers, and also enables late network entry by communication devices into an already established conversation. The self-synchronizing mode of operation provides a way for a receiver to synchronize its local cryptographic algorithm when joining a conversation for which the synchronization information and initialization variable for the cryptographic algorithm has already been sent to participants. Based on pseudo-random events, the communication devices of a participant self-synchronize their cryptographic algorithms during the conversation. The pseudo-random events are based on the ciphertext being transmitted because the ciphertext appears statistically random. Every node on the network has access to the ciphertext, and is configured to detect patterns in the ciphertext. When a pattern is detected, a node will re-initialize a state of its cryptographic algorithm using the ciphertext transmitted over the channel. The channel may include, but is not limited to, a low bit error rate channel. In this way, the nodes will access uncorrupted ciphertext and concurrently synchronize states of their cryptographic algorithms.

An illustration of an illustrative system <NUM> is provided in <FIG>. As shown in <FIG>, system <NUM> comprises a transmitting communication device <NUM> and a receiving communication device <NUM>. The communication devices <NUM>, <NUM> can include, but are not limited to, radios, smart phones, cellular phones and/or personal computers. The communication devices <NUM>, <NUM> implement a self-synchronizing cipher feedback mode. The particulars of the self-synchronizing cipher feedback mode will become evident as the discussion progresses.

Referring now to <FIG>, there is provided an illustration that is useful for understanding an illustrative self-synchronizing cipher feedback mode of operation for the transmitting communication device <NUM>. The communication device <NUM> may comprise communication device <NUM> of <FIG>.

The communication device <NUM> comprises a transmitter circuit employing traditional block cipher encryption. The traditional block cipher encryption can include, but is not limited to, Advanced Encryption Standard (AES) based encryption, Data Encryption Standard (DES) based encryption, International Data Encryption Algorithm (IDEA) based encryption, and/or RC5 based encryption. Each of the listed types of block cipher encryption is well known.

As shown in <FIG>, the communication device <NUM> comprises a block cipher device <NUM>, a key buffer <NUM>, a combiner <NUM>, a computing device <NUM>, a Plaintext (PT) buffer <NUM>, a Ciphertext (CT) buffer <NUM>, a pattern detector <NUM>, a transceiver <NUM> and an antenna <NUM>. Computing device <NUM> can be the same as or similar to computing device <NUM> of <FIG>. One or more components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can be implemented by or integrated with computing device <NUM>. Accordingly, the listed components comprise hardware, software and/or machine-readable media.

The block cipher device <NUM> is configured to perform a block cipher encryption algorithm for encrypting plaintext <NUM> generated by computing device <NUM>. This encryption is achieved using keystream block(s) <NUM> output from the block cipher device <NUM>. The plaintext <NUM> is stored in the PT buffer <NUM>. A single bit <NUM> of the plaintext is provided from the PT buffer <NUM> to the combiner <NUM>. The combiner <NUM> combines the plaintext bit <NUM> with a keystream bit <NUM> to generate a ciphertext bit <NUM>. This combining can be achieved via modulo arithmetic. The ciphertext bit <NUM> is stored in the CT buffer <NUM> and transmitted from the communication device <NUM> via transceiver <NUM> and antenna <NUM>. Transceivers and antennas are well known.

For self-synchronization of the block cipher device <NUM>, the pattern detector <NUM> obtains ciphertext <NUM> from the CT buffer <NUM> and analyzes the same to detect a known fixed pattern therein (e.g., <NUM>). The known fixed pattern is defined by a given number of bits which is equal to or less than the total number of bits in the keystream block(s) <NUM>. For example, the keystream block(s) <NUM> include(s) sixty-four bits or one hundred twenty eight bits, while the known fixed pattern includes five to eleven bits. The present solution is not limited in this regard.

The length of the known fixed pattern defines the statistical frequency at which the pattern will be detected by the pattern detector <NUM>. The shorter the pattern the more frequently the pattern is detected by the pattern detector <NUM>. The longer the pattern the less frequently the pattern is detected by the pattern detector <NUM>. The pattern length can be selected by a user of the communication device <NUM>, and specifies an average frequency of cryptographic algorithm re-synchronization. Shorter patterns allow for quicker late network entry by the communication device <NUM> to an established conversation, but with a reduced performance. Longer patterns allow for an improved performance, but with a slower late network entry by the communication device <NUM>. In response to the user selection of a pattern length, the communication device <NUM> performs operations to configure the pattern detector <NUM> to detect a given pattern from a list of pre-defined known fixed patterns which has the user selected pattern length.

When the pattern is detected, the pattern detector <NUM> provides the ciphertext <NUM> to the block cipher device <NUM>. The block cipher device <NUM> uses the ciphertext <NUM> as an initialization value to re-initialize a state of the block cipher encryption algorithm.

It should be noted that the ciphertext <NUM> of a given iteration of the pattern detection process can include one or more bits of ciphertext, and can have a total number of bits that is equal to or less than the keystream block(s) <NUM>. For example, in an N-M (e.g., thirty-seventh) iteration of the pattern detection process, a keystream block <NUM> has N bites (e.g., sixty-four bits or one hundred twenty eight bits), while the ciphertext <NUM> analyzed by the pattern detector <NUM> comprises N-M bits (e.g., thirty-seven bits). M and N are integers. The present solution is not limited to the particulars of this example. The bit size of the ciphertext <NUM> can increase by one bit per iteration of the pattern detection process performed by pattern detector <NUM>.

Referring now to <FIG>, there is provided an illustration that is useful for understanding an illustrative self-synchronizing cipher feedback mode of operation for a receiving communication device <NUM>. Communication device <NUM> can be comprise communication device <NUM> of <FIG>.

The communication device <NUM> comprises a receiver circuit employing traditional block cipher decryption. The traditional block cipher decryption can include, but is not limited to, AES based decryption, DES based decryption, IDEA based decryption, and/or RC5 based decryption. Each of the listed types of block cipher encryption is well known.

As shown in <FIG>, the communication device <NUM> comprises an antenna <NUM>, a receiver <NUM>, a combiner <NUM>, a computing device <NUM>, a CT buffer <NUM>, a pattern detector <NUM>, a block cipher device <NUM>, and a key buffer <NUM>. Computing device <NUM> can be the same as or similar to computing device <NUM> of <FIG>. One or more components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can be implemented by or integrated with computing device <NUM>. Accordingly, the listed components comprise hardware, software and/or machine-readable media.

Communication device <NUM> receives ciphertext (e.g., ciphertext <NUM> of <FIG>) via antenna <NUM> and receiver <NUM>. Ciphertext bits <NUM> are provided to the combiner <NUM> in a bit-by-bit manner. The combiner <NUM> combines each ciphertext bit <NUM> with a keystream bit <NUM> to generate a plaintext bit <NUM>. This combining can be achieved via modulo arithmetic. The plaintext bit <NUM> is then provided to the computing device <NUM>. The computing device <NUM> can store and further process the plaintext bits (e.g., for display or otherwise output to a user thereof).

The keystream bits <NUM> are generated by the block cipher device <NUM> and stored in the key buffer <NUM>. The block cipher device <NUM> is configured to perform a block cipher decryption algorithm for decrypting ciphertext <NUM> received by communication device <NUM>. This decryption is achieved using bits of keystream block(s) <NUM> output from the block cipher device <NUM>. As described above, the decryption is achieved by combining ciphertext bits with keystream bits the combiner <NUM>.

For self-synchronization of the block cipher device <NUM>, the ciphertext bits <NUM> are also provided to the ciphertext buffer <NUM> for storage therein. Ciphertext <NUM> is provided from the ciphertext buffer <NUM> to the pattern detector <NUM>. Pattern detector <NUM> analyzes the ciphertext <NUM> to detect a known fixed pattern therein (e.g., <NUM>). The known fixed pattern is defined by a given number of bits which is equal to or less than the total number of bits in the keystream block(s) <NUM>. For example, the keystream block(s) <NUM> include(s) sixty-four bits or one hundred twenty eight bits, while the known fixed pattern includes five to eleven bits. The present solution is not limited in this regard. The length of the known fixed pattern defines the statistical frequency at which the pattern will be detected by the pattern detector <NUM>.

When the pattern is detected, the pattern detector <NUM> provides the ciphertext <NUM> to the block cipher device <NUM>. The block cipher device <NUM> uses the ciphertext <NUM> as an initialization value to re-initialize a state of the block cipher decryption algorithm.

The self-synchronization concept discussed above in relation to <FIG> can be implemented in systems employing duplex constructions for cryptography. Illustrative communication devices are shown in <FIG> which employ duplex constructions and are configured to self-synchronize the same. An illustrative duplex sponge construction is described above in relation to <FIG>. The discussion of <FIG> is sufficient for understanding the cryptographic algorithm employed by the communication devices of <FIG>.

Referring now to <FIG>, there is provided an illustration of an illustrative transmitting communication device <NUM> configured to operate in a self-synchronization mode for synchronizing and re-synchronizing its sponge based cryptographic algorithm. The communication device <NUM> may comprise communication device <NUM> of <FIG>. The sponge based cryptographic algorithm implements a permutation function f described above in relation to <FIG>. Accordingly, the communication device <NUM> comprises combiners <NUM>, <NUM>, <NUM> and permutation functional blocks <NUM>, <NUM>, <NUM>. These listed components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> are the same as or similar to components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of <FIG>. Thus, the discussion of components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of <FIG> is sufficient for understanding components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of <FIG>.

Communication device <NUM> also comprises a synchronization circuit <NUM>. The synchronization circuit <NUM> is configured to facilitate a self-synchronizing mode of operation. The self-synchronizing mode of operation enables automatic cryptographic resynchronization between communication device <NUM> and another communication device (e.g., communication device <NUM> of <FIG>). Based on pseudo-random events, the communication device <NUM> self-synchronizes it's cryptographic algorithm during on-going conversations or communication sessions. The pseudo-random events are based on the ciphertext being transmitted from the communication device <NUM> because the ciphertext appears statistically random. The synchronization circuit <NUM> is configured to detect patterns in the ciphertext. When a pattern is detected, the synchronization circuit <NUM> will cause a state of the cryptographic algorithm to be re-initialized using the ciphertext as an initialization value.

As shown in <FIG>, the synchronization circuit <NUM> comprises a key buffer <NUM>, a combiner <NUM>, a PT buffer <NUM>, a CT buffer <NUM>, a pattern detector <NUM>, and multiplexers (or other switching/selection devices) <NUM>, <NUM>. The synchronization circuit <NUM> is coupled to a computing device <NUM>. Computing device <NUM> can be the same as or similar to computing device <NUM> of <FIG>. One or more components of the synchronization circuit <NUM> can be implemented by or integrated with computing device <NUM>. Accordingly, the listed components comprise hardware, software and/or machine-readable media.

During operation, the synchronization circuit <NUM> receives message body data B from the computing device <NUM> and a keystream block Z<NUM> from permutation functional block <NUM>. The message body data B is stored in PT buffer <NUM>, and the keystream block Z<NUM> is stored in key buffer <NUM>. A single bit <NUM> of plaintext is provided from the PT buffer <NUM> to the combiner <NUM>. A single bit <NUM> of a keystream block is provided from the key buffer <NUM> to the combiner <NUM>. The combiner <NUM> combines the plaintext bit <NUM> with the keystream bit <NUM> to generate a ciphertext bit <NUM>. This combining can be achieved via modulo arithmetic. The ciphertext bit <NUM> is stored in the CT buffer <NUM> and transmitted from the communication device <NUM> via a transceiver <NUM> and an antenna <NUM>. Transceivers and antennas are well known.

For self-synchronization of the cryptographic algorithm, the pattern detector <NUM> obtains ciphertext <NUM> from the CT buffer <NUM> and analyzes the same to detect a known fixed pattern therein (e.g., <NUM>). The known fixed pattern is defined by a given number of bits which is equal to or less than the total number of bits in the keystream block(s) Z<NUM>. For example, the keystream block(s) Z<NUM> include(s) sixty-four bits or one hundred twenty eight bits, while the known fixed pattern includes five to eleven bits. The present solution is not limited in this regard.

When the pattern is detected, the pattern detector <NUM> generates and provides a resynchronization signal <NUM> to multiplexers <NUM>, <NUM>. The resynchronization signal <NUM> causes the ciphertext <NUM> to be passed to the permutation functional block <NUM> instead of the keystream block Z<NUM>, and causes a value of zero to be passed to the permutation functional block <NUM> instead of the capacity c<NUM>. The permutation functional block <NUM> uses the ciphertext <NUM> and zero value to re-initialize the cryptographic algorithm. More specifically, the unique permutation function f is performed in the permutation functional block <NUM> using the ciphertext <NUM> and zero value as inputs to generate a keystream block Z<NUM>.

It should be noted that the keystream block Z<NUM> and capacity c<NUM> are passed to the permutation functional block <NUM> when the pattern is not detected by the pattern detector <NUM> and the resynchronization signal <NUM> is not being provided to the multiplexers <NUM>, <NUM>. In these scenarios, the permutation function f is performed in the permutation functional block <NUM> using the keystream block Z<NUM> and capacity c<NUM> as inputs to generate a keystream block Z<NUM>.

It should be noted that the ciphertext <NUM> of a given iteration of the pattern detection process can include one or more bits of ciphertext, and can have a total number of bits that is equal to or less than the keystream block(s) Z<NUM>. For example, in an N-M (e.g., thirty-seventh) iteration of the pattern detection process, a keystream block Z<NUM> has N bites (e.g., sixty-four bits or one hundred twenty eight bits), while the ciphertext <NUM> analyzed by the pattern detector <NUM> comprises N-M bits (e.g., thirty-seven bits). M and N are integers. The present solution is not limited to the particulars of this example. The bit size of the ciphertext <NUM> can increase by one bit per iteration of the pattern detection process performed by pattern detector <NUM>.

In some scenarios, the keystream block(s) can be truncated in manner described above in relation to <FIG>. An illustration showing a modified version of the duplex construction <NUM> is provided in <FIG>. The modified duplex construction <NUM>' includes the synchronization circuit <NUM> of <FIG> inserted between permutation functional blocks <NUM> and <NUM>.

The duplex construction employed by communication device can comprise an MK-<NUM> cryptographic algorithm. An illustration showing implementation of the present solution in an MK-<NUM> context is provided in <FIG>. As shown in <FIG>, the MK-<NUM> cryptographic algorithm first absorbs the key into the algorithm state. In a next iteration, the Initialization Variable (IV) is absorbed into the algorithm state. Following the second iteration, the MK-<NUM> cryptographic algorithm is ready to process data. The Rate (R) portion of algorithm state is loaded into the key buffer and plaintext is loaded into the plaintext buffer. The contents of the key and plaintext buffers are left shifted by one bit at a time, mod-<NUM> added together and left shifted into the ciphertext buffer. Encryption continues in this manner until another iteration is initiated. Another iteration will begin either when the entire block of keystream is consumed or when the pattern detector is triggered. If another iteration is triggered when a block of keystream is consumed, the ciphertext buffer contents are concatenated with the capacity portion of the algorithm state and passed on for the next iteration of processing by the MK-<NUM> cryptographic algorithm. If another iteration is triggered by the pattern detector, the traffic key is re-absorbed by mod-<NUM> adding it into the ciphertext buffer. The ciphertext buffer contents are concatenated with a vector of all zeros and are passed on for the next iteration of processing by the MK-<NUM> cryptographic algorithm.

Referring now to <FIG>, there is provided an illustration of a receiving communication device <NUM> that is configured to operate in a self-synchronization mode for synchronizing and re-synchronizing its sponge based cryptographic algorithm. The communication device <NUM> can be comprise communication device <NUM> of <FIG>.

The sponge based cryptographic algorithm implements a permutation function f described above in relation to <FIG>. Accordingly, the communication device <NUM> comprises combiners <NUM>, <NUM>, <NUM> and permutation functional blocks <NUM>, <NUM>, <NUM>. These listed components <NUM>, <NUM>-<NUM> are the same as or similar to components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of <FIG>. Thus, the discussion of components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of <FIG> is sufficient for understanding components <NUM>, <NUM>-<NUM> of <FIG>.

As shown in <FIG>, the synchronization circuit <NUM> comprises a key buffer <NUM>, a combiner <NUM>, a PT buffer <NUM>, a CT buffer <NUM>, a pattern detector <NUM>, and multiplexers (or other switching/selection devices) <NUM>, <NUM>. The synchronization circuit <NUM> is coupled to a receiver <NUM> and a computing device <NUM>. Computing device <NUM> can be the same as or similar to computing device <NUM> of <FIG>. One or more components of the synchronization circuit <NUM> can be implemented by or integrated with computing device <NUM>. Accordingly, the listed components comprise hardware, software and/or machine-readable media.

During operation, the communication device <NUM> receives ciphertext via antenna <NUM> and receiver <NUM>. The ciphertext <NUM> is passed to the synchronization circuit <NUM>. At the synchronization circuit <NUM>, the ciphertext <NUM> is stored in the CT buffer <NUM>, and provided to the combiner <NUM> in a bit-by-bit manner. The combiner <NUM> combines each ciphertext bit <NUM> with a keystream bit <NUM> to generate a plaintext bit <NUM>. This combining can be achieved via modulo arithmetic. The plainttext bit <NUM> is then provided to the ' computing device <NUM>. The computing device <NUM> can store and further process the plainttext bits (e.g., for display or otherwise output to a user thereof).

The keystream bits <NUM> are generated by the cryptographic algorithm and stored in the key buffer <NUM>. The cryptographic algorithm is configured to perform a sponge based decryption algorithm for decrypting ciphertext <NUM> received by communication device <NUM>. This decryption is achieved using bits of keystream block(s) Z<NUM> output from the cryptographic device. As described above, the decryption is achieved by combining ciphertext bits with keystream bits the combiner <NUM>.

For self-synchronization of the cryptographic algorithm, the ciphertext <NUM> is provided from the ciphertext buffer <NUM> to the pattern detector <NUM>. Pattern detector <NUM> analyzes the ciphertext <NUM> to detect a known fixed pattern therein (e.g., <NUM>). The known fixed pattern is defined by a given number of bits which is equal to or less than the total number of bits in the keystream block(s) Z<NUM>. For example, the keystream block(s) Z<NUM> include(s) sixty-four bits or one hundred twenty eight bits, while the known fixed pattern includes five to eleven bits. The present solution is not limited in this regard. The length of the known fixed pattern defines the statistical frequency at which the pattern will be detected by the pattern detector <NUM>.

Referring now to <FIG>, there is provided an illustration of a receiving communication device implementing an MK-<NUM> cryptographic algorithm and configured to synchronize/re-synchronize the same in accordance with the present solution.

Referring now to <FIG>, there is provided an illustration of a flow diagram of an illustrative method <NUM> for operating a communication device (e.g., communication device <NUM> of <FIG>, <NUM> of <FIG>, <NUM> of <FIG>, <NUM> of <FIG>, <NUM>' of <FIG>, <NUM> of <FIG>, <NUM> of <FIG> or <NUM> of <FIG>). Method <NUM> begins with <NUM> and continues to <NUM> where ciphertext is obtained. <NUM> can involve generating the ciphertext by a cryptographic system in accordance with a cryptographic algorithm or receiving the ciphertext from a remote device. The cryptographic algorithm can include, but is not limited to, an adaption of a sponge construction framework. The adaptation of the sponge construction framework can include, but is not limited to, a duplex construction in which a permutation function is iteratively performed (e.g., as shown in <FIG>).

Next, a decision is made in <NUM> as to whether a pseudo-random event has been detected. This detection can be made based on an analysis of the ciphertext. For example, the system can analyze the ciphertext to determine whether a given sequence of values exits within the ciphertext. If the given sequence of values does exist within the ciphertext so, then the pseudo-random event is deemed to exist.

When the pseudo-random event does not exist (e.g., the given sequence of values does not exist within the ciphertext), then method <NUM> continues with <NUM> which will be discussed below. In contrast, when the pseudo-random event does exit, then method <NUM> continues with <NUM>-<NUM>. <NUM> involves synchronizing the cryptographic system with another cryptographic system using the ciphertext as at least part of an initialization value for the cryptographic algorithm. In some scenarios, the ciphertext is used in <NUM> as a bitrate portion r of the initialization value, while zero is used as a capacity portion c of the initialization value for the cryptographic algorithm. In <NUM>, the cryptographic algorithm is performed to encrypt or decrypt information. It should be noted that in some scenarios results from combining plaintext with a keystream block is used in <NUM> as the bitrate portion of the initialization value for a cryptographic algorithm when the pseudo-random event was not detected in <NUM> (and/or a determination is made that a given sequence of values does not exist within the ciphertext). Subsequently, <NUM> is performed where method <NUM> ends or other operations are performed (e.g., return to <NUM>).

All of the apparatus, methods, and algorithms disclosed and claimed herein can be made and executed without undue experimentation in light of the present disclosure. While the present solution has been described in terms of preferred embodiments, it will be apparent to those having ordinary skill in the art that variations may be applied to the apparatus, methods and sequence of steps of the method without departing from the concept, spirit and scope of the present solution. More specifically, it will be apparent that certain components may be added to, combined with, or substituted for the components described herein while the same or similar results would be achieved. All such similar substitutes and modifications apparent to those having ordinary skill in the art are deemed to be within the spirit, scope and concept of the present solution as defined.

Claim 1:
A method for operating a cryptographic system, comprising:
obtaining ciphertext by the cryptographic system;
performing operations by the cryptographic system to determine whether a given sequence of values exists
within the ciphertext, wherein length of the sequence of values can be selected by a user; and
synchronizing the cryptographic system with another cryptographic system using the ciphertext as a bitrate portion R of an initialization value B for a cryptographic algorithm and zero as a capacity portion C of the initialization value for the cryptographic algorithm, by causing a state of the cryptographic algorithm to be re-initialized using the ciphertext as an initialization value, when a determination is made that the given sequence of values exist within the ciphertext, wherein B=R+C;
characterized in that the cryptographic algorithm comprises an adaptation of a sponge construction framework and the adaptation of the sponge construction framework comprises a duplex construction in which a permutation function is iteratively performed, wherein the cryptographic algorithm comprises a unique permutation function f that is used with a sponge construction and/or the duplex construction.