Exploiting Duplicate R Values in Signatures

Hey everyone, I’ve been digging into this vulnerability tied to using the same R when signing with the same key. I got it to work with a bunch of examples. Check out these two transactions: fae3e414425f008196f9127a01dcea59e22ab66768ce5bcb4aba260993494de1 ab1deb8544de4bb1d3319e67b1bfc354601406d4a00ecbe8cbdd7674f96e9699 Both of them spent from 14tVK2JhEPsZEL7yYzMNXDYQ6dG3FnzzEY and share the same R value.

So yeah, I find z1 and z2 using the open up script, not the signature, and set irrelevant inputs to 0 length. But here’s the deal... the R value is missing its first byte, 0x00. The signature should be 33 bytes, so that’s a problem.

Good catch on that! I skipped mentioning it, but I had the 0x00 there. Still, those leading zeroes don’t seem to matter for calculating the key. I think it might be something else causing the issue.

Here’s the breakdown: R: 009ac20335eb38768d2052be1dbbc3c8f6178407458e51e6b4ad22f1d91758895b S1: 16c91427cb20a7321029c311e757dfee67f5e3f9bad23266fad8bf8aaf5cac01 Z1: e69364d551385880ddbb19338b633e2d6c17f1922817b3e3776851780b6aacb5 S2: 43273c2390b15bbe7e4d38559b1d4e6c0d63aad2c586652ec423d851df065271 Z2: 015b14bdc6f69058bfa8dcdc0e8bcd1fc87f4303804f200bfa6aadf627a8d5f6 PubKey: 036ee29b13e9d9f060d078bdcee464cb21aeafe5b5bc15206c5fa3c62f882c97c9

....and the end result is "9674578d05e0bc65284cc4db99420957858e1f57505baebb1d0d3e0d25957b7c". Pro tip: try using ( ORDER S1 ) instead of S1.

Wow, that worked! Thanks a bunch. So now I get it... we need the inverse of S1 sometimes. Is there a rule for when to do this? Like, does it happen if S crosses a certain limit?

Here’s a quick Python snippet for the math: from fastecdsa.curve import secp256k1 from fastecdsa.point import Point def extended_gcd(aa, bb):... Just gotta adjust for the inverse.

Hey, can you tweak r to get r, s, z for the same pubkey?