WO2007069236A2 - Method and system for usage of block cipher encryption - Google Patents
Method and system for usage of block cipher encryption Download PDFInfo
- Publication number
- WO2007069236A2 WO2007069236A2 PCT/IL2006/001394 IL2006001394W WO2007069236A2 WO 2007069236 A2 WO2007069236 A2 WO 2007069236A2 IL 2006001394 W IL2006001394 W IL 2006001394W WO 2007069236 A2 WO2007069236 A2 WO 2007069236A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- blocks
- block
- key
- function
- input key
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
- G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
- G09C1/04—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system with sign carriers or indicators moved relative to one another to positions determined by a permutation code, or key, so as to indicate the appropriate corresponding clear or ciphered text
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0625—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation with splitting of the data block into left and right halves, e.g. Feistel based algorithms, DES, FEAL, IDEA or KASUMI
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/12—Details relating to cryptographic hardware or logic circuitry
- H04L2209/125—Parallelization or pipelining, e.g. for accelerating processing of cryptographic operations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/24—Key scheduling, i.e. generating round keys or sub-keys for block encryption
Definitions
- a broadcast Headend typically transmits content to many broadcast clients in the system.
- broadcast content is usually encrypted.
- Each encryption/decryption key is used for a relatively short period of time (known as the key period), after which it is replaced by a new key.
- Key replacement is performed in order to protect the broadcast system from key distribution attacks, an attack in which an authorized client distributes the key to a group of unauthorized clients.
- Broadcast systems may also be subject to pirate attacks that are addressed to facilitate unauthorized consumption of copyrighted content by simulating the decryption process on general purpose machines, such as a PC. Therefore, in addition to regular key replacement, the decryption • process sometimes includes operations that can be executed efficiently only on specialized hardware.
- An example of a standard that describes a broadcast system in the field of digital television is the digital video broadcasting (DVB) standard.
- the block cipher specified by the DVB standard known as the DVB Common Scrambling Algorithm version 2.0 (DVB CSA 2.0), is indeed software unfriendly.
- Frequent key modification may slow the encryption/decryption speed.
- frequent key modification typically strengthens the cipher against cryptanalysis.
- frequent key modification may also be beneficial when the cipher is required to be efficient in hardware implementations and inefficient in software implementations. The latter requirement typically arises in broadcasting systems.
- the system including an encryption key module to determine an input key for each of blocks based, on a function having a plurality of inputs including the root key and an initialization vector, for a first one of the blocks, and the plaintext of at least one of the blocks which was previously encrypted and the root key, for the blocks other than the first block, and an encryption module to encrypt each of the blocks based on the input key determined for each of the blocks, respectively.
- the input key for the blocks other than the first block is also based on the initialization vector.
- the input key of each of the blocks other than the first block is also based on the ciphertext of at least one of the blocks which was previously encrypted.
- each of the blocks has a block index, the input key of each of the blocks also being based on the block index.
- the encryption input key module includes a counter module to maintain a block counter of the number of the blocks processed such that the input key of each of the blocks is also based on the block counter. Additionally in accordance with a preferred embodiment of the present invention the input key of each of the blocks is determined using an exclusive-OR function.
- the input key of each of the blocks is determined using a cryptographic ⁇ hash function.
- each of the blocks has a block index, the input key of each of the blocks also being based on the block index.
- the decryption input key module includes a counter module to maintain a block counter of the number of the blocks processed such that the input key of each of the blocks is also based on the block counter.
- the input key of each of the blocks is determined using an exclusive-OR function.
- the input key of each of the blocks is determined using a cryptographic hash function.
- 5 encryption/decryption module including a plurality of block ciphers to jointly encrypt/decrypt between the plaintext and the ciphertext such that, for each of the blocks, between a first pair of the block ciphers there is a first intermediate value which is a value between the plaintext and the ciphertext, at least one of the ciphers performing encryption/decryption based on an input key, and an 0 encryption/decryption key module to determine the input key for each of blocks based on a function having a plurality of inputs including the root key and an initialization vector, for a first one of the blocks, and the first intermediate value of a prior one of the blocks and the root key, for the blocks other than the first block.
- the encryption/decryption module includes at least three block ciphers such that encrypting/decrypting between the plaintext and the ciphertext is performed jointly by the at least three block ciphers.
- the encryption/decryption key module being operative to determine the input key, for the blocks other than the first block, such that one of the inputs of the function also includes the second intermediate value of a prior one of the blocks.
- the prior one block is a last prior-processed one of the blocks.
- the input key of each of the blocks is determined using an exclusive-OR function.
- a method for operating a block cipher for decrypting a plurality of blocks from ciphertext to plaintext each of the blocks being associated with at least one constant root key
- the method including determining an input key for each of blocks based on a function having a plurality of inputs including the root key and an initialization vector, for a first one of the blocks, and the ciphertext of a last decrypted one of the blocks and the plaintext of a last decrypted one of the blocks and the root key, for the blocks other than the first block, and decrypting each of the blocks based on the input key determined for each of the blocks, respectively.
- a method for operating a block cipher to encrypt/decrypt a plurality of blocks between ciphertext and plaintext each of the packets having a plurality of blocks, the packets being associated with at least one constant root key
- the method including providing a plurality of block ciphers to jointly encrypt/decrypt between the plaintext and the ciphertext such that, for each of the blocks, between a first pair of the block ciphers there is a first intermediate value which is a value between the plaintext and the ciphertext, determining an input key for each of blocks based on a function having a plurality of inputs including, the root key and an initialization vector, for a first one of the blocks, and the first intermediate value of a prior one of the blocks and the root key, for the blocks other than the first block, and performing encryption/decryption for one of the block ciphers based on the input key.
- Fig. 1 is a cryptographic process flow diagram of a preferred general mode of operation of a block cipher system constructed and operative in accordance with a preferred embodiment of the present invention
- Fig. 2 is a cryptographic process flow diagram of a most preferred mode of operation of the block cipher system of Fig. 1;
- Fig. 3 is a block diagram of the modules of the block cipher system of Fig. 1;
- Fig. 4 is a flow chart of a preferred mode of operation of the block cipher system of Fig. 1;
- Fig. 5 is a cryptographic process flow diagram of a block cipher system constructed and operative in accordance with an alternative preferred embodiment of the present invention
- Fig. 6 is a cryptographic process flow diagram of a block cipher system constructed and operative in accordance with another alternative preferred embodiment of the present invention
- Fig. 7 is a block diagram of the modules of the block cipher system of Figs. 5 or 6;
- Fig. 9 is an illustration of a Combine Key RightPart function comprised in the hardened Feistel-like structure of Fig. 8;
- Fig. 12 is an illustration of a Combine RightPart Combine LeftPart function comprised in the hardened Feistel-like structure of Fig. 8;
- Fig. 13 is an illustration of one preferred implementation of a linear layer in the Combine RightPart Combine LeftPart function of Fig. 12;
- FIG. 16 is an illustration of one preferred implementation of round key generation utilizing the Mix and Condense function in the key expansion function of Fig. 15;
- Figs. 17 - 20 are simplified flowchart illustrations of preferred alternative methods of operation of the hardened Feistel-like structure of Fig. 8, in accordance with preferred embodiments thereof;
- Fig. 23 is a simplified block diagram illustration depicting the use of MUX and DEMUX modules in a preferred implementation of the method of Fig. 21;
- Fig. 24 is a simplified block diagram illustration of a preferred implementation of a round key generation function operative to generate round keys in a cipher designed according to the method of Fig. 21;
- Fig. 25 is a simplified block diagram illustration of four rounds of a typical Feistel block cipher constructed and operative in accordance with the system of Fig. 21;
- Fig. 26 is a simplified block diagram illustration of four rounds of a typical AES-like block cipher constructed and operative in accordance with the system of Fig. 21; .
- Fig. 27 is a simplified block diagram illustration of eight rounds of a typical Feistel block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21;
- Fig. 28 is a simplified block diagram illustration of eight rounds of a typical AES-like block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21;
- Fig. 29 is a simplified block diagram illustration of eight rounds of a typical Feistel block cipher constructed and operative in accordance with yet another alternative preferred embodiment of the system of Fig. 21;
- Fig. 30 is a simplified block diagram illustration of eight rounds of a typical AES-like block cipher constructed and operative in accordance with yet another alternative preferred embodiment of the system of Fig. 21 ;
- Fig. 31 is an illustration of a hardened Feistel-like structure for use with a preferred embodiment of the present invention.
- Fig. 32 is an illustration of an alternative preferred embodiment of the hardened Feistel-like structure of Fig. 31;
- Fig. 33 is a simplified block diagram of a preferred implementation of a MixKey function of the system of Fig. 31;
- Fig. 34 is a simplified block diagram of a CombParts function of the system of Fig. 31.
- Main Appendix is a description of a Feistel-like cipher system
- Appendix A is a description of a method for robust cipher design, comprising a preferred method of key expansion and set up and a preferred implementation of a round key encryption function, the method of Appendix A comprising a preferred implementation of the Feistel-like structure of Fig. 8;
- Appendix B is a copy of Appendix A.5 of the Serpent Cipher specification, describing S-boxes So through S7 of the Serpent Cipher;
- blocks in a single packet are preferably encrypted (and decrypted) using a different key, different terms are needed in order to distinguish between the different keys.
- a root key 12 is the external key that is input into the cipher system.
- Each of the packets is preferably associated with one constant root key 12.
- the same root key 12 is typically valid for a key period so that each root key 12 is used by more than one packet.
- more than one root key 12 may be used in the encryption/decryption process for each packet.
- all the packets are associated with the same root key.
- An input key 16 (Kj) is the actual key that is used for encrypting a plaintext block 30 (Pj), or decrypting a ciphertext block 32 (Cj) of a packet using an encryption function 18 or a decryption function 20, respectively.
- the input key 16 (Kj) is preferably determined using a function H (block 22) for . plaintext block 30 and ciphertext block 32.
- the inputs of the function H (block 22) typically include one or more of the following: one or more of plaintext blocks 24 ( ⁇ to Pj. ⁇ ) of the packet that were processed (encrypted or . decrypted) before the current block j; one or more of ciphertext blocks 26 (C ⁇ to Cj_]_) of the packet that were processed before the current block j; an Initialization Vector (IV) 28; the root key 12 and a block index 14.
- the function H (block 22) is operative to select or ignore all or part of the abovementioned inputs. For example, if the function H (block 22) ignores all the inputs except for the root key 12, the
- ⁇ output of the function H (block 22) is the root key 12, so that the input key 16 is equal to the root key 12 and therefore the block cipher system 10 operates in the known Electronic Control Book (ECB) mode.
- EBC Electronic Control Book
- the input key 16 of the first block of a packet is preferably based on the root key 12 and the Initialization Vector 28.
- the input key 16 of subsequent blocks of the packet is typically based on: the root key 12 and one or more of the plaintext blocks 24 (P ⁇ to Pj. ⁇ ) of the packet that were processed (encrypted or decrypted) before the current block j; preferably one or more of the ciphertext blocks 26 (C ⁇ to Cj_i) of the packet that were processed before the current block j; and preferably the block index 14.
- the block index 14 allows the function H (block 22) to exhibit different behavior depending on the index of the block being processed.
- the function H (block 22) maintains a block counter internally by counting the number of blocks processed within a packet. It should be noted that the block counter is the same as the block index 14 if the blocks within a packet are processed in order.
- the function H (block 22) typically combines the inputs into a single, input key 16 using simple operations such as bit-bit XOR or more complex operations such as a cryptographic hash function, for example, but not limited to, SHA-I.
- the system may be implemented regardless of the order in which the blocks within a packet are processed.
- the blocks may be processed in the same order in which they arrived over the communication media or in reverse order.
- Fig. 2 is a cryptographic process • flow diagram of a most preferred mode of operation of the block cipher system 10 of Fig. 1.
- the input key 16 for encrypting/decrypting each block is determined by the function H (block 22) based on the root key 12, the block index 14, only the last processed (encrypted/decrypted) plaintext block and only the last processed (encrypted/decrypted) ciphertext block.
- the input key 16 (K2) for encrypting a plaintext block 34 (P2) is based on the root key 12, the block index 14, only the last processed plaintext block 36 (Pi) and only the last processed ciphertext block 38 (Ci).
- the input key 16 for the first block in the packet is based on the root key 12 and the Initialization Vector 28 and optionally the block index 14.
- Fig. 3 is a block diagram of the modules of the block cipher system 10 of Fig. 1.
- Fig. 4 is a flow chart of a preferred mode of operation of the block cipher system 10 of Fig. 1. Reference is also made to Fig. 1.
- the block cipher system 10 includes an encryption/decryption key module 40 and an encryption/decryption module 42.
- the encryption/decryption key module 40 is operative to determine the input key 16 for the first block (Pi) based on the root key 12 and the initialization vector 28 and optionally the block index 14 (or the block counter) (block 46).
- the encryption/decryption key module 40 is operative to determine the input keys 16 for the blocks other than the first block (Pi) based on: the root key 12; one or more of the plaintext blocks 24 previously encrypted/decrypted and most preferably only the last plaintext block 24 encrypted/decrypted; optionally the block index 14 or the block counter; and preferably one or more of the ciphertext blocks 26 previously encrypted/decrypted and most preferably only the last ciphertext block 26 encrypted/decrypted (block 46):
- the block index 14 or the block counter also allows the encryption/decryption key module 40 to know which inputs to use in determining the input key 16, as the inputs for- the first block differ from the inputs of the subsequent blocks, as described above.
- the determination of the input key 16 by the encryption/decryption key module 40 is preferably performed using an exclusive-OR function and/or a cryptographic hash function, for example, but not limited to, SHA-I.
- the encryption/decryption key module 40 preferably includes a counter module 44 which is operative to maintain the block counter of the number of the blocks processed.
- the counter module 44 increments the block counter after each block has been processed (block 50) .
- the process of blocks 46-52 is preferably repeated for all the packets in the data stream.
- the components of the present invention are preferably implemented in hardware, using conventional techniques.
- Fig. 5 is a cryptographic process flow diagram of a block cipher system 56 constructed and operative in accordance with an alternative preferred embodiment of the present invention.
- the block cipher system 56 typically includes an encryption block cipher arrangement having three block ciphers, a cipher 58, a cipher 60 and a cipher 62.
- the ciphers 58, 60, 62 are preferably configured such that: a plaintext block 64 of a packet is encrypted by the cipher 58 producing an encrypted output 66; the encrypted output 66 is encrypted by the cipher 60 producing an encrypted output 68; the encrypted output 68 is encrypted by the cipher 62 producing a ciphertext block 70. Therefore, processing by the encryption block cipher arrangement from plaintext to ciphertext is performed such that between each of the block ciphers 58, 60, 62 there is an intermediate value which is a value between the plaintext and the ciphertext.
- an encryption key, k ⁇ , of the cipher 60 is typically determined by a function H with the following inputs: an initial value 72 and a root key 74 and optionally a block index 76.
- the function H typically combines the inputs into a single input key using simple operations such as bit-bit XOR or more complex operations such as cryptographic hash functions, for example, but not limited to, SHA-I.
- Subsequent blocks, for example, but not limited to, a second plaintext block 78, an encryption key, k2, of the cipher 60 is generally determined by the function H with the following inputs: the root key 74; optionally the block index 76; and at least one intermediate value between the plaintext and ciphertext of a prior block, for example: the encrypted output of the cipher 58 for a prior block, preferably of the last prior processed block, for example, associated with the plaintext block 64; and preferably the encrypted output of the cipher 60 for a prior block, preferably of the last prior processed block, for example, associated with the plaintext block 64.
- Decryption of the ciphertext blocks 70, 80 is typically performed using three appropriate decryption block ciphers, a cipher 82, a cipher 84 and a cipher 86 corresponding to ciphers 62, 60, 58, respectively.
- the ciphertext block 70 is preferably decrypted by the cipher 82.
- the output of the cipher 82 is typically decrypted by the cipher 84.
- the output of the cipher 84 is typically decrypted by the cipher 86 producing the plaintext block 64.
- Subsequent blocks for example, but not limited to, the second ciphertext block 80, the decryption key, k2, of the cipher 84 is preferably determined by the function H with the following inputs: the root key 74; optionally the block index 76; and at least one intermediate value between the ciphertext and plaintext of a prior block, for example: the decrypted output of the cipher 82 for a prior block, preferably of the last prior processed block, for example, associated with the ciphertext block 70; and preferably the decrypted output of the cipher 84 for a prior block, preferably of the last prior processed block, for example, associated with the ciphertext block 70.
- the output of the cipher 60 for the ciphertext block 80 is typically decrypted by the cipher 86 producing the plaintext block 78.
- the block cipher system 56 helps prevent related key attacks on the block cipher system 56 by using the intermediate values between the plaintext and the ciphertext as input for the function H for a future block.
- the block cipher arrangement can include more than three block ciphers as long as an intermediate value of a prior block is used as an input for determining the key of a current block for one of the block ciphers.
- Fig. 6 is a cryptographic process flow diagram of a block cipher system 88 constructed and operative in accordance with another alternative preferred embodiment of the present invention.
- the block cipher system 88 is substantially the same as the block cipher system 56, except that the block cipher system 88 has an encryption cipher arrangement preferably including two ciphers, a cipher 90 and a cipher 92.
- the block cipher system 88 has a decryption cipher arrangement preferably including two ciphers, a cipher 94 and a cipher 96.
- FIG. 7 is a block diagram of the modules of the block cipher system 56 of Fig. 5 or the block cipher system 88 of
- the functionality of the block cipher system 56 of Fig. 5 and the block cipher system 88 of Fig. 6 are preferably implemented with an encryption/decryption key module 112 and an encryption/decryption module 114.
- the encryption/decryption module 114 can include two, three or more ciphers for encryption/decryption.
- the ciphers of the encryption/decryption module 114 are typically operative to jointly encrypt/decrypt between plaintext and ciphertext such that, for each of a plurality of blocks, between a first pair of the block ciphers (for example, between ciphers 58, 60 of Fig. 5 or ciphers 90, 92 of Fig. 6) there is a first intermediate value which is a value between the plaintext and the ciphertext.
- the term "encrypt/decrypt between the plaintext and the ciphertext" as used in the specification and claims is defined as encrypting from plaintext to ciphertext and/or decrypting from ciphertext to plaintext.
- encryption/decryption as used in the specification and claims, in all grammatical forms thereof, is defined as encryption and/or decryption.
- the encryption/decryption key module 112 preferably includes a counter module 116 to maintain a block counter of the number of the blocks processed.
- the input key is optionally also based on a block-index/block counter of the block being processed.
- the encryption/decryption module 114 typically includes three or more ciphers for encryption/decryption
- the encryption/decryption between the plaintext and the ciphertext is preferably performed jointly by the three or more block ciphers.
- a second pair of the block ciphers which may include one of the ciphers of the first pair of ciphers
- there is generally a second intermediate value which is a value between the plaintext and the ciphertext.
- Feistel networks also termed herein “Feistel cipher methods”, or “Feistel-like cipher methods”; a single round of a Feistel cipher method is termed herein a “Feistel cipher round”.
- HAC Applied Cryptography
- a Feistel cipher is an iterated block cipher mapping a plaintext (comprising two parts, LQ and RQ), for t-hit blocks LQ and RQ, to a ciphertext (R r and L r ), through an 7--round process where r ⁇ 1.
- FOX A New Family of Block Ciphers, (Pascal Junod and Serge Vaudenay, Selected Areas in Cryptography 2004: Waterloo, Canada, August 9-10, 2004. Revised papers. Lecture Notes in Computer Science. Springer- Verlag.) describes the design of a new family of block ciphers based on a Lai-Massey scheme, named FOX.
- a new design of strong and efficient key-schedule algorithms is proposed.
- Evidence is provided that FOX is immune to linear and differential cryptanalysis.
- the Serpent Cipher specified at: www.frp.cl.cam.ac.uk/ftp/users/rjal4/se ⁇ ent.pdf, was an Advanced Encryption Standard (AES) candidate.
- AES Advanced Encryption Standard
- the design of the serpent cipher design is highly conservative, yet still allows a very efficient implementation.
- the serpent cipher uses S-boxes similar to those of DES in a new structure that simultaneously allows a more rapid avalanche, and a more efficient bitslice implementation.
- a Feistel-like cipher, described herein, is preferably designed to be easily implemented in hardware and difficult to implement in software.
- Fig. 9 is an illustration of a Combine Key RightPart function comprised in the hardened Feistel-like structure of Fig. 8;
- Fig. 10 is an illustration of a preferred implementation of hardware for a RightPart Expansion Function comprised in the Combine Key RightPart function of Fig. 9;
- Fig. 13 is an illustration of one preferred implementation of a linear layer in the Combine RightPart Combine LeftPart function of Fig. 12;
- Fig. 14 is an illustration of one preferred implementation of an S- boxes layer in the Combine RightPart Combine LeftPart function of Fig. 12;
- Fig. 15 is an illustration of one preferred implementation Of a key expansion function comprised in the hardened Feistel-like structure of Fig. 8;
- Figs. 17 - 20 are simplified flowchart illustrations of preferred alternative methods of operation of the hardened Feistel-like structure of Fig. 8, in accordance with preferred embodiments thereof;
- Fig. 21 is a simplified block diagram illustration of a system for robust cipher design for use with a preferred embodiment of the present invention.
- Fig. 22 is a time line showing one preferred implementation of the relationship between key expansion and encryption rounds in a cipher designed according to the method of Fig. 21;
- Fig. 23 is a simplified block diagram illustration depicting the use of MUX and DEMUX modules in a preferred implementation of the method of Fig. 21;
- Fig. 26 is a simplified block diagram illustration of four rounds of a typical AES-like block cipher constructed and operative in accordance with the system of Fig. 21;
- Fig. 27 is a simplified block diagram illustration of eight rounds of a typical Feistel block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21;
- Fig. 28 is a simplified block diagram illustration of eight rounds of a typical AES-like block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21;
- Fig. 31 is an illustration of a hardened Feistel-like structure for use with a preferred embodiment of the present invention
- Fig. 32 is an illustration of an alternative preferred embodiment of the hardened Feistel-like structure of Fig. 31;
- Fig. 34 is a simplified block diagram of a CombParts function of the system of Fig. 31.
- Appendix A is a description of a method for robust cipher design, comprising a preferred method of key expansion and set up and a preferred implementation of a round key encryption function, the method of Appendix A comprising a preferred implementation of the Feistel-like structure of Fig. 8;
- Appendix B is a copy of Appendix A.5 of the Serpent Cipher specification, describing S-boxes SQ through S7 of the Serpent Cipher;
- Appendix C comprises a description of certain alternative preferred embodiments for use with the present invention.
- L and R two halves of a plaintext, left and right, depicted as L and R, are operated on by the CKR function 3110 and the CRL function 3120.
- L and R preferably have an identical size of 64 bits.
- L and R may be any equal size, and 64 bits is used herein as an example.
- the size of the round key, RKj is described herein as 100 bits by way of example, only. RKf may be any appropriate size.
- the plurality of rounds may preferably be preceded by preprocessing of L and R.
- L and R may preferably be permuted according to a pre-defined permutation in the same manner the DES block cipher permutes the input before the first round (refer to FIPS 46-3).
- an encrypted output of the hardened Feistel-like structure 3100 may be post-processed.
- output may preferably be further permuted according to a pre-defined permutation in the same manner the DES block cipher permutes the state after the 16 th round (refer to FIPS 46-3).
- a particular round (first round, last round, or any other round) may preferably differ from the other n-1 rounds.
- the Feistel-like structure 3100 preferably uses a 128-bit key to encrypt and decrypt 128-bit blocks.
- the number of rounds (RN) is preferably RN between 40 and 50, inclusive.
- Feistel-like structure 3100 is preferably less efficient if implemented in software.
- the Feistel-like structure 3100 preferably utilizes CKR 3110 to integrate a round key with a right half of a state and the function CRL 3120 to combine the result of the key integration with a left half of the state.
- the left and right halves of the state are referred below as L and R, respectively.
- Fig. 9 is an illustration of a
- the CKR function 3110 preferably comprises the following operations: 1.
- RExp (Right Part Expansion) 3210 preferably expands the right half R from 64 to 100 bits;
- a 100 bit round key, RKi is preferably combined with the expanded 100 bit right half;
- FIG. 10 is an illustration of a preferred implementation of hardware for a RightPart Expansion Function comprised in the Combine Key RightPart function of Fig. 9. It is appreciated that Fig. 10 provides an illustration of a preferred implementation of hardware structures and methods for implementing an expansion function, the illustration being drawn in a format which is well known in the art.
- RExp 2310 (Fig. 9)
- SUBSTITUTE SHBIT (RULE U) preferably uses a linear transformation to expand the 64 bit R into a 100 bit expanded RightPart, where each of the 100 bit output bits is the result of a XORing of 2 or 3 input bits.
- Indices implemented in the proposed hardware of Fig. 10 are preferably selected pseudo-randomly with the following constraints:
- Each one of the 64 input bits of the R preferably influences at least two output bits
- Each bit of the 100 bit round key preferably influences exactly one output bit; 3. Indices are preferably selected so as to be spread equally between the input and output bits, thereby avoiding a situation where a small number of input bits influence only a small number of output bits; and
- any small set of input bits preferably influences a larger set of output bits.
- error correcting codes such as the well known Hamming error correcting code
- the RExp function 3210 (Fig. 9) and the subsequent XOR 3220 operation balance between a proper mixing of the round key with the right part and a time-efficient implementation of the mixing, thereby allowing a hardware implementation of both the RExp function 3210 (Fig. 9) and the XOR 3220 operation that preferably comprises only two layers of XOR operations (and, in some preferred embodiments, an additional layer of NOT gates).
- the 100 bit expanded right half, after XORing with the 100 bit round key RKi, is preferably input into the MCF function 3230.
- a 100 bit result of the XORing is preferably reduced and condensed into a 64-bit temporary result, which is used later as a control input of the CRL function (described with reference to
- the MCF function 3230 is preferably critical in making the Feistel-like structure 3100 (Fig. 8) emulation resistant.
- the MCF function preferably uses between round key generation function and 50, inclusive, layers of mini-functions 3400, where each of the mini- functions 3400 preferably comprises two micro-functions, a balanced micro- function BF 3410 and a non-linear micro-function NLF 3420.
- NLF 3420 is preferably executed on the other input bits; and afterwards BF 3410 is preferably executed on the output of NLF 3420 and on the balancing set of bits, received from the splitter 3415.
- the balancing set of bits goes through a third type of micro-functions, comprising an invertible transformation, such as a 2bit-to-2bit S-box, where the balancing set comprises 2 bits.
- Putting the balancing set through the invertible transformation is preferably performed simultaneously with the NLF, and thus, employing the third micro-function can be performed preferably without cost in execution time.
- the following functions process 3 -bit inputs (according to the design criteria stated immediately above):
- MUX where a single bit selects which of the two other input bits to output.
- the mini-functions 3400 in layer i preferably receive inputs from the outputs of the mini-functions 3400 in layer i-1. Selection of which output of layer i-1 goes to which input of layer i is preferably performed in a manner that preferably maximizes the mixing between layers and thus preferably avoids localization effects .
- the exact MCF 3230 (Fig. 9) utilized is automatically generated during design.
- the MCF utilized preferably passes several statistical tests measuring correlation between output bits (in particular, linear correlations).
- the statistical tests are preferably not restricted to input and output, but preferably also measure correlations in internal layers between inputs and outputs.
- MCF 3230 (Fig. 9) preferably is implemented in two versions.
- the two versions are preferably used in an alternating manner throughout the rounds of the Feistel-like structure 3100 (Fig. 8). It is appreciated that even if one of the two versions is found to be "faulty", the Feistel-like structure 3100 (Fig. 8) as a whole preferably remains strong.
- a "faulty" function in the present context is either a cryptographically weak function (e.g., having strong linear or differential properties) or a function that is easy to emulate in software.
- Combine RightPart Combine LeftPart (CRL) function 3120 comprised in the hardened Feistel-like structure 3100 of Fig. 8.
- the CRL 3120 function combines the 64-bit result of the MCF 3230 as the last stage of the CKR 3110 with the unchanged 64-bit left half Lj to get a new 64-bit pseudo-random right half, Rj+ ⁇ .
- CRL 3120 is preferably not an involution. That is, ICRL preferably differs significantly from CRL 3120 (as opposed, for example, to the XOR function that is used in DES).
- the CRL function 3120 preferably comprises two stages, each stage working on small sub-blocks.
- each sub-block comprises 4 bits.
- a permutation is preferably applied to the result, breaking any locality effect of working on small sub-blocks.
- the first stage comprises a linear layer LL 3510 that mixes the control input with the transform input.
- bit-permutation PL 3520 is preferably applied to the result of the LL 3510.
- bit-permutation (not depicted) is preferably applied to the output of SL 3530.
- LL 3510 comprises a first splitter 3610 which splits transform input, Lj, into 4-bit micro-blocks. Similarly, a second splitter splits control input into 4-bit micro-blocks. The 4-bit micro-blocks
- A(C) is invertible; that is there exists B(C), such that:
- * ⁇ (C) comprises:
- Fig. 15 is an illustration of one preferred implementation of a key expansion function 3800 comprised in the hardened Feistel-like structure 3100 of Fig. 8.
- the key setup function 3800 preferably extends a 128-bit key to RN 100-bit round keys (RN is the number of rounds).
- the key expansion function is preferably designed according to the following principles:
- the key expansion function 3800 takes advantage of the fact that the MCF preferably comprises two variations; one variation is preferably active during any round in the MCF function for the CKR 3110 (Fig. 9), while the other variation is preferably available for use.
- the key expansion function 3800 therefore preferably uses the available MCF function in order to generate the round keys in a cryptographically secure manner.
- the 128-bit shift register is initialized 3850 with the 128-bit key.
- the state update function 3810 preferably comprises a circular rotation of the 128-bit register. It is appreciated that the number of rounds (RN) is preferably smaller than the size of the 128-bit register, and thus the state update function preferably does not loop during a round.
- a decrypter in order to get the round keys in the proper order (reverse order from the order used during encryption), a decrypter preferably receives the state in reverse order used during encryption.
- decryption preferably begins with shifting the shift register as many times as needed in order to get the state appropriate for the last round key. Each subsequent round then preferably shifts the state in the opposite direction to the direction used to circularly shift the state during encryption.
- SUBSTITUTE SHEET (RULE 21) It is appreciated that replacement of a short LFSR (left shift register) with 2-3 smaller LFSRs may be preferable. If 2-3 smaller LFSRs are utilized, the decryption key is the result of applying a linear transformation (calculated in advance and hard-wired) on the encryption key, and then the LFSRs are preferably rolled back to get the round keys in the reverse order.
- an additional XOR with a predefined round string may preferably be applied after the state update function 3810.
- Fig. 16 is an illustration of one preferred implementation of round key generation 3830 utilizing the Mix and Condense function (MCF) 3230 (Fig. 9) in the key expansion function 3800 of Fig. 15.
- the round key generation 3830 function inputs the 128-bit state into the MCF 3230 (Fig. 9) and takes the 100-bit output as the next round key, as discussed above with reference to Appendix A.
- the following are design principles for selecting the order of using the MCF variations in the key setup and the round operation:
- the round operation preferably uses A and B in the following order: A A B B A A B B A A B B A A B B B ...
- MCF 3230 (Fig. 9) that is preferably used in the round operation and the MCF that is used in the key expansion have different sizes of inputs and outputs. Specifically, a 128 bit value is preferably input in order to produce a 100 bit output for key setup, and a 100 bit value is preferably input in order to produce a 64 bit output for a round operation.
- the implemented MCFs are preferably implantations of 100 bits going to 128 bits going to 100 bits going to 64 bits, where most of the layers are in the 128 bits going to 100 bits part.
- the round operation uses the whole function and the key expansion uses only the middle part of the function.
- the blowing effect herein described also contributes to preferably making the function hard to emulate in software.
- FIGs. 17 to 20 are simplified flowchart illustrations of preferred alternative methods of operation of the hardened Feistel-like structure of Fig. 8, in accordance with preferred embodiments thereof.
- the methods of Figs. 17 to 20 are believed to be self explanatory with reference to the above discussion.
- SUBSTITUTE SHEET (RULE U) invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.
- Block ciphers are a well known family of symmetric key-based ciphers.
- Block ciphers operate on plain text in groups of bits. The groups of bits are referred to as blocks.
- Block ciphers are dealt with at length in Chapters 12 - 15 of Applied Cryptography. Second Edition, by Bruce Schneier, published by John Wiley and Sons, 1996.
- Many block ciphers are constructed by repeatedly applying a function. Such block ciphers are known as iterated block ciphers. An iteration of the block cipher is termed a round, and the repeated function is termed a round function. The number of times the round is repeated in an iterated block cipher is referred to as a round number (RN)-
- FIPS 46-3 One block cipher, DES, is specified in FIPS 46-3, available on the Internet at: csrc.nist.gov/publicati ons/fips/fips46-3/fips46-3.pdf. FIPS 46-3 is hereby incorporated herein by reference.
- a second well known block cipher, AES is specified in FIPS 197, available on the Internet at: csrcnist.gov/publications/f ⁇ ps/fips ⁇ V/fips-WT.pdf.
- FIPS 197 is hereby incorporated herein by reference. The disclosures of all references mentioned above and throughout the present specification, as well as the disclosures of all references mentioned in those references, are hereby incorporated herein by reference.
- Fig. 21 is a simplified block diagram illustration of a system for robust cipher design for use with a preferred embodiment of the present, invention
- Fig. 22 is a time line showing one preferred implementation of the relationship between key expansion and encryption rounds in a cipher designed according to the method of Fig. 21
- Fig. 23 is a simplified block diagram illustration depicting the use of
- Fig. 24 is a simplified block diagram illustration of a preferred implementation of a round key generation function operative to generate round keys in a cipher designed according to the method of Fig. 21;
- Fig. 25 is a simplified block diagram illustration of four rounds of a typical Feistel block cipher constructed and operative in accordance with the system of Fig. 21;
- Fig. 26 is a simplified block diagram illustration of four rounds of a typical AES-like block cipher constructed and operative in accordance with the system of Fig. 21;
- Fig. 27 is a simplified block diagram illustration of eight rounds of a typical Feistel block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21;
- Fig. 28 is a simplified block diagram illustration of eight rounds of a typical AES-like block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21;
- Fig. 29 is a simplified block diagram illustration of eight rounds of a typical Feistel block cipher constructed and operative in accordance with yet another alternative preferred embodiment of the system of Fig. 21 ;
- FIG. 30 is a simplified block diagram illustration of eight rounds of a typical AES-like block cipher constructed and operative in accordance with yet another alternative preferred embodiment of the system of Fig. 21.
- the function F in preferred embodiments thereof, preferably comprises at least one of: a significant portion of cipher security (that is to say that if F is poorly selected, a cipher comprising F may be insecure); and a significant portion of hardware complexity of a typical hardware implementation of the cipher comprising F (the inventors of the present invention anticipate that at least 10% and preferably 20% of the gates in the hardware implementation of the cipher comprising F are dedicated to the function F 5 or at least 10% and preferably 20% of the voltage of the hardware implementation of the cipher comprising F is dedicated to the function F).
- the function F therefore, preferably comprises a significant portion of cipher security and comprises a significant portion of the hardware implementation of the cipher.
- the function F may preferably comprise a layer of S-boxes (well known cryptographic structures), such as the AES invertible 8-bit-to-8-bit S-boxes, or DES non-invertible 6-bit-to-4-bit S-boxes.
- the function F may comprise a linear transformation such as the AES ShiftRows transformation function, or the AES MixColumns transformation function.
- the system of Fig. 21 also comprises a round key generation function 1020, depicted in round n as comprising the first function, F a , and later depicted in round n+1 as comprising the second function, F c .
- the system of Fig. 21 also comprises a round mixing function 1030, depicted in round n as
- SUBSTITUTE SHEET (RULE n) comprising a third function, Fj 3 , and later depicted in round n+1 as comprising a fourth function, F ⁇ .
- F a , F] 3 , F c , and F ⁇ are preferably selected from among two functions, Fj and Fj, thereby allowing implementation of only the two functions, F 1 and Fj for the four functions, F 3 , F] 3 , F c , and F ⁇ .
- the functions F a and F ⁇ can be either of functions ⁇ or Fj.
- Fig. 22 is a time line showing one preferred implementation of the relationship between key expansion (note that the terms “key expansion” and “key generation” are used interchangeably in the present disclosure and figures) and encryption rounds in a cipher designed according to the method of Fig. 21.
- the round key generation function 1020 Prior to round 1, the round key generation function 1020 produces a round key for use by the round mixing function 1030 in round 1. Substantially in parallel to the operation of the round mixing function 1030 in round 1, the round key generation function 1020 produces a round key for use by the round mixing function 1030 in round 2.
- the process of the round key generation function 1020 producing a round key for use by the round mixing function 1030 in the next round continues substantially in parallel to the operation of the round mixing function 1030 until in round rounds number - 1 (RN - 1), the round key generation function 1020 produces a round key for use by the round mixing function 1030 in round RN.
- the round key generation function 1020 preferably does not generate a key.
- F, F a and F] 3 are preferably implemented only once, preferably in hardware. It is appreciated that F a and F] 3 may, under some circumstances, also be implemented in software.
- F] 3 preferably is operating as part of the round key generation function 1020 for the next round.
- F a preferably is operating as part of the round key generation function 1020 (Fig. 21) for the next round.
- a MUX module and a DEMUX module are preferably operative to differentiate between different sources for input, a key expansion input or an input as part of the round, as well as the different outputs, a register for round keys or a round key state register.
- the MUX modules are preferably updated by a counter (not depicted) which is operative to count rounds.
- Hardware comprising key expansion logic 1310 outputs a temporal result to a first MUX module 1320.
- hardware comprising round encryption logic 1330 outputs a temporal result to the first MUX module 1320.
- the first MUX module 1320 determines if the output of the MUX module 1320 has to be a value taken as MUX input from the key expansion logic 1310 hardware or the value taken as MUX input from the round encryption logic 1330 hardware.
- a preferred implementation, given by way of example, relevant for the discussion below of Figs. 29 and 30, of the selection criteria 1340 comprises a counter ranging in value from 0 to 3. If the counter value is 0 or 1, one option is implemented by the MUX module. If the counter value is 2 or 3, the second option is implemented by the MUX module.
- Output from the MUX module 1320 is preferably sent to F[ as appropriate for a particular round.
- Output from F 1 is preferably input into a DEMUX module 1360.
- DEMUX module 1360 preferably applies the selection criteria 1340 to determine if the received input needs to be preferably output as a round key generation temporal result 1370 to the key expansion logic 1310 hardware or as- a round key • mixing temporal result 1380 to the round encryption logic 1330 hardware.
- key expansion logic 1310 has a MUX component (not depicted) which selects between the round key generation temporal result 1370 of Fj and the round key mixing temporal result 1380 of Fj.
- the round encryption logic 1330 has a MUX component (not depicted) which selects between the round key generation temporal result 1370 of F; and the round key mixing temporal result 1380 of Fj.
- a design similar to the system of Fig. 23 comprises a preferred embodiment of MUX and DEMUX selection logic for Fj, where the selection criteria 1340 that is used for Fj is preferably the negation of the selection logic that is used for Fj. That is, when the function Fj is used for round key generation, function Fj is preferably used for round key mixing, and vice- versa.
- the function F is deliberately designed to be inefficient in any implementation, except for an implementation comprising specialized hardware, thereby making a cipher comprising the function F inefficient in any implementation, except for an implementation comprising specialized hardware. Therefore, a cipher designed so as to comprise such an embodiment of the function F in Fj and in F;, Fj being is inefficient, except for an implementation comprising specialized hardware, and Fj not being inefficient in an implementation not comprising specialized hardware, comprises an implementation of the cipher which is still, substantially inefficient except for an implementation comprising specialized hardware.
- Fig. 24 is a simplified block diagram illustration of a preferred implementation of a round key generation function operative to generate round keys in a cipher designed according to the method of Fig. 21.
- Fj and Fj may comprise either invertible functions or non-invertible functions, as appropriate, depending on the cipher in which functions Fj and Fj are implemented, and on the stage of implementing the cipher in which functions Fj and Fj are implemented. As will be discussed below with reference to Figs. 25,
- F 1 and Fj (as part of the key mixing mechanism) preferably comprise a part of the combination of the round key with "right" half, prior to combining (XORing in DES) with the "left" half (a non-invertible operation).
- functions Fj and Fj are preferably implemented as non-invertible functions.
- Fj and Fj in substitution permutation ciphers such as the AES cipher (FIPS 197), Fj and Fj preferably comprise part of the round function.
- functions Fj and Fj are preferably implemented as invertible functions.
- the round key generation function 1327 operates iteratively in order to generate a plurality of keys.
- the iterative operation of round key generation function 1327 comprises a state, R.
- the state R is initialized by executing a function, Statelnit 1337, with root key K as input during every round.
- R is updated by a State Update function 1347.
- the State Update function 1347 is applied to the state from the previous round in order to update R for the round,
- a Round Key Generation function 1357 generates a new round key RKj 1367 from the updated value of R.
- RQ InitState(K)
- the size of the state R is preferably equal to the size of the key.
- the key is 128 bits
- the state R is preferably 128 bits.
- One preferred method of determining the state during the iterative process described above, applicable when RN is less than the size of the key in bits comprises initializing an L-bit state with an L-bit key K, and circularly shifting the L bit key one bit each round.
- RoundKeyGenerate 1357 need not be an invertible function.
- non-invertible function F preferably comprises a portion of the
- RoundKeyGenerate 1357 function In preferred implementations where Fj and Fj comprise invertible functions, and the round key generation function is designed as described above, the StateUpdate 1347 function is preferably invertible, and invertible function F preferably comprises a portion of the StateUpdate 1347 function. Non-limiting examples of different preferred implementations are now described.
- FIG. 25 is a simplified block diagram illustration of four rounds of a typical Feistel block cipher 1400 constructed and operative in accordance with the system of Fig. 21. It is appreciated that Fig. 25 provides an illustration of data structures and methods for implementing an encryption network, the illustration being drawn in a format which is well known in the art.
- the Feistel block cipher 1400 comprises round mixing function designated hereinafter as function A 1420 and function B 1430. Additionally, a combine function 1440, depicted in Fig. 21 as ⁇ , XOR (exclusive OR), combines the output of either of function A 1420 or of function B 1430 with an input. Even though the combine function 1440 is depicted as XOR, it is appreciated that any appropriate combining function may be implemented to combine the output of either of function A 1420 or of function B 1430 with the input.
- Substitution in which an output of the key mixing function is subdivided into 8 6-bit sub-blocks.
- Each of the 8 6-bit sub-blocks is input into a substitution box ("S-box"), which, according to a non-linear transformation, outputs a 4-bit block, thereby producing a total of 32 output bits; and 4.
- S-box substitution box
- Permutation in which the 32 output bits of the substitution are rearranged according to a fixed permutation, the "P-box".
- a function, F operative as a sub- function comprised in the round function of the block cipher 1410 is replaced with different instances of F: Fj and Fj.
- the round encryption function preferably uses a round key generated during a previous round
- function A 1420 comprising function Fj
- function Fj comprises the round mixing function
- Fj is preferably used in the round key generation function to generate the round key for the next round.
- function B 1430 comprising function Fi
- Fi is preferably used in the round key generation function to generate the round key for the next round.
- each sequence of rounds comprises ABAB..., such that each round alternates the use of the implementation of F (Fj,
- key expansion preferably comprises XBABA..., where a first round uses a key, X, that can be derived either from A or B.
- X a key that can be derived either from A or B.
- Fig. 26 is a simplified block diagram illustration of four rounds of a typical AES-like block cipher 1500
- Each round of the AES-like block cipher comprises a round key generation function 1510 (for ease of depiction, "key setup", in Fig. 26) operative to provide the round key to the round mechanism 1520.
- Each round mechanism 1520 typically comprises a key mixing function 1530 (for ease of depiction, ' "key comb”, in Fig. 26), which is operative to receive the key from the round key generation function 1510, and combine, typically using a XOR function, the key with a known constant.
- Output from the key mixing function 1530 is typically input into a linear layer 1540.
- the linear layer 1540 typically comprises functions well known in the art, such as "MixRows" and "ShiftColumns". Output from the linear layer 1540 is typically input into a non-linear layer 1550.
- the non-linear layer 1550 typically comprises S-boxes. Additionally, in preferred embodiments, the non-linear layer 1550 comprises an implementation of the function F, either Fj or Fj. In the preferred implementation depicted in Fig. 26, implementations of F[ or Fj alternate, similar to the preferred implementation depicted in Fig. 25.
- Fig. 27 is a simplified block diagram illustration of eight rounds of a typical Feistel block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21.
- Fig. 28 is a simplified block diagram illustration of eight rounds of a typical AES-like block cipher constructed and operative in accordance with an alternative preferred embodiment of the system of Fig. 21.
- Fig. 29 is a simplified block diagram illustration of eight rounds of a typical Feistel block cipher constructed and operative in accordance with yet another alternative preferred embodiment of the system of Fig. 21.
- Fig. 30 is simplified block diagram illustration of eight rounds of a typical AES-like block cipher constructed and operative in accordance with yet another alternative preferred embodiment of the system of Fig. 21.
- software components of the present invention may, if desired, be implemented in ROM (read only memory) form.
- the software components may, generally, be implemented in hardware, if desired, using conventional techniques.
- Feistel networks also termed herein “Feistel cipher methods”, or “Feistel-like cipher methods”; a single round of a Feistel cipher method is termed herein a “Feistel cipher round”.
- HAC Applied Cryptography
- a Feistel cipher is an iterated block cipher mapping a plaintext (comprising two parts, LQ and RQ), for t-bit blocks LQ and RQ, to a ciphertext (R r and L 1 ), through an r-round process where r > 1.
- Decryption of a Feistel cipher is often achieved using the same r- round process but with subkeys used in reverse order, K r through K ⁇ .
- Types of block ciphers which are cases of Feistel networks include the following well-known methods: DES, Lucifer, FEAL, Khufu, Khafre, LOKI, " GOST, CAST 5 and Blowfish. Feistel ciphers are also discussed in Applied Cryptography, Second Edition (B. Schneier, John Wiley and Sons, Inc., 1996) on pages 347 - 351. The discussion of Feistel ciphers in Applied Cryptography, Second Edition is hereby incorporated herein by reference. DES is specified in FIPS 46-3, available on the Internet at: csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf. FJJPS 46-3 is hereby incorporated herein by reference.
- FOX A New Family of Block Ciphers, (Pascal Junod and Serge Vaudenay, Selected Areas in Cryptography 2004: Waterloo, Canada, August 9-10, 2004. Revised papers. Lecture Notes in Computer Science. Springer-Verlag.) describes the design of a new family of block ciphers based on a Lai-Massey scheme, named FOX.
- a new design of strong and efficient key-schedule algorithms is proposed.
- Evidence is provided that FOX is immune to linear and differential cryptanalysis.
- the method of- this Appendix seeks to provide an improved encryption method, and in particular an improved encryption method related to
- a Feistel-like cipher, described herein, is preferably designed to be easily implemented in hardware and difficult to implement in software.
- the P-box is preferably used in every second round of the Feistel- like cipher.
- the Feistel-like cipher preferably uses a full-size key and at least one reduced-size intermediate key, such that a size of the reduced-size intermediate key is chosen so that implementation of the Feistel-like cipher without specialized hardware is inefficient.
- the size of the intermediate key in bits is preferably not a power of two (2).
- the size of the intermediate key in bits is typically eighty nine (89).
- Plaintext inputs are preferably not of equal size.
- a multi-round Feistel-like cipher using a first P-box and a second P-box, such that the first P-box is used on a first half of an input, and the second P-box is used on a second half of the input, after the second half input has been modified in a round of the Feistel-like cipher.
- Fig. 31 is an illustration of a hardened Feistel-like structure for use with a preferred embodiment of the present invention
- Fig. 32 is an illustration of an alternative preferred embodiment of the hardened Feistel-like structure of Fig. 31;
- Fig. 33 is a simplified block diagram of a preferred implementation of a MixKey function of the system of Fig. 31 ;
- Fig. 34 is a simplified block diagram of a CombParts function of the system of Fig. 31.
- FIG. 31 is an illustration of a hardened Feistel-like structure for use with a preferred embodiment of the present invention. It is appreciated that Fig. 31 provides an illustration of data structures and methods for implementing an encryption network, the illustration being drawn in a format which is well known in the art. Persons skilled in the art will appreciated that, as discussed below with reference to Fig. 34, the data structures and methods of the illustrated encryption network may be implemented in special purpose hardware, in software combined with general purpose hardware, or in any appropriate combination thereof. The system/method described in this Appendix encompasses implementations using any such appropriate implementation.
- Fig. 31 depicts two rounds of the hardened Feistel-like structure 2100, it being appreciated that a plurality of rounds comprising more than two rounds is preferred, similarly to the plurality of rounds known in the prior art in the case of Feistel-like networks.
- L and R In each round of the hardened Feistel-like structure 2100, two halves of a plaintext, left and right, depicted as L and R, are operated on by a MixKey function 2110 and a CombParts function 2120.
- a preferred method of operation of the MixKey function 2110 is discussed below with reference to Fig. 33, and a preferred method of operation of the CombParts function 2120 is discussed below with reference to Fig. 34.
- L and R preferably have an identical size of 64 bits. It is appreciated that L and R may be any equal size, and 64 bits is used herein as an example.
- the plurality of rounds may preferably be preceded by preprocessing of L and R.
- L and R may preferably be permuted according to a pre-defined permutation in the same manner the DES block cipher permutes the input before the first round (refer to FIPS 46-3).
- an encrypted output of the hardened Feistel-like structure 2100 may be post-processed.
- output may preferably be further permuted according to a pre-defined permutation in the same manner the DES block cipher permutes the state after the 16 th round (refer to FIPS 46-3).
- a first round of the hardened Feistel-like structure 2100 and a last round, and other round of the hardened Feistel-like structure 2100 may preferably differ from each other and from other rounds among the plurality of rounds. After every at least two rounds, L and R are input into a
- Permutation-box 2130 (P-box). It is appreciated that L and R can be input into the
- R may optionally not be input into the P-box 2130.
- P-boxes are well known cryptographic structures. Typically, P- boxes are used to introduce permutations into ciphertext messages.
- P-box 2130 preferably comprises a bit permutation routine which preferably: concatenates L and R; permutes the bits comprising L and R; produces a result of the permutation; and splits the result into the next iteration of L and R. It is appreciated that implementing the P-box 2130 every two rounds makes the Feistel-like structure 2100 harder to implement in software.
- a 128 bit key (not shown) is preferably used to generate a plurality of round keys 2190, where each round key 2190 is used in one Feistel round.
- a typical number of rounds is 46.
- Round key 2190 generation is preferably done through a key expansion algorithm such as the
- FIG. 32 is an illustration of an alternative preferred embodiment of the hardened Feistel-like structure 2100 of Fig. 31.
- the hardened Feistel-like structure 2100 is implemented as in Fig. 31.
- the output of the CombParts function 2120 is input into P-box PLi
- Fig. 33 is a simplified block diagram of a preferred implementation of the MixKey function 2110 of the system of Fig. 31.
- the MixKey function 2110 preferably integrates the round key 2230 with the 64 bit right half in order to generate a 64 bit input to the CombParts function 2120.
- the MixKey function 2110 preferably comprises three subfunctions: •
- Implementations of the MixKey function 2110 may differ by using different instances of the three subfunctions RExpansion 2210, CombKey 2220, and Reduce 2240.
- RExpansion 2210 preferably expands the right half of the plaintext
- RExpansion 2210 is a deliberate choice, in that 89 is not a power of 2. Therefore,
- RExpansion 2210 preferably replicates a predefined set of 25 input bits in order to produce an 89 bit intermediate value.
- the 89 bit intermediate value is sent to CombKey 2220 for combining with the round key 2230.
- the predefined set may be unique per round.
- RExpansion 2210 preferably performs an expanding linear transformation on R by performing an exclusive-OR (XOR) on a predefined set of input bits.
- RExpansion 2210 preferably replicates a predefined set of 25 input bits and permutes, with, a XOR, the predefined set of 25 input bits.
- RExpansion 2210 preferably comprises a sparse linear transformation, such that each output bit is the result of a XOR of two input bits, and each input bit affects one or two output bits.
- CombKey 2220 preferably performs an operation which combines the 89 bit intermediate value with the round key 2230. Any appropriate reversible operation may be used.
- the size of the round key 2230 is preferably identical to the size of the output of RExpansion 2210, and the combining operation preferably comprises a bitwise XOR. In other preferred implementations the combining operation preferably comprises one of addition and subtraction modulo some constant.
- CombKey 2220 preferably outputs a result which is preferably input into Reduce 2240.
- Reduce 2240 preferably reduces the output of CombKey into a 64 bit result.
- the reduce function 2240 is preferably designed in such a fashion that the reduce function 2240 is difficult to efficiently implement without specialized hardware, and easy to implement in specialized hardware.
- the reduce function 2240 preferably comprises a plurality of AM), OR, and NOT gates, arranged in a plurality of layers. After each one of the plurality of layers of gates, a resulting set of bits are preferably permuted and input into a next layer of the plurality of layers of gates.
- each output bit is preferably close to balanced. Specifically, the probability that any output bit has a value of 1 is approximately one half, given a uniform distribution of input bits. It is preferable that each output bit is close to balanced even when a small subset of input bits comprise fixed values.
- each output bit function preferably does not comprise linear approximations. Specifically, for every linear operator L and for each output bit, the probability that a given output bit is identical to the result of applying the operator L on a corresponding input bit, assuming uniform distribution of the input bits, is preferably close to one half. Preferably, there are a plurality of instances of the reduce function 2240, such that different instances of the reduce function 2240 can be used in different rounds.
- the reduce function 2240 can be one of: identical for all rounds; unique for all rounds; selected differently for even and odd rounds; and any other appropriate combination of instances of the reduce function 2240.
- the reduce function 2240 is preferably implemented comprising 20 - 50 layers of small functions, each of the small functions serving as building blocks from which the reduce function 2240 is constructed.
- Each of the small functions preferably employs a balanced function, BF 5 and a non-linear function, NLF.
- NLF is preferably executed on at least one of the bits, thereby producing an output, Q.
- BF is preferably executed on Q and at least a second input bit.
- Non-limiting examples of appropriate small functions processing 3- bit inputs- which are appropriate building blocks used in implementations of the reduce function 2240 include:
- Implementations of the reduce function 2240 in a second layer preferably takes, as inputs, outputs of the reduce function 2240 in a first layer. It is preferable that a selection of which output of the first layer is input to which reduce function 2240 in the second layer is performed in such a way as to maximize mixing between layers.
- reduce function 2240 A may be used during rounds 1, 6, 11, and 16; reduce function 2240 B may be used during rounds 2, 7, 12, and 17; reduce function 2240 C may be used during rounds 3, 8, 13, and 18; reduce function 2240 D may be used during rounds 4, 9, 14, and 19; and reduce function 2240 E may be used during rounds 5, 10, 15, and 20. It is appreciated that any other suitable arrangement of the ' 4 to 6 reduce functions 2240 is acceptable.
- CombParts should not be an involution; that is, ICombParts preferably differs significantly from CombParts. Specifically, a function such as XOR (such as is implemented in DES) would be unacceptable.
- the bit result of MixKey 2110 is preferably input into a splitter 2310.
- the 64 bit unchanged L is input into a splitter 2315.
- Splitter 2310 and splitter 2315 preferably divide their respective inputs into small sub-blocks, preferably of 2 to 4 bits each in size. In some preferred implementations, splitter
- splitter 2310 preferably divides the 64 bit result of MixKey 2110 into 16 4-bit sub-blocks, and splitter 2315 preferably divides the 64 bit unchanged L into 16 4-bit sub- blocks.
- SubComb 2320 functions, and in still other preferred implementations, there are some other number of SubComb 2320 functions.
- SubComb 2320 is preferably implemented such that:
- SubComb 2320 is preferably reversible with respect to a second input.
- SubComb 2320 it is assumed that SubComb 2320 receives two k-bit inputs and one k-bit output.
- Input bits from MixKey 2110 are referred to hereinafter as data bits, and input bits from L are referred to. as control bits, k is preferably a small integer between 2 and 8.
- a third preferred implementation of SubComb 2320 comprises the following function:
- a fourth preferred implementation of SubComb 2320 comprises defining a mapping of control input to a domain of invertible linear transformations.
- the mapping may comprise starting with the identity transformation and replacing certain locations with control bits. It appreciated that when the replaced locations are selected over the primary diagonal, the linear transformation remains invertible. For example, for L(Bl 1, B12, B 13, B14), use: [ 1 BIl 0 B14 ]
- the Join function 2330 is preferably implemented as a concatenation of the output of the plurality of SubComb functions 2320.
- output from CombParts 2120 goes through a bitwise permutation (P-box 2130 (Fig. 31)).
- software components of the present invention may, if desired, be implemented in ROM (read only memory) form.
- the software components may, generally, be implemented in hardware, if desired, using conventional techniques.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Storage Device Security (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Description
Claims
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP06821614A EP1961140A4 (en) | 2005-12-14 | 2006-12-04 | Method and system for usage of block cipher encryption |
US12/085,393 US20090080647A1 (en) | 2005-12-14 | 2006-12-04 | Method and System for Usage of Block Cipher Encryption |
AU2006324920A AU2006324920B2 (en) | 2005-12-14 | 2006-12-04 | Method and system for usage of block cipher encryption |
IL191685A IL191685A (en) | 2005-12-14 | 2008-05-25 | Method and system for usage of block cipher encryption |
IL219656A IL219656A (en) | 2005-12-14 | 2012-05-08 | Method and system for usage of block cipher encryption |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IL172578 | 2005-12-14 | ||
IL172578A IL172578A0 (en) | 2005-12-14 | 2005-12-14 | Method and system for usage of block cipher encryption |
IL173863A IL173863A0 (en) | 2006-02-21 | 2006-02-21 | System and method for usage of block cipher encryption |
IL173863 | 2006-02-21 | ||
IL175802A IL175802A0 (en) | 2006-05-21 | 2006-05-21 | Method and system for usage of block cipher encryption |
IL175802 | 2006-05-21 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2007069236A2 true WO2007069236A2 (en) | 2007-06-21 |
WO2007069236A3 WO2007069236A3 (en) | 2009-04-16 |
Family
ID=38163322
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IL2006/001394 WO2007069236A2 (en) | 2005-12-14 | 2006-12-04 | Method and system for usage of block cipher encryption |
Country Status (6)
Country | Link |
---|---|
US (1) | US20090080647A1 (en) |
EP (1) | EP1961140A4 (en) |
KR (2) | KR20080080175A (en) |
AU (1) | AU2006324920B2 (en) |
IL (2) | IL191685A (en) |
WO (1) | WO2007069236A2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010024003A1 (en) * | 2008-08-29 | 2010-03-04 | 日本電気株式会社 | Device for encrypting block with double block length, decrypting device, encrypting method, decrypting method, and program therefor |
FR2949010A1 (en) * | 2009-08-05 | 2011-02-11 | St Microelectronics Rousset | COUNTERMEASURE PROCESS FOR PROTECTING STORED DATA |
US8314093B2 (en) | 2006-02-17 | 2012-11-20 | Rigel Pharmaceuticals, Inc. | 2,4-pyrimidinediamine compounds for treating or preventing autoimmune diseases |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9361617B2 (en) * | 2008-06-17 | 2016-06-07 | Verifone, Inc. | Variable-length cipher system and method |
KR101520617B1 (en) * | 2007-04-17 | 2015-05-15 | 삼성전자주식회사 | Method for encrypting message for keeping integrity of message and apparatus and Method for decrypting message for keeping integrity of message and apparatus |
US20080263366A1 (en) * | 2007-04-19 | 2008-10-23 | Microsoft Corporation | Self-verifying software to prevent reverse engineering and piracy |
KR100930591B1 (en) * | 2007-12-10 | 2009-12-09 | 한국전자통신연구원 | Encryption device capable of fast session change |
JP4952627B2 (en) * | 2008-03-21 | 2012-06-13 | 富士通株式会社 | Image processing apparatus, image processing method, and image processing program |
US20090245510A1 (en) * | 2008-03-25 | 2009-10-01 | Mathieu Ciet | Block cipher with security intrinsic aspects |
US20100306553A1 (en) * | 2009-06-01 | 2010-12-02 | Poletti Iii Joseph William | High-throughput cryptographic processing using parallel processing |
DE102009050493A1 (en) * | 2009-10-23 | 2011-04-28 | Röllgen, Bernd | Block data encryption methods |
US8862900B2 (en) * | 2010-01-08 | 2014-10-14 | The Research Foundation For The State University Of New York | Secure distributed storage system and method |
US8850410B2 (en) * | 2010-01-29 | 2014-09-30 | International Business Machines Corporation | System using a unique marker with each software code-block |
JP5704951B2 (en) * | 2011-02-10 | 2015-04-22 | ソニー株式会社 | Information processing apparatus, information processing method, and computer program |
KR101118826B1 (en) | 2011-02-15 | 2012-04-20 | 한양대학교 산학협력단 | Encryption apparatus and method for preventing physical attack |
JP5593458B2 (en) * | 2012-01-19 | 2014-09-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | A system that authenticates whether a string is accepted by an automaton |
US9160525B2 (en) * | 2013-07-19 | 2015-10-13 | Qualcomm Incorporated | Apparatus and method for key update for use in a block cipher algorithm |
EP3084968A4 (en) * | 2013-12-16 | 2017-11-29 | McAfee, LLC | Process efficient preprocessing for an encryption standard |
US9515818B2 (en) * | 2014-09-16 | 2016-12-06 | Apple Inc. | Multi-block cryptographic operation |
US9252943B1 (en) * | 2014-09-26 | 2016-02-02 | The Boeing Company | Parallelizable cipher construction |
US11418321B2 (en) * | 2014-12-03 | 2022-08-16 | Nagravision Sari | Block cryptographic method for encrypting/decrypting messages and cryptographic devices for implementing this method |
EP3089398B1 (en) * | 2015-04-30 | 2017-10-11 | Nxp B.V. | Securing a cryptographic device |
US11876889B2 (en) * | 2015-09-03 | 2024-01-16 | Fiske Software, Llc | NADO cryptography with key generators |
KR101989956B1 (en) * | 2015-10-29 | 2019-06-17 | 삼성에스디에스 주식회사 | Apparatus and method for encryption |
CN109218010B (en) * | 2017-07-04 | 2021-11-30 | 阿波罗智能技术(北京)有限公司 | Data encryption method and device and data decryption method and device |
US10187200B1 (en) * | 2017-12-18 | 2019-01-22 | Secure Channels Inc. | System and method for generating a multi-stage key for use in cryptographic operations |
KR102038598B1 (en) | 2018-11-08 | 2019-10-30 | 국민대학교산학협력단 | Encryption apparatus and method for preventing coupling effect |
US11038677B2 (en) | 2019-01-31 | 2021-06-15 | Re Formsnet, Llc | Systems and methods for encryption and authentication |
US10454906B1 (en) | 2019-01-31 | 2019-10-22 | Re Formsnet, Llc | Systems and methods for encryption and authentication |
US11283619B2 (en) * | 2019-06-20 | 2022-03-22 | The Boeing Company | Bit mixer based parallel MAC and hash functions |
KR102287962B1 (en) | 2019-09-30 | 2021-08-09 | 국민대학교 산학협력단 | Encryption method of 128-bit lightweight block cipher suitable for side-channel countermeasures |
KR102169369B1 (en) | 2019-10-31 | 2020-10-23 | 국민대학교산학협력단 | Countermeasure method of first-order side-channel attack on lightweight block cipher and apparatus using the same |
KR102157219B1 (en) | 2019-10-31 | 2020-09-17 | 국민대학교산학협력단 | Countermeasure method of higher-order side-channel attack on lightweight block cipher and apparatus using the same |
CN114095153A (en) * | 2020-08-05 | 2022-02-25 | 迈络思科技有限公司 | Cipher data communication device |
CN117134886B (en) * | 2023-08-21 | 2024-01-30 | 湖北大学 | Optimized FOX algorithm linear layer circuit |
Family Cites Families (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
NL9301784A (en) * | 1993-10-14 | 1995-05-01 | Irdeto Bv | System for encrypting and decrypting digital information. |
US5671283A (en) * | 1995-06-08 | 1997-09-23 | Wave Systems Corp. | Secure communication system with cross linked cryptographic codes |
JP2000517497A (en) * | 1996-09-03 | 2000-12-26 | シーメンス アクチエンゲゼルシヤフト | Apparatus and method for processing digital data stream with arbitrary number of data |
TW367465B (en) * | 1997-04-23 | 1999-08-21 | Matsushita Electric Ind Co Ltd | Cryptographic processing apparatus cryptographic processing method, and storage medium storing cryptographic processing program for improving security without greatly increasing hardware scale and processing time |
US6307940B1 (en) * | 1997-06-25 | 2001-10-23 | Canon Kabushiki Kaisha | Communication network for encrypting/deciphering communication text while updating encryption key, a communication terminal thereof, and a communication method thereof |
US6055316A (en) * | 1997-12-26 | 2000-04-25 | Sun Microsystems, Inc. | System and method for deriving an appropriate initialization vector for secure communications |
JP2000066587A (en) * | 1998-08-24 | 2000-03-03 | Toshiba Corp | Data processor and communication system as well as recording medium |
JP3824121B2 (en) * | 1999-04-01 | 2006-09-20 | 株式会社日立製作所 | Method and apparatus for decrypting encrypted data |
US6820203B1 (en) * | 1999-04-07 | 2004-11-16 | Sony Corporation | Security unit for use in memory card |
EP1063811B1 (en) * | 1999-06-22 | 2008-08-06 | Hitachi, Ltd. | Cryptographic apparatus and method |
US7184549B2 (en) * | 2000-01-14 | 2007-02-27 | Mitsubishi Denki Kabushiki Kaisha | Method and apparatus for encryption, method and apparatus for decryption, and computer-readable medium storing program |
ES2301525T3 (en) * | 2000-01-21 | 2008-07-01 | Sony Corporation | DATA AUTHENTICATION SYSTEM. |
US7046802B2 (en) * | 2000-10-12 | 2006-05-16 | Rogaway Phillip W | Method and apparatus for facilitating efficient authenticated encryption |
JP2002132141A (en) * | 2000-10-20 | 2002-05-09 | Sony Corp | Data memory and data recording method, data reproducing method as well as program provision medium |
JP2002202719A (en) * | 2000-11-06 | 2002-07-19 | Sony Corp | Device and method for enciphering, device and method for deciphering, and storage medium |
US7360075B2 (en) * | 2001-02-12 | 2008-04-15 | Aventail Corporation, A Wholly Owned Subsidiary Of Sonicwall, Inc. | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols |
US7155011B2 (en) * | 2001-03-13 | 2006-12-26 | Victor Company Of Japan, Limited | Encryption method, decryption method, and recording and reproducing apparatus |
US7200227B2 (en) * | 2001-07-30 | 2007-04-03 | Phillip Rogaway | Method and apparatus for facilitating efficient authenticated encryption |
US20020076044A1 (en) * | 2001-11-16 | 2002-06-20 | Paul Pires | Method of and system for encrypting messages, generating encryption keys and producing secure session keys |
JP4235174B2 (en) * | 2002-08-08 | 2009-03-11 | パナソニック株式会社 | Encryption / decryption device, encryption device, decryption device, and transmission / reception device |
US7336783B2 (en) * | 2003-01-24 | 2008-02-26 | Samsung Electronics, C., Ltd. | Cryptographic systems and methods supporting multiple modes |
US20060269055A1 (en) * | 2005-05-26 | 2006-11-30 | International Business Machines Corporation | Method and apparatus for improving performance and security of DES-CBC encryption algorithm |
JP2007041223A (en) * | 2005-08-02 | 2007-02-15 | Mitsubishi Electric Corp | Data distribution device and data communications system |
US7428306B2 (en) * | 2006-04-18 | 2008-09-23 | International Business Machines Corporation | Encryption apparatus and method for providing an encrypted file system |
-
2006
- 2006-12-04 KR KR1020087016937A patent/KR20080080175A/en not_active Application Discontinuation
- 2006-12-04 WO PCT/IL2006/001394 patent/WO2007069236A2/en active Application Filing
- 2006-12-04 US US12/085,393 patent/US20090080647A1/en not_active Abandoned
- 2006-12-04 AU AU2006324920A patent/AU2006324920B2/en not_active Ceased
- 2006-12-04 EP EP06821614A patent/EP1961140A4/en not_active Withdrawn
- 2006-12-04 KR KR1020127023158A patent/KR20120115425A/en not_active Application Discontinuation
-
2008
- 2008-05-25 IL IL191685A patent/IL191685A/en not_active IP Right Cessation
-
2012
- 2012-05-08 IL IL219656A patent/IL219656A/en not_active IP Right Cessation
Non-Patent Citations (1)
Title |
---|
See references of EP1961140A4 * |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8314093B2 (en) | 2006-02-17 | 2012-11-20 | Rigel Pharmaceuticals, Inc. | 2,4-pyrimidinediamine compounds for treating or preventing autoimmune diseases |
WO2010024003A1 (en) * | 2008-08-29 | 2010-03-04 | 日本電気株式会社 | Device for encrypting block with double block length, decrypting device, encrypting method, decrypting method, and program therefor |
JPWO2010024003A1 (en) * | 2008-08-29 | 2012-01-26 | 日本電気株式会社 | Double block length block encryption device, decryption device, encryption method and decryption method, and program thereof |
FR2949010A1 (en) * | 2009-08-05 | 2011-02-11 | St Microelectronics Rousset | COUNTERMEASURE PROCESS FOR PROTECTING STORED DATA |
EP2284748A1 (en) | 2009-08-05 | 2011-02-16 | STMicroelectronics Rousset SAS | Countermeasure for the protection of stored data |
US9483663B2 (en) | 2009-08-05 | 2016-11-01 | Stmicroelectronics (Rousset) Sas | Countermeasure method for protecting stored data |
Also Published As
Publication number | Publication date |
---|---|
IL191685A0 (en) | 2008-12-29 |
AU2006324920A1 (en) | 2007-06-21 |
US20090080647A1 (en) | 2009-03-26 |
IL219656A0 (en) | 2012-06-28 |
IL191685A (en) | 2012-07-31 |
AU2006324920B2 (en) | 2010-08-12 |
IL219656A (en) | 2013-02-28 |
KR20080080175A (en) | 2008-09-02 |
EP1961140A4 (en) | 2013-02-27 |
WO2007069236A3 (en) | 2009-04-16 |
EP1961140A2 (en) | 2008-08-27 |
KR20120115425A (en) | 2012-10-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2006324920B2 (en) | Method and system for usage of block cipher encryption | |
Mouha et al. | Chaskey: an efficient MAC algorithm for 32-bit microcontrollers | |
Alabaichi et al. | Enhance security of advance encryption standard algorithm based on key-dependent S-box | |
US5745577A (en) | Symmetric cryptographic system for data encryption | |
EP2829010B1 (en) | Updating key information | |
AU2007232123B2 (en) | Robust cipher design | |
US8437470B2 (en) | Method and system for block cipher encryption | |
Duta et al. | Randomness evaluation framework of cryptographic algorithms | |
KR20190020988A (en) | Computer-executable lightweight white-box cryptographic method and apparatus thereof | |
Mohan et al. | Revised aes and its modes of operation | |
RU2738321C1 (en) | Cryptographic transformation method and device for its implementation | |
Alabaichi | A dynamic 3D S-box based on cylindrical coordinate system for blowfish algorithm | |
GN et al. | Blow-CAST-Fish: A New 64-bit Block Cipher | |
Azzawi | Enhancing the encryption process of advanced encryption standard (AES) by using proposed algorithm to generate S-Box | |
Hallappanavar et al. | Efficient implementation of AES by modifying S-Box | |
Mahdi | Design and implementation of proposed BR encryption algorithm | |
Pramod et al. | An advanced AES algorithm using swap and 400 bit data block with flexible S-Box in Cloud Computing | |
Salman | New method for encryption using mixing advanced encryption standard and blowfish algorithms | |
Saeb | The Chameleon Cipher-192 (CC-192)-A Polymorphic Cipher. | |
El-Morshedy et al. | Cryptographic Algorithms for Enhancing Security in Cloud Computing. | |
WO2008117142A9 (en) | Method and system for block cipher encryption | |
Hashim | Type-3 Feistel Network of The 128-bits Block Size Improved Blowfish Cryptographic Encryption | |
Ali | Proposed 256 bits RC5 Encryption Algorithm Using Type-3 Feistel Network | |
Lozano | IDEA cipher | |
Cipher | THE CHAMELEON CIPHER-192 (CC-192) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2006821614 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 191685 Country of ref document: IL |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2006324920 Country of ref document: AU |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2006324920 Country of ref document: AU Date of ref document: 20061204 Kind code of ref document: A |
|
WWP | Wipo information: published in national office |
Ref document number: 2006324920 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 12085393 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020087016937 Country of ref document: KR |
|
WWP | Wipo information: published in national office |
Ref document number: 2006821614 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 219656 Country of ref document: IL |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020127023158 Country of ref document: KR |