Various XMPP extensions make use of cryptographic hash functions, but they do so in different ways (e.g., some define XML elements and some define XML attributes) and often mandate support for different algorithms.
This specification provides recommendations from the XMPP council as to which cryptographic hash functions should and should not be used by XMPP entities.
This recommendation does not specify the hash algorithms themselves; it merely refers to existing algorithms.
Use of Cryptographic Hash Functions in XMPP (XEP-0300) [1] (which historically has contained the recommendations in this specification) describes a common wire-format to be used to transport hash function values in XMPP.
This recommendation should meet the following goals:
This specification is not meant to override recommendations or requirements laid out by other specifications. Other specifications can however defer their recommendations or requirements to this specification.
A specification which makes use of cryptographic hash functions (such as Jingle File Transfer (XEP-0234) [2] or Entity Capabilities 2.0 (XEP-0390) [3]) can refer to this specification instead of making recommendations on hash functions on their own.
If a protocol specification defers its decision on hash functions to this document, it should support transporting multiple hashes at the same time (preferably using Use of Cryptographic Hash Functions in XMPP (XEP-0300) [1]).
By default, when an entity receives multiple hash function values for the same input, it SHOULD either (a) use all hash values or (b) the hash value of the algroithm with the most security confidence for verification purposes.
The MD2 algorithm is not used in any XMPP protocols and has been deprecated by the IETF (see RFC 6149 [4]).
The MD4 algorithm is not used in any XMPP protocols and has been deprecated by the IETF (see RFC 6150 [5]).
The MD5 algorithm was commonly used in earlier generations of Internet technologies. As explained in RFC 6151 [6], the MD5 algorithm "is no longer acceptable where collision resistance is required" (such as in digital signatures) and "new protocol designs should not employ HMAC-MD5" either.
The currently known best attack against the pre-image resistance property of the MD5 algorithm is slightly better than the generic attack and was released 2009 [7].
The primary use of MD5 in XMPP protocols is SI File Transfer (XEP-0096) [8], which will be obsoleted by Jingle File Transfer (XEP-0234) [2].
The SHA-0 algorithm was developed by the U.S. National Security Agency and first published in 1993. It was never widely deployed and is not used in any XMPP protocols.
The SHA-1 algorithm was developed by the U.S. National Security Agency and first published in 1995 to fix problems with SHA-0. The SHA-1 algorithm is currently the most widely-deployed hash function. As described in RFC 4270 [9] in 2005, attacks have been found against the collision resistance property of SHA-1. RFC 6194 [10] notes that as of 2011 no published results indicate improvement upon those attacks. In addition, RFC 6194 notes that "[t]here are no known pre-image or second pre-image attacks that are specific to the full round SHA-1 algorithm". Furthermore, there is no indication that attacks on SHA-1 can be extended to HMAC-SHA-1. Nevertheless, the U.S. National Institute of Standards and Technology (NIST) has recommended that SHA-1 not be used for generating digital signatures after December 31, 2010.
In fall 2015 the SHA-1 collision cost has been estimated between 75K$ to 120K$ [11].
The SHA-2 family of algorithms (SHA-224, SHA-256, SHA-384, and SHA-512) was developed by the U.S. National Security Agency and first published in 2001. Because SHA-2 is somewhat similar to SHA-1, it is thought that the security flaws with SHA-1 described above could be extended to SHA-2 (although no such attacks have yet been found on the full-round SHA-2 algorithms).
The SHA-3 family of algorithms (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) is based on the Keccak algortihm developed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, and was pubished by NIST on August 5, 2015 in FIPS PUB 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions [12] after a public hash function competition.
The BLAKE2 family of algorithms was designed by Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn, and Christian Winnerlein. It is described in RFC 7693 [13] and is designed to be highly secure and run well on both software and hardware platforms.
The current recommendations are as follows:
| Algorithm | Digest Size | Support |
|---|---|---|
| MD2 | 128 bits | MUST NOT |
| MD4 | 128 bits | MUST NOT |
| MD5 | 128 bit | MUST NOT |
| SHA-1 | 160 bits | SHOULD NOT |
| SHA-256 | 256 bits | MUST |
| SHA-512 | 512 bits | SHOULD |
| SHA3-256 | 256 bits | MUST |
| SHA3-512 | 512 bits | SHOULD |
| BLAKE2b256 | 256 bits | SHOULD |
| BLAKE2b512 | 512 bits | MUST |
These recommendations ought to be reviewed yearly by the XMPP Council [14].
Thanks to the authors and involved people in Use of Cryptographic Hash Functions in XMPP (XEP-0300) [1]; This specification is a mostly verbatim excerpt of a Use of Cryptographic Hash Functions in XMPP (XEP-0300) [1] version 0.5.3.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. XEP-0300: Use of Cryptographic Hash Functions in XMPP <https://xmpp.org/extensions/xep-0300.html>.
2. XEP-0234: Jingle File Transfer <https://xmpp.org/extensions/xep-0234.html>.
3. XEP-0390: Entity Capabilities 2.0 <https://xmpp.org/extensions/xep-0390.html>.
4. RFC 6149: MD2 to Historic Status <http://tools.ietf.org/html/rfc6149>.
5. RFC 6150: MD4 to Historic Status <http://tools.ietf.org/html/rfc6150>.
6. RFC 6151: Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms <http://tools.ietf.org/html/rfc6151>.
7. Yu Sasaki and Kazumaro Aoki, "Finding preimages in full MD5 faster than exhaustive search" <https://doi.org/10.1007/978-3-642-01001-9_8>.
8. XEP-0096: SI File Transfer <https://xmpp.org/extensions/xep-0096.html>.
9. RFC 4270: Attacks on Cryptographic Hashes in Internet Protocols <http://tools.ietf.org/html/rfc4270>.
10. RFC 6194: Updated Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms <http://tools.ietf.org/html/rfc6194>.
11. The SHAppening: freestart collisions for SHA-1 <https://sites.google.com/site/itstheshappening/>.
12. FIPS PUB 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions <http://dx.doi.org/10.6028/NIST.FIPS.202>.
13. RFC 7693: The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) <http://tools.ietf.org/html/rfc7693>.
14. The XMPP Council is a technical steering committee, authorized by the XSF Board of Directors and elected by XSF members, that approves of new XMPP Extensions Protocols and oversees the XSF's standards process. For further information, see <https://xmpp.org/about/xmpp-standards-foundation#council>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Split from XEP-0300.
END