You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: bip-0340.mediawiki
+19
Original file line number
Diff line number
Diff line change
@@ -237,6 +237,25 @@ the algorithms of the signature scheme will perform more hashing internally.
237
237
In particular, the hashing performed by the signing algorithm will process the message twice,
238
238
which leads to performance penalties for large messages.
239
239
240
+
==== Domain Separation ====
241
+
242
+
It is good cryptographic practice to use a key pair only for a single purpose.
243
+
Nevertheless, there may be situations in which it may be desirable to use the same key pair in multiple contexts,
244
+
i.e., to sign different types of messages within the same application
245
+
or even messages in entirely different applications
246
+
(e.g., a secret key may be used to sign Bitcoin transactions as well plain text messages).
247
+
248
+
As a consequence, applications should ensure that a signed application message intended for one context is never deemed valid in a different context
249
+
(e.g., a signed plain text message should never be misinterpreted as a signed Bitcoin transaction, because this could cause unintended loss of funds).
250
+
This is called "domain separation" and it is typically realized by partitioning the message space.
251
+
Even if key pairs are intended to be used only within a single context,
252
+
domain separation is a good idea because it makes it easy to add more contexts later.
253
+
254
+
As a best practice, we recommend to pre-process application messages before passing it the signature scheme as follows:
255
+
* Either, pre-hash the application message using ''hash<sub>tag</sub>'', where the ''tag'' is a byte string that identifies the context uniquely (e.g., "my-fancy-application/signing-foo-messages"),
256
+
* or prefix the actual message with a 64-byte string that identifies the context uniquely (e.g. "my-fancy-application/signing-foo-messages", padded with null bytes to 64 bytes).
257
+
As the two pre-processing methods yield different sizes (32 bytes vs. at least 64 bytes), there is no risk of collision between them.
258
+
240
259
== Applications ==
241
260
242
261
There are several interesting applications beyond simple signatures.
0 commit comments