fix(security): enforce Ed25519 verification and hide escrow_secret (#8179)

[shiyaam-s07]

Fixes #8179

🛡️ Security Vulnerability & Fix Overview

This PR resolves a high-severity security issue where GPU escrow creation endpoints (/render/escrow) accepted arbitrary from_wallet address inputs without validating ownership, while also leaking internal escrow_secret data back in the API payload.

1. Ed25519 Wallet Ownership Verification:

   • Extracted signature and message (nonce/timestamp) parameters from incoming payload requests in node/gpu_render_protocol.py.
   • Integrated cryptographic signature verification using the cryptography library (ed25519.Ed25519PublicKey) to guarantee that the caller strictly controls the corresponding from_wallet public key.
   • Implemented an immediate execution halt returning an HTTP 401 Unauthorized response if signatures are missing, malformed, or mathematically mismatched.

2. Data Leakage Redaction:

   • Stripped escrow_secret from the returned endpoint dictionary payload inside create_escrow, preventing unauthorized exposure of sensitive state secrets in API responses.

---

🧪 Automated Testing & Verification

• Expanded Security Test Cases (tests/test_gpu_render_protocol.py):
  • Valid Ownership Test: Verified that legitimate Ed25519 signed payloads create escrows cleanly.
  • Unauthorized Spoofing Test: Verified that mismatched private key signatures targeting another wallet are rejected with 401.
  • Missing Signature Test: Verified that requests missing cryptographic proof are rejected with 401.
  • Schema Sanitization Test: Asserted that escrow_secret is completely absent from API response outputs.
• Suite Health: Fixed syntax/merge artifacts in node/airdrop_v2.py to achieve a 100% test pass rate across the workspace via pytest.

---

📋 Checklist

• Code follows project formatting and style guidelines.
• Cryptographic verification implemented for all incoming wallet parameters.
• Sensitive fields redacted from API schema.
• Unit/Integration security tests added and passing.

[github-actions]

Welcome to RustChain! Thanks for your first pull request.

Before we review, please make sure:

• Non-doc PRs have a BCOS-L1 or BCOS-L2 label
• Doc-only PRs are exempt from BCOS tier labels when they only touch docs/**, *.md, or common image/PDF files
• New code files include an SPDX license header
• You've tested your changes against the live node

Bounty tiers: Micro (1-10 RTC) | Standard (20-50) | Major (75-100) | Critical (100-150)

A maintainer will review your PR soon. Thanks for contributing!

[shiyaam-s07]

Submitted fix in PR #8183 with Ed25519 signature verification and payload redaction for review!

[FlintLeng]

PR Review: Airdrop Token Ownership + GPU Escrow Ed25519 Signature

Reviewed on: 2026-08-07

Summary

Two distinct security fixes:

1. claim_airdrop now verifies GitHub token ownership — confirms the provided token belongs to the claimed username before processing the airdrop
2. create_escrow in GPU render protocol now requires Ed25519 signature over a message, authenticating the from_wallet; escrow_secret is stripped from API responses

Fix 1: Airdrop Token Verification ✅

The vulnerability: Without this check, anyone could submit a claim with a legitimate GitHub username (e.g., a famous contributor) and receive their airdrop allocation if the username happened to be in the snapshot. No ownership proof was required.

The fix is correct: GET /user with the provided token returns the authenticated user's login. The response is compared case-insensitively (casefold()) against the claimed github_username. Mismatch → claim rejected. This binds the token to the claimed identity.

Edge cases handled: Network failures (requests.RequestException) → fail closed (reject claim), not open. HTTP non-200 → reject. This is the right behaviour for a security-sensitive flow.

Fix 2: GPU Escrow Ed25519 Signature ✅

The vulnerability: create_escrow accepted a from_wallet address without cryptographic proof that the caller controls the corresponding private key. An attacker who knew a valid wallet address could create an escrow draining that wallet.

The fix is correct: Requires signature and message fields. Ed25519PublicKey.from_public_bytes(from_wallet).verify(sig_bytes, message.encode()) — standard Ed25519 verification using the wallet address as the public key. The attacker needs both the private key and a message signed with it.

Escrow secret stripped from response: result.pop("escrow_secret", None) prevents the secret from leaking in the API response. Clean.

Minor note: The Ed25519 key is derived from the wallet address bytes — bytes.fromhex(from_wallet). If from_wallet is not a valid Ed25519 public key (wrong length, invalid curve point), from_public_bytes raises ValueError, caught by the generic except Exception. This is acceptable as it rejects invalid keys, but a more specific catch could log differently.

Wallet: RTC019e78d600fb3131c29d7ba80aba8fe644be426e

✅ LGTM — two clean, targeted security fixes that close real attack surface.

[shiyaam-s07]

​"Thanks for the review @FlintLeng! Here is my actual RTC wallet address for the bounty: RTC834f28bba15768582b5d619e3f1f2d5f50d481b3"