idnits 2.17.1 draft-eastlake-fnv-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 226 has weird spacing: '...ed char hash...' -- The document date (April 4, 2015) is 3307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N' is mentioned on line 226, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Glenn Fowler 2 INTERNET-DRAFT Google 3 Intended Status: Informational Landon Curt Noll 4 Cisco Systems 5 Kiem-Phong Vo 6 Google 7 Donald Eastlake 8 Huawei Technologies 9 Expires: October 3, 2015 April 4, 2015 11 The FNV Non-Cryptographic Hash Algorithm 12 14 Abstract 16 FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with 17 good dispersion. The purpose of this document is to make information 18 on FNV and open source code performing FNV conveniently available to 19 the Internet community. 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the authors. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................3 48 2. FNV Basics..............................................4 49 2.1 FNV Primes.............................................4 50 2.2 FNV offset_basis.......................................5 51 2.3 FNV Endianism..........................................5 53 3. Other Hash Sizes and XOR Folding........................7 54 4. FNV Constants...........................................8 56 5. The Source Code........................................10 57 5.1 FNV-1a C Code.........................................10 58 5.1.1 FNV32 Code..........................................10 59 5.1.2 FNV64 C Code........................................10 60 5.1.3 FNV128 C Code.......................................10 61 5.1.4 FNV256 C Code.......................................10 62 5.1.5 FNV512 C Code.......................................11 63 5.1.6 FNV1024 C Code......................................11 64 5.2 FNV Test Code.........................................11 66 6. Security Considerations................................12 67 6.1 Why is FNV Non-Cryptographic?.........................12 69 7. IANA Considerations....................................13 70 Normative References......................................13 71 Informative References....................................13 72 Acknowledgements..........................................14 74 Appendix A: Work Comparison with SHA-1....................15 75 Appendix B: Previous IETF Reference to FNV................16 76 Appendix C: A Few Test Vectors............................17 78 Appendix Z: Change Summary................................18 79 From -00 to -01...........................................18 80 From -01 to -02...........................................18 81 From -02 to -03...........................................18 82 From -03 to -04...........................................18 83 From -04 to -05...........................................19 84 From -05 to -06...........................................19 85 From -06 to -07 to -08....................................19 86 From -08 to -09...........................................19 88 Author's Address..........................................20 90 1. Introduction 92 The FNV hash algorithm is based on an idea sent as reviewer comments 93 to the [IEEE] POSIX P1003.2 committee by Glenn Fowler and Phong Vo in 94 1991. In a subsequent ballot round Landon Curt Noll suggested an 95 improvement on their algorithm. Some people tried this hash and found 96 that it worked rather well. In an EMail message to Landon, they named 97 it the "Fowler/Noll/Vo" or FNV hash. [FNV] 99 FNV hashes are designed to be fast while maintaining a low collision 100 rate. The high dispersion of the FNV hashes makes them well suited 101 for hashing nearly identical strings such as URLs, hostnames, 102 filenames, text, IP addresses, etc. Their speed allows one to quickly 103 hash lots of data while maintaining a reasonably low collision rate. 104 However, they are generally not suitable for cryptographic use. (See 105 Section 6.1.) 107 The FNV hash is widely used, for example in DNS servers, the Twitter 108 service, database indexing hashes, major web search / indexing 109 engines, netnews history file Message-ID lookup functions, anti-spam 110 filters, a spellchecker programmed in Ada 95, flatassembler's open 111 source x86 assembler - user-defined symbol hashtree, non- 112 cryptographic file fingerprints, computing Unique IDs in DASM (DTN 113 Applications for Symbian Mobile-phones), Microsoft's hash_map 114 implementation for VC++ 2005, the realpath cache in PHP 5.x 115 (php-5.2.3/TSRM/tsrm_virtual_cwd.c), and many other uses. 117 A study has recommended FNV in connetion with the IPv6 Flow Label 118 field [IPv6flow]. 120 FNV hash algorithms and source code have been released into the 121 public domain. The authors of the FNV algorithm took deliberate steps 122 to disclose the algorithm in a public forum soon after it was 123 invented. More than a year passed after this public disclosure and 124 the authors deliberately took no steps to patent the FNV algorithm. 125 Therefore, it is safe to say that the FNV authors have no patent 126 claims on the FNV algorithm as published. 128 If you use an FNV function in an application, you are kindly 129 requested to send an EMail about it to: fnv-mail@asthe.com 131 2. FNV Basics 133 This document focuses on the FNV-1a function whose pseudo-code is as 134 follows: 136 hash = offset_basis 137 for each octet_of_data to be hashed 138 hash = hash xor octet_of_data 139 hash = hash * FNV_Prime 140 return hash 142 In the pseudo-code above, hash is a power-of-two number of bits (32, 143 64, ... 1024) and offset_basis and FNV_Prime depend on the size of 144 hash. 146 The FNV-1 algorithm is the same, including the values of offset_basis 147 and FNV_Prime, except that the order of the two lines with the "xor" 148 and multiply operations are reversed. Operational experience 149 indicates better hash dispersion for small amounts of data with 150 FNV-1a. FNV-0 is the same as FNV-1 but with offset_basis set to zero. 151 FNV-1a is suggested for general use. 153 2.1 FNV Primes 155 The theory behind FNV_Prime's is beyond the scope of this document 156 but the basic property to look for is how an FNV_Prime would impact 157 dispersion. Now, consider any n-bit FNV hash where n is >= 32 and 158 also a power of 2. For each such an n-bit FNV hash, an FNV_Prime p is 159 defined as: 161 When s is an integer and 4 < s < 11, then FNV_Prime is the 162 smallest prime p of the form: 164 256**int((5 + 2^s)/12) + 2**8 + b 166 where b is an integer such that: 168 0 < b < 2**8 169 The number of one-bits in b is 4 or 5 171 and where p mod (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7). 173 Experimentally, FNV_Primes matching the above constraints tend to 174 have better dispersion properties. They improve the polynomial 175 feedback characteristic when an FNV_Prime multiplies an intermediate 176 hash value. As such, the hash values produced are more scattered 177 throughout the n-bit hash space. 179 The case where s < 5 is not considered because the resulting hash 180 quality is too low. Such small hashes can, if desired, be derived 181 from a 32 bit FNV hash by XOR folding (see Section 3). The case where 182 s > 10 is not considered because of the doubtful utility of such 183 large FNV hashes and because the criteria for such large FNV_Primes 184 is more complex, due to the sparsity of such large primes, and would 185 needlessly clutter the criteria given above. 187 Per the above constraints, an FNV_Prime should have only 6 or 7 one- 188 bits in it. Therefore, some compilers may seek to improve the 189 performance of a multiplication with an FNV_Prime by replacing the 190 multiplication with shifts and adds. However, note that the 191 performance of this substitution is highly hardware-dependent and 192 should be done with care. FNV_Primes were selected primarily for the 193 quality of resulting hash function, not for compiler optimization. 195 2.2 FNV offset_basis 197 The offset_basis values for the n-bit FNV-1a algorithms are computed 198 by applying the n-bit FNV-0 algorithm to the 32 octets representing 199 the following character string in [RFC20]: 201 chongo /\../\ 203 The \'s in the above string are not C-style escape characters. In C- 204 string notation, these 32 octets are: 206 "chongo /\\../\\" 208 That string was used because the person testing FNV with non-zero 209 offset_basis values was looking at an email message from Landon and 210 was copying his standard email signature line; however, they couldn't 211 see very well and copied it incorrectly. In fact, he uses 213 "chongo (Landon Curt Noll) /\oo/\" 215 but, since it doesn't matter, no effort has been made to correct 216 this. In the general case, almost any offset_basis will serve so 217 long as it is non-zero. 219 2.3 FNV Endianism 221 For persistent storage or interoperability between different hardware 222 platforms, an FNV hash shall be represented in the little endian 223 format. That is, the FNV hash will be stored in an array hash[N] with 224 N bytes such that its integer value can be retrieved as follows: 226 unsigned char hash[N]; 227 for ( i = N-1, value = 0; i >= 0; --i ) 228 value = value << 8 + hash[i]; 230 Of course, when FNV hashes are used in a single process or a group of 231 processes sharing memory on processors with compatible endian-ness, 232 the natural endianness of those processors can be used regardless of 233 its type, little, big, or some other exotic form. 235 3. Other Hash Sizes and XOR Folding 237 Many hash uses require a hash that is not one of the FNV sizes for 238 which constants are provided in Section 4. If a larger hash size is 239 needed, please contact the authors of this document. 241 Most hash applications make use of a hash that is a fixed size binary 242 field. Assume that k bits of hash are desired and k is less than 1024 243 but not one of the sizes for which constants are provided in Section 244 4. The recommended technique is to take the smallest FNV hash of size 245 S, where S is larger than k, and calculate the desired hash using xor 246 folding as shown below. The final bit masking operation is logically 247 unnecessarily if the size of hash is exactly the number of desired 248 bits. 250 temp = FNV_S ( data-to-be-hashed ) 251 hash = ( temp xor temp>>k ) bitwise-and ( 2**k - 1 ) 253 Hash functions are a trade-off between speed and strength. For 254 example, a somewhat stronger hash may be obtained for exact FNV sizes 255 by calculating an FNV twice as long as the desired output ( S = 2*k ) 256 and performing such data folding using a k equal to the size of the 257 desired output. However, if a much stronger hash, for example one 258 suitable for cryptographic applications, is wanted, algorithms 259 designed for that purpose, such as those in [RFC6234], should be 260 used. 262 If it is desired to obtain a hash result that is a value between 0 263 and max, where max is a not a power of two, simply choose an FNV hash 264 size S such that 2**S > max. Then calculate the following: 266 FNV_S mod ( max+1 ) 268 The resulting remainder will be in the range desired but will suffer 269 from a bias against large values with the bias being larger if 2**S 270 is only a little bigger than max. If this bias is acceptable, no 271 further processing is needed. If this bias is unacceptable, it can be 272 avoided by retrying for certain high values of hash, as follows, 273 before applying the mod operation above: 275 X = ( int( ( 2**S - 1 ) / ( max+1 ) ) ) * ( max+1 ) 276 while ( hash >= X ) 277 hash = ( hash * FNV_Prime ) + offset_basis 279 4. FNV Constants 281 The FNV Primes are as follows: 283 32 bit FNV_Prime = 2**24 + 2**8 + 0x93 = 16,777,619 284 = 0x01000193 286 64 bit FNV_Prime = 2**40 + 2**8 + 0xB3 = 1,099,511,628,211 287 = 0x00000100 000001B3 289 128 bit FNV_Prime = 2**88 + 2**8 + 0x3B = 290 309,485,009,821,345,068,724,781,371 291 = 0x00000000 01000000 00000000 0000013B 293 256 bit FNV_Prime = 2**168 + 2**8 + 0x63 = 294 374,144,419,156,711,147,060,143,317,175,368,453,031,918,731,002,211 = 295 0x0000000000000000 0000010000000000 0000000000000000 0000000000000163 297 512 bit FNV_Prime = 2**344 + 2**8 + 0x57 = 35, 298 835,915,874,844,867,368,919,076,489,095,108,449,946,327,955,754,392, 299 558,399,825,615,420,669,938,882,575,126,094,039,892,345,713,852,759 = 300 0x0000000000000000 0000000000000000 0000000001000000 0000000000000000 301 0000000000000000 0000000000000000 0000000000000000 0000000000000157 303 1024 bit FNV_Prime = 2**680 + 2**8 + 0x8D = 5, 304 016,456,510,113,118,655,434,598,811,035,278,955,030,765,345,404,790, 305 744,303,017,523,831,112,055,108,147,451,509,157,692,220,295,382,716, 306 162,651,878,526,895,249,385,292,291,816,524,375,083,746,691,371,804, 307 094,271,873,160,484,737,966,720,260,389,217,684,476,157,468,082,573 = 308 0x0000000000000000 0000000000000000 0000000000000000 0000000000000000 309 0000000000000000 0000010000000000 0000000000000000 0000000000000000 310 0000000000000000 0000000000000000 0000000000000000 0000000000000000 311 0000000000000000 0000000000000000 0000000000000000 000000000000018D 313 The FNV offset_basis values are as follows: 315 32 bit offset_basis = 2,166,136,261 = 0x811C9DC5 317 64 bit offset_basis = 14695981039346656037 = 0xCBF29CE4 84222325 319 128 bit offset_basis = 144066263297769815596495629667062367629 = 320 0x6C62272E 07BB0142 62B82175 6295C58D 322 256 bit offset_basis = 100,029,257,958,052,580,907,070,968, 323 620,625,704,837,092,796,014,241,193,945,225,284,501,741,471,925,557 = 324 0xDD268DBCAAC55036 2D98C384C4E576CC C8B1536847B6BBB3 1023B4C8CAEE0535 325 512 bit offset_basis = 9, 326 659,303,129,496,669,498,009,435,400,716,310,466,090,418,745,672,637, 327 896,108,374,329,434,462,657,994,582,932,197,716,438,449,813,051,892, 328 206,539,805,784,495,328,239,340,083,876,191,928,701,583,869,517,785 = 329 0xB86DB0B1171F4416 DCA1E50F309990AC AC87D059C9000000 0000000000000D21 330 E948F68A34C192F6 2EA79BC942DBE7CE 182036415F56E34B AC982AAC4AFE9FD9 332 1024 bit offset_basis = 14,197,795,064,947,621,068,722,070,641,403, 333 218,320,880,622,795,441,933,960,878,474,914,617,582,723,252,296,732, 334 303,717,722,150,864,096,521,202,355,549,365,628,174,669,108,571,814, 335 760,471,015,076,148,029,755,969,804,077,320,157,692,458,563,003,215, 336 304,957,150,157,403,644,460,363,550,505,412,711,285,966,361,610,267, 337 868,082,893,823,963,790,439,336,411,086,884,584,107,735,010,676,915 = 338 0x0000000000000000 005F7A76758ECC4D 32E56D5A591028B7 4B29FC4223FDADA1 339 6C3BF34EDA3674DA 9A21D90000000000 0000000000000000 0000000000000000 340 0000000000000000 0000000000000000 0000000000000000 000000000004C6D7 341 EB6E73802734510A 555F256CC005AE55 6BDE8CC9C6A93B21 AFF4B16C71EE90B3 343 5. The Source Code 345 The following sub-sections provide reference C source code and a test 346 driver for FNV-1a. 348 Section 5.1 provides the direct FNV-1a function for each of the 349 lengths for which it is specified in this document. Note that for 350 applications of FNV-32 where 32-bit integers are supported and FNV-64 351 where 64-bit integers are supported, the code is sufficiently simple 352 that use of open coding or macros may be more appropriate to maximize 353 performance. 355 Alternative source code, including such things as 32 and 64 bit FNV-1 356 and FNV-1a in x86 aseembler, is currently available at [FNV]. 358 Section 5.2 provides a test driver. 360 5.1 FNV-1a C Code 362 TBD 364 5.1.1 FNV32 Code 366 TBD 368 5.1.2 FNV64 C Code 370 TBD 372 5.1.3 FNV128 C Code 374 TBD 376 5.1.4 FNV256 C Code 378 TBD 380 5.1.5 FNV512 C Code 382 TBD 384 5.1.6 FNV1024 C Code 386 TBD 388 5.2 FNV Test Code 390 TBD 392 6. Security Considerations 394 This document is intended to provide convenient open source access by 395 the Internet community to the FNV non-cryptographic hash. No 396 assertion of suitability for cryptographic applications is made for 397 the FNV hash algorithms. 399 6.1 Why is FNV Non-Cryptographic? 401 A full discussion of cryptographic hash requirements and strength is 402 beyond the scope of this document. However, here are three 403 characteristics of FNV that would generally be considered to make it 404 non-cryptographic: 406 1. Sticky State - A cryptographic hash should not have a state in 407 which it can stick for a plausible input pattern. But, in the very 408 unlikely event that the FNV hash variable becomes zero and the 409 input is a sequence of zeros, the hash variable will remain at 410 zero until there is a non-zero input byte and the final hash value 411 will be unaffected by the length of that sequence of zero input 412 bytes. Of course, for the common case of fixed length input, this 413 would usually not be significant because the number of non-zero 414 bytes would vary inversely with the number of zero bytes and for 415 some types of input runs of zeros do not occur. Furthermore, the 416 inclusion of even a little unpredictable input may be sufficient 417 to stop an adversary from inducing a zero hash variable. 419 2. Diffusion - Every output bit of a cryptographic hash should be an 420 equally complex function of every input bit. But it is easy to see 421 that the least significant bit of a direct FNV hash is the XOR of 422 the least significant bits of every input byte and does not depend 423 on any other input bit. While more complex, the second through 424 seventh least significant bits of an FNV hash have a similar 425 weakness; only the top bit of the bottom byte of output, and 426 higher order bits, depend on all input bits. If these properties 427 are considered a problem, they can be easily fixed by XOR folding 428 (see Section 3). 430 3. Work Factor - Depending on intended use, it is frequently 431 desireable that a hash function should be computationally 432 expensive for general purpose and graphics processors since these 433 may be profusely available through elastic cloud services or 434 botnets. This is to slow down testing of possible inputs if the 435 output is known. But FNV is designed to be very inexpensive on a 436 general-purpose processor. (See Appendix A.) 438 Nevertheless, none of the above have proven to be a problem in actual 439 practice for the many applications of FNV. 441 7. IANA Considerations 443 This document requires no IANA Actions. 445 Normative References 447 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 448 RFC 20, October 1969, . 450 Informative References 452 [FNV] - FNV web site: 453 http://www.isthe.com/chongo/tech/comp/fnv/index.html 455 [IEEE] - http://www.ieee.org 457 [IPv6flow] - https://researchspace.auckland.ac.nz/bitstream/handle/ 458 2292/13240/flowhashRep.pdf 460 [RFC3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 461 1 (SHA1)", RFC 3174, September 2001. 463 [RFC6194] - Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 464 Considerations for the SHA-0 and SHA-1 Message-Digest 465 Algorithms", RFC 6194, March 2011. 467 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 468 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 469 2011. 471 Acknowledgements 473 The contributions of the following are gratefully acknowledged: 475 Frank Ellermann, Tony Finch, Bob Moskowitz, and Stefan Santesson. 477 Appendix A: Work Comparison with SHA-1 479 This section provides a simplistic rough comparison of the level of 480 effort required per input byte to compute FNV-1a and SHA-1 [RFC3174]. 482 Ignoring transfer of control and conditional tests and equating all 483 logical and arithmetic operations, FNV requires 2 operations per 484 byte, an XOR and a multiply. 486 SHA-1 is a relatively weak cryptographic hash producing a 160-bit 487 hash. It that has been partially broken [RFC6194]. It is actually 488 designed to accept a bit vector input although almost all computer 489 uses apply it to an integer number of bytes. It processes blocks of 490 512 bits (64 bytes) and we estimate the effort involved in SHA-1 491 processing a full block. Ignoring SHA-1 initial set up, transfer of 492 control, and conditional tests, but counting all logical and 493 arithmetic operations, including counting indexing as an addition, 494 SHA-1 requires 1,744 operations per 64 bytes block or 27.25 495 operations per byte. So by this rough measure, it is a little over 13 496 times the effort of FNV for large amounts of data. However, FNV is 497 commonly used for small inputs. Using the above method, for inputs of 498 N bytes, where N is <= 55 so SHA-1 will take one block (SHA-1 499 includes padding and an 8-byte length at the end of the data in the 500 last block), the ratio of the effort for SHA-1 to the effort for FNV 501 will be 872/N. For example, with an 8 byte input, SHA-1 will take 109 502 times as much effort as FNV. 504 Stronger cryptographic functions than SHA-1 generally have an even 505 high work factor. 507 Appendix B: Previous IETF Reference to FNV 509 FNV-1a was referenced in draft-ietf-tls-cached-info-08.txt that has 510 since expired. It was later decided that it would be better to use a 511 cryptographic hash for that application. 513 Below is the Jave code for FNV64 from that TLS draft include by the 514 kind permission of the author: 516 517 /** 518 * Java code sample, implementing 64 bit FNV-1a 519 * By Stefan Santesson 520 */ 522 import java.math.BigInteger; 524 public class FNV { 526 static public BigInteger getFNV1aToByte(byte[] inp) { 528 BigInteger m = new BigInteger("2").pow(64); 529 BigInteger fnvPrime = new BigInteger("1099511628211"); 530 BigInteger fnvOffsetBasis = 531 new BigInteger("14695981039346656037"); 533 BigInteger digest = fnvOffsetBasis; 535 for (byte b : inp) { 536 digest = digest.xor(BigInteger.valueOf((int) b & 255)); 537 digest = digest.multiply(fnvPrime).mod(m); 538 } 539 return digest; 541 } 542 } 543 545 Appendix C: A Few Test Vectors 547 Below are a few test vectors in the form of ASCII strings and their 548 FNV32 and FNV64 hashes using the FNV-1a algorithm. 550 Strings without null (zero byte) termination: 552 String FNV32 FNV64 553 "" 0x811c9dc5 0xcbf29ce484222325 554 "a" 0xe40c292c 0xaf63dc4c8601ec8c 555 "foobar" 0xbf9cf968 0x85944171f73967e8 557 Strings including null (zero byte) termination: 559 String FNV32 FNV64 560 "" 0x050c5d1f 0xaf63bd4c8601b7df 561 "a" 0x2b24d044 0x089be207b544f1e4 562 "foobar" 0x0c1c9eb8 0x34531ca7168b8f38 564 Appendix Z: Change Summary 566 RFC Editor Note: Please delete this appendix on publication. 568 From -00 to -01 570 1. Add Security Considerations section on why FNV is non- 571 cryptographic. 573 2. Add Appendix A on a work factor comparison with SHA-1. 575 3. Add Appendix B concerning previous IETF draft referenced to FNV. 577 4. Minor editorial changes. 579 From -01 to -02 581 1. Correct FNV_Prime determination criteria and add note as to why s 582 < 5 and s > 10 are not considered. 584 2. Add acknowledgements list. 586 3. Add a couple of references. 588 4. Minor editorial changes. 590 From -02 to -03 592 1. Replace direct reference to US-ASCII standard with reference to 593 RFC 20. 595 2. Update dates and verion number. 597 3. Minor editing changes. 599 From -03 to -04 601 1. Change reference to RFC 20 back to a reference to the ANSI 1968 602 ASCII standard. 604 2. Minor addition to Section 6, point 3. 606 3. Update dates and version number. 608 4. Minor editing changes. 610 From -04 to -05 612 1. Add Twitter as a use example and IPv6 flow hash study reference. 614 2. Update dates and version number. 616 From -05 to -06 618 1. Add code subsections. 620 2. Update dates and version number. 622 From -06 to -07 to -08 624 1. Update Author info. 626 2. Minor edits. 628 From -08 to -09 630 1. Change reference for ASCII to [RFC20]. 632 2. Add more details on history of the string used to compute 633 offset_basis. 635 3. Re-write "Work Factor" part of Section 6 to be more precise. 637 4. Minor editorial changes. 639 Author's Address 641 Glenn Fowler 642 Google 644 Email: glenn.s.fowler@gmail.com 646 Landon Curt Noll 647 Cisco Systems 648 170 West Tasman Drive 649 San Jose, CA 95134 USA 651 Telephone: +1-408-424-1102 652 Email: fnv-ietf2-mail@asthe.com 653 URL: http://www.isthe.com/chongo/index.html 655 Kiem-Phong Vo 656 Google 658 Email: phongvo@gmail.com 660 Donald Eastlake 661 Huawei Technologies 662 155 Beaver Street 663 Milford, MA 01757 USA 665 Telephone: +1-508-333-2270 666 EMail: d3e3e3@gmail.com 668 Copyright, Disclaimer, and Additional IPR Provisions 670 Copyright (c) 2015 IETF Trust and the persons identified as the 671 document authors. All rights reserved. 673 This document is subject to BCP 78 and the IETF Trust's Legal 674 Provisions Relating to IETF Documents 675 (http://trustee.ietf.org/license-info) in effect on the date of 676 publication of this document. Please review these documents 677 carefully, as they describe your rights and restrictions with respect 678 to this document. Code Components extracted from this document must 679 include Simplified BSD License text as described in Section 4.e of 680 the Trust Legal Provisions and are provided without warranty as 681 described in the Simplified BSD License. This Internet-Draft is 682 submitted to IETF in full conformance with the provisions of BCP 78 683 and BCP 79.