→top: see the talk page |
ToadetteEdit (talk | contribs) Declining submission: v - Submission is improperly sourced (AFCH) |
||
(9 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{AFC submission|d|v|u=Evgeny Kapun|ns=118|decliner=ToadetteEdit|declinets=20240421090408|ts=20240126003031}} <!-- Do not remove this line! --> |
|||
{{AFC comment|1=Feels that there are some original research. [[User:ToadetteEdit|<span style="color:#fc65b8;">'''Toadette'''</span>]] <sup>''([[User talk:ToadetteEdit|<span style="color:blue;">Let's talk together!</span>]])''</sup> 09:04, 21 April 2024 (UTC)}} |
|||
---- |
|||
{{Short description|Cryptographic technique}} |
{{Short description|Cryptographic technique}} |
||
{{Draft topics|computing|mathematics}} |
{{Draft topics|computing|mathematics}} |
||
{{AfC topic|stem}} |
{{AfC topic|stem}} |
||
{{AfC submission|||ts=20240126003031|u=Evgeny Kapun|ns=118}} |
|||
{{AfC submission|t||ts=20240125224202|u=Evgeny Kapun|ns=118|demo=}} |
|||
{{more footnotes|date=January 2024}} |
{{more footnotes|date=January 2024}} |
||
In [[cryptography]], '''domain separation''' is |
In [[cryptography]], '''domain separation''' is a construct used to implement multiple different functions using only one underlying template in an efficient way.{{sfn | Hampiholi | Alpár | van den Broek | Jacobs | 2015 | p=317}} For example, multiple [[cryptographic hash function]]s can be constructed from a single hash implementation by prepending different "domain identifier" strings to the input message. |
||
== 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 |
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 independent<ref>{{cite web|url=https://www.rfc-editor.org/rfc/rfc9380.html|title=RFC 9380: Hashing to Elliptic Curves|first1=A.|last1=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|date=August 2023 |issn=2070-1721}}</ref> (cf. {{link section|Random oracle|Domain separation}}). 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 16: | Line 20: | ||
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.<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| |
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|first1=Mihir|last1=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|first1=Arno|last1=Mittelbach|first2=Marc|last2=Fischlin|date=19 January 2021 |publisher=Springer |isbn=9783030632878}}</ref> |
||
== Kinds of functions == |
== Kinds of functions == |
||
Line 24: | Line 28: | ||
=== 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.<ref>{{cite conference|url=https://link.springer.com/chapter/10.1007/978-3-030-44223-1_28|title=Collapseability of Tree Hashes| |
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|first1=Aldo|last1=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>{{sfn | Hampiholi | Alpár | van den Broek | Jacobs | 2015 | p=317}} |
||
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| |
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|first1=Guido|last1=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|date=2023 }}</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.<ref>{{cite book|title=Real-World Cryptography|first=David|last=Wong|isbn=9781638350842}}</ref> |
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|date=19 October 2021 |publisher=Simon and Schuster |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| |
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|first1=Jean-Philippe|last1=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 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| |
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|first1=Erica|last1=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/> |
<references/> |
||
== Sources == |
|||
* {{cite book | last1=Hampiholi | first1=Brinda | last2=Alpár | first2=Gergely | last3=van den Broek | first3=Fabian | last4=Jacobs | first4=Bart | title=Security, Privacy, and Applied Cryptography Engineering | chapter=Towards Practical Attribute-Based Signatures | publisher=Springer International Publishing | publication-place=Cham | volume=9354 | date=2015 | isbn=978-3-319-24125-8 | doi=10.1007/978-3-319-24126-5_18 | pages=310–328 | chapter-url=https://books.google.com/books?id=RxOcCgAAQBAJ&pg=PA317 }} |
|||
== External links == |
== External links == |
||
Line 46: | Line 53: | ||
{{Draft categories| |
{{Draft categories| |
||
[[Category:Cryptography]] |
[[:Category:Cryptography]] |
||
}} |
}} |
Revision as of 09:04, 21 April 2024
- Comment: Feels that there are some original research. Toadette (Let's talk together!) 09:04, 21 April 2024 (UTC)
In cryptography, domain separation is a construct used to implement multiple different functions using only one underlying template in an efficient way.[1] For example, multiple cryptographic hash functions can be constructed from a single hash implementation by prepending different "domain identifier" strings to the input message.
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 independent[2] (cf. Random oracle § Domain separation). 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.[3][4]
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.[5][1]
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
- ^ a b Hampiholi et al. 2015, p. 317.
- ^ Faz-Hernandez, A.; Scott, S.; Sullivan, N.; Wahby, R. S.; Wood, C. A. (August 2023). "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 (19 January 2021). The Theory of Hash Functions and Random Oracles: An Approach to Modern Cryptography. Springer. 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.
- ^ Bertoni, Guido; Daemen, Joan; Hoffert, Seth; Peeters, Michaël; Van Assche, Gilles; Van Keer, Ronny; Viguier, Benoît (2023). "TurboSHAKE".
- ^ Wong, David (19 October 2021). Real-World Cryptography. Simon and Schuster. 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.
Sources
- Hampiholi, Brinda; Alpár, Gergely; van den Broek, Fabian; Jacobs, Bart (2015). "Towards Practical Attribute-Based Signatures". Security, Privacy, and Applied Cryptography Engineering. Vol. 9354. Cham: Springer International Publishing. pp. 310–328. doi:10.1007/978-3-319-24126-5_18. ISBN 978-3-319-24125-8.
External links