Green Cryptography: Cleaner Engineering Through Recycling Justin Troutman Extorque Information Security Engineering [email protected]Vincent Rijmen Dept. of Electrical Engineering, K.U.Leuven and IBBT Graz University of Technology [email protected]June 16, 2010 The original draft is dated April 1, 2008. Abstract We introduce the concept of “green cryptography,” which adopts the principle of recycling cryptographic design strategies, components, and primitives; in this essay, we’ll focus on the AES, and it’s underlying block cipher, Rijndael. Cryptographic implementation is met with a mature and minimalist, “do a lot with a little” design paradigm – mature in that it recycles the rigorously cryptanalyzed AES, and its underlying block cipher, Rijndael, and minimalist in that it recycles the AES for both encryption and authentication, via generic composition, where we en- crypt then authenticate, separately (e.g., AES-CTR-then-AES-CMAC), or via an integrity-aware confidentiality mode of operation based on generic composition, where encryption then authen- tication is handled in a single mode (e.g., EAX). The end result is an implementation-centric framework for achieving the strongest notions of confidentiality and integrity, while retaining simplicity within the implementation. In short, recycling-based green cryptography is aimed at sustainable security within scalable implementations. We take a concise look – with an emphasis on symmetric cryptography – at some of the issues that are responsible for why cryptography usually ends up looking bad, in practice, and fails to establish the right threat model, let alone realize it; this is largely due to a lack of cryptographic competence, and the dreaded habit of crammed-in-and-cobbled-together design. To address these issues, we, with the assistance, and comedic relief, of Alice and Bob, give several rules of thumb for sufficient and simplistic crypto- graphic implementations. Be prepared for a bowl of acronymous porridge, but don’t worry; we’ll make sure it’s as easy to swallow as possible, and it might even up your Scrabble game. So, to the pulpit we go, ready to preach a sermon so desperately in need of being heard, and to which heed should be taken. 1
Transcript
Green Cryptography: Cleaner Engineering Through Recycling
Justin TroutmanExtorque Information Security Engineering
We introduce the concept of “green cryptography,” which adopts the principle of recyclingcryptographic design strategies, components, and primitives; in this essay, we’ll focus on theAES, and it’s underlying block cipher, Rijndael. Cryptographic implementation is met with amature and minimalist, “do a lot with a little” design paradigm – mature in that it recycles therigorously cryptanalyzed AES, and its underlying block cipher, Rijndael, and minimalist in thatit recycles the AES for both encryption and authentication, via generic composition, where we en-crypt then authenticate, separately (e.g., AES-CTR-then-AES-CMAC), or via an integrity-awareconfidentiality mode of operation based on generic composition, where encryption then authen-tication is handled in a single mode (e.g., EAX). The end result is an implementation-centricframework for achieving the strongest notions of confidentiality and integrity, while retainingsimplicity within the implementation. In short, recycling-based green cryptography is aimed atsustainable security within scalable implementations. We take a concise look – with an emphasison symmetric cryptography – at some of the issues that are responsible for why cryptographyusually ends up looking bad, in practice, and fails to establish the right threat model, let alonerealize it; this is largely due to a lack of cryptographic competence, and the dreaded habit ofcrammed-in-and-cobbled-together design. To address these issues, we, with the assistance, andcomedic relief, of Alice and Bob, give several rules of thumb for sufficient and simplistic crypto-graphic implementations. Be prepared for a bowl of acronymous porridge, but don’t worry; we’llmake sure it’s as easy to swallow as possible, and it might even up your Scrabble game. So, tothe pulpit we go, ready to preach a sermon so desperately in need of being heard, and to whichheed should be taken.
1
Contents
1 Green Cryptography 3
2 The Cryptographers (Or, AESthetically speaking) 4
Green cryptography1 is a school of thought that observes a natural progression of cryptographic prim-itives, from the moment they’re designed to the moment they’re deployed; it is realized throughrecycling, where design strategies, components, and primitives, are recycled, supported by a twofoldargument: Firstly, if we are comfortable, cryptanalytically-speaking, with a design strategy, compo-nent, or primitive, we should attempt to recycle it. This makes sense, because the most compellingreason to use a design strategy, component, or primitive is that it has “earned its bones,” cryptanalyt-ically. Secondly, to ensure the simplicity of implementations, we should recycle primitives, wheneverand wherever possible. This also makes sense, because complexity is the culprit behind nearly allinstances of cryptography failing in practice. Concisely, recycling-based green cryptography is aboutmaximizing confidence in cryptographic primitives while minimizing complexity in their implementa-tion. A concept of practical heft, we’d say.
In the first section of this essay, we look at green cryptography from the perspective of cryptog-raphers, who, despite having certain design criteria to meet, can be quite liberal in choosing whatthey recycle and how they recycle it, be it design strategies, components, or primitives. This portraysthe more voluntary aspect of recycling, where most everything is at the cryptographer’s discretion.In the second section of this essay, we look at green cryptography from the perspective of developers,who are often bound by policies that dictate which cryptographic primitives they can, and cannot,use; needless to say, this often means sticking to standards and standards only. This portrays theinvoluntary aspect of recycling, where neither cryptographers nor developers, despite their ability toinfluence, get to choose what becomes a standard.
Fortunately, the poster child for good recycling at work happens to be a standard – the AES.From being the brainchild of Vincent Rijmen and Joan Daemen, to its ratification by NIST as astandard, to its current role as the most cryptanalytical-attention-grabbing block cipher in use today,it’s an attractive solution, and one that was tailored to fit into numerous environments. Of course, wehave no qualms about potential niche applications with environmental constraints for which anothersecure block cipher may be more suitable. For the sake of this essay, though, we’re going to focus onthe AES, the cryptographic primitive behind it, Rijndael, the components of which it is composed,and the design strategy on which it all rests. Not only that, but we’re going to serve an algorithmicappetizer to show you the right way to go about recycling the AES for both symmetric messageencryption and message authentication, in order to achieve the strongest notions of confidentialityand integrity, with implementation simplicity in mind.
Recycling is a grand concept, and what it can do for an environment is worth the effort in doingit. We recycle for a cleaner ecosystem, and most everyone “gets it,” from those who design recyclablesto those who end up using them and tossing them in the recycle bin. Of course, we could do a lotbetter2, but most of us are aware of what happens when we do and what happens when we don’t.In cryptography, it’s much the same; we recycle for a cleaner cryptosystem. It’s a process that takesplace from “conception to cellophane,” and one that preaches the fruits of mature (i.e., security)and minimalist (i.e., simplicity) cryptography – cryptosystems that achieve the strongest notions ofsecurity while being gutted of all the “unnecessaries.”
On the cryptographer side of things, green cryptography is about fostering the maturation of1And so another term enters the cryptographic lexicon.2A gigantic understatement, we know.
3
cryptographic design by recycling design strategies, components, and primitives. On the developerside of things, green cryptography is about doing a lot with a little, and recycling mature primitiveswhenever and wherever you can. Less is more! Simplicity is king! Cryptographic design boasts animpeccable track record – arguably the best out of all the layers of the proverbial security onion.Tragically, cryptographic deployment isn’t following suit, which is evidenced by all of the cryptosys-tems that fall apart, due to excessive complexities. Green cryptography is our effort in educating andconditioning all those involved in the birth of a cryptosystem, so the paradigm of recycling can befully realized.
2 The Cryptographers (Or, AESthetically speaking)
First, it’s the cryptographers turn. They engage in three primary levels of recycling: design strategies,components, and primitives. In the following subsections, we’ll break each level down, with an emphasison how cryptographers recycle design strategies, components, and primitives, within the context ofthe AES.
2.1 Recycling Design Strategies
For a cryptographer, this is the “game plan.” Before the components are formed and the primitivesnamed, a design strategy is hatched. The design strategy lays out how components will be shaped, inorder to meet specific cryptographic goals; that is, to ensure resistance against specific cryptanalyticaltechniques, such as linear cryptanalysis (in the known-plaintext attack model) and differential crypt-analysis (in the chosen-plaintext attack model). In particular, we like the wide trail strategy [1, 2],which renders efficient round transformations and allows for provable bounds on the correlation oflinear trails and the weight of differential trails. In other words, the goal of this strategy is to provideprovable security against linear and differential cryptanalysis, while achieving high performance on amyriad of platforms.
The predecessors and successors of Rijndael, and even stream ciphers and hash functions, havelatched onto this strategy – a culmination of conservative design, across the board. It’s a recipe forbuilding a primitive that facilitates analysis such that security properties are easily captured, whilenot sacrificing its ability to perform, and perform well, most everywhere you throw it.
2.2 Recycling Components
Most folks are familiar with the colorful, animated names3 that are given to primitives, but don’tthink about the guts that lie beneath the epidermis of a name tag. We can look at the compositionof a cryptographic primitive in much the same way as we look at the composition of ourselves, inthat we’re both composed of “organs4,” which have been designed to carry out specific functions andachieve certain properties; if they fail to do so, it could jeopardize our survival. It’s no different witha cryptographic primitive. To ensure a “healthy” primitive, cryptographers employ a toolkit’s worth
3Blowfish, Twofish, Serpent, and Square. Lion, Tiger, Shark, and a Bear! So many names for us to rhyme, but itjust so happens that we don’t have the time.
4We can’t help but see the parallel between cryptanalysis and a nice, retro-inspiring game of OperationTM.
of techniques for determining the resistance of a primitive’s organs against an onslaught of numerousattacks; this requires the cryptographer to also be a good cryptanalyst, because to know what todo, you need to know what not to do. In other words, to understand security is to first recognizeinsecurity. Cryptanalysis determines whether or not advertised security claims are being lived up to,by looking at individual components, interaction between components, and the composite primitiveas a whole.
While the wide trail strategy selects different components according to separate design criteria,the general focus remains the same for each component: optimize the worst-case behavior. Thisoptimization is approached in two ways: local and global. Local optimization is concerned withbuilding a round transformation for which the worst-case behavior for one round is optimized; globaloptimization is concerned with building a round transformation for which the worst-case behaviorfor a sequence of rounds is optimized. Both of these approaches are used to determine the numberof rounds necessary to provide resistance against linear and differential cryptanalysis; for a securitymargin, more rounds are usually tacked on5. Ultimately, the wide trail strategy allows us to evaluateand select components independently, while providing security bounds for the composite.
Rijndael’s round transformation consists of four transformations, or steps: SubBytes, ShiftRows,MixColumns, and AddRoundKey. With the exception of the final round, which omits the MixColumnsstep, Rijndael recycles them all in a specific number of iterations, or rounds – the number of whichdepends on the block and key length. Recycling components leads to designs with simple descriptions;the benefit of this is two-fold. Not only does a simple description form a more attractive target forcryptanalysts, who will be more inclined to spend time evaluating the primitive, but it facilitatesthe correctness of implementations, which, as you’ll see later on in the essay, is the make-or-breakdictator of cryptography’s ability to do its job in practice. We want the highest level of confidencein a primitive that we can get, and this two-fold benefit of recycling components is a great way to goabout contributing to that.
2.3 Recycling Primitives
When you think of the AES, encryption is usually the concept that comes to mind; after all, it iscalled the Advanced Encryption Standard. However, there’s an equally important concept that theAES can address: authentication. MACs, or Message Authentication Codes, preserve integrity. Twoexamples are CMAC[3], a block cipher-based MAC that was built to accommodate the AES as itsunderlying primitive, and EAX[4], an integrity-aware mode of confidentiality, which not only takescare of message authentication, but message encryption, as well. Not only can we recycle primitivesfor different purposes, such as encryption and authentication, but we can also recycle primitives in thedesign of new primitives. As for recycling the AES in block ciphers and MACs, we say, “Feel free.”Heck, even stream ciphers are taking notes![5]
2.4 The Family Tree
To further our chances of getting that “Oh! I had no idea recycling was that big of a deal” reactionfrom you, we thought some visuals should be thrown in. With that in mind, we present to you a
5Of course, you’ve got to be careful when you consider margins of security. See §2.5.
pedigree of Rijndael. Inlaws, outlaws, and even the sister’s best friend’s boyfriend’s grandmother’shairdresser – if they recycled something, they’re on some branch of the recycling tree.
Figure 1: Family tree of cryptographic primitive recycling.
In Figure 1, we see two essential elements of Rijndael that have been recycled numerous times.The first element is the branch number; this concept was proposed in 1995 as a measure for thediffusion quality of a map. From this came the MDS-based diffusion, pioneered in SHARK, whichlater evolved into two-step diffusion as exhibited in Square. And then there’s the S-box based oninversion in a finite field; it’s because of its superior nonlinearity that it has been recycled over andover again.
This pedigree of Rijndael’s predecessors, successors, and other other related primitives – blockciphers, stream ciphers, and hash functions – shows around a decade’s worth of recycling, whichmakes it evident that recycling is a viable design paradigm, and one that’s well established andliberally applied.
6
2.5 Limitations of Recycling
While the wide trail strategy can certainly be recycled in the design of hash functions, as exhibitedin the designs of both Whirlpool[6] and Maelstrom-0[7], recycling the AES in hash functions ismet with uncertainty. Truth be told, we don’t know enough about what constitutes good criteriafor designing cryptographically-secure hash functions. Furthermore, there’s a significant difference toconsider. Hash functions don’t have secret keys; block ciphers do. Given that, a block cipher used ina hash function should be secure in situations where the key is not secret. Unfortunately, there aren’tany good methods for evaluating the security of a block cipher when a cryptanalyst knows the key.Fret not, though; cryptographers are working on it, and we’re hopeful that the in-progress SHA-3competition will be a prime catalyst for generating answers in this matter. In fact, quite a few ofthe candidates have recycled the AES in some way, so we’d say the conditions for answers are quitefavorable. And with that, we give you a pedigree of SHA-3 candidates that recycle from the AES.
Figure 2: Pedigree of SHA-3 candidates that recycle from Rijndael.
In Figure 2, to show the continued viability of recycling, we look at a bunch of SHA-3 candidatesthat look to AES for structural advice, and, with a Wikipedia-styled “[citation needed],” it has beensaid that the AES is the real winner of the SHA-3 competition, due to how much the SHA-3 candidates
Mmm. Security margins. It’s this one metric that’s predominantly responsible for the “preferencebattle” between Rijndael, Twofish, and Serpent; it’s a battle with regiments spanning forums galore.“Serpent has the largest margin of security, so it’s the most secure,” says a zealous advocate of thetank-of-a-block-cipher that Serpent is. First things first; neither this section nor this essay is anti-security margin. The concept of a security margin is quite useful as a design metric, but it’s usefulnessis bounded by its limitations; to get the most out of it, it pays to be aware of them. Don’t assumethat a block cipher with the most rounds is the most secure; it’s not as easy as a round-measuringcompetition.
Suppose we have two block ciphers, A and B. A is a Feistel, while B is an SPN. There’s atruncated differential attack on A that covers 7 of its 10 rounds and a higher-order differential-linearattack on B that covers 20 of its 40 rounds. On the surface, we might say that B is stronger than A,because it still has 20 rounds left untouched, whereas A is only 3 rounds shy of a full break. On theother hand, this assumption starts to lose foundation, when you consider that we’re talking about twoblock ciphers based on different structural designs, employing two different round transformations,and analyzed under two different attack models. It could very well be the case that extending theattack on B ’s 20 remaining rounds is easier than extending the attack on A’s 3 remaining rounds;then again, maybe it’s the other way around. The number of rounds in question isn’t conclusive; itall depends on what’s going on inside the round transformation.
To further support this point, let’s look at an aspect of Rijndael’s round transformation thatoutscores the round transformations of Twofish and Serpent, respectively: full diffusion. First, Twofishis a Feistel network, unlike Rijndael and Serpent, which are Substitution-Permutation Networks (SPN).With a Feistel, each bit of a plaintext block is modified at least once, after two rounds. Because ofthis, we need to introduce the notion of a cycle, where one cycle equals two rounds, in the case of aFeistel, and one round, in the case of an SPN, which allows us to compare Feistels and SPNs. Easyenough. Rijndael achieves full diffusion after two rounds, while Serpent achieves full diffusion afterthree rounds, with Twofish pulling in last, by achieving full diffusion after four rounds. Here are sometables to cast a perspective light on these numbers:
Table 3: Figures reflect necessary number of cycles (rounds) to achieve 5 full diffusion steps.
In Table 1, the block ciphers are set at their defined number of rounds – Rijndael, 10; Twofish,12; and Serpent, 32 – assuming a 128-bit block length and key length; this assumption applies to alltables. Obviously, Serpent’s juggernaut-of-a-round-count brings it out on top. In Table 2, the blockciphers are set to 10 rounds, showing the number of full diffusion steps achieved. In Table 3, the blockciphers are set to the necessary number of rounds in order to achieve 5 full diffusion steps. In Tables2 and 3, the efficiency of Rijndael’s round transformation is obvious.
3 The Point of Diminishing Returns
Bear in mind that all measurements of security margins are valid only for the attacks that we knowabout now. Adding more rounds for the sake of a larger security margin sounds a bit like buildingdikes or levees a bit higher, to withstand an increase in water level. Unfortunately, it doesn’t work inthe same deterministic way. Sure, if future cryptanalytical methods are a lot like the cryptanalyticalmethods of today, but perhaps a little better, then those block ciphers that padded themselves withextra rounds will profit. On the other hand, if these future attacks are completely different, then wehave no way of gauging which block ciphers have the largest security margin at the present.
Revisiting a tried-and-true analogy, look at the block cipher as a house that you’re trying toprotect against a burglar. Since we have a lot of experience with securing doors, we might put multiplelocking mechanisms in place; hopefully, they will thwart the burglar’s attempts by outsmarting hislockpicking capabilities. This may work, but only if we assume that the burglar will only try to pickthe locks. What happens if he decides to climb through the window or descend from the chimney?Ultimately, our security margin depends on burglars not getting much better at lockpicking in thefuture; if they get better at some other means of entry, then we’re out of luck.
And then comes convenience. In practice, security and usability must strike a balance; otherwise,it might turn into a “versus.” Tragically for us, as cryptographers, convenience trumps security all too
9
often. After a (short) while, 15 locks on our front door will become more cumbersome than they’reworth; this is why we don’t do it in the first place (setting aside that this is probably a lousy use ofsecurity dollars anyway). When designing primitives, we’re often faced with the task of designing themsuch that they fit and perform well in a variety of architectures. Some applications will impose verytight constraints, and it’s applications like this that often answer the question, “How much securitymargin do I want and can I afford it?”
Just as a bulky primitive may sacrifice its implementability for extra security margin padding,so will any security feature be ditched if its users find the overhead too much of a hassle. It’s notthat security margins are a bad idea; it’s certainly wise to be conservative. Just as well, though, itneeds to make sense in context, because practical cryptography is often dictated by non-cryptography– and even non-security – issues. For security to be at its optimal game, it needs to do its job astransparently as possible. Don’t be too noticeable. As consumers of security, we’re willing to maketrade-offs, but only if it doesn’t hinder our ability to live out the human condition as we see fit.
4 The Developers (Or, Alice tutors Bob)
Now, it’s the developers turn to pick up where the cryptographers left off, by recycling primitives.With a bit of comedic relief from Alice and Bob, we’ll look at why developers should recycle, twofundamental goals they should be concerned with – confidentiality and integrity – and how to goabout achieving those goals through recycling.
4.1 Recycling: It’s good for the ecosystem, and your cryptosystem.
With a cryptographic palette full of block ciphers to choose from, you might find yourself wonderingwhich to use. The answer is simpler than you might think: Use the AES[8, 9], unless there areconstraints that don’t allow you to. (A possible exception would be niche applications that imposeenvironmental constraints for which another block cipher is more suitable.) The most compellingreason for using the AES is based on what happens as a result of being a standard - it receivesmore cryptanalytical attention than any of the other AES finalist candidates, which gives us a solidcryptographic position on recommending it. Not only that, but it fits in with the engineering principleof “recycling primitives.” Oh, and we don’t want to hear any of that “I need other block ciphers justin case the AES is broken” sputter; the odds that you’ll make an implementation blunder are a stackof magnitudes greater than the surfacing of a practical attack on the AES. So, here’s something weask of you: Unless you absolutely cannot, use the AES. “What’s so holy about the alliancebetween the AES and recycling primitives?,” you might question. Alice, you take it from here.
“Hey Alice, I picked up some things at the Diffie Mart.” “Please tell me you didn’t forget theHellman’s mayonnaise.” “Calm down, Alice. It’s right here.” “Whew. So, what else did you pick up?”“Well, they had a sale on fresh Twofish and Blowfish, so I got a filet of each. Let’s see, I bought a boxof HMAC6 ’n cheese - the SHArp7 cheddar kind. Oh, and while I was in the check-out lane, I saw aMARS8 bar. I know, I know, but I’ve been craving one.” “Bob, why do we need all of that?” “Themore, the merrier, Alice! The more, the merrier!” “Oh Bob, now we have to worry about cooking
6Hash function-based Message Authentication Code.7Secure Hash Algorithm.8IBM’s submission to the AES selection process.
fish, and you know I can’t cook fish. HMAC ’n cheese and a MARS bar? Seriously, Bob. Seriously.Things would be a lot easier on our wallets, and our stomachs, if we just stick with our AES diet. Ithas all we need, and there’s a lot of analysis to back it.” “Can I just keep the MARS bar?” “Bob.”“Yeah, yeah, Alice. You win.”
Bob is a complete smorgasbord addict. To him, more is more, and more is good. What he’s miss-ing is the fact that cryptographic implementation isn’t served well by this way of thinking. Academia-borne cryptographic design has a remarkably good-looking track record, and you’d hope that thiswould carry over to its implementation. Tragically, this is far from the case. In practice, when cryp-tography fails, it’s almost never the cryptography’s fault; if we’re looking to point fingers, we usuallylook in the direction of the implementation. Many developers, like Bob, try to cram in as muchcryptography as possible. Oh yeah. Let’s throw in every block cipher known to Bruce. How about anassortment of stream ciphers and hash functions? How many do you intend to invite to this primitiveparty? If you’re a “Bob,” you might think something along the lines of, “Aren’t more options better?”If you’re an “Alice,” you’ll see that more options lead to more complexity.
The more you attempt to shove into an implementation, the more likely you are to make amistake. And believe me when I say that even the most subtle of mistakes can pack a huge punch.Don’t get caught up in the illusion that you need a lot to do a lot; in fact, you can do a lot with alittle. Less is more. Be resourceful. Reuse what’s already there; that is, recycle. If you can use asingle primitive for multiple purposes, then by all means, do so. Simplify the implementation by usinggood design rationale, because the fruits of your decisions are passed on to the implementation andthe user. Don’t burden the implementation with unnecessary complexities or smother the user witha plethora of configurations, as this is where things usually go wrong.
By using the AES as the underlying primitive in our encryption scheme, authentication scheme,and PRF9, or pseudorandom function, we do our implementation both cryptographic and engineeringfavors. Two birds, one - oh, you know10. You see, by recycling primitives, we not only simplify theimplementation, but we take advantage of the cryptanalysis that the AES has received, in each of theschemes in which we recycle it. This reflects the perpetually mutual relationship between cryptographyand engineering, within the context of recycling primitives, when the correctness and security of theimplementation are at stake. It’s great to know what should be in your toolbox, but that doesn’tamount to much if you don’t know how to use it; this is why you’re probably about to say, “So, guys,we know we need confidentiality and integrity, and we know we can use the AES to achieve both, buthow do we put this all together?” Time to break out the alphabet adhesive.
4.2 If you want confidentiality, you want integrity too.
“Hey Alice. You’re looking splendid, as usual.” “You’re not too bad yourself, Bob.” “I don’t knowabout you, Alice, but I’m feeling a little exposed. Why don’t we put on our matching sweaters thatVincent and Joan gave us? 100% SPN11. How much more elegant can encryption get? The blockpattern is great. Argyle just doesn’t do it for me anymore.” “You’re right, Bob. The length is justright for me, too - 128 bits. But, aren’t you forgetting something?” “We’ve got encryption. Whatmore do we need?” “We might as well go out in our birthday paradox suits, if all we’re wearing is
9Pseudorandom function; the MACs we discuss in this essay, namely the identical OMAC1 and CMAC constructions,are good PRFs, which implies that they’re also good MACs.
10No birds were harmed during the writing of this essay.11Substitution-Permutation Network.
11
encryption.” “I’m not following you, Alice.” “Bob, Bob, Bob. How do we get confidentiality?” “Weuse encryption, Alice. Are you feeling alright?” “I’m fine, Bob, but if you don’t put on your MAC12,you won’t be.” “Wait a minute. If all I want is confidentiality, why are you telling me to put on myMAC? I already checked the forecast and I don’t think I’ll need integrity today.” “You might notthink you’ll need it, but you probably will. Put it on, Bob. Now.” “Okay, okay, Alice. Easy.”
Alice and Bob. At times, it’s all they can do to agree on a key, but Bob’s leading lady is going tosave his ciphertext. If I were to ask you, “How do you achieve confidentiality?,” your retort might alsobe, “That’s easy; use encryption.” And so it goes that confidentiality is all too often the only goalthat’s considered. There’s another goal though, that, if not met, results in grave consequences. Forthose of you who don’t know about it - you probably should; for those of you who know about it, butdon’t think you need it - you’re probably wrong. That goal is integrity, and the consequences for notachieving this goal are often far worse than those for not achieving confidentiality. Now you may bethinking to yourself, “Why does he insist that we need integrity? Okay, so there are consequences fornot having it, but we want confidentiality, not integrity.” The reality is quite the contrary. When wewant confidentiality, the obvious thought is, “we need encryption,” but, realistically, it’s much wiserto say that if we want confidentiality, “we need authentication, too.” If that’s not enough for you,consider that one of these consequences might include losing confidentiality, as well.
In [10], Bellovin cuts to the chase with his cut-and-paste attacks on IPsec, and makes a point,and very clearly at that: “It is quite clear that encryption without integrity checking is all but useless.We strongly recommend that all systems mandate joint use of the two options.” That was 1996. In[11], Vaudenay furthers the case for authentication with his side-channel attacks on CBC padding,with applications to IPsec. By mirroring the work of Bleichenbacher, in [12], and Manger, in [13], inthe asymmetric case, Vaudenay shows that the symmetric case is just as vulnerable to these types ofside channels when an adversary is able to distinguish between valid and invalid ciphertexts. In [14],Black and Urtubia extend this work, in a more efficient manner, and conclude that “perhaps it is timeto view authentication as a strongly-desirable property of any symmetric encryption scheme, includingthose where privacy is the only security goal,” and that “the way to prevent all of these attacks is toinsist on integrity of ciphertexts13 in addition to semantic security14 as the ‘proper’ notion of privacyfor symmetric encryption schemes.” That was 2002 – six years later.
Some folks mistakenly look at ciphertext as plaintext that has been sprayed with OFF! repellent,such that any curious, malicious mosquitoes (malsquitoes, if you will) would be quickly deterred fromany potential attempt at latching on. Unfortunately, S. C. Johnson & Son isn’t in the cryptographybusiness, and even when using a good block cipher confidentiality mode of operation, such as CTR orCBC, ciphertext is still malleable. Yet, here we are in 2009, another seven years later, reviving thepioneering work of yesterday, with the “in the times” updates of today, begging, pleading, preaching,and near bullying, all for one cause. You say confidentiality is what you want – not integrity. We’retelling you that if you want the former, you better have the latter. In short, if you don’t want it –tough. Use it anyway! Confucius says. Simon too. Jantje zegt. O mestre mandou. Alright, theydidn’t, but we’re pretty sure they could be easily convinced.
Meet MAC, otherwise known by its full name, Message Authentication Code. If you’ve already met,it won’t hurt to get to know each other a little better. Laymanizing this as much as possible, a MACachieves the goal of integrity; if an adversary attempts to manipulate ciphertext, a MAC detects it.You feed the MAC a shared secret key and a message of arbitrary length, and it spits out a tag. Let’ssay Alice is sending a message to Bob. She’ll encrypt it, then compute a tag on the ciphertext15[15, 16],of which it will accompany on its way to Bob. When Bob receives the message, he recomputes a tag onthe ciphertext, using the same shared secret key, and compares it with the tag that accompanied theciphertext. If the tags match, the integrity of the message has been preserved; if not, the ciphertexthas probably been tampered with.
When we’re ready to put this wisdom into action, we might, for example, recommend CMAC16
for message authentication schemes; it’s a MAC that uses a block cipher as its underlying primitive.This allows us to use the AES17, which we already like to use for message encryption. Why do welike the AES and why do we want to use it for both encryption (i.e., to achieve confidentiality) andauthentication (i.e., to achieve integrity)? Well, go pour yourself a glass of your poison-of-choice18,then sit back down. There’s more crypto-sorcery to come.
4.2.2 Use the AES: It Comes With The Standardized Territory
Once more, we want to reinforce our recommendation of using the AES. Take the foremost cryptogra-phers from all corners of this planetary marble we call Earth, throw them together into a free-for-all,and you’ve got yourself one big cryptographic shindig bound to churn out something good. Untetheredaccess to the best of the best – a cryptographic primitive can’t ask for much more. Such cryptanalysiswasn’t limited to the AES selection process, however; in fact, once the Rijndael became a standard,it became a target, and the most popular one at that, marking the beginning of ongoing cryptana-lytical bombardment that won’t cease. The AES carried an enormous burden, and one that policieseverywhere will require it shoulder on its own.
In such a case, the reasoning behind recommending the AES becomes as clear as it is simple;after all, it’s receiving more cryptanalytical attention than any other block cipher. We can’t think ofa more compelling reason to recommend a cryptographer primitive. Fielded designs should be designswe’re comfortable with, and in whose structure we have confidence. What we want developers to takefrom this is that they shouldn’t look at implementing the AES as merely “policy;” they should look atit as being prudent. We’ve been blessed with a healthy standard. Embrace it, whenever and whereverpossible.
4.3 Putting it together with cryptographic Elmer’s
It’s not enough to know the goals you want to achieve, or even the tools necessary for achieving them,if you don’t know how to use the tools. Whenever cryptographic implementations fall apart, it’s often
15For cryptographic reasons, as examined in [15, 16], we recommend computing a tag on the ciphertext, instead ofthe plaintext.
16Block cipher-based Message Authentication Code.17Advanced Encryption Standard.18Ours happens to be sweet iced tea.
because the developer had the right idea, and the right tools, but failed to correctly and securelyrealize it. We’ve helped you define the right goals, given you the tools to achieve them, so now let’sbreak out the cryptographic glue you’ll need to stick it all together.
4.3.1 Authenticated Encryption Via Generic Composition
By now, we’re going to assume that you understand the goals of confidentiality and integrity, as wellas the mantra of, “If you want confidentiality, you want integrity too[17].” We’re going to lay out asimple framework for achieving these two goals through a generic composition of message encryption,to address confidentiality, and message authentication, to address integrity.
Simply put, we’re dealing with two base schemes: Message Encryption (ME = (Ke, E , D)) andMessage Authentication (MA = (Ka, T , V)). ME=(K, E ,D) is the authenticated encryption schemeobtained by composing ME and MA in the Encrypt-then-Authenticate composition19.
You’ll probably notice that we’ve chosen to encrypt first, then authenticate; this is crucial, be-cause it’s the only generically secure composition, in the sense that it’s secure for all possible secureinstantiations of its constituent primitives. Being secure from all angles, it’s the least error-prone,and anything that makes it easier for developers to get right is a gigantic plus. Not only that, but itallows us the ability to achieve the strongest notions of confidentiality and integrity: IND-CCA2 ∧INT-CTXT.
Algorithm K Algorithm E(Ke||Ka,M) Algorithm D(Ke||Ka, C)
Ke$←− Ke C ′ $←− E(Ke,M) Parse C as C ′||τ ′
Ka$←− Ka τ ′ $←− T (Ka, C
′) M ← D(Ke, C′)
Return Ke||Ka C ← C ′||τ ′ v ← V(Ka, C′, τ ′)
Return C If v = 1 then return M else return ⊥.
The premise is simple: Key generation algorithm, K, is used to derive both encryption key, Ke,and authentication key, Ka. Alice encrypts a plaintext message, M , using encryption algorithm, E ,with encryption key, Ke, yielding the ciphertext, C ′. She then computes a tag, τ ′, on the ciphertext,C ′, using tagging algorithm, T , with authentication key Ka. She appends the tag, τ ′, to the ciphertext,C ′, yielding the tagged ciphertext, C, which she sends to Bob. Bob parses C as C ′||τ ′. He thenverifies the ciphertext, C ′, using verification algorithm, V, with authentication key, Ka. If the tag hecomputes matches the tag, τ ′, that Alice sent along with the ciphertext, C ′, he proceeds to decrypt theciphertext, C ′, using decryption algorithm D, with encryption key, Ke, thus returning the plaintextmessage, M (i.e., if v = 1 then return M , signifying a valid ciphertext); if it doesn’t match, theciphertext is discarded (i.e., else return ⊥, signifying an invalid ciphertext).
19In [16], the authors refer to this as “Encrypt-then-MAC”, which is equivalent to our “Encrypt-then-Authenticate.”We made this alteration in order to better coincide with our base schemes of Message Encryption, ME, and MessageAuthentication, MA; as such, their notation for Symmetric Encryption, SE, and the MAC key, Km, becomes MessageEncryption, ME, and authentication key, Ka, respectively. However, there is no change in the meaning of the notation,so please refer to [16] for a detailed look at this composition and its associated security proofs.
4.3.2 Authenticated Encryption Via Integrity-aware Modes
What if we had a single, self-contained mode of operation, that addressed both confidentiality andintegrity? You’re in luck; we do. Confidentiality modes of operation, such as CTR20, are, well,confidentiality-only; they do nothing for integrity. With an integrity-aware mode of operation, you’regetting integrity preservation on top of confidentiality preservation. Two birds, one – there’s reallyno need to call PETA21. Oh, and such modes are often designed to directly achieve IND-CCA2 ∧INT-CTXT security. A prime example of this is EAX[4], a mode for authenticated-encryption withassociated data, or AEAD, where associated data refers to information that you wouldn’t encrypt, suchas a packet header. (On the other hand, while this associated data may not require confidentiality, itis often needed for the sake of authenticity.) It’s a two-pass scheme, meaning that encryption is takencare of in the first pass, while authentication is handled by the second pass.
What’s particular nifty about EAX is that, if you were to peer below its epidermis, you’d see ageneric composition, known as EAX2; in fact, it uses CTR mode for confidentiality and OMAC122 forintegrity, with the latter being equivalent to CMAC. While a generic composition uses two separatekeys – one for encryption and one for authentication – EAX2 collapses two keys into one. If you’repartial towards generic composition, you really can’t go wrong with EAX2; if you’re in the market foran integrity-aware mode of operation, you really can’t go wrong with EAX, either, given that EAX2makes up its guts. As far as authenticated encryption is concerned, cryptographers have ensured thatyou’re well covered, and efficiently so. We’re taking out more birds than even Hitchcock’s imaginationcould summon.
4.3.3 Juxtaposing generic composition and integrity-aware modes
In a generic composition, the encryption and authentication schemes are separated, and applied in anarbitrary order; in our case, we’ve chosen to encrypt first, then authenticate. As these schemes handletwo different conceptual goals – confidentiality and integrity – it makes sense, aesthetically, to applythem separately; in turn, this makes the correctness of the implementation more clearly defined, whilemaking it more flexible, as well. With an integrity-aware mode, encryption and authentication arewed together into a single mode, which requires a lot less from the developer, in regards to thinkingabout encryption and authenticate separately; instead, the developer thinks about one mode that doesit all. This could very well makes mistakes less likely. Aside from these cryptographic and engineeringobservations, there are performance attributes to take into consideration. One of the most obvious ofthese attributes is exemplified through EAX, which, for example, collapses two keys into one, while ageneric composition requires two keys; this saves on key material and key-setup. When all is said anddone, you can get IND-CCA2 ∧ INT-CTXT security with either. You can do either securely, so don’tbe afraid to consider the advantages of whichever may be especially well-suited to your environment.
20Counter mode.21Refer to 3 for reassurance. Cryptographer’s honor.22One-key Message Authentication Code.
Going into the “whys” of this is far beyond the scope of this essay, but in short, when we toutthe importance of authenticated encryption, below that generality lies what we really want: IND-CCA2 ∧ INT-CTXT security – the two notions of security that capture the strongest notions ofconfidentiality and integrity. To achieve this, we need an IND-CPA encryption scheme and a SUF-CMA authentication scheme, in the Encrypt-then-Authenticate composition; within the context ofrecycling the AES, this could be something along the lines of first encrypting with AES-CTR, thencomputing a MAC on the ciphertext using AES-CMAC.
5.2 Brief definitions, or “Briefinitions,” if you will.
We’ve thrown several attack model acronyms at you, without any definitions, thus far, and with goodreason: We want to spare you from the math. In the interest of not keeping you completely in thedark, here are some brief definitions, or “briefinitions,” if you will. If you’re looking for directions tothe Carnaval de Matematica23, consult the references we’ve provided – especially the work of Bellareand Namprempre, in [16].
In a chosen-plaintext attack (CPA), the adversary has access to an encryption oracle, whichhe will query with arbitrary plaintexts to be encrypted, with the corresponding ciphertexts beingreturned; the adversary is allowed to make multiple, adaptive queries based on information gainedfrom previous encryptions. IND-CPA security means that the adversary is not able24 to distinguishbetween the encryptions of different messages, even if he has the ability to make arbitrary encryptions.
In an adaptive chosen-ciphertext attack (CCA2), the adversary also has access to a decryptionoracle, which he will query with arbitrary ciphertexts to be decrypted, with the corresponding plain-texts being returned; the adversary is allowed to make multiple, adaptive queries based on informationgained from previous encryptions or decryptions. IND-CCA2 security means that the adversary is notable to distinguish between the encryptions of different messages, even if he has the ability to makearbitrary encryptions and decryptions.
To have integrity of ciphertexts (INT-CTXT), the adversary must not be able to produce aciphertext that was not previously produced by the sender, regardless of whether or not the underlyingplaintext is “new.” The adversary is allowed to mount a chosen-message attack. For a MAC to bestrongly unforgeable under a chosen-message attack (SUF-CMA), the adversary must not be able tofind a new message-tag pair, even after a chosen-message attack. Note that any PRF is a SUF-CMAMAC.
To recap, when considering authenticated encryption schemes, it’s common to think of it in termsof coupling an integrity notion, like INT-CTXT, with a confidentiality notion, like IND-CPA. Let’ssuppose our authentication scheme meets the criteria for INT-CTXT ∧ IND-CPA. INT-CTXT ∧IND-CPA → IND-CCA2 (Read → as “implies.”), which means that our authenticated encryptionscheme is IND-CCA2 ∧ INT-CTXT secure – exactly what we want. Apply a SUF-CMA MAC, likeAES-CMAC, to the ciphertext of an IND-CPA secure encryption scheme, like AES-CTR, or, use an
23When in need of spice, reference Brazil.24Read “is not able” as “computationally infeasible.”
integrity-aware mode built to achieve IND-CCA2 ∧ INT-CTXT security directly, and you get justthat.
5.3 Mathematicians versus Cryptographers
CTR, OMAC1, CMAC, and EAX carry proofs of security that depend on the underlying block cipherbeing a secure PRP, or pseudorandom permutation. Furthermore, they’re components in genericcompositions and integrity-aware modes of operation that are proven to be secure in the sense ofIND-CCA2 ∧ INT-CTXT. But, we can’t toss in a term like “proof,” without sprinkling in a littleon the heated debates hanging heavily around it, like gold around Mr. T. Unfortunately, “provablesecurity” has been juggled a bit too carelessly by some and misunderstood by others, so the opposition’ssentiment[18] is understood. They’re not absolute proofs of anything, so don’t stretch them that far.
Look at them as rigorous proofs, given in the context of information security. Practical conse-quences aren’t guaranteed. We’ll call on the automobile industry for an analogy. A car is advertisedas getting x miles per gallon (MPG), and under certain, well-defined laboratory conditions, it will dojust that. This is a rigorous number, obtained in a reproducible manner (like a consumption proof).However, if you were to, let’s say, drive in the city, over the hills, up the mountains, or with a leadfoot – any real-life environment – the car will consume more – sometimes vastly more. You might beled to believe that the MPG figure is inaccurate or lacking mathematical soundness; this is certainlynot the case. It’s accurate science, and in the ideal world, it works perfectly; it’s in the real worldthat its impact is limited. Obviously, in regards to security proofs, there’s a need to better gauge thebalance between our expectations and their limitations.
Despite all of the opinionated back-and-forth, when the dust settles, we’re of the mindset thatprovable security is a useful cryptographic design metric. Security proofs are a good “sanity check,”if you will. They make it easier to hone in on potential design weaknesses, which, believe you me, cansave you from the most brain-jangling of cryptographic migraines. Yes! That’s right! Real systemscan fail[10, 14] for not taking adaptive chosen-ciphertext attacks into consideration! Proper integritypreservation, through the use of a MAC (Aha!) or integrity-aware mode (Aha Part Deux!), addressthese attacks.
One could, and probably should, write a book about provable security and its cans and cannots,but we’ll leave you with this to consider: “Cleanliness” is a desirable attribute for making analysiseasier, from design to deployment, and provable security is a proponent of that. It’s easier to design agood system if you can clearly define your goals and assumptions, and justify your design claim, suchthat if the assumptions hold, your system meets the goals. Ad hoc approaches won’t pass the musterin this department. Now, place your bets. We know where ours will be.
6 From Developer to Implementation to User
With implementations like loose slacks, we’ve got a belt, yet we can’t seem to put it on right. De-velopers don’t need to spend so much time worrying about which block cipher and key length to use;this is likely to be the easiest part of your decision-making process. Cryptography is like that goodstudent in class, always doing what you ask of it, and doing it well. In other words, your attentionis direly needed elsewhere; rest assured that cryptography won’t be the first to misbehave. Sear this
into long-term memory: Cryptography is only as effective as the implementation allows it to be, sothe logical path to better odds in getting it right is to simplify the way developers look at it. It followsthat the implementation, and essentially, the user, are at the mercy of the developer’s decisions. If thedevelopers aren’t given the heads up, things start to look pretty bleak as you travel from developerto implementation to user.
If you get it right, cryptography will be good to you. We’ll go so far as to say that it’s likelythe most dependable part of your system. (If cryptography is the weakest part of your system, you’redoing incredibly well. Teach us.) While we tout the simplification of cryptographic design decisions,cryptography isn’t paint-by-numbers simple; it can be downright difficult. So, if you take anythingfrom this essay: Don’t do cryptography without a cryptographer on board! Be that the exhortationof our careers. There are some things that we can’t do, so we call a professional. For instance, youwouldn’t perform a root canal on yourself; you’d trust this procedure to a dentist. (At least, we hopeyou would; if you’ve ever done this yourself, you’re probably Chuck Norris or his offspring.)
On the other hand, there are some things we could probably learn to do ourselves, with a littletime and patience, yet we still often call a professional. Take painting a room or installing ceramicfloor tile, for example. What are two DIY projects are more easily outsourced. Besides, by having anexperienced someone do the job, you reduce the likelihood of mistakes happening, which, as you knowby now, is exactly what cryptographic implementation counts on – reduced likelihood of mistakes.Why is it that folks trust professionals to do jobs, both PhD-only and piece-of-cake, yet they chance thefantasy that they can take on the intricately artistic and scientific nooks and crannies of cryptographicdesign?
Although we’d like to tell you that educating developers on how to properly implement cryptog-raphy will solve the issue, this is where the bad news comes in. It’s not enough that developers knowhow to use the tools properly. First, they need to know which tools they should be using; this is whatwe know as threat modeling. It’s where a good design begins, so you’d better get it right, becauseeverything thereafter depends on it. Look at this as the digital analog of a physical structure’s foun-dation; everything else will collapse under the weight of a failure to threat model properly. Riskingthis without know-how is risking it all.
While the correctness and security of an implementation dictates whether or not the cryptographycan do its job, the threat model dictates which cryptography is right for the job, and it requires whata cryptographer’s forte delivers. We can educate developers to a certain extent, but, after all, reachingsecurity is first recognizing insecurity. Knowing what to do requires knowing what not to do. And, letus be the first to tell you - this takes a certain kind of expertise that’s born of experience, experience,and more experience. There’s no substitute for having a cryptographer on hand.
The reality is that we don’t need better cryptography; we need better implementations. The morewe simplify the way developers approach cryptography, the simpler, and better, the implementationswill be. There’s an enormous gap between cryptographers and developers, and education is one of theways we can lessen it. Whaddya say? We’re game if you are.
7 Conclusion
Educating developers is a solid effort in mitigating the potential hazards of implementing cryptography,but it’s far from a panacea; if anything, it’s a small, but worthwhile, piece of weaponry in this
18
“war on incompetence” (don’t mind the parallel of political satire). Bear in mind that much of thecryptographic software you see is the product of software vendors. Not cryptographers. Not evensecurity folks. Without a cryptographer close by, or a well-versed-in-cryptography security expert, atleast, you’re placing your bets on software vendors to establish the right threat model; it’s a crapshoot,really, and the odds aren’t in favor of the consumer.
We’ll also take a moment to mention the open-source versus closed-source debate. “Open-sourceis inherently more secure,” preach some open-source zealots. Wrong; inherently, it’s no more securethan closed-source. Open-source proponents dwell on the idea that the more eyes you have looking,the more secure the implementation will be; in reality, it’s not about how many eyes are looking– it’s whose eyes are looking. (To establish a case for this, imagine a commercial entity that hasthe financial resources to hire a cryptanalyst to analyze their closed-source product, while a similaropen-source project, although boasting a lively community, hasn’t the resources to get the right pairof eyes looking at their code.) It’s all about potential, and we are certainly all for the open-sourcemodel as the most potentially secure.
Openness has always been the pulse of cryptographic design, and we should expect nothing lessfrom its implementation. It’s important to understand, however, that openness works in cryptographicdesign, because, well, cryptographers and cryptanalysts are the ones doing the designing and analyzing.When it comes to implementing cryptography, it’s usually non-cryptographers behind the scene, soit’s simply not enough to open the source – you’ve got to point the right people to it. We say, “Keepit open,” but, just as importantly, realize that opening it doesn’t mean they’ll come; it might haveworked for Ray in Field of Dreams, but you’re most likely going to have to find them.
While we only skim the surface of what needs to be considered, this essay will have done its jobif it steers developers towards more fruitful cryptography, through mature and minimalist design. Wehope that you’ll add these tidbits to your arsenal of design philosophies, and wield them liberally, thenext time you’re faced with implementing things cryptographic. It’s about time that the instantiationof cryptography reflects the decorated heritage that decades of academic research have begotten. Onbehalf of Alice and Bob, we bid you farewell and better cryptography. Oh, and allow us to stress,once more, a point so dear to our cryptographic hearts, in a Ray Parker Jr. slash Ghostbusteresquetone: Who you gonna call? Cryptographers! We ain’t ’fraid of no crypto.25
8 Because One Conclusion Isn’t Enough
Such a bugbear of an issue, this complexity, that we were muscled into verbosity. As this essay mightsuggest, we’re pretty hardcore when it comes to cryptography, but we realize that cryptography isusually the strongest link of any system; when things go wrong, this is rarely where it occurs. It’sbecause of the implementation, and complexity is usually the culprit. The more options you have, themore complexity you have; complexity is security’s worst enemy. That’s a given. In fact, had NoahWebster been a cryptographer, we’d probably have this:
Main Entry: com·plex·i·tyPronunciation: \k@m-"plek-s@-te, kam-\Function: noun, enemy
25And so it goes that we’re not paid for our pun.
19
Inflected Form(s): plural com·plex·i·tiesDate: 16611. security’s worst enemy2. the antithesis of security3. an anathema to implementations
And, if we had our way, we’d even employ different languages to emphasize our disdain for complexity:
4. bicho de sete cabecas; bete noire; omethingsay eallyray adbay
Unfortunately, folks tend to overemphasize the application of cryptography. Romanticize, even. Why?Well, it’s sexier. More seems to be better, naıvely, but when it comes to security – cryptographyincluded – less is more. So, developers: Focus on the more problematic areas of security; i.e., notcryptography. Implementing cryptography should be as simple and painless as possible; piling it on isnot the answer. There’s no need to obsess over it; do it right and it will do its job. Besides, it will bethe least of your worries. Security’s effectiveness is dictated by the soundness of its implementation,so each design decision should be implementation-centric – “implementationally benign,” if you will.Infrastructures begat of such design decisions are much more sustainable as they scale, and that’sgood. Really good.
Implementations shouldn’t adopt a Rube Goldberg design strategy, to say the very least. If theprowess of Vincent and Joan can turn a block cipher into a creature of elegance and poise, there’s noreason that its implementation need turn into a byzantine mess of bad decisions. Signing off, takethis as our version of a much-needed cryptographic stimulus package for security decisions – both forthe clean-up of bad-decision aftermath and the influence of those decisions pending. Here’s hopingyou dodge the former. Look at green cryptography as good ergonomics for your cryptoposture.
Ante up for a greener cryptoscape.
9 Acknowledgments
We extend our utmost gratitude to David Wagner, Chanathip Namprempre, Bruce Schneier, PauloBarreto, Eli Biham, and Peter Gutmann, for their indispensable insight and much-appreciated assis-tance in bettering the way developers look at cryptographic engineering. And an extra special thanksto Ludmila Marques Lopes Troutman for breathing graphical life into the concept of recycling. Wealso appreciate the work of Daniel Day-Lewis, who, through his character, Daniel Plainview, taughtus that there is no greater shame to cast upon someone than to drink their milkshake. Be this ourattempt to keep that from happening to you.
20
References
[1] J. Daemen and V. Rijmen, “The Wide Trail Design Strategy,” in Proceedings of the 8th IMAInternational Conference on Cryptography and Coding, (London, UK), pp. 222–238, Springer-Verlag, 2001.
[2] J. Daemen and V. Rijmen, “Security of a Wide Trail Design,” in INDOCRYPT ’02: Proceedingsof the Third International Conference on Cryptology, (London, UK), pp. 1–11, Springer-Verlag,2002.
[3] M. Dworkin, “Recommendation for Block Cipher Modes of Operation: The CMAC Mode forAuthentication.” NIST Special Publication 800-38B, 2005.
[4] M. Bellare, P. Rogaway, and D. Wagner, “The EAX mode of operation,” in Fast Software En-cryption (FSE) 2004, (Berlin, Germany), pp. 389–487, Springer-Verlag, 2004.
[5] S. Halevi, D. Coppersmith, and C. S. Jutla, “Scream: A Software-Efficient Stream Cipher,” inFSE ’02: Revised Papers from the 9th International Workshop on Fast Software Encryption,(London, UK), pp. 195–209, Springer-Verlag, 2002.
[6] P. S. L. M. Barreto and V. Rijmen, “The Whirlpool Hashing Function.” First open NESSIEWorkshop, Leuven, Belgium, 2000.
[7] D. L. G. Filho, P. S. L. M. Barreto, and V. Rijmen, “The Maelstrom-0 Hash Function.” VIBrazilian Symposium on Information and Computer Systems Security – SBSeg’2006, 2006.
[8] “Specification for the Advanced Encryption Standard (AES).” FIPS Publication 197, 2001.
[9] J. Daemen and V. Rijmen, The Design of Rijndael. Secaucus, NJ, USA: Springer-Verlag NewYork, Inc., 2002.
[10] S. M. Bellovin, “Problem areas for the IP security protocols,” in SSYM’96: Proceedings of the 6thconference on USENIX Security Symposium, Focusing on Applications of Cryptography, (Berke-ley, CA, USA), pp. 1–16, USENIX Association, 1996.
[11] S. Vaudenay, “Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS...,” in EUROCRYPT ’02: Proceedings of the International Conference on the Theory and Ap-plications of Cryptographic Techniques, (London, UK), pp. 534–546, Springer-Verlag, 2002.
[12] D. Bleichenbacher, “Chosen Ciphertext Attacks Against Protocols Based on the RSA EncryptionStandard PKCS #1,” in CRYPTO ’98: Proceedings of the 18th Annual International CryptologyConference on Advances in Cryptology, (London, UK), pp. 1–12, Springer-Verlag, 1998.
[13] J. Manger, “A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding(OAEP) as Standardized in PKCS #1 v2.0,” in CRYPTO ’01: Proceedings of the 21st AnnualInternational Cryptology Conference on Advances in Cryptology, (London, UK), pp. 230–238,Springer-Verlag, 2001.
[14] J. Black and H. Urtubia, “Side-Channel Attacks on Symmetric Encryption Schemes: The Case forAuthenticated Encryption,” in Proceedings of the 11th USENIX Security Symposium, (Berkeley,CA, USA), pp. 327–338, USENIX Association, 2002.
[15] H. Krawczyk, “The Order of Encryption and Authentication for Protecting Communications (or:How Secure Is SSL?),” in CRYPTO ’01: Proceedings of the 21st Annual International CryptologyConference on Advances in Cryptology, (London, UK), pp. 310–331, Springer-Verlag, 2001.
[16] M. Bellare and C. Namprempre, “Authenticated Encryption: Relations among Notions andAnalysis of the Generic Composition Paradigm,” in ASIACRYPT ’00: Proceedings of the 6thInternational Conference on the Theory and Application of Cryptology and Information Security,(London, UK), pp. 531–545, Springer-Verlag, 2000.
[17] J. Troutman, “The Virtues of Mature and Minimalist Cryptography (Adapted from, “Alice TutorsBob on Mature and Minimalist Cryptography”),” IEEE Security and Privacy, vol. 6, no. 4,pp. 62–65, 2008.
[18] B. Schneier, “Mathematicians vs. Cryptographers.” Schneier on Security (2007/09 Archive), 2007.
