# Non interactive anti-exfil (airgap compatible)

**URL:** <https://delvingbitcoin.org/t/non-interactive-anti-exfil-airgap-compatible/1081>\
**Category:** Protocol Design\
**Tags:** cryptography\
**Created:** [August 20, 2024, 3:15pm UTC](https://delvingbitcoin.org/t/non-interactive-anti-exfil-airgap-compatible/1081 "2024-08-20T15:15:29Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\
**Post date:** [August 20, 2024, 5:12pm UTC](https://delvingbitcoin.org/t/non-interactive-anti-exfil-airgap-compatible/1081/4 "2024-08-20T17:12:38Z")

</div>

i replaced `vc` with `hash` which should be understood as a cryptographically secure hash commitment to a list of parameters.

```plaintext
[Scheme 2: deterministic nonce, S2C tweak]
* SW generates random t, and requests a signature by sending (Q,m,t) to HW.
* HW computes k0=H(d,m,t), R0=k0G, k=k0+H(R0,t), R=kG,
  s=k+H(R,Q,m)d, and sends (R0,R,s) to SW.
* SW verifies sG=R+H(R,Q,m)Q, R=R0+H(R0,t)G, and publishes sig (R,s) if all
  is good.

```

this is indeed essentially the same! in this case my main question is answered. the scheme is good enough. i think we can proceed with formal specification, and maybe incorporation of support into secp256k1 lib, because people are in fact looking forward to use it.

---

_[View the full topic](https://delvingbitcoin.org/t/non-interactive-anti-exfil-airgap-compatible/1081)._