From d80e437ab1660a134c0cdd3e0397f37482e47f43 Mon Sep 17 00:00:00 2001 From: Tim Ruffing Date: Wed, 27 Jul 2022 16:01:04 +0200 Subject: bip340: Add subsection on Domain Separation --- bip-0340.mediawiki | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index 3b61c57..c941916 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -237,6 +237,26 @@ In particular, the signing algorithm needs two sequential hashing passes over th which means that the full message must necessarily be kept in memory during signing, and large messages entail a runtime penalty.Typically, messages of 56 bytes or longer enjoy a performance benefit from pre-hashing, assuming the speed of SHA256 inside the signing algorithm matches that of the pre-hashing done by the calling application. +==== Domain Separation ==== + +It is good cryptographic practice to use a key pair only for a single purpose. +Nevertheless, there may be situations in which it may be desirable to use the same key pair in multiple contexts, +i.e., to sign different types of messages within the same application +or even messages in entirely different applications +(e.g., a secret key may be used to sign Bitcoin transactions as well plain text messages). + +As a consequence, applications should ensure that a signed application message intended for one context is never deemed valid in a different context +(e.g., a signed plain text message should never be misinterpreted as a signed Bitcoin transaction, because this could cause unintended loss of funds). +This is called "domain separation" and it is typically realized by partitioning the message space. +Even if key pairs are intended to be used only within a single context, +domain separation is a good idea because it makes it easy to add more contexts later. + +As a best practice, we recommend applications to use exactly one of the following methods to pre-process application messages before passing it to the signature scheme: +* Either, pre-hash the application message using ''hashname'', where ''name'' identifies the context uniquely (e.g., "foo-app/signed-bar"), +* or prefix the actual message with a 33-byte string that identifies the context uniquely (e.g., the UTF-8 encoding of "foo-app/signed-bar", padded with null bytes to 33 bytes). + +As the two pre-processing methods yield different message sizes (32 bytes vs. at least 33 bytes), there is no risk of collision between them. + == Applications == There are several interesting applications beyond simple signatures. -- cgit v1.2.3