fix: use domain separation for wallet message signing #5400
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4 tasks
AaronFeickert
force-pushed
the
wallet-message-signing
branch
2 times, most recently
from
ce1cfd5 to
cb338c9
Compare
AaronFeickert
force-pushed
the
wallet-message-signing
branch
from
cb338c9 to
d6e7927
Compare
stringhandler
approved these changes
May 22, 2023
ghpbot-tari-project
added
the
P-acks_required
Well, and there isn't a common standard for Schnorr-like signatures over arbitrary curves. Domain separation is handled in a really haphazard (and sometimes nonexistent) way across standards including things like RFC 8032. Writing a compatible verifier outside of Rust wouldn't be that tricky, |
|
While it's not directly applicable here, this is a good read on how subtle even something as seemingly simple as |
SWvheerden
added a commit
that referenced
this pull request
May 29, 2023
## [0.50.0-pre.2](v0.50.0-pre.1...v0.50.0-pre.2) (2023-05-29) ### ⚠ BREAKING CHANGES * add optional range proof types (5372) ### Features * add metadata signature check ([5411](#5411)) ([9c2bf41](9c2bf41)) * add optional range proof types ([5372](#5372)) ([f24784f](f24784f)) * added burn feature to the console wallet ([5322](#5322)) ([45685b9](45685b9)) * improved base node monitoring ([5390](#5390)) ([c704890](c704890)) ### Bug Fixes * **comms:** only set final forward address if configured to port 0 ([5406](#5406)) ([ff7fb6d](ff7fb6d)) * deeplink to rfc spec ([5342](#5342)) ([806d3b8](806d3b8)) * don't use in memory datastores for chat client dht in integration tests ([#5399](#5399)) ([cbdca6f](cbdca6f)) * fix panic when no public addresses ([5367](#5367)) ([49be2a2](49be2a2)) * loop on mismatched passphrase entry ([5396](#5396)) ([ed120b2](ed120b2)) * use domain separation for wallet message signing ([5400](#5400)) ([7d71f8b](7d71f8b))
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Uses domain separation for wallet message Schnorr signatures to prevent context misuse. Supersedes PR 5394.
Motivation and Context
Wallets can sign and verify arbitrary messages using their secret keys. Because such messages are signed using Schnorr signatures with a default Fiat-Shamir challenge hash domain, it may be possible to replay them in different contexts, with possibly dangerous consequences.
Another pending PR suggests prepending fixed data to wallet messages, but this can still lead to collisions.
Fortunately, the
tari-cryptosignature API provides a handy type alias that makes domain separation straightforward. Using this, it is not possible to produce signature collisions (up to the collision resistance of the hash function itself). This is a safer and more idiomatic design.How Has This Been Tested?
An existing test passes.
What process can a PR reviewer use to test or verify this change?
Confirm that the
tari-cryptosignature API is being used correctly, and that the macro-derived domain separator is unique within the codebase.Breaking Changes
Existing signatures will fail to verify, but this is unlikely to be problematic.