Significa liberdade (talk | contribs) AFC draft Tag: moveToDraft |
Evgeny Kapun (talk | contribs) Added references Tag: 2017 wikitext editor |
||
Line 8: | Line 8: | ||
== Example == |
== Example == |
||
Suppose that a certain application needs two [[Cryptographic hash function|hash functions]]. Using the same function for both of them is not always possible ‒ there may be reasons why they must be different. An obvious solution may be to pick two existing hash functions ‒ say, [[SHA-2]] and [[SHA-3]] ‒ and use them. |
Suppose that a certain application needs two [[Cryptographic hash function|hash functions]]. Using the same function for both of them is not always possible ‒ there may be reasons why they must be different.<ref>{{cite web|url=https://www.rfc-editor.org/rfc/rfc9380.html|title=RFC 9380: Hashing to Elliptic Curves|first=A.|last=Faz-Hernandez|first2=S.|last2=Scott|first3=N.|last3=Sullivan|first4=R. S.|last4=Wahby|first5=C. A.|last5=Wood|at=2.2.5. Domain Separation|series=The RFC Series|issn=2070-1721}}</ref> An obvious solution may be to pick two existing hash functions ‒ say, [[SHA-2]] and [[SHA-3]] ‒ and use them. |
||
However, this solution is problematic. Different functions may have different performance and security characteristics, so it is desirable to use the one that suits best everywhere. New functions are designed to improve on the old ones or to support different use cases, not just to increase the number of different functions in existence. Also, using multiple functions like this increases implementation footprint and potential attack surface. |
However, this solution is problematic. Different functions may have different performance and security characteristics, so it is desirable to use the one that suits best everywhere. New functions are designed to improve on the old ones or to support different use cases, not just to increase the number of different functions in existence. Also, using multiple functions like this increases implementation footprint and potential attack surface. |
||
Line 14: | Line 14: | ||
A much better solution is to use just one function, but to use a subset of the possible inputs for one hash, and another (disjoint) subset for the other. Because an input to a hash function is an arbitrarily long string, this is easy to implement: just prepend 0 to the input for one function, and 1 for the other. Formally, given a function <math>\mathcal H(x)</math>, the new functions would be <math>\mathcal H_1(x)=\mathcal H(0||x)</math> and <math>\mathcal H_2(x)=\mathcal H(1||x)</math> (here, <math>||</math> denotes concatenation). |
A much better solution is to use just one function, but to use a subset of the possible inputs for one hash, and another (disjoint) subset for the other. Because an input to a hash function is an arbitrarily long string, this is easy to implement: just prepend 0 to the input for one function, and 1 for the other. Formally, given a function <math>\mathcal H(x)</math>, the new functions would be <math>\mathcal H_1(x)=\mathcal H(0||x)</math> and <math>\mathcal H_2(x)=\mathcal H(1||x)</math> (here, <math>||</math> denotes concatenation). |
||
The functions <math>\mathcal H_1</math> and <math>\mathcal H_2</math> produced like this behave as separate, independent hash functions: because their inputs to <math>\mathcal H</math> don't overlap and because the outputs of <math>\mathcal H</math> on different inputs are [[Statistical independence|statistically independent]] (at least so far as a hash function is considered an approximation for a [[random oracle]]), the outputs of <math>\mathcal H_1</math> and <math>\mathcal H_2</math> on any inputs are likewise independent. This approach can be generalized to any number of functions, and to different kinds of functions. |
The functions <math>\mathcal H_1</math> and <math>\mathcal H_2</math> produced like this behave as separate, independent hash functions: because their inputs to <math>\mathcal H</math> don't overlap and because the outputs of <math>\mathcal H</math> on different inputs are [[Statistical independence|statistically independent]] (at least so far as a hash function is considered an approximation for a [[random oracle]]), the outputs of <math>\mathcal H_1</math> and <math>\mathcal H_2</math> on any inputs are likewise independent. This approach can be generalized to any number of functions, and to different kinds of functions.<ref>{{cite conference|url=https://link.springer.com/chapter/10.1007/978-3-030-45724-2_1|title=Separate Your Domains: NIST PQC KEMs, Oracle Cloning and Read-Only Indifferentiability|first=Mihir|last=Bellare|first2=Hannah|last2=Davis|first3=Felix|last3=Günther|date=1 May 2020|book-title=Advances in Cryptology – EUROCRYPT 2020|doi=10.1007/978-3-030-45724-2_1}}</ref><ref>{{cite book|title=The Theory of Hash Functions and Random Oracles: An Approach to Modern Cryptography|first=Arno|last=Mittelbach|first2=Marc|last2=Fischlin|isbn=9783030632878}}</ref> |
||
== Kinds of functions == |
== Kinds of functions == |
||
Line 22: | Line 22: | ||
=== Hash functions === |
=== Hash functions === |
||
Domain separation is most commonly used with hash functions. Because the domain of a hash function is practically unlimited, it is not difficult to partition it among any number of sub-functions. This is commonly done by prepending or appending to the message a distinct string (domain separator) for each sub-function. |
Domain separation is most commonly used with hash functions. Because the domain of a hash function is practically unlimited, it is not difficult to partition it among any number of sub-functions. This is commonly done by prepending or appending to the message a distinct string (domain separator) for each sub-function.<ref>{{cite conference|url=https://link.springer.com/chapter/10.1007/978-3-030-44223-1_28|title=Collapseability of Tree Hashes|first=Aldo|last=Gunsing|first2=Bart|last2=Mennink|date=10 April 2020|book-title=PQCrypto 2020: Post-Quantum Cryptography|doi=10.1007/978-3-030-44223-1_28}}</ref><ref>{{cite conference|url=https://link.springer.com/chapter/10.1007/978-3-319-24126-5_18|title=Towards Practical Attribute-Based Signatures|first=Brinda|last=Hampiholi|first2=Gergely|last2=Alpár|first3=Fabian|last3=van den Broek|first4=Bart|last4=Jacobs|date=13 November 2015|book-title=SPACE 2015: Security, Privacy, and Applied Cryptography Engineering|doi=10.1007/978-3-319-24126-5_18}}</ref> |
||
Domain separation is used within the implementation of some hash functions to produce multiple different functions from the same design. For example, [[SHA-224]] is almost identical to [[SHA-256]] truncated to 224 bits. However, without additional modifications, it would have certain undesirable properties (for example, it would be possible to compute SHA-224 hash of a message knowing only its SHA-256 hash, something that is not possible for arbitrary different hash functions), so a modification was made to make SHA-224 produce a different output without changing its design (specifically, the initialization constants are different). |
Domain separation is used within the implementation of some hash functions to produce multiple different functions from the same design.<ref>{{cite web|url=https://eprint.iacr.org/2023/342|title=TurboSHAKE|first=Guido|last=Bertoni|first2=Joan|last2=Daemen|first3=Seth|last3=Hoffert|first4=Michaël|last4=Peeters|first5=Gilles|last5=Van Assche|first6=Ronny|last6=Van Keer|first7=Benoît|last7=Viguier}}</ref> For example, [[SHA-224]] is almost identical to [[SHA-256]] truncated to 224 bits. However, without additional modifications, it would have certain undesirable properties (for example, it would be possible to compute SHA-224 hash of a message knowing only its SHA-256 hash, something that is not possible for arbitrary different hash functions), so a modification was made to make SHA-224 produce a different output without changing its design (specifically, the initialization constants are different). |
||
=== Symmetric ciphers and MACs === |
=== Symmetric ciphers and MACs === |
||
The security of [[symmetric cipher]]s and [[Message authentication code|MAC]]s critically depends of the key not being used for other purposes. If an application needs multiple keys but has only one source of [[keying material]], it would typically employ a [[key derivation function]] to produce the keys. KDFs can usually produce output of arbitrary length, so they can be used to generate any number of keys. |
The security of [[symmetric cipher]]s and [[Message authentication code|MAC]]s critically depends of the key not being used for other purposes. If an application needs multiple keys but has only one source of [[keying material]], it would typically employ a [[key derivation function]] to produce the keys. KDFs can usually produce output of arbitrary length, so they can be used to generate any number of keys.<ref>{{cite book|title=Real-World Cryptography|first=David|last=Wong|isbn=9781638350842}}</ref> |
||
Also, just like hash functions, some symmetric ciphers and MACs use domain separation internally.<ref>{{cite conference|url=https://link.springer.com/chapter/10.1007/978-3-319-11212-1_2|title=NORX: Parallel and Scalable AEAD|first=Jean-Philippe|last=Aumasson|first2=Philipp|last2=Jovanovic|first3=Samuel|last3=Neves|book-title=Computer Security - ESORICS 2014|doi=10.1007/978-3-319-11212-1_2}}</ref> |
|||
=== Signatures === |
=== Signatures === |
||
In many cases, it is desirable to use a single signing key to produce [[digital signature]]s for different |
In many cases, it is desirable to use a single signing key to produce [[digital signature]]s for different purposes. If this is done, it is important to make sure that signed messages intended for one purpose cannot be used for the other. A simple way to achieve this is to add to each message an identifier specifying the purpose, and to reject a message if the identifier doesn't match.<ref>{{cite conference|url=https://link.springer.com/chapter/10.1007/978-3-030-36030-6_6|title=Synchronous Consensus with Optimal Asynchronous Fallback Guarantees|first=Erica|last=Blum|first2=Jonathan|last2=Katz|first3=Julian|last3=Loss|date=22 November 2019|book-title=TCC 2019: Theory of Cryptography|doi=10.1007/978-3-030-36030-6_6}}</ref> |
||
== References == |
== References == |
||
<references/> |
|||
* {{cite web|url=https://csrc.nist.gov/glossary/term/Domain_Separation#name-domain-separation|title=Domain Separation - Glossary|website=[[NIST]] Computer Security Resource Center}} |
|||
* {{cite web|url=https://www.rfc-editor.org/rfc/rfc9380.html|title=RFC 9380: Hashing to Elliptic Curves|first=A.|last=Faz-Hernandez|first2=S.|last2=Scott|first3=N.|last3=Sullivan|first4=R. S.|last4=Wahby|first5=C. A.|last5=Wood|at=2.2.5. Domain Separation|series=The RFC Series|issn=2070-1721}} |
|||
* {{cite web|url=https://eprint.iacr.org/2020/241|title=Separate Your Domains: NIST PQC KEMs, Oracle Cloning and Read-Only Indifferentiability|first=Mihir|last=Bellare|first2=Hannah|last2=Davis|first3=Felix|last3=Günther}} |
|||
== External links == |
== External links == |
Revision as of 00:29, 26 January 2024
In cryptography, domain separation is a method used to implement multiple different functions of the same kind using only one such function. This is done by partitioning the set of values that the function's parameters may take (the function's domain) between the new functions.
Example
Suppose that a certain application needs two hash functions. Using the same function for both of them is not always possible ‒ there may be reasons why they must be different.[1] An obvious solution may be to pick two existing hash functions ‒ say, SHA-2 and SHA-3 ‒ and use them.
However, this solution is problematic. Different functions may have different performance and security characteristics, so it is desirable to use the one that suits best everywhere. New functions are designed to improve on the old ones or to support different use cases, not just to increase the number of different functions in existence. Also, using multiple functions like this increases implementation footprint and potential attack surface.
A much better solution is to use just one function, but to use a subset of the possible inputs for one hash, and another (disjoint) subset for the other. Because an input to a hash function is an arbitrarily long string, this is easy to implement: just prepend 0 to the input for one function, and 1 for the other. Formally, given a function , the new functions would be and (here, denotes concatenation).
The functions and produced like this behave as separate, independent hash functions: because their inputs to don't overlap and because the outputs of on different inputs are statistically independent (at least so far as a hash function is considered an approximation for a random oracle), the outputs of and on any inputs are likewise independent. This approach can be generalized to any number of functions, and to different kinds of functions.[2][3]
Kinds of functions
Domain separation can be used with functions implementing different cryptographic primitives.
Hash functions
Domain separation is most commonly used with hash functions. Because the domain of a hash function is practically unlimited, it is not difficult to partition it among any number of sub-functions. This is commonly done by prepending or appending to the message a distinct string (domain separator) for each sub-function.[4][5]
Domain separation is used within the implementation of some hash functions to produce multiple different functions from the same design.[6] For example, SHA-224 is almost identical to SHA-256 truncated to 224 bits. However, without additional modifications, it would have certain undesirable properties (for example, it would be possible to compute SHA-224 hash of a message knowing only its SHA-256 hash, something that is not possible for arbitrary different hash functions), so a modification was made to make SHA-224 produce a different output without changing its design (specifically, the initialization constants are different).
Symmetric ciphers and MACs
The security of symmetric ciphers and MACs critically depends of the key not being used for other purposes. If an application needs multiple keys but has only one source of keying material, it would typically employ a key derivation function to produce the keys. KDFs can usually produce output of arbitrary length, so they can be used to generate any number of keys.[7]
Also, just like hash functions, some symmetric ciphers and MACs use domain separation internally.[8]
Signatures
In many cases, it is desirable to use a single signing key to produce digital signatures for different purposes. If this is done, it is important to make sure that signed messages intended for one purpose cannot be used for the other. A simple way to achieve this is to add to each message an identifier specifying the purpose, and to reject a message if the identifier doesn't match.[9]
References
- ^ Faz-Hernandez, A.; Scott, S.; Sullivan, N.; Wahby, R. S.; Wood, C. A. "RFC 9380: Hashing to Elliptic Curves". The RFC Series. 2.2.5. Domain Separation. ISSN 2070-1721.
- ^ Bellare, Mihir; Davis, Hannah; Günther, Felix (1 May 2020). "Separate Your Domains: NIST PQC KEMs, Oracle Cloning and Read-Only Indifferentiability". Advances in Cryptology – EUROCRYPT 2020. doi:10.1007/978-3-030-45724-2_1.
- ^ Mittelbach, Arno; Fischlin, Marc. The Theory of Hash Functions and Random Oracles: An Approach to Modern Cryptography. ISBN 9783030632878.
- ^ Gunsing, Aldo; Mennink, Bart (10 April 2020). "Collapseability of Tree Hashes". PQCrypto 2020: Post-Quantum Cryptography. doi:10.1007/978-3-030-44223-1_28.
- ^ Hampiholi, Brinda; Alpár, Gergely; van den Broek, Fabian; Jacobs, Bart (13 November 2015). "Towards Practical Attribute-Based Signatures". SPACE 2015: Security, Privacy, and Applied Cryptography Engineering. doi:10.1007/978-3-319-24126-5_18.
- ^ Bertoni, Guido; Daemen, Joan; Hoffert, Seth; Peeters, Michaël; Van Assche, Gilles; Van Keer, Ronny; Viguier, Benoît. "TurboSHAKE".
- ^ Wong, David. Real-World Cryptography. ISBN 9781638350842.
- ^ Aumasson, Jean-Philippe; Jovanovic, Philipp; Neves, Samuel. "NORX: Parallel and Scalable AEAD". Computer Security - ESORICS 2014. doi:10.1007/978-3-319-11212-1_2.
- ^ Blum, Erica; Katz, Jonathan; Loss, Julian (22 November 2019). "Synchronous Consensus with Optimal Asynchronous Fallback Guarantees". TCC 2019: Theory of Cryptography. doi:10.1007/978-3-030-36030-6_6.
External links