From: "Michael Grønager" <gronager@mac•com>
To: Alan Reiner <etotheipi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
Date: Wed, 04 Apr 2012 10:35:12 +0200 [thread overview]
Message-ID: <416DB500-46F1-4249-8728-F08B1FFADE11@mac.com> (raw)
In-Reply-To: <CA+s+GJBFYNZjOzRJd19wZ29h-uKqaVNx-RhnsgGpRAMg-nRgZw@mail.gmail.com>
Hi Alan,
I am using an approach similar to your proposal in a service I am developing. I have, however, chosen to sign using the following scheme:
1. take sha512 of document (=hash512)
2. take ripemd160 of hash512
3. create 512 bit data structure, where the first 352bits are '0', and the rest is the ripemd160 of our hash512
4. sign it with the key
This procedure prevents an evil site from fooling you to sign a transaction spending your own coins. So bottom like never sign a full sha512 with a key for any other purpose than a transaction. (The above could easily well have been implemented as just truncating the hash512 to 256 bits, feel free to propose the optimal scheme).
/M
On 04/04/2012, at 08:23, Wladimir wrote:
> Alan,
>
> On Wed, Apr 4, 2012 at 2:01 AM, Alan Reiner <etotheipi@gmail•com> wrote:
> There is all this fanfare around P2SH and how multi-sig is the solution to all these security problems, but how the hell do you use it? I believe that BIP 10 (or successor) is critical to the success of multi-sig, because the greatest barrier to using multi-sig will be the ability to actually execute them in less than 14 steps. And if every client implements it differently, there's even less chance it will be used (assuming the userbase reaches any level of client diversity).
>
> That is a laudable goal.
>
> So your proposal is about signing "Preformatted messages from sites" to make financial transactions more secure, not arbitrary user-to-user messages such as email. That really restricts the scope, which is good.
>
> In this case there is no use for S/MIME, which deals with encoding/signing multipart mail messages. And no need to deal with MIME headers, html, or embedded images, and such. And we can simply require one character encoding, no need to support hundreds.
>
> The "request signing" bitcoin URL makes sense in my eyes. Less copy/pasting is good. Do mind that there is usually a URL size limit (depending on the browser) so this cannot be used for long messages/contracts. A possible solution would be to make an option to pass the address where the message can be retrieved (and maybe also where the signature must be sent, to save a copy-paste back?).
>
> Looking at existing solutions, the only other "sign request" that I know of is the CSR (https://en.wikipedia.org/wiki/Certificate_signing_request) but the functionality and goal is very different.
>
> It'd be useful (and IMO most important) to write down some use-cases in which this makes P2SH easier and less involved. How many steps can be eliminated of the 14?
>
> Wladimir
> BTW: we also still need a BIP to define URL signing / authentication itself.
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next prev parent reply other threads:[~2012-04-04 8:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 20:55 Alan Reiner
2012-04-03 0:44 ` Luke-Jr
2012-04-03 18:46 ` Gavin Andresen
2012-04-03 18:55 ` Luke-Jr
2012-04-03 19:42 ` Wladimir
2012-04-03 20:04 ` Peter Vessenes
2012-04-03 21:12 ` Alan Reiner
2012-04-03 23:37 ` Mike Koss
2012-04-04 0:01 ` Alan Reiner
2012-04-04 6:23 ` Wladimir
2012-04-04 8:35 ` Michael Grønager [this message]
2012-04-03 20:51 ` Alan Reiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=416DB500-46F1-4249-8728-F08B1FFADE11@mac.com \
--to=gronager@mac$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox