1 2016-12-20 04:32:48 <Steve132> So, based on a couple discussions from reddit and looking at 4-5 implementations that seem to exist in the wild, I wrote a draft BIP and an implementation for a standardized ECIES variant
2 2016-12-20 04:33:39 <Steve132> to allow people to use their bitcoin wallet and existing HD wallet schemes to manage encryption keys for encrypted messages
3 2016-12-20 04:34:24 <Steve132> This functionality would be in a similar vein to the message signing feature that exists, but would not expose keys to a reusing-nonce vulnerability
4 2016-12-20 04:34:45 <Steve132> Where should I go next once I finish my draft/does anyone here have any comments on that?
5 2016-12-20 04:35:47 <luke-jr> bitcoin-dev ML, see BIP 2
6 2016-12-20 04:36:07 <luke-jr> would be nice if any new such system supports multisig and other non-simple key setups
7 2016-12-20 04:39:27 <Steve132> luke-jr: I agree, but it might not be possible easily within the confines of ECIES
8 2016-12-20 04:39:38 <Steve132> If you have any ideas about that I'm all ears
9 2016-12-20 04:40:25 <luke-jr> can it be done in a way such that the simple use case is ECIES, but not the complex one?
10 2016-12-20 04:41:37 <Steve132> Potentially, but that seems to be something that would necessitate a seperate bip/standard...because then you're in the realm of developing your own crypto schema, which is the cardinal sin...ECIES has a lot of research supporting it
11 2016-12-20 04:41:48 <Steve132> Looking at multisig, it seems pretty easy to do actually
12 2016-12-20 04:42:02 <Steve132> That uses of M of N shamirs to derive the pubkey, right?
13 2016-12-20 04:42:28 <luke-jr> no
14 2016-12-20 04:42:40 <luke-jr> it uses M of N separate pubkeys ;)
15 2016-12-20 04:46:43 <Steve132> Hm.
16 2016-12-20 04:48:05 <Steve132> So, honestly, it seems like with a real academic crypto expert something could be created, but that's the realm of making your own crypto
17 2016-12-20 04:48:37 <Steve132> I can come up with some M of N schemas that work in my head but the first BIP should probably be limited to the well-known case with an extension to multisig to come later
18 2016-12-20 04:49:28 <Steve132> One of them could be to use shamir's to create a pubkey
19 2016-12-20 04:49:40 <Steve132> the privkey for shamirs can be reconstructed later
20 2016-12-20 04:50:02 <Steve132> from the privkeys
21 2016-12-20 04:50:29 <Steve132> but that protocol should be investigated and researched first honestly
22 2016-12-20 04:55:23 <luke-jr> AFAIK shamir doesn't really help for multisig use cases (but I am no cryptography expert)
23 2016-12-20 04:55:48 <luke-jr> What if you just take the single-key signature format, and make it so you can combine multiple of them?
24 2016-12-20 04:57:08 <Steve132> The point is you need an actual public key, you can't encrypt with a signature
25 2016-12-20 04:57:27 <Steve132> "AFAIK shamir doesn't really help for multisig use cases (but I am no cryptography expert)" Why not? It seems like that's literally what it's designed for....
26 2016-12-20 04:58:23 <Steve132> Not to argue, just wanted to know if you had a justification or source because I didn't understand why
27 2016-12-20 04:59:00 <luke-jr> sure, so when you input the "public key", accept a sequence of multiple pubkeys combined, and encrypt to one after the next?
28 2016-12-20 04:59:15 <luke-jr> for Shamir, don't you need to input all the private keys into the same computer?
29 2016-12-20 04:59:48 <luke-jr> I may be confusing it with something else..
30 2016-12-20 05:03:49 <Steve132> You're right about shamir, that's for decrypting..... there are fancy ways to implement it so you don't have to but they are exceedingly complex
31 2016-12-20 05:04:05 <Steve132> for encrypting you just need all the pubkeys
32 2016-12-20 05:04:13 <Steve132> > sure, so when you input the "public key", accept a sequence of multiple pubkeys combined, and encrypt to one after the next?
33 2016-12-20 05:04:22 <Steve132> The problem with this is it would be 1 of M :D
34 2016-12-20 05:05:02 <Steve132> unless you did it like, you encrypt them in sequence, in which case the bitstream size of the number of times you'd need to encrypt would be exponential in N of M
35 2016-12-20 05:05:23 <Steve132> like, it would be (m choose n)*length_of_message bytes at least
36 2016-12-20 05:05:53 <Steve132> If M and N are small like they are in bitcoin (<3) this could be acceptable I guess, but it seems like a hack
37 2016-12-20 05:06:08 <Steve132> seems better to putt off multisig till later
38 2016-12-20 05:07:47 <luke-jr> right
39 2016-12-20 05:08:22 <luke-jr> just that this is arguably a bigger problem with the current scheme than the resigning
40 2016-12-20 05:28:26 <Steve132> I'll still submit the draft to the mailing list
41 2016-12-20 05:28:35 <Steve132> but only for single pubkeys
42 2016-12-20 05:30:45 <Steve132> I can add a note that multisig will have to be added later after research