Is part of the address private key revealed when the user reattaches a failed transaction?

Question

A reattach is defined as follows:

Reattach: The process of reattaching a transaction is simply doing the proof of work and tip selection process to reattach the transaction to a different part of the Tangle. Reattach once every 30 minutes that a transaction remains pending, and then if still pending after 5 reattachments be sure to contact the sender to verify that the transaction wasn’t double spent.

Given that the inputs have already been signed and a web server is listening for reattaches, could the server then:

1. Detect a reattach
2. Stop the transaction (don't propagate it).
3. Sign a new stealing transaction with the address private key?

Additionally, could other nodes in the network use a found address key from a reattach to send a higher priority successful double spend by utilizing a much higher Minimum Weight Magnitude and sending it faster through a larger set of neighbors to the network?

Is the use of reattaches from failed Trinity transactions already exposing this vulnerability to users?

If not, what safeguards prevent this from happening?

Answer 1

You cannot get parts of the private key using reattachments. To understand why, let's see how signing works.

First of all, there is an unsigned bundle consisting out of several transactins. To sign it, we first need to calculate the bundle hash. Only the address, value, obsolete tag, timestamp, current index and last index are used. Note, nonce, trunk/branch tx and the tx hash are not required to sign a bundle

We then use the hash to calculate the signature for each input. Finally we select our branch and trunk tx and find s nonce so the final tx hash ends with 14 0-trits.

When reattaching, we use the same set of in-and outputs, so the bundle hash doesn't change. As the hash is the same, the signature is also the same. But as our trunk/branch tx has changed, we need to redo the PoW.

To successfully steal IOTA, we need an input signed several times with different bundle hashes. As the hash doesn't change it doesn't make any difference for an attacker if a transaction is reattached 0 or 100 times