--- Log opened Tue Jul 05 00:00:11 2022
05:56 -!- andytosh1 is now known as andytoshi
07:14 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
08:34 < andytoshi> elligator^2 always has a 64 byte output, right? is there any way to shrink that
08:35 < sipa> yes, actually
08:36 < sipa> though the uniformity guarantees probably don't hold anymore in that case
08:36 < andytoshi> ah okay, i'm thinking about stego applications
08:36 < andytoshi> where obviously you want as little data as possible to minimize distortion
08:36 < andytoshi> but uniformity is crucial :)
08:36 < sipa> Also, use ElligatorSwift instead: https://eprint.iacr.org/2022/759.pdf
08:37 < sipa> (also 64 bytes, but lower complexity and 2.5x faster)
08:38 < andytoshi> oo thanks!
08:39 < sipa> The paper currently needs a separate extra bit for the Y coordinate if you need a full point, though I've mailed the authors a suggestion to get rid of that.
08:39 < andytoshi> i probably only need x to do ecdh right? using dettmann's thing?
08:40 < sipa> If you're thinking of ecdh, I'm currently writing an integrated ElligatorSwift + xonly ECDH module.
08:40 < sipa> For BIP324.
08:41 < sipa> See https://github.com/bitcoin-core/secp256k1/pull/1118 for a starter.
08:44 < sipa> But I was hoping to have ElligatorSwiftXDH working today.
08:44 < andytoshi> cool!
08:44 < andytoshi> ok i'll wait a day or two :)
08:58 < real_or_random> andytoshi: what's your concrete use case?
09:02 < andytoshi> real_or_random: stegoing bitcoin transactions into images
09:11 < halosghost> 6/whois sipa 
09:11 < halosghost> lol
09:11 < halosghost> my apologies
09:56 < andytoshi> real_or_random: there are three components to the stego stuff 1) actual steganography (putting random shit into images), (2) encryption .. which maybe we can just use bip324 for, (3) tx compression
09:57 < andytoshi> we have a basic version of the stego stuff working, though we need to understand more about image encoders to do it properly .. tx compression is "easy"
09:57 < andytoshi> so we'd been working on crypto stuff for the last few weeks .. but it just occurred to me that we can shortcut basically all of it by just reusing bip324 code
10:30 < real_or_random> hm idk, at least parts of it... i don't know, bip324 is a session based protocol, this is still different from storing ciphertexts 
10:30 < real_or_random> or stegotexts, fwiw
10:31 < sipa> yeah i think full bip324 will be overkill, and will need shoehorning to fit a non-interactive setting
10:32 < sipa> though some parts like the key negotiation may be reusable
10:33 < real_or_random> sipa: it's interesting to see this discussion here
10:33 < real_or_random> because we talked about committing encryption and every said: meh, we won't need this in a secure session protocol
10:34 < real_or_random> and now there's a discussion about  a use case of storing ciphertexts even before we have our bip draft out
10:34 < real_or_random> (not saying that it changes anything, I just find it remarkable)
10:35 < sipa> I suspect andytoshi may just not have seen BIP324, or know its scope exactly.
10:36 < real_or_random> sure ok
10:37 < andytoshi> yes, i am not part of the bip324 cabal :)
10:37 < andytoshi> (nor do i want to be, i don't have time sadly)
10:38 < andytoshi> but at the very least, the contents of #1118 seem directly applicable to my uscase
10:38 < andytoshi> like, if i took #1118 and then just stuck aes-cbc onto that i'd have ecies
10:39 < andytoshi> and i assumed that bip324 would contain "#1118 plus aes"
10:39 < sipa> 1118 is just x-only point multiplication
10:41 < andytoshi> oh, oops, i thought it included elligatorswift
10:41 < andytoshi> sorry, i just got off the phone, lemme actually look at this stuff
10:41 < sipa> andytoshi: It has a bunch of other things, but the primary thing that makes it unnecessarily complex, is that an encrypted session just isn't a single encrypted message; it is bidirectional, and has both directions.
10:41 < sipa> *and has multiple messages in both directions
10:41 < sipa> which need to be delineated
10:41 < andytoshi> ah yeah, ok, that is way overkill for what i'm doing
10:42 < andytoshi> do you think though, that if bip324 were implemented, that i'd have an easy time using the new crypto primitives in libsecp to do what i'm doing
10:43 < sipa> https://github.com/sipa/secp256k1/commits/202206_ellswift has a working x-only elligatorswift
10:43 < sipa> but it is gratuitously inefficient for the ECDH use case, where some inversions and square roots can be avoided
10:45 < andytoshi> awesome, thanks
10:45 < andytoshi> the crypto stuff is not the long pole in the tent right now, so we'll probably just try to use this as-is so that we have some scaffolding to work on the other stuff
10:46 < andytoshi> but i'll try to take a look in the next week or two and understand how this works and how to avoid the extra operations
12:31 < sipa> andytoshi: FWIW, if you want 128-bit indistinguishability from uniform of the encoding, elligatorswift/elligatorsquare need 64 byte encodings.
12:32 < sipa> If say 64-bit indistinguishability is sufficient, I believe you can get away with 48 bytes.
12:32 < sipa> and more generally, you need (256+N) bits encodings for roughly N/2 bits worth of indistinguishability .
12:36 < sipa> In your case, you may want to use Elligator1-style rejection sampling, which only needs 32 bytes, but will need EC key generation inside the rejection sampling loop, meaning you'll need on average 4 ec point multiplications to construct a key.
12:39 < sipa> ElligatorSquare/Swift only need inversions/squareroots and a bit of field arithmetic inside the rejection loop
12:41 < real_or_random> re ecies: you'd still need a MAC
12:42 < real_or_random> ECIES comes up now and then, maybe it would be nice to have a module here or in secp256k1-zkp
12:43 < real_or_random> it shouldn't be that much work, we have all the parts in the code already... (not implying that I volunteer to do this :P)
12:50 < andytoshi> real_or_random: i don't need a mac for my application
12:50 < andytoshi> sipa: thanks for the tip about elligator1
12:50 < real_or_random> famous last words :P
12:50 < andytoshi> :)
12:51 < real_or_random> but then it's not ECIES :P
12:51 < andytoshi> i promise you a MAC will accomplish exactly nothing when applied to self-authenticating data sent over an async channel with no response and multi-day latency
12:51 < andytoshi> real_or_random: yeah, that's true
12:51 < andytoshi> unfortunate, because i will need to rip the mac out to save space, so i won't be able to use off-the-shelf code
12:52 < andytoshi> and will be forced to roll my own crypto
12:52 < real_or_random> what is the data? signed transactions?
12:52 < andytoshi> although the stego is already home-rolled crypto
12:52 < andytoshi> real_or_random: yeah
12:52 < real_or_random> ok yeah I tend to believe this
12:53 < real_or_random> at this point in the conversation I typically refer people to the story where apple screwed up (we won't need a MAC because we have signatures)
12:53 < andytoshi> yes :) i know that story well .. at blockstream we made the same mistake actually
12:53 < real_or_random> but ok in this case, it seems fine
12:54 < andytoshi> (though i think at bs there was not a vulnerability because of it ... though we still fixed it)
12:54 < real_or_random> yes, I remember :) I spotted it :)
12:54 < andytoshi> haha right
12:54 < real_or_random> you know something is wrong apple says you don't need a mac
12:54 < real_or_random> *when
12:54 < andytoshi> lol!!
12:56 < andytoshi> for the stego application i have the world's most convenient security model ... the transactor sends self-authenticated data over a passive channel and expects no response. the "server" picks it up, decodes/decompresses the transaction, and attempts to broadcast it after a random delay of many hours or days
12:56 < andytoshi> i don't care if data is lost, i don't care if keys are destroyed (though i care if they're leaked!), i have less than 1 round of communication
12:58 < andytoshi> ofc i'm glossing over the steganography, which is the trickiest part
13:00 < real_or_random> and there's just a single recipient?
13:00 < real_or_random> or will there be multiple recipients?
13:00 < andytoshi> there may be many .. but all with independent keys
13:00 < andytoshi> so the user would basically just do the protocol multiple independent times in parallel
13:05 < real_or_random> so it may make sense to use some multi-receiver encryption
13:05 < real_or_random> e.g., pk-encrypt the same symmetric key multiple times
13:09 < andytoshi> i think not because we want to make the encrypted blob as small as possible .. if te user wants to send to multiple people they should use multiple cover images
13:10 < andytoshi> and different recipients might even be monitoring different cover image sources
13:10 < real_or_random> ok
13:40 -!- fanquake [sid369002@user/fanquake] has quit [Quit: Updating details, brb]
13:40 -!- fanquake [sid369002@user/fanquake] has joined #secp256k1
13:51 < real_or_random> hm after having seen this comment again https://github.com/bitcoin-core/secp256k1/pull/570#issuecomment-1001224613 I wonder if I regret that we made all contexts signing contexts
13:52 < sipa> you don't want ECIES, because you don't need some of the security properties it provides
13:52 < real_or_random> once we have the small multicomb tables, copying them into the context seems reasonable
13:53 < real_or_random> well ok, we could always introduce a new context flag for this...  could even be an "opt-out" flag.
13:54 < real_or_random> or we postpone that problem to the nextgen API ^^
13:55 < sipa> andytoshi: You can't use actual Elligator1 because it only applies to a few curves (and specifically, not any odd-ordered ones), but you could use the elligator1-style sampling loop with the map-to-curve function from the paper on mapping to BN curves.
14:13 < sipa> Heh, interesting.
14:14 < sipa> I guess that's possible, and it's an interesting evolution. Going from fully runtime-generated tables, to potentially-compile-generated ones, to only compile-time-generated ones, and then back to permitting runtime-tweaked versions of those compile-time-generated ones.
18:42 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.5]
23:57 -!- midnight [~midnight@user/midnight] has quit [Remote host closed the connection]
23:58 -!- midnight [~midnight@user/midnight] has joined #secp256k1
--- Log closed Wed Jul 06 00:00:12 2022