CFRG S. Halevi (IBM) Internet-Draft H. Krawczyk (IBM) Expires: April 18, 2008 October 18, 2007 Strengthening Digital Signatures via Randomized Hashing draft-irtf-cfrg-rhash-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The IETF Trust (2007). Abstract This document describes a randomized hashing scheme consisting of a simple message randomization transform that when used as a front-end to regular hash-then-sign signature schemes, such as RSA and DSS, frees these signatures from their current vulnerability to off-line collision attacks against the underlying hash function. The proposed mechanism can work with any hash function as-is and requires no change to the underlying signature algorithm. Incorporating this mechanism into existing applications requires changes that are comparable in their complexity to accommodating a new (deterministic) hash function such as SHA-256. Visit http://www.ee.technion.ac.il/~hugo/rhash/ for more information and updates on this work. Halevi and Krawczyk [Page 1]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 1 Introduction The recent collision attacks against popular hash functions have a profound effect on the security of some applications of these functions, most notably digital signatures. In this document we propose a randomized mode of operation for hash functions that when used in conjunction with standardized hash-then-sign signature schemes (such as RSA or DSS) frees these schemes from their current essential dependency on full collision resistance. This mode of operation can work with any hash function and requires no change to the underlying signature algorithms. It consists of a simple message randomization transform, called RMX, which is fully specified in this document and used as a front-end to existing hash-then-sign signature schemes. The analysis in [HK06] shows that breaking a signature scheme that uses RMX requires solving a cryptanalytical problem related to finding second pre-images in the underlying compression function, and hence significantly harder than simply finding (off-line) collisions as in current attacks against standard signature schemes. The full specification of RMX is presented in Section 2. In a nutshell, RMX prepends to the message a random string ("salt") of one block, and then XORs (exclusive-or) the same random string with every block of the message itself (where a "block" is of the length specified by the underlying hash function or, if such block size is not defined by the hash function, it is the length of the salt). That is, if M=(M1, ...,Mn) where the Mi's are message blocks then: RMX(r,M) = (r, M1 XOR r, ..., Mn XOR r). We note that the full specification of RMX includes a simple padding rule for the last message block; also, to save bandwidth and randomness, the scheme accommodates salt strings shorter than a full message block. RMX can be implemented either as a simple front-end interface to the iterated hash function, or it can be integrated with typical implementations of digest functions (in particular, Merkle-Damgard functions such as the SHA family) that read the message block by block and feed these successive blocks into the compression function. RMX can be used with any hash-then-sign scheme by replacing the message M in the original signature scheme with RMX(r,M), i.e., instead of SIG(H(M)) a signature is computed as SIG(H(RMX(r,M))). The salt r is generated for each signature by the signer and transmitted to the verifier together with the message and signature. The verifier uses the regular verification procedure where the original digest function is applied to RMX(r,M) rather than to M. Note that only the signer needs to generate randomness, the verifier receives it with the message/signature. As said, off-line collision search is useless against a signature scheme that uses RMX. Rather, to break the signatures the attacker needs to solve a cryptanalytical problem close to finding second preimages (which is a much harder task than finding collisions, and it has to be done on a Halevi and Krawczyk [Page 2]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 per-signature basis rather than off-line). Importantly, to gain this security advantage the value of r must be unpredictable to the attacker until the full content of the message to be signed is determined; we recommend that the length of r be at least 128 bits. The use of RMX and its application to signatures do not depend on the way the salt r is transmitted; therefore, different applications may choose different ways to transport r. This is analogous to the use of the IV in CBC encryption: the definition of CBC specifies how to use a block cipher to encrypt any-length message given the value of an IV, but leaves it up to the application to decide how to transmit the IV. In Section 4 we report on some experimental implementations of RMX (openssl, NSS/Firefox, and XML signatures), and discuss some options for the transport of the salt in applications using RMX. In particular, we suggest a mechanism that can be shared by applications that use algorithm identifiers (as per X.509), namely, transporting the salt as a parameter of the algorithm identifier. It is important to note that the use of RMX in the context of digital signatures does not require changes in signature standards such as PKCS#1 (RSA) or FIPS 186 (DSS). Furthermore, an important conclusion of initial implementation experience with RMX is that the complexity of implementing and deploying RMX in the context of digital signatures is comparable to the effort needed to upgrade existing systems to use a new deterministic hash function, such as SHA256. Moreover, once the mechanisms are in place to deal with such upgrade (cf. [BR05]), supporting RMX becomes a relatively simple matter (see Section 4 and the references there). We stress that our proposal is not intended as an alternative to the search for new, stronger hash functions to replace SHA-1 and MD5, but it is rather intended to complement this effort by providing a "safety net" for digital signatures in case a hash function in use is later found to be weaker than believed initially. Given our limited understanding of the best ways to build collision resistant hash functions, prudent engineering principles call for building cryptographic primitives that rely as little as possible on the strength of hash functions. Our work addresses this principle in the context of digital signatures and as such it resembles the effect of the HMAC design in the message authentication area. We refer the reader to the paper by these authors [HK06] for a more extensive description and rationale of the design of RMX, as well as an analysis of the cryptographic strength of the scheme (in that paper the scheme specified here, namely, applying RMX to the message before inputting it to the hash function, is referred to as the "eTCR construction"). COMPATIBILITY WITH NIST's RANDOMIZED HASHING PUBLICATION [NIST]. The present document is somewhat wider in scope than [NIST] which defines the same randomized hashing transform but provides less implementation guidance. Also, the specification here of the central RMX transform is slightly more general than [NIST], in particular it Halevi and Krawczyk [Page 3]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 allows for some hash-specific optimizations (especially for Merkle-Damgard and related hash functions). We anticipate that the final specifications of RMX in both documents (here and [NIST]) will be identical. IETF SCOPE. This Internet Draft is offered to the IETF community for consideration for standardization and adoption in protocols whose security heavily relies on digital signatures. The need for randomized hashing is especially acute in applications (e.g., PKIX, S/Mime) where non-repudiation or third-party-verifiability are crucial; however, it is recommended also as a general way of strengthening signatures in other applications. In particular, protocols that support hash agility (newer TLS versions, for example) should make provisions for the future use of randomized hashing (see Section 4 for some implementation guidance). Visit http://www.ee.technion.ac.il/~hugo/rhash/ for more information and updates on this work. 2 The Message Randomization Scheme RMX The RMX message randomization procedure is the core of the randomized hashing scheme and it is specified next. RMX takes as input a message M (to be signed) and a random salt value r, and outputs M', the transformed message that will be input into the hash-then-sign signature module. RMX should be seen as a mode of operation for hash functions, and as such it may depend on some of the parameters of the underlying hash function such as a block length or the hash function's padding mechanism. Specifically, the RMX definition uses two parameters, block_length and pad_length, that may depend on the underlying hash function. The first, block_length, is used by RMX to determine the expansion of the input salt r into an internal salt value r'. RMX sets block_length to the block length of the underlying hash function (e.g., it will be 512 for SHA-256). However, if this hash function does not define a block length (or if this length is less that 128 bits) then block_length is set to the length of the salt value r input to RMX. (This provision for a non-blockwise hash function is due to NIST's desire [NIST] to accommodate any, possibly unconventional, hash function that may emerge in the future.) The parameter pad_length is used by RMX to determine the number of bits with which RMX pads the input message (RMX performs an internal padding in addition to any padding that may be defined by the underlying hash function). In all cases, pad_length is computed as a function of the length of the input message M (we denote this length by |M|) and possibly also as a function of block_length. After the description of RMX below, we present two concrete instantiations of pad_length: a generic function that does not assume Halevi and Krawczyk [Page 4]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 any structure on the underlying hash function (this is the same as the RMX mechanism defined in [NIST]), and a different instantiation that is optimized for Merkle-Damgard hash functions (where a block length is well defined). We expect the latter instantiation to be used with contemporary hash functions such as SHA-1 and SHA-2. (See discussion in Section 5 regarding the security advantages of using the second instantiation when the underlying hash function is a Merkle-Damgard iterated hash function.) Specification of the RMX transform. Parameters: block_length // Length of the internal salt value r' used in the // algorithm pad_length // A function to determine the number L of padding // bits used internally by RMX (depends on |M|). Input: Message M, Salt r // r is random of size at least 128 bits Output: Randomized Message M' // input to hash function and signature 1. Let r' be r concatenated with itself as many times as needed (last copy possibly truncated) to cover block_length bits 2. Let L = pad_length(|M|) 3. Define m to be a message obtained by concatenating the original message M, followed by L zeros and by two bytes containing the number L written in big-endian notation. That is: m = M || 0^L || L 4. Define R to be the a string of the same length as m (i.e., |M|+L+16 bits) composed by concatenating r' with itself as many times as needed (with the last copy of r' possibly truncated) R = (r' || r' || ... || r' || r') truncated to |M|+L+16 bits 5. Define m' to be the bitwise XOR of m and R. That is: m' = m XOR R 6. Define M' to be the concatenation of r' followed by m'. That is: M' = r' || m' 7. Output M' Halevi and Krawczyk [Page 5]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 NOTE: While the description of RMX above treats the input message M as one unit, actual implementations of RMX do not need to buffer the whole message but can rather (as in a streaming scenario) read and process M block by block. The same is true for the output message M' that can be output block by block. This is particularly convenient when inputting M' into a hash function that reads its input block-by-block; in this case the RMX and hash computation can be pipelined. Also worth noting is that since the parameter (function) pad_length depends on the length of M, its value will usually be computed as part of the RMX procedure after the whole message is received. Next, we present two possible instantiations of the parameters pad length and block_length. GENERIC PARAMETERS. This definition can be used with any hash function regardless of its structure or iteration. It corresponds to the current randomized hashing definition in [NIST]. Set block_length = |r| (i.e., r'=r). pad_length is set to: 0 if |r'| <= 16+|M| |r'|-(16+|M|) otherwise. PARAMETERS FOR MERKLE-DAMGARD HASHING. This specification of the parameters is intended for Merkle-Damgard hash functions (and related iterated functions) and it provides the maximal benefits of RMX for such functions (by maximizing the number of random bits XOR-ed to the last padded block). The specification is optimized by setting r' to be of the length of a hash block. We use b to denote this block length and c to denote the number of padding bits added by the underlying hash function (for the so-called MD-strengthening). For example, b=512, c=64 in SHA-256 and b=1024, c=128 in SHA-512. Specifically, in the Merkle-Damgard case we define: Set block_length to b. Let b' = |M| mod b and b''=b'+c+24. pad_length is set to: 2b-b'' if b'' > b b-b'' otherwise (The first case corresponds to the cases where the hash function adds a full new padding block and hence pad_length = (b-b')+(b-24-c); in the other case pad_length = b-(b'+c+24)).) IMPLEMENTATION. As we already said, the definition of RMX allows for an implementation that acts as a simple front-end interface to the iterated hash function, or it can be integrated with typical implementations of digest functions that read the message block by block and feed these successive blocks into the compression function. We discuss more implementation issues in Section 4. Halevi and Krawczyk [Page 6]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 3 Building Signatures using RMX The main purpose of randomized hashing, and specifically the RMX transform, is for use with digital signatures where RMX may preserve the security of the signatures even in the presence of off-line collision attacks. To compute a signature on a message M using the RMX transform with hash function H (e.g., SHA1, SHA2) and signature algorithm SIG (e.g., RSA or DSA) one proceeds as follows (we assume pad_length and block_length are set by the hash function H): 1. Choose a random value r as the input salt for the RMX transform (the length of r may be specified by an application or by the signer itself; in all cases, it has to be in the range [128,block_length]). 2. Set M' = RMX(r,M) according to the RMX message randomization scheme defined in Section 2. 3. Apply H to M' 4. Sign the value H(M') using algorithm SIG to obtain a signature s. 5. Transmit the salt r, message M and signature s to the receiving side. NOTE: For block-based iterative hash functions such as Merkle-Damgard Steps 2 and 3 are block-wise computations and can be interleaved (or pipelined). In these cases there is no need to wait for the full message M' to be computed out of r and M before starting the H computation. In a typical implementation one feeds each block of M into the RMX computation and then feeds the resultant block of M' into the hash function H. The verification procedure is defined similarly to the above: it receives the three elements r, M, s, computes M' = RMX(r,M) and provides the (randomized) message M' and signature s to the verification procedure (as before the RMX and hash computations can be pipelined). Note that the above procedure can be used with any signature scheme that follows the hash-then-sign paradigm including the two major standards: RSA (both deterministic and PSS encoding) [PKCS1] and DSS [DSS]. To support RMX-enabled signatures as above, an application needs to satisfy two requirements: (1) the ability of the signer (not the verifier) to generate the random salt r; and (2) the ability of the application to accommodate the transmission of r. We expect most applications to meet requirement (1), and even more so given the increasing capabilities of computing devices. In particular, most cryptographic applications already require the ability to generate (pseudo) random bits for key generation, IV's, nonces, or Halevi and Krawczyk [Page 7]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 probabilistic signatures such as DSS. Moreover, note that it is only the signer that needs to generate randomness, not the verifier (see Section 5). As for (2), a great majority of applications can afford the sending of a few extra bytes of salt in addition to a message and signature. While different applications can accommodate the sending of the salt in different ways, we discuss a general mechanism that may work for many different application in Section 4. A few more comments are in order here: 1. A receiver of a signature can only start to hash the message after it knows the salt. Hence, in applications where buffering the entire incoming message is impractical, it is necessary to send the salt before the message (rather than with the signature itself that is often transmitted after the message). Also, we stress that an application using RMX must ensure that an attacker cannot choose, or influence, the contents of the message to be signed after seeing the salt. Hence the salt, even if sent before the message, will be sent to the verifier only after the message to be signed has been fully determined. 2. For extremely bandwidth-limited applications, one can sometime save on bandwidth by including the salt in the signature (even if it means sending the salt after the message). For example, with DSS signatures one can re-use the random component r = g^k that already exists in the signature as the hashing salt, thus preserving the original data size. It should be noted, however, that this means that the quantity r = g^k must be computed before computing the message digest (and kept secret until the message with which r will be used is fully determined). In the case of RSA-PSS [PKCS1] an approach similar to DSS can be used to save bandwidth (here the randomness used internally by the signature can be recovered by the recipient of the signature via the RSA-verification operation). The situation is more problematic with the deterministic RSA encoding of PKCS#1 v1.5 [PKCS1]; here the only way to preserve bandwidth is to include the salt r under the signature itself. That is, instead of applying the RSA operation solely to the result of the randomized hash operation one applies it to the concatenation of this result and the salt r. In this way, the recipient of the signature can recover the salt via the RSAverification procedure. This, however, requires a change in the message encoding of PKCS#1 v1.5, and hence less appealing as a general solution. 3. Using an independent salt value has the additional advantage that it allows for the pre-computation of the randomized hash value. That is, one can choose r, compute d = H(RMX(r,M)) and store the triple (r, M, d), such that upon a request for a signature on M one computes the signature directly on the pre-computed d. Also, using an independent salt value supports multi-level hashing which is required, for example, in XML signatures [RMX]. Halevi and Krawczyk [Page 8]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 4. One cannot overstate the importance of not disclosing the value of the salt r before a message to be signed is fully determined. However, while it will be the general case that a new random string is used for each signature, there is no impediment to reusing the same r for several messages as long as r is not disclosed before all these messages are fully determined (this may be appropriate for applications, maybe a CA, that sign a batch of messages before disclosing the signatures). 4 Implementation Notes The fact that one can use RMX while leaving the hash-then-sign module intact makes its adoption and implementation quite straight- forward. Our implementation experience shows that adding support for RMX to existing applications and software libraries entails the same complexity as adding a new deterministic hash function (e.g. SHA256). The one issue that requires attention is the transmission of the salt r, which needs to be done at the application level. Several experimental implementations of RMX deal with this issue. These include works of Boneh and Shao [BS06] for the NSS Library and the Firefox browser, by us [RMX] for the openssl library, and by McIntosh for XML signatures [RMX]. All these projects implemented RMX-enabled X.509 certificates, and in particular needed to specify how the salt r is communicated from the signer to the verifier of the certificate. The two alternatives that were considered are as follows: THE SALT AS PART OF THE SIGNATURE. A natural solution for transporting the salt with a signature is to append the salt to the signature itself (i.e., in this case the salt becomes an additional component of the signature string). As discussed in Section 3, this approach may require the buffering of the whole message at the sender or receiver, and hence it is less desirable as a general solution. In the specific case of certificates this buffering may be practical, in which case this transport solution is the one to require the smallest change to the certificate-handling code. THE SALT AS AN ALGORITHM PARAMETER. The projects mentioned above chose to implement a more general, and slightly more involved, option; i.e., to specify the salt as a parameter of the signature's algorithm identifier. For example, the certificate structure as defined in X.509 and RFC 3280 (PKIX) includes an AlgorithmIdentifier, whose ASN.1 definition is as follows: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } This structure has an (optional) parameter that can be used to carry the value of the salt. One can define the signature algorithms that use RMX (e.g., OBJ rmxsha1WithRSAEncryption) to have a parameter of type OCTET STRING. The signing function would copy the salt that it used for hashing into that parameter, and the verification code will Halevi and Krawczyk [Page 9]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 extract it from there. (See above references for more details.) NOTE. A previous version of this document required to concatenate the salt r to the result of the randomized hash operation before signing; this resulted in the need to change encoding schemes for standards such as PKCS1. The current specification simplifies the scheme (and eases adoption) by dropping this requirement without jeopardizing the security. 5 Security Considerations This whole document is about security. Here we highlight some important rules to observe, and comment on some of the analysis work that backs up the security of the proposed mechanisms. Any application that implements digital signatures using the randomized hashing scheme described here must ensure that an attacker cannot choose, or influence, the contents of a message to be signed after seeing the random salt. In particular, the salt must be unpredictable by the attacker before the message is determined. Consequently, the input r to the RMX function must be generated by a strong random number generator, or by a cryptographically-strong pseudo-random generator, and should be of length at least 128 bits but no more than the parameter block_length. Note that it is only the signer who generates randomness; the verifier receives it as part of the signature (or message). For example, in the important case of certificates, the CA will generate randomness to sign a certificate but verifiers of the certificate (which may be many and computatio- nally restricted) do not need to generate randomness at all. We note that while it would have been advantageous to specify the RMX transform independently of any parameter of the hash function (such as in the "default" specification of RMX discussed at the end of Section 2), there are substantial advantages to synchronizing the RMX parameters with those of the underlying hash function. Specifically, for block-based iterative hash functions, such as Merkle-Damgard, it is best to align the (extended) salt r' defined by RMX with a full block of the hash function; this ensures that the r' value, that occupies the first block of M', is hashed into a randomized IV before starting the processing of the message m0 (this is not the case if r' and the beginning of m0 occupy the same block). Another reason to have the length of r' (i.e., block_length) be the same as a hash block length is that it allows for a more efficient implementation of RMX in the case of iterative hash functions (as noted in Section 2). Another hash-dependent parameter is the amount of padding RMX appends to message M, and which is determined by the function pad_length. This is best exemplified (and motivated) using Merkle-Damgard (M-D) hash functions. Recall that M-D functions specify a padding rule in which a pad of the form 100...0 is added to the end of a message followed by an encoding of the message length. When applied to a message whose length is (close to) an integral number of blocks this padding results in the addition of a full padding block by the M-D Halevi and Krawczyk [Page 10]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 processing. In the case of RMX, this padding block is added to M' after the RMX procedure has finished, and hence this added block is NOT randomized at all. Similarly, a message of length just slightly over an integral number of blocks will be padded by a M-D function to a full block, where only very few bits of that last block will be randomized by RMX. In these cases, the attacker has a predictable (i.e., little randomized) block to attack, thus reducing the level of security offered by the randomization scheme. We take care of these issues, i.e., maximizing the number of bits randomized by RMX in the last block, via the function pad_length. Specifically, for the case of M-D functions, this maximization is achieved using the implementation of pad_length presented at the end of Section 2. In general, it is best to consider the randomized hashing mechanism specified in this document as a mode of operation of hash functions. In this case, the dependency on specific parameters of the underlying hash function is natural and appropriate (similarly to the case of CBC mode where both the padding and the IV have lengths that depend on the block length of the underlying block cipher). ANALYSIS: The randomized hashing mechanism specified here is presented and analyzed in [HK06] (in that paper this scheme is referred to as the "eTCR construction"; the RMX scheme itself, instantiated for M-D functions, is presented in the full web version of the paper). We refer the reader to that document for the mathematical analysis. In a nutshell, it is shown that finding off-line collisions against the underlying hash function (as in recent attacks) is insufficient to break RMX-based signatures. Instead, an attacker against such signatures needs to solve a cryptanalytical problem much harder than finding off-line collisions, namely, one that is equivalent to a variant of second-preimage finding (called e-SPR in [HK06]). Thus, RMX provides a "safety net" for digital signatures in the case that the hash function in use turns out to be vulnerable to collision attacks. (It may be worth pointing out that if a hash function is collision resistant then the same hash function used with RMX is also e-SPR; hence, RMX schemes can only add security to a signature scheme, never decrease it.) Acknowledgments. We thank Michael McIntosh, Dan Boneh and Weidong Shao for their RMX implementation work, and Mark Davis and Suresh Chari for their assistance with our own implementation. We are also indebted to Quynh Dang for documenting RMX for NIST and for many fruitful discussions on the subject. Halevi and Krawczyk [Page 11]

Internet Draft draft-irtf-cfrg-rhash-01.txt October 18, 2007 References [BR05] Steven M. Bellovin and Eric K. Rescorla, "Deploying a New Hash Algorithm", NDSS'06. http://www.cs.columbia.edu/~smb/papers/new-hash.pdf [BS06] Dan Boneh and Weidong Shao, "Randomized Hashing for Digital Certificates: Halevi-Krawczyk Hash, An implementation in Firefox". http://crypto.stanford.edu/firefox-rhash/ [DSS] Digital Signature Standard (DSS), FIPS 186, May 1994. [HK06] Shai Halevi and Hugo Krawczyk, "Strengthening Digital Signatures via Randomized Hashing", Crypto'2006. http://www.ee.technion.ac.il/~hugo/rhash/ [RMX] Shai Halevi and Hugo Krawczyk, "The RMX Transform and Digital Signatures". http://www.ee.technion.ac.il/~hugo/rhash/. [NIST] "Randomized Hashing Digital Signatures", NIST Special Publication SP 800-106, Draft, July 2007 [PKCS1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Halevi and Krawczyk [Page 12]