--- Log opened Tue Jan 11 00:00:27 2022
06:46 < nickler> FYI we're doing a Bitcoin Core PR Review Club (https://bitcoincore.reviews/) session Feb 2nd on elichai2's PR #748 ("Add usage examples"). Will add notes & questions soon.
06:46 < sipa> Cool!
09:09 < mercurian> so, I'm pretty sure I know the answer to this (and I'm assuming the answer is “yeah… no, that's not secure, don't do that”), but I'd love to understand why and what alternatives I might have: the blinding factor for pedersen commitments are 32-byte buffers; I'm going to be making a lot of pedersen commitments, and for a separate proof, I'd like to be able to use the values in the blinding factors
09:09 < mercurian> (namely, I'd like to be able to sum them). If those blinding factors are randomly-drawn 32-byte buffers, it's incredibly likely that summing them would overflow 32-bytes. Is it totally insane to roll 64-bit integers randomly and zero-pad them to 32-bytes for use as blinding factors?
09:11 < sipa> Yeah, because then a 2^64 attacker can unblind them; just try them all.
09:11 < mercurian> yeah…
09:11 < mercurian> that's what I figured
09:11 < mercurian> I mean, I suppose I can have the sum just be potentially a fair bit larger than 32-bytes…
09:12 < sipa> Why is overflow a problem?
09:12 < sipa> It just wraps around mod the curve order.
09:12 < mercurian> the proof I'm working to create would require that two things (one of which would be the sum of all the blinding factors) sum to zero
09:13 < mercurian> if I allow overflow, then there are tons of potential things that would meet the requirement (instead of only one)
09:13 < mercurian> s/things/numbers/
09:13 < mercurian> s/tons/an infinity ☺
09:13 < sipa> That's normal. Just choose all of them randomly, except the last one, which you set to the negation of the sum of the others?
09:14 < mercurian> that's what I'm trying to do already ☺
09:15 < sipa> Ok, then I don't understand the issue. I'd strongly recommend against anything but uniformly random scalars over the entire range for your blinding factors. At the very least, you lose information theoretical blinding that way.
09:15 < mercurian> for each pedersen commitment, I was planning to randomly roll all the blinding factors save for the last commitment, which would have the blinding factor of the negation of the sum of all the others (just as you suggested)
09:16 < mercurian> I was thinking that modular overflow there would be a major no-no, sounds like I was thinking incorrectly?
09:17 < sipa> It's just arithmetic in the field of integers modulo the curve order, "overflow" doesn't exist there.
09:17 < mercurian> hmm
09:17 < mercurian> cheers
09:17 < sipa> As in, which additions overflow when you think of it as integers depends on your choice of representation of those numbers.
09:18 < sipa> Unless you're going to actually use that representation (e.g. by making things depend on the individual bits), but that shouldn't be the case for blinding factors.
09:23 < mercurian> that makes sense
09:25 < mercurian> I suppose I was thinking that, to ensure no wrap-around (assuming unsigned binary integers), I'd need n bits of additional space (where n = the number of blinding factors to sum, since the maximum increase in bitsize for addition is 1)
09:26 < mercurian> but if indeed wrap-around doesn't matter (which I'll need to think about more), then there's no need for me to worry about it
09:27 < mercurian> ugh, C has infected my brain, I really want to get out of the habit of saying “unsigned integer”… everytime I think about that phrase, it makes me a bit sad
09:30 < sipa> think about this: if you're working modulo an odd number N
09:31 < sipa> then you could (it'd be silly, but it's possible) represent every element of the field i (as integer mog N) by the residue of (2*i mod N).
09:32 < mercurian> sure
09:32 < sipa> addition still works
09:32 < sipa> negation still works
09:32 < sipa> 0 is is still zero
09:32 < sipa> multiplication doesn't work, but that doesn't matter for the scalar ring (because you can't multiple the corresponding points either)
09:32 < sipa> but which elements added together now "overflow" is different
09:33 < sipa> without breaking any of the properties you need
09:33 < mercurian> mm
09:33 < mercurian> I think I agree on all points, I just need to check with a colleague that it does indeed still keep all the properties that we want/need
09:33 < mercurian> sipa: I really appreciate your talking through it with me
09:35 < sipa> maybe this works better as an argument: what if instead of generator point P (the point you'd multiply the blinding factor with), you'd have used P*(1/2), and doubled all your blinding factors?
09:35 < sipa> clearly all computed points would be exactly the same
09:35 < mercurian> sure
09:36 < sipa> so clearly those scalars overflowing can't matter, because now different things will overflow
09:58 < mercurian> mm
10:37 < mercurian> that all makes sense
10:40 -!- ajonas_ [sid385278@helmsley.irccloud.com] has quit []
10:40 -!- ajonas [sid385278@id-385278.helmsley.irccloud.com] has joined #secp256k1
21:29 -!- andytosh1 [~apoelstra@user/andytoshi] has joined #secp256k1
21:35 -!- Netsplit *.net <-> *.split quits: andytoshi, roconnor, meshcollider, jesseposner
21:38 -!- andytosh1 [~apoelstra@user/andytoshi] has quit [Ping timeout: 256 seconds]
21:40 -!- Netsplit over, joins: meshcollider, roconnor, jesseposner
21:40 -!- Netsplit over, joins: andytoshi
--- Log closed Wed Jan 12 00:00:28 2022