This was one of my concerns when implementing a scheme where you sign a
refund transaction before the original transaction is broadcast. I
originally tried to pass a hash and have the server sign it. However, I
had no way to know that what I was signing wasn't a transaction that was
spending my coins! So I changed the code to require sending the full
transaction, not just the hash. The other way to mitigate this is through
not having any unspent outputs from this key.
For authentication, you could have both a user-generated and
server-generated portion, so that you signed something that clearly had
data from you, so even if the server-data was a hash of $EVIL_DOCUMENT, you
have clear plausible deniability in that your data that is also signed is
"ATTEMPTING LOGIN TO XYZ.COM Hash($EVIL_DOCUMENT)".
On Sat, Nov 2, 2013 at 4:51 PM, Mark Friedenbach <m...@monetize.io> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Or SIGHASH of a transaction spending those coins or updating the SIN...
>
> On 11/2/13 2:14 PM, Johnathan Corgan wrote:> On 11/01/2013 10:01 PM,
> bitcoingr...@gmx.com wrote:
> >
> >> Server provides a token for the client to sign.
> >
> > Anyone else concerned about signing an arbitrary string? Could be
> > a hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my
> > own randomly generated nonce, sign that, then pass the nonce and
> > the signature back to the server for verification.
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSdXPaAAoJEAdzVfsmodw4+m8P/1Ce/PwZOYfiFuFJ8pmT2tb2
> ro7tw7zSr12RSTvs+qRl7lDzJzQ6BDXOdXZCkcU0Vj3TDm8fdrrXN/iw3iQYU/5Y
> 3K7hj2mGqQUMovCLw0CbrMWrMvor7FhO6MZsRwe0+VxDV/dDrX5f5vSEhnkR26be
> NrzOFU4hqGM3R4eLq8Bmw5rVD/VCrRzKoXXAvJb1EwM1+fQPjKi+bNMJu3reyfXU
> 5eMbbiM6tUMmPXy9M6vZrN+6ad53x3KUVP6+/hXxsrnfPp57WQzRZlvwTo/qdJ1C
> Oxl71m6o2zkXbLTFmg1xmK/A4V1BPTLD6nLDIsw+wTBBfdn22pfDv6Q8d3VRctrd
> 6x+PMkwysoMjhemmkXCY/7G9GD6AGsrYSqIShSULd9QO5WxAFzRO01ewiRUCUFHi
> Dn0LEjy8/R/CWK3jvj9uL3vQh9DLdOtqf/X7cEtjF3LThVP+stFTsmXObhTh/8Ai
> YYjpnwOFG5ZtDzRZfP3OCwyhqlsaMlNgN4xnyR4GPaoJRP3a0zllblIbTWzg6nhY
> jbON5Ec9N9txGhagYOoAvcQYqGyJdffkBzW82CRUsFYuYYmW2oLUQXPhAGDBIzzj
> g/7RjMlM1OEp3qctxMZQlrTj7VJmhD768PRLh2XvEDmEC5Qb8Tcq28Nq5t85/O/6
> i3+pzT5rMuiIZWLx7Msv
> =tAUY
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
