-In Perls 5.8.0 and earlier it was easy to create degenerate hashes.
-Processing such hashes would consume large amounts of CPU time,
-enabling a "Denial of Service" attack against Perl. Such hashes may be
-a problem for example for mod_perl sites, sites with Perl CGI scripts
-and web services, that process data originating from external sources.
-
-In Perl 5.8.1 a security feature was introduced to make it harder to
-create such degenerate hashes. A visible side effect of this was that
-the keys(), values(), and each() functions may return the hash elements
-in different order between different runs of Perl even with the same
-data. It also had unintended binary incompatibility issues with
-certain modules compiled against Perl 5.8.0.
-
-In Perl 5.8.2 an improved scheme was introduced. Hashes will return
-elements in the same order as Perl 5.8.0 by default. On a hash by hash
-basis, if pathological data is detected during a hash key insertion,
-then that hash will switch to an alternative random hash seed. As
-adding keys can always dramatically change returned hash element order,
-existing programs will not be affected by this, unless they
-specifically test for pre-recorded hash return order for contrived
-data. (eg the list of keys generated by C<map {"\0"x$_} 0..15> trigger
-randomisation) In effect the new implementation means that 5.8.1 scheme
-is only being used on hashes which are under attack.
-
-One can still revert to the old guaranteed repeatable order (and be
-vulnerable to attack by wily crackers) by setting the environment
-variable PERL_HASH_SEED, see L<perlrun/PERL_HASH_SEED>. Another option
-is to add -DUSE_HASH_SEED_EXPLICIT to the compilation flags (for
-example by using C<Configure -Accflags=-DUSE_HASH_SEED_EXPLICIT>), in
-which case one has to explicitly set the PERL_HASH_SEED environment
-variable to enable the security feature, or by adding -DNO_HASH_SEED to
-the compilation flags to completely disable the randomisation feature.
-
-B<Perl has never guaranteed any ordering of the hash keys>, and the
+Perl 5.18 reworked the measures used to secure its hash function
+from algorithmic complexity attacks. By default it will build with
+all of these measures enabled along with support for controlling and
+disabling them via environment variables.
+
+You can override various aspects of this feature by defining various
+symbols during configure. An example might be:
+
+ sh Configure -Accflags=-DPERL_HASH_FUNC_SIPHASH
+
+B<Unless stated otherwise these options are considered experimental or
+insecure and are not recommended for production use.>
+
+Since Perl 5.18 we have included support for multiple hash functions,
+although from time to time we change which functions we support,
+and which function is default (currently SBOX+STADTX on 64 bit builds
+and SBOX+ZAPHOD32 for 32 bit builds). You can choose a different
+algorithm by defining one of the following symbols during configure.
+Note that there security implications of which hash function you choose
+to use. The functions are listed roughly by how secure they are believed
+to be, with the one believed to be most secure at release time being PERL_HASH_FUNC_SIPHASH.
+
+ PERL_HASH_FUNC_SIPHASH
+ PERL_HASH_FUNC_SIPHASH13
+ PERL_HASH_FUNC_ZAPHOD32
+ PERL_HASH_FUNC_STADTX
+
+In addition, these, (or custom hash functions), may be "fronted" by the
+SBOX32 hash function for keys under a chosen size. This hash function is
+special in that it has proven theoretical security properties, and is very
+fast to hash, but which by nature is restricted to a maximum key length,
+and which has rather expensive setup costs (relatively speaking), both in
+terms of performance and more importantly in terms of memory. SBOX32
+requires 1k of storage per character it can hash, and it must populate that
+storage with 256 32-bit random values as well. In practice the RNG we use
+for seeding the SBOX32 storage is very efficient and populating the table
+required for hashing even fairly long keys is negligble as we only do it
+during startup. By default we build with SBOX32 enabled, but you change that
+by setting
+
+ PERL_HASH_USE_SBOX32_ALSO
+
+to zero in configure. By default Perl will use SBOX32 to hash strings 24 bytes
+or shorter, you can change this length by setting
+
+ SBOX32_MAX_LEN
+
+to the desired length, with the maximum length being 256.
+
+As of Perl 5.18 the order returned by keys(), values(), and each() is
+non-deterministic and distinct per hash, and the insert order for
+colliding keys is randomized as well, and perl allows for controlling this
+by the PERL_PERTURB_KEYS environment setting. You can disable this behavior
+entirely with the define
+
+ PERL_PERTURB_KEYS_DISABLED
+
+You can disable the environment variable checks and compile time specify
+the type of key traversal randomization to be used by defining one of these:
+
+ PERL_PERTURB_KEYS_RANDOM
+ PERL_PERTURB_KEYS_DETERMINISTIC
+
+Since Perl 5.18 the seed used for the hash function is randomly selected
+at process start, which can be overridden by specifying a seed by setting
+the PERL_HASH_SEED environment variable.
+
+You can change this behavior so that your perl is built with a hard coded
+seed with the define
+
+ NO_HASH_SEED
+
+Note that if you do this you should modify the code in hv_func.h to specify
+your own key. In the future this define may be renamed and replaced with one
+that requires you to specify the key to use.
+
+B<NOTE WELL: Perl has never guaranteed any ordering of the hash keys>, and the