highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 13:22:51 +01:00
Code Issues Packages Projects Releases Wiki Activity

bip340: Add subsection on Domain Separation

Browse Source
This commit is contained in:
Tim Ruffing 2022-07-27 16:01:04 +02:00 committed by Pieter Wuille
parent 200f9b26fe
commit d80e437ab1
1 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
bip-0340.mediawiki
View File

@ -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.<ref>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.</ref>
==== 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 ''hash<sub>name</sub>'', 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.