RFC 9923: The FNV Non-Cryptographic Hash Algorithm
- L. Noll,
- K. Vo,
- D. Eastlake 3rd,
- T. Hansen
Abstract
FNV
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
FNV
The purpose of this document is to make information on FNV and open-source code performing all specified sizes of FNV conveniently available to the Internet community. This work is not an Internet Standard and does not have the consensus of the IETF community.¶
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
1.2. Applicability of Non-Cryptographic Hashes and FNV
While a general theory of hash function strength and utility is beyond the scope of this document, typical attacks on hash functions involve one of the following:¶
- Collision:
- Finding two data inputs that yield the same hash output.¶
- First Pre-Image:
- Given a hash output, finding a data input that hashes to that output.¶
- Second Pre-Image:
- Given a first data input, finding a second input that produces the same hash output as the first.¶
For a hash function producing N bits, there necessarily will be collisions among the hashes of more than 2N distinct inputs. And if the hash function can produce hashes covering all 2N possible outputs, then there will exist first and second pre-images. FNV is NOT RECOMMENDED for any application that requires that it be computationally infeasible for one of the above types of attacks to succeed.¶
FNV hashes are generally not applicable for use when faced with
an active adversary in a security scheme where the modest effort
required to compute FNV hashes (see Appendix A) and
their other non
For a discussion of adversarial inducement of collisions, see Section 6.1.¶
1.3. FNV Hash Uses
The FNV hash has been widely used. Examples include the following:¶
and many other uses. It is also referenced in the following standards documents: [RFC7357], [RFC7873], and [IEEE8021Q-2022].¶
A study has recommended FNV in connection with the IPv6 flow
label value [IPv6flow]. Additionally, there was a
proposal to use FNV for Bidirectional Forwarding Detection (BFD) sequence number generation [BFDseq]. [NCHF] discusses criteria for evaluating non
If you use an FNV function in an application, you are kindly requested to send a note via the process outlined at <http://
1.4. Why Is FNV Non-Cryptographic?
A full discussion of cryptographic hash requirements and strength
is beyond the scope of this document. However, here are three
characteristics of FNV that would generally be considered to make it
non
Nevertheless, none of the above have proven to be a problem in
actual practice for the many non
2. FNV Basics
This document focuses on the FNV-1a function, whose pseudocode is as follows:¶
In the pseudocode above, hash is a power-of-2 number of bits (HashSize is 32, 64, 128, 256, 512, or 1024), and offset_basis and FNV_Prime depend on the size of hash.¶
The FNV-1 algorithm is the same, including the values of offset_basis and FNV_Prime, except that the order of the two lines with the "XOR" and multiply operations is reversed. Operational experience indicates better hash dispersion for small amounts of data with FNV-1a. FNV-0 is the same as FNV-1 but with offset_basis set to zero. FNV-1a is suggested for general use.¶
2.1. FNV Primes
The theory behind FNV_Primes is beyond the scope of this document, but the basic property to look for is how an FNV_Prime would impact dispersion. Now, consider any n-bit FNV hash where n >= 32 and is also a power of 2 -- in particular, n = 2s. For each such n-bit FNV hash, an FNV_Prime p is defined as follows:¶
Experimentally, FNV_Primes matching the above constraints tend to have better dispersion properties. They improve the polynomial feedback characteristic when an FNV_Prime multiplies an intermediate hash value. As such, the hash values produced are more scattered throughout the n-bit hash space.¶
The case where s < 5 is not considered due to the resulting low hash quality. Such small hashes can, if desired, be derived from a 32-bit FNV hash by XOR folding (see Section 3). The case where s > 10 is not considered because of the doubtful utility of such large FNV hashes and because the criteria for such large FNV_Primes would be more complex, due to the sparsity of such large primes, and would needlessly clutter the criteria given above.¶
Per the above constraints, an FNV_Prime should have only six or seven one bits in it: one relatively high-order one bit, the 29 bit, and four or five one bits in the low-order byte. Therefore, some compilers may seek to improve the performance of a multiplication with an FNV_Prime by replacing the multiplication with shifts and adds. However, the performance of this substitution is highly hardware dependent and should be done with care. The selection of FNV_Primes prioritizes the quality of the resulting hash function, not compiler optimization considerations.¶
2.2. FNV offset_basis
The offset_basis values for the n-bit FNV-1a algorithms are computed by applying the n-bit FNV-0 algorithm to the following 32-octet ASCII [RFC0020] character string:¶
or, in C notation [C], the following string:¶
In the general case, almost any offset_basis would serve as long as it is non-zero. However, FNV hashes calculated with different offset_basis values will not interoperate. The choice of a non-standard offset_basis may be beneficial in some limited circumstances to defend against attacks that try to induce hash collisions as discussed in Section 6.1. Any entity that can observe the FNV hash output and can cause the null string (the string of length zero) to be hashed will thereby be able to directly observe the offset_basis which will be the hash output.¶
2.3. FNV Endianism
For persistent storage or interoperabilit
However, when FNV hashes are used in a single process or a group of processes sharing memory on processors with compatible endianness, the natural endianness of those processors can be used, as long as it is used consistently, regardless of its type -- little, big, or some other exotic form.¶
The code provided in Section 8 has FNV hash functions that return a
little-endian byte vector for all lengths. Because they are more
efficient, the code also provides functions that return FNV hashes as
32-bit integers or, where supported, 64-bit integers, for those sizes
of FNV hash. Such integers are compatible with the same-size byte
vectors on little-endian computers, but the use of the functions returning
integers on big-endian or other non
3. Other Hash Sizes and XOR Folding
Many hash uses require a hash that is not one of the FNV sizes for which constants are provided in Section 5. If a larger hash size is needed, please contact the authors of this document.¶
For scenarios where a fixed-size binary field of k bits is desired with k < 1024 but not among the constants provided in Section 5, the recommended approach involves using the smallest FNV hash of size S where S > k and employing XOR folding, as shown below. The final bit-masking operation is logically unnecessary if the size of the variable k-bit-hash is exactly k bits.¶
A somewhat stronger hash may be obtained for exact FNV sizes by calculating an FNV twice as long as the desired output ( S = 2*k ) and performing such XOR data folding using a k equal to the size of the desired output. However, if a much stronger hash is desired, cryptographic algorithms, such as those specified in [FIPS202] or [RFC6234], should be used.¶
If it is desired to obtain a hash result that is a value between 0 and max, where max+1 is not a power of 2, simply choose an FNV hash size S such that 2S > max. Then, calculate the following:¶
The resulting remainder will be in the range desired but will suffer from a bias against large values, with the bias being larger if 2S is only slightly larger than max. If this bias is acceptable, no further processing is needed. If this bias is unacceptable, it can be avoided by retrying for certain high values of hash, as follows, before applying the mod operation above:¶
4. Hashing Multiple Values Together
Sometimes, there are multiple different component values, say three strings X, Y, and Z, where a hash over all of them is desired. The simplest thing to do is to concatenate them in a fixed order and compute the hash of that concatenation, as in¶
where the vertical bar character ("|") represents string concatenation. If the components being combined are of variable length, some information is lost by simple concatenation. For example, X = "12" and Y = "345" would not be distinguished from X = "123" and Y = "45". To preserve that information, each component should be preceded by an encoding of its length or should end with some sequence that cannot occur within the component, or some similar technique should be used.¶
For FNV, the same hash results if 1) X, Y, and Z are actually concatenated and the FNV hash is applied to the resulting string or 2) FNV is calculated on an initial substring and the result is used as the offset_basis when calculating the FNV hash of the remainder of the string. This can be done several times. Assuming that FNVoffset_basis ( v, w ) is the FNV of w using v as the offset_basis, then in the example above, fnvx = FNV ( X ) could be calculated and then fnvxy = FNVoffset_basis ( fnvx, Y ), and finally fnvxyz = FNVoffset_basis ( fnvxy, Z ). The resulting fnvxyz would be the same as FNV ( X | Y | Z ).¶
This means that if you have the value of FNV ( X ) and you want to calculate FNV ( X | Y ), you do not need to find X. You can simply calculate FNVoffset_basis ( FNV ( X ), Y ) and thereby get FNV ( X | Y ).¶
Sometimes, such a hash needs to be repeatedly calculated; the component values vary, but some vary more frequently than others. For example, assume that some sort of computer network traffic flow ID, such as the IPv6 Flow Label [RFC6437], is to be calculated for network packets based on the source and destination IPv6 addresses and the Traffic Class [RFC8200]. If the Flow Label is calculated in the originating host, the source IPv6 address would likely always be the same or would perhaps assume one of a very small number of values. By placing this quasi-constant IPv6 source address first in the string being FNV-hashed, FNV ( IPv6source ) could be calculated and used as the offset_basis for calculating the FNV of the IPv6 destination address and Traffic Class for each packet. As a result, the per-packet hash would be over 17 bytes rather than over 33 bytes, saving computational resources. The source code in this document includes functions facilitating the use of a non-standard offset_basis.¶
An alternative method of hashing multiple values is to concatenate the hashes of those values and then hash the concatenation -- that is, compute something like¶
This will involve more computation than simply computing the hash of the concatenation of the values and thus, unless parallel computational resources are available, greater latency; however, if parallel computational resources are available and the values being hashed together are long enough to overcome any initial/final hash function overhead, which is very small for FNV, latency can be reduced by hashing the concatenation of the hashes of the values.¶
For another example of a similar technique, assume a desire to use FNV-N to hash a byte string of length L. Let B = N/8, the number of bytes of FNV-N output. If that string is divided into k successive substrings of equal length and assuming, for simplicity, that L is an integer multiple of k, hashing the substrings and then hashing the concatenation of their hashes will hash a total of L + k*B bytes, clearly more than the initial string size L. However, if sufficient parallel computational resources are available to hash all the substrings simultaneously, the elapsed time can be changed approximately from on the order of L to on the order of L/k + k*B. For sufficiently large L, this parallelization will reduce the elapsed time to produce the overall hash.¶
5. FNV Constants
The FNV Primes are as follows:¶
The FNV offset_basis values are as follows:¶
6. Security Considerations
No assertion of suitability for cryptographic applications is made for the FNV hash algorithms.¶
The use of a cryptographic hash function should be considered when active adversaries are a factor (see Section 1.2).¶
6.1. Inducing Collisions
An attacker could attempt to induce collisions to cause denial or degradation of service. Consider the following simplified example: A hash table of n buckets is being maintained with the bucket used by some item i determined by¶
and with a linked list out of each bucket of the items that all hash to that bucket. Such an arrangement might be used for the symbol table in a compiler or for some of the routing information (i.e., a RIB (Routing Information Base)) in a router. A large number of items hashing to the same bucket will then likely result in much slower times to retrieve from or update the information stored through the table for one of those items. Typically, an attacker could arrange for the number of distinct items being hashed to be orders of magnitude larger than n, even if n was tens or hundreds of thousands, so collisions are guaranteed to occur in this example regardless of the nature of the hash function.¶
There are a number of different circumstances that might surround this example, of which the following three are illustrative:¶
7. Historical Notes
The FNV hash algorithm originated from an idea submitted as
reviewer comments to the IEEE POSIX P1003.2 committee [IEEE] in 1991 by Glenn Fowler and Phong Vo. Subsequently, during
a ballot round, Landon Curt Noll proposed an enhancement to their
algorithm. Some people tried this hash and found that it worked
rather well. In an email message to Landon, they named it the
"Fowler
The string used to calculate the offset_basis values (see Section 2.2) was selected because the person testing FNV with non-zero offset_basis values was looking at an email message from Landon and was copying his standard email signature line; however, they "did not see very well" [FNV] and copied it incorrectly. In fact, Landon uses¶
but, since it doesn't matter, no effort has been made to correct this.¶
8. The Source Code
The following subsections provide reference C source code [C] and a test driver with a command line interface for FNV-1a.¶
Section 8.2 provides the C header and code source files for the FNV functions. Section 8.3 provides the test driver. Section 8.4 provides a simple makefile to build the test driver or a library file with all FNV sizes.¶
Alternative source code for 32- and 64-bit FNV is available at [LCN2]. Other alternative source code, including in x86 assembler, is currently available at [FNV]. In some cases, this further source code has been further optimized.¶
8.1. Source Code Details
8.1.1. FNV Functions Available
The functions provided are listed below. The "xxx" in the
function names is "32", "64", "128", "256", "512", or "1024",
depending on the length of the FNV. All of the FNV hash functions
have as their return value an integer whose meaning is specified in
FNVError
Functions providing a byte vector hash are available for all
lengths. For FNV-32, versions are available that provide a 32-bit
integer and are identified by replacing "xxx" with "32INT". For
example, FNV32string provides a 4-byte vector, but FNV32INTstring
provides a 32-bit integer. For FNV-64, if compiled with 64-bit
integers enabled (i.e., FNV
If you want to copy the source code from this document, note that it is indented by three spaces in the ".txt" version. It may be simplest to copy from the ".html" version of this document.¶
- FNVxxxstring, FNVxxxblock, FNVxxxfile:
- FNVxxxstring
Basis, FNVxxxblock Basis, FNVxxxfile Basis : - FNVxxxINTstring, FNVxxxINTblock, FNVxxxINTfile:
- FNVxxx
INTstring Basis, FNVxxx INTblock Basis, FNVxxx INTfile Basis : - These are simple functions for directly returning the FNV hash of a zero-terminated byte string not including that zero byte, the FNV hash of a counted block of bytes, and the FNV of a file, respectively. The functions whose names have the "Basis" suffix take an additional parameter specifying the offset_basis. Note that for applications of FNV-32 and of FNV-64 where integers of that size are supported and an integer data type output is acceptable, the code is sufficiently simple that, to maximize performance, the use of open coding or macros may be more appropriate than calling a subroutine.¶
- FNVxxxinit, FNVxxxinit
Basis : - FNVxxx
INTinit Basis : - These functions and the next two sets of functions below provide facilities for incrementally calculating FNV hashes. They all assume a data structure of type FNVxxxcontext that holds the current state of the hash. FNVxxxinit initializes that context to the standard offset_basis. FNVxxxinitBasis takes an offset_basis value as a parameter and may be useful for hashing concatenations, as described in Section 4, as well as for simply using a non-standard offset_basis.¶
- FNVxxxblockin, FNVxxxstringin, FNVxxxfilein:
- These
functions hash a sequence of bytes into an FNVxxxcontext that was
originally initialized by FNVxxxinit or
FNVxxxinit
Basis . FNVxxxblockin hashes in a counted block of bytes. FNVxxxstringin hashes in a zero-terminated byte string not including the final zero byte. FNVxxxfilein hashes in the contents of a file.¶ - FNVxxxresult, FNVxxx
INTresult : - This function extracts the final FNV hash result from an FNVxxxcontext.¶
8.1.2. Source Files and 64-Bit Support
Code optimized for 64-bit integer support -- that is, support of
64-bit integer addition and 32-bit x 32-bit multiplication producing a
64-bit product -- is provided based on whether or not the
FNV
For support of a single FNV size, say "xxx" (e.g., FNV64), in an application, the
application itself needs to include the appropriate FNVxxx.h file (which will, in turn,
include the FNVconfig.h and FNVErrorCodes.h files). To build the
particular FNVxxx code itself, compile the FNVxxx.c file with
the following files available to the compiler: FNVconfig.h, fnv-private.h, FNVError
8.1.3. Command Line Interface
The test program provided in Section 8.3 has a command line interface. By default, with no command line arguments, it runs tests of all FNV lengths. Command line options are as follows:¶
The option letters have the following meanings:¶
- -a
- Run tests for all lengths.¶
- -h
- Print a help message about the command line.¶
- -v
- Complement the Verbose flag, which is initially off. When the flag is on, the program prints more information during tests, etc.¶
- -t nnn
- Run tests for length nnn, which must be one of 32, 64, 128, 256, 512, or 1024.¶
- -u nnn
- Use hash size nnn, which must be one of 32, 64, 128, 256, 512, or 1024. This is useful for setting the hash size for use by the -f option or in hashing tokens on the command line after the options.¶
- -f filename
- Hash the contents of the file with name filename. The hash size must have been set by a prior -t or -u option in the command line.¶
- token
- Tokens appearing on the command line after the options are hashed with the current hash size, which must have been set by a prior -t or -u option in the command line.¶
For example,¶
runs tests for FNV128, then prints a command line help message, then turns on Verbose, then runs the tests for FNV64, then turns off Verbose, then sets the hash size to 256, then hashes the contents of file foobar.txt, then hashes the token "RabOof", and finally hashes the token "1234".¶
8.2. FNV-1a C Code
This section provides the direct FNV-1a function for each of the lengths for which it is specified in this document.¶
The following is a configuration header to set whether 64-bit integers are supported and establish an enum used for return values.¶
The following code is a simple header file to define the return value error codes for the FNV routines.¶
The following code is a private header file that is used by all the FNV functions further below and that states the terms for use and redistribution of all of this source code.¶
8.2.1. FNV32 Code
The following code is the header and C source for 32-bit FNV-1a providing a 32-bit integer or 4-byte vector hash.¶
8.2.2. FNV64 Code
The following code is the header and C source for 64-bit FNV-1a providing an 8-byte vector or, optionally, if 64-bit integers are supported, a 64-bit integer hash.¶
8.2.3. FNV128 Code
The following code is the header and C source for 128-bit FNV-1a providing a byte vector hash.¶
8.2.4. FNV256 Code
The following code is the header and C source for 256-bit FNV-1a providing a byte vector hash.¶
8.2.5. FNV512 Code
The following code is the header and C source for 512-bit FNV-1a providing a byte vector hash.¶
8.2.6. FNV1024 Code
The following code is the header and C source for 1024-bit FNV-1a providing a byte vector hash.¶
8.3. FNV Test Code
Below is source code for a test driver with a command line interface as documented in Section 8.1.3. By default, with no command line arguments, it runs tests of all FNV lengths.¶
9. IANA Considerations
This document has no IANA actions.¶
10. References
10.1. Normative References
- [C]
- Kernighan, B. W. and D. M. Ritchie, "The C Programming Language, 2nd Edition", ISBN-10 0-13-110362-8, ISBN-13 978-0131103627, .
- [RFC0020]
-
Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10
.17487 , , <https:///RFC0020 www >..rfc -editor .org /info /rfc20 - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174
10.2. Informative References
- [BASIC]
-
Diamond, W., "FNV32 PowerBASIC inline x86 assembler", <http://
www >..isthe .com /chongo /tech /comp /fnv /index .html#Power BASIC - [BFDseq]
-
Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and A. DeKok, "Secure BFD Sequence Numbers", Work in Progress, Internet-Draft, draft
-ietf , , <https://-bfd -secure -sequence -numbers -09 datatracker >..ietf .org /doc /html /draft -ietf -bfd -secure -sequence -numbers -09 - [calc]
-
Bell, D. and L. Noll, "Calc - C-style arbitrary precision calculator", <http://
www >..isthe .com /chongo /tech /comp /calc /index .html - [deliantra]
-
The Deliantra Team, "Deliantra MMORPG", , <http://
www >..deliantra .net / - [fasmlab]
-
Fasmlab, "Integrated Development Environments", <https://
sourceforge >..net /projects /fasmlab / - [FIPS202]
-
NIST, "SHA-3 Standard: Permutation
-Based Hash and Extendable , FIPS PUB 202, DOI 10-Output Functions" .6028 , , <https:///NIST .FIPS .202 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .202 .pdf - [flatassembler]
-
Grysztar, T., "flat assembler: Assembly language resources", , <https://
flatassembler >..net / - [FNV]
-
Fowler, G., Noll, L., and K. Vo, "FNV
(Fowler , <http:///Noll /Vo )" www >..isthe .com /chongo /tech /comp /fnv /index .html - [Fortran]
-
Fortran Standard Library, "A community driven standard library for (modern) Fortran", <https://
stdlib >..fortran -lang .org / - [FragCache]
-
Weaver, E., "Improving Running Components at Twitter", Slide 31, , <https://
www >..slideshare .net /slideshow /improving -running -components -at -twitter /1141786 - [FreeBSD]
-
Baio, D. G., "FreeBSD 4.3 Release Notes (Last modified on 21 February 2021)", The Free BSD Project, , <https://
www >..freebsd .org /releases /4 .3R /notes .html - [FRET]
-
McCarthy, M., "FRET: helping understand file formats", , <https://
fret >..sourceforge .net / - [IEEE]
-
Institute for Electrical and Electronics Engineers, "IEEE website", <https://
www >..ieee .org / - [IEEE8021Q-2022]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Networks
--Bridges and Bridged Networks" , DOI 10.1109 , IEEE Std 802.1Q-2022, , <https:///IEEESTD .2022 .10004498 ieeexplore >..ieee .org /document /10004498 - [IEN137]
-
Cohen, D., "On Holy Wars and A Plea For Peace", IEN 137, , <https://
www >..rfc -editor .org /ien /ien137 .txt - [IPv6flow]
-
Anderson, L., Brownlee, N., and B. E. Carpenter, "Comparing Hash Function Algorithms for the IPv6 Flow Label", University of Auckland Department of Computer Science Technical Report 2012-002, ISSN 1173-3500, , <https://
www >..cs .auckland .ac .nz /~brian /flowhash Rep .pdf - [LCN2]
-
Noll, L. and C. Ferguson, "lcn2 / fnv", commit 953444c, , <https://
github >..com /lcn2 /fnv - [Leprechaun]
-
Sanmayce project, "Sanmayce project 'Underdog Way'", <http://
www >..sanmayce .com /Downloads / - [libketama]
-
Jones, R., "libketama: Consistent Hashing library for memcached clients", , <https://
www >..metabrew .com /article /libketama -consistent -hashing -algo -memcached -clients - [libsir]
-
Lederman, R. and J. Johnson, "libsir logging library", commit 0ae0173, , <https://
github >..com /aremmell /libsir - [memcache]
-
Dovgal, A., Joye, P., Radtke, H., Johansson, M., and T. Srnka, "PHP memcached extension", , <https://
pecl >..php .net /package /memcache - [NCHF]
-
Hayes, C. and D. Malone, "Questioning the Criteria for Evaluating Non
-Cryptographic Hash Functions" , Communications of the ACM, Vol. 68 No. 2, pp. 46-51, DOI 10.1145/3704255, , <https://cacm >..acm .org /practice /questioning -the -criteria -for -evaluating -non -cryptographic -hash -functions / Hayes, C. and D. Malone, "An Evaluation of FNV Non-Cryptographic Hash Functions" , Proceedings of the 35th Irish Signals and Systems Conference (ISSC), DOI 10.1109 , , <https:///ISSC61953 .2024 .10603139 ieeexplore >..ieee .org /abstract /document /10603139 - [RFC3174]
-
Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10
.17487 , , <https:///RFC3174 www >..rfc -editor .org /info /rfc3174 - [RFC6194]
-
Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10
.17487 , , <https:///RFC6194 www >..rfc -editor .org /info /rfc6194 - [RFC6234]
-
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10
.17487 , , <https:///RFC6234 www >..rfc -editor .org /info /rfc6234 - [RFC6437]
-
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10
.17487 , , <https:///RFC6437 www >..rfc -editor .org /info /rfc6437 - [RFC7357]
-
Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10
.17487 , , <https:///RFC7357 www >..rfc -editor .org /info /rfc7357 - [RFC7873]
-
Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10
.17487 , , <https:///RFC7873 www >..rfc -editor .org /info /rfc7873 - [RFC8200]
-
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10
.17487 , , <https:///RFC8200 www >..rfc -editor .org /info /rfc8200 - [RimStone]
-
Gliim LLC, "Golf Language Hash Tables", , <https://
rimstone >.-lang .com / - [Smash]
-
Emms, S., "Smash - find duplicate files super fast", , <https://
www >..linuxlinks .com /smash -find -duplicate -files -super -fast / - [twistylists]
-
Zethmayr, D., "twistylists: A no-sort namespace engine; developers invited", , <https://
twistylists >..blogspot .com /
Appendix A. Work Comparison with SHA-1 and SHA-256
This appendix provides a simplistic rough comparison of the level of effort required to compute FNV-1a, SHA-1 [RFC3174], and SHA-256 [RFC6234] for short messages -- that is, those less than around 50 bytes. Some CPUs may have special instructions or other hardware to accelerate certain cryptographic operations, so if performance is particularly important for an application, benchmarking on the target platform would be appropriate.¶
Ignoring transfer of control and conditional tests, and equating all logical and arithmetic operations, FNV requires two operations per byte: an XOR operation and a multiply operation.¶
SHA-1 and SHA-256 are actually designed to accept a bit vector input, although almost all computer uses apply them to an integer number of bytes. They both process blocks of 512 bits (64 bytes), and we estimate the effort involved in processing a full block. There is some overhead per message to indicate message termination and size. Assuming that the message is an even number of bytes, this overhead would be 9 bytes for SHA-1 and 17 bytes for SHA-256. So, assuming that the message with that overhead fits into one block, the message would be up to 55 bytes for SHA-1 or up to 47 bytes for SHA-256.¶
SHA-1 is a relatively weak cryptographic hash function producing a 160-bit hash. It has been substantially broken [RFC6194]. Ignoring SHA-1's initial setup, transfer of control, and conditional tests, but counting all logical and arithmetic operations, including counting indexing as an addition, SHA-1 requires 1,744 operations per 64-byte block or 31.07 operations per byte for a message of 55 bytes. By this rough measure, it is a little over 15.5 times the effort of FNV.¶
SHA-256 is, at the time of publication, considered to be a stronger cryptographic hash function than SHA-1. Ignoring SHA-256's initial setup, transfer of control, and conditional tests, but counting all logical and arithmetic operations, SHA-1 requires 2,058 operations per 64-byte block or 48.79 operations per byte for a message of 47 bytes. By this rough measure, it is over 24 times the effort of FNV.¶
However, FNV is commonly used for short inputs, so doing a comparison of such inputs is relevant. Using the above comparison method, for inputs of N bytes, where N is <= 55 so SHA-1 will take one block, the ratio of the effort for SHA-1 to the effort for FNV will be 872/N. For inputs of N bytes, where N is <= 47 so SHA-256 will take one block, the ratio of the effort for SHA-256 to the effort for FNV will be 1029/N. Some examples are given below.¶
Appendix B. Previous IETF FNV Code
FNV-1a was referenced in draft
Acknowledgements
The authors greatly appreciate the work of Glenn S. Fowler, who was part of the team that created the FNV algorithm.¶
The contributions of the following, listed in alphabetical order, are gratefully acknowledged:¶
Roman Donchenko, Frank Ellermann, Stephen Farrell, Tony Finch, Paul Hoffman, Charlie Kaufman, Eliot Lear, Bob Moskowitz, Gayle Noble, Stefan Santesson, Mukund Sivaraman, and Paul Wouters.¶