TON proof updates #342

Vladimir-Khm · 2025-07-07T10:59:57Z

1. Its very hard to know what exactly payload was sent

func (v *TonConnectVerifier) VerifyProof(ctx context.Context, addr *address.Address, proof TonConnectProof, expectedPayload string, stateInit []byte) error {
	// ...

	if proof.Payload != expectedPayload {
		return errors.New("invalid payload in proof")
	}

	// ..
}

ton/wallet/proof.go

In the current implementation, when verifying TON proof, you need to remember the exact payload your server sent to the user. In practice, this can be very difficult or impossible

A better approach to verify that the payload was sent by your server is to sign the payload. This way, you can easily verify its origin without having to remember it exactly (similar to JWT)

Proposed Solution

The solution involves introducing two functions: GeneratePayload and CheckPayload, and simplify VerifyProof

GeneratePayload: Generates a payload containing a random value and an expiration timestamp, then signs it using a secret.
CheckPayload: Verifies the signature of the payload and validates the expiration timestamp.

Additionally, we can provide a new function, VerifyProofWithPayload, which accepts a custom payloadVerifier function to handle the payload verification logic:

func (v *TonConnectVerifier) VerifyProofWithPayload(ctx context.Context, addr *address.Address, proof TonConnectProof, stateInit []byte, payloadVerifier func(payload, secret string) error, secret string) error {
	if err := payloadVerifier(proof.Payload, secret); err != nil {
		return fmt.Errorf("payload check failed: %w", err)
	}

	return v.VerifyProof(ctx, addr, proof, stateInit)
}

Remove the payload check from VerifyProof, as it is unrelated to the core verification logic:

func (v *TonConnectVerifier) VerifyProof(ctx context.Context, addr *address.Address, proof TonConnectProof, stateInit []byte) error {
	// ...
}

2. Optimize getting a public key

When verifying a signature, we need to retrieve the public key. There are two possible ways:

Parse from stateInit (already provided in the request)
Or fetch via API or other external request if the wallet is already initialized

Currently, the implementation prioritizes fetching the public key via an API request and falls back to parsing it from stateInit only if the API request fails. However, parsing the key from stateInit is much faster and more reliable since it avoids making an external request

It will be more optimized to make the vice versa approach: firstly, try to parse the key from stateInit, as it's faster, and generally, we have it. And only if it fails, try to get the public key from the request, as it is longer and less reliable:

func (v *TonConnectVerifier) getPubKey(ctx context.Context, addr *address.Address, stateInit []byte) (ed25519.PublicKey, error) {
	// First, try to get public key "offline" from stateInit
	key, err := getPublicKeyFromStateInit(addr, stateInit)

	// Only if it's impossible to parse public key from stateInit, make a request to get it
	if err != nil {
		key, err = GetPublicKey(ctx, v.client, addr)
		if err != nil {
			return nil, fmt.Errorf("failed to get public key: %w", err)
		}
	}

	return key, nil
}

- VerifyProof verifies only proof, not payload. VerifyProofWithPayload to check with payload - Payload generation and check functions

xssnick · 2025-07-08T12:14:44Z

ton/wallet/proof.go

+	h := hmac.New(sha256.New, []byte(secret))
+	h.Write(payload)
+	payload = h.Sum(payload)
+	return hex.EncodeToString(payload[:32]), nil


Lets increase random size to 24 bytes and keep whole hash, not only 16 bytes, it costs us almost nothing, but looks more secure

Or we can add half of domain hash (16 bytes) to payload before hashing, for example, to additionally bound to domain

Thanks for your comments! I agree that keeping all hash is more secure, so let's do it)

The random bytes in the payload ensure uniqueness, but they don’t improve cryptographic security, which comes from hmac and its secret. Increasing the random bytes won’t make payload more secure, but ok, let's enlarge it 16 bytes to make random nonce more distributed

As for domain, it could be useful in complex systems with multiple domains, but in a single-domain system it doesn’t add much value. Plus, we then check the domain in VerifyProof

So checking the full hash is very reasonable, but increasing random bytes or adding domain may not actually increase security. Should I add a commit to check the full hash and enlarge random bytes to 16?

While hashing only 16 bytes we can get only 2^128 unique hashes (so it is almost same as keeping 16 bytes of hash), but when we increasing payload to 32 bytes we could get up to 2^256 unique hashes, and full hash security is utilized.

So i think lets increase random size and check full hash

Thanks for the explanation, it's really so. I'll fix it)

Vladimir-Khm added 2 commits July 7, 2025 11:44

VerifyProof payload check update

845ffa2

- VerifyProof verifies only proof, not payload. VerifyProofWithPayload to check with payload - Payload generation and check functions

Optimize getting a public key. Try to parse it from stateInit first

7e11201

Vladimir-Khm mentioned this pull request Jul 7, 2025

TON proof improvments #343

Open

xssnick changed the base branch from master to dev-14 July 8, 2025 12:08

xssnick reviewed Jul 8, 2025

View reviewed changes

Make GeneratePayload and CheckPayload more secure

063a296

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

TON proof updates #342

TON proof updates #342

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TON proof updates #342

Are you sure you want to change the base?

TON proof updates #342

Uh oh!

Conversation

1. Its very hard to know what exactly payload was sent

Proposed Solution

2. Optimize getting a public key

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!