We present an update of the Pelican MAC function, called Pelican 2.0. Both versions have the Alred construction and are based on Rijndael. they are a factor 2.5 more efficient than CBC-MAC with Rijndael, while providing a comparable claimed security level.

The difference between Pelican 2.0 and the original version is that the initial value changes from the all-zero string to another constant. The reason for this is the negative impact on security if key check values are available computed with a certain standard key check value algorithm that applies the block cipher to the zero string and takes as key check value its truncated output. The security impact of this on a number of standard MACs is studied in Cryptology ePrint Archive Report 2014/183 and the analysis carries over for Pelican

Joan Daemen

Vincent Rijmen

Abstract. We present an update of the Pelican MAC function, called Pelican 2.0. Both versions have the Alred construction [5] and are based on Rijndael. they are a factor 2.5 more efficient than CBC-MAC with Rijndael, while providing a comparable claimed security level. The difference between Pelican 2.0 and the original version is that the initial value changes from the all-zero string to another constant. The reason for this is the negative impact on security if key check values are available computed with a certain standard key check value algorithm that applies the block cipher to the zero string and takes as key check value its truncated output. The security impact of this on a number of standard MACs is studied in [11], and the analysis carries over for Pelican. 

CiteSeerX

The MAC function Pelican 2.0

Cryptology ePrint Archive

The MAC function Pelican 2.0Joan Daemen1 and Vincent Rijmen21 STMicroelectronics Belgiumjoan.daemen@st.com2 KU Leuven & iMinds (Belgium)vincent.rijmen@esat.kuleuven.beAbstract. We present an update of the Pelican MAC function, calledPelican 2.0. Both versions have the Alred construction [5] and arebased on Rijndael. they are a factor 2.5 more efficient than CBC-MACwith Rijndael, while providing a comparable claimed security level.The difference between Pelican 2.0 and the original version is that theinitial value changes from the all-zero string to another constant. Thereason for this is the negative impact on security if key check values areavailable computed with a certain standard key check value algorithmthat applies the block cipher to the zero string and takes as key checkvalue its truncated output. The security impact of this on a numberof standard MACs is studied in [11], and the analysis carries over forPelican.1 IntroductionMessage Authentication Codes (MAC functions) are symmetric primitives, usedto ensure authenticity of messages. They take as input a secret key and themessage, and produce as output a short tag. The basic property of a MACfunction is that it provides an unpredictable mapping between messages and thetag for someone who does not know, or only partially knows the key.We propose here a new version of the Pelican MAC function [6], calledPelican 2.0. We will indicate the first version of Pelican with the suffix 1.0and use Pelican without suffix in statements that apply to both versions.The design of Pelican is based on the Alred construction, which was pre-sented in [5]. Pelican 1.0 can be seen as a simplification of Alpha-MAC, theconcrete design presented in [5]. In a follow-up paper [7], we refined the secu-rity claims for iterative MAC functions that we proposed in [5] and did someadditional analysis on internal collisions in the Alred structure.Pelican is based on Rijndael [4]. We have chosen for Rijndael mainlybecause it is widely available thanks to its status as the AES standard. Addi-tionally, Rijndael is efficient in hardware and software and it has withstoodintense public scrutiny very well since its publication [8].We specify Pelican 2.0 in Section 2. In Section 3, we briefly repeat the se-curity claims introduced in [5], and in Section 5 we recall the provable securityproperties of the Alred construction, that apply to Pelican. In Section 4 wemotivate the change between Pelican 1.0 and 2.0 and in Section 6 we brieflysummarize the state-of-the-art of cryptanalysis of Pelican. We discuss perfor-mance in Section 7 and conclude in Section 8.2 SpecificationPelican is an Alred construction with Rijndael [4], restricted to a blocklength of 128 bits, as underlying block cipher. As Rijndael, Pelican supportskeys of 16, 20, 24, 28 and 32 bytes. For the key lengths 16, 24 and 32 bytes,Rijndael coincides with AES [12]. Pelican can take a message m of any lengthand generates tags with length up to 128 bits.In the Pelican 2.0 algorithm we can distinguish a number of stages. Firstthe message is padded and split in message words. These message words areapplied to a state that is initialized using the key and that afterwards undergoesa final step again using the key. More exactly:Message padding and splitting: pad the message by appending a single 1bit followed by the minimum number of 0 bits so that the resulting length isa multiple of 128 bits (padding method 2 in [10]). Split the result in 128-bitmessage words x1, x2, . . . xq.State initialization: fill the 128-bit state with the initialisation vector IV andsubsequently apply the Rijndael block cipher to it using the key.IV =0x00 0x00 0x00 0x000x01 0x01 0x00 0x010x01 0x00 0x01 0x000x01 0x01 0x01 0x00Chaining: XOR the first message word x1 to the state. For each additionalmessage word xi, apply to the state the iteration function and then XORthe message word xi to the state. The iteration function consists of fourRijndael rounds with round keys set to 0.Finalization: Apply Rijndael encryption to the state using the key and formthe tag by taking the first ℓm bits of the state.Pelican 2.0 is illustrated in Figure 1.3 Security claimsPelican is an iterative MAC function. Iterative MAC functions have the dis-advantage that different messages may be found that lead to the same value ofthe state during the MAC generation process. This is called an internal colli-sion [13]. We have proposed in [5] a set of three orthogonal security claims foriterative MAC functions that reflect this limitation and used these to expressthe security claim for Pelican 1.0. Later we found a problem with the claimrelated to internal collisions that was expressed in terms of number of messages.In our paper [7] we addressed this by proposing a claim expressed in terms oftotal number of blocks in the messages. We base the security claim of Pelican2.0 on this new formulation. For clarity, we repeat the claims here.The claims are formulated in terms of three dimension parameters: the taglength ℓm, the key length ℓk and the capacity ℓc. The capacity is the size ofthe internal memory of a random map with the same probability for internalcollisions as the MAC function and the designer must fix its value in the securityclaim.For Pelican 1.0 we based the value of the capacity in our security claimson a preliminary analysis of generating internal collisions, based on the theorypresented in [5]. We made our rationale more explicit in our paper [7]. Thisrationale remains valid for Pelican 2.0.Claim 1 The probability of success of any forgery attack not involving key re-covery or internal collisions is 2−ℓm .Claim 2 There are no key recovery attacks faster than exhaustive key search,i.e. with an expected complexity less than 2ℓk−1 MAC function executions.Claim 3 The probability that an internal collision occurs in a set of adaptivelychosen messages presented to the MAC function is not above 1−exp(−A2/2ℓc+1),with A the total number of blocks in the messages.Pelican 2.0 should satisfy these three claims for the following range of valuesof the dimension parameters:– Tag length ℓm: any value up to 128 bits.– Key length ℓk: 128, 160, 192, 224 and 256 bits.– Capacity ℓc: 120 bits4 Motivation of the change of initial valueANSI X9.24-1:2009 [1] specifies the manual and automated management of key-ing material used for financial services. This includes the suggestion to computea key check value (KCV) on a block cipher key K. The method proposed isto apply the associated block cipher to an all-zero block under the key K andtake the s most significant bits of the result as KCV, with s typically 24. TheKCV can then be used to verify the integrity of the key and is treated as a pub-lic value. Unfortunately, this method has been widely applied in a.o. hardwaresecurity modules (HSM).In [11], the authors study the impact on the security of MAC algorithmsspecified in ISO/IEC 9797-1 [10] if the KCV of the used key is known. It turnsout that for the majority of them there is a significant impact on the security.Clearly, for Pelican 1.0, the KCV simply gives away s bits of the chainingvalue, the secrecy of which is critical for its security. Changing the IV from theall-zero block to any other value solves this problem and so this is what we didfor Pelican 2.0.Fig. 1. Block scheme of Pelican 2.0.5 ProvabilityPelican has the Alred structure [5]. For this structure, the security withrespect to forgery in the absence of collisions and with respect to key recoverycan be provably reduced to security properties of the used block cipher. Thisresults in the following theorems for Pelican.Theorem 1. Every key recovery attack on Pelican, requiring t (adaptively)chosen messages, can be converted to a key recovery attack on Rijndael, re-quiring t+ 1 adaptively chosen plaintexts.Theorem 2. Every forgery attack on Pelican not involving internal collisions,requiring t (adaptively) chosen messages, can be converted to a ciphertext guess-ing attack on Rijndael, requiring t+ 1 adaptively chosen plaintexts.For the proofs of these theorems we refer to [5].6 State of cryptanalysis of PelicanPelican has received quite some cryptanalysis since it was first published [2,3,9,14,15]. All this cryptanalysis concentrates on retrieving the state value duringthe chaining stage.Recovery of the value of the state during the chaining stage is not equivalentto key recovery. Still, as observed in a.o. [2], its secrecy is essential for the securityof Pelican. An attacker who can find out its value for a given key and inputmessage, can perform forgeries at the expense of a single correcting block of size128 bits, where she can even choose the position of this block in the message.At the time of writing, all known cryptanalytic methods for recovering thisstate value require internal collisions. They make use of the specific properties ofthe Rijndael round function, including its symmetry properties in the absenceof round keys (or constants). Upon inspection, it turns out that none of theseattacks violate the Pelican security claims. In fact, none of them allows gener-ating inner collisions in Pelican with a higher success probability than genericmethods. In other words, with respect to the published attacks, even a claimwith capacity ℓc = 128 would hold up and with respect to the claimed capacitythere is still a safety margin of 8 bits.Some of the published attacks can be countered by applying round constantsor sub-keys in the chaining phase. However, as the attacks do not compromisethe security claims, we have decided to honor the motto “if it ain’t broke, don’tfix it”. Implementations shall take special precautions to protect the secrecy ofthe internal state against applicable side channel and fault attacks.7 PerformanceIn this section we express the performance of Pelican in terms of Rijndaeloperations, more particularly, the Rijndael key schedule and the Rijndaelencryption operation. This allows to use Rijndael (or AES) benchmarks forsoftware implementations on many platform and hardware implementations toget a pretty good idea on the performance of Pelican. We restrict ourselves tothe case of 128-bit keys.One iteration of Pelican corresponds roughly to 4 rounds of Rijndael,hence 2/5 of a Rijndael encryption. It is actually better because the XORs with0 in the round key addition don’t have to be implemented. Some implementationsof Rijndael recompute the round keys for every encryption. This overhead isnot present in Pelican. As the first message word is simply XORed withoutadditional rounds, the message processing of the first message word must besubtracted from the message processing. Using these rough approximations, wecan state that MACing a message requires:setup: 1 Rijndael key schedule and 1 Rijndael encryption,message processing: 0.4 Rijndael encryptions per 16-byte message word,finalization: 0.6 Rijndael encryptions.Hence, for long messages the computational workload of Pelican is only 40 %of Rijndael encryption. For short messages, the minimum cost is 1 Rijndaelencryption for generating a tag and 1 additional Rijndael encryption and keyschedule at key setup.On many platforms this can speed up MAC computation by a factor up to 2.5.Like any other serial mode of operation, Pelican gets only a limited performanceimprovement from the AES-NI instructions present on modern processors. Thisis due to the long latency of these instructions. Exploiting the pipelining on suchplatforms is possible only with parallelizable MAC constructions. Note howeverthat Pelican is still 2.5 times faster than CBC-MAC with Rijndael.8 ConclusionsWe presented Pelican 2.0, an update of the Pelican MAC function that isbased on the Alred construction. The difference with its predecessor is thechange in initial value to avoid negative interference with a popular key checkvalue method. The Alred construction comes with some security proofs, whichare also applicable to this primitive.References1. ANSI, X9.24: Retail financial services symmetric key management part 1: Usingsymmetric techniques, 2009.2. Alex Biryukov, Andrey Bogdanov, Dmitry Khovratovich, and Timo Kasper, Col-lision attacks on AES-based MAC: Alpha-MAC, CHES (Pascal Paillier and IngridVerbauwhede, eds.), Lecture Notes in Computer Science, vol. 4727, Springer, 2007,pp. 166–180.3. Charles Bouillaguet, Patrick Derbez, and Pierre-Alain Fouque, Automatic searchof attacks on round-reduced aes and applications, CRYPTO (Phillip Rogaway, ed.),Lecture Notes in Computer Science, vol. 6841, Springer, 2011, pp. 169–187.4. J. Daemen and V. Rijmen, The design of Rijndael — AES, the advanced encryptionstandard, Springer-Verlag, 2002.5. , A new MAC construction ALRED and a specific instance ALPHA-MAC,Fast Software Encryption (Henri Gilbert and Helena Handschuh, eds.), LectureNotes in Computer Science, vol. 3557, Springer, 2005, pp. 1–17.6. , The Pelican MAC function, IACR Cryptology ePrint Archive 2005 (2005),8 p.7. , Refinements of the ALRED construction and MAC security claims, IETinformation security 4 (2010), 149–157.8. Joan Daemen and Vincent Rijmen, AES proposal: Rijndael, AES submission,1999, http://jda.noekeon.org/.9. Orr Dunkelman, Nathan Keller, and Adi Shamir, ALRED blues: New at-tacks on AES-based MAC’s, Cryptology ePrint Archive, Report 2011/095, 2011,http://eprint.iacr.org/.10. ISO/IEC, 9797-1: Information technology - security techniques - message authen-tication codes (macs) - part 1: Mechanisms using a block cipher, 2011.11. Tetsu Iwata and Lei Wang, Impact of ANSI X9.24-1:2009 key check value onISO/IEC 9797-1:2011 MACs, Cryptology ePrint Archive, Report 2014/183, 2014,http://eprint.iacr.org/.12. NIST, Federal information processing standard 197, advanced encryption standard(AES), November 2001.13. Bart Preneel and Paul C. van Oorschot, On the security of iterated message au-thentication codes, IEEE Transactions on Information Theory 45 (1999), no. 1,188–199.14. Wei Wang, Xiaoyun Wang, and Guangwu Xu, Impossible differential cryptanalysisof Pelican, MT-MAC-AES and PC-MAC-AES, IACR Cryptology ePrint Archive2009 (2009), 5.15. Zheng Yuan, Keting Jia, Wei Wang, and Xiaoyun Wang, Distinguishing andforgery attacks on Alred and its AES-based instance Alpha-MAC, Cryptology ePrintArchive, Report 2008/516, 2008, http://eprint.iacr.org/.

The MAC function Pelican 2.0

Abstract

Similar works

Full text

Available Versions

CiteSeerX

Cryptology ePrint Archive