--- Log opened Mon Apr 29 00:00:58 2019
01:48 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-kmuwegoznfdvdxth] has joined #secp256k1
03:01 < elichai2> I'm looking at: https://www.secg.org/sec1-v2.pdf (4.1.6) and https://crypto.stackexchange.com/a/18106/60124 on how to recover a public key from a valid signature and there's one thing I don't understand.
03:02 < elichai2> Can't you just calc the acceptable Y's by taking `r` as the x and putting it in the EC formula? then you just need to know if it's the upper n or lower n (just like compressed public keys)
04:09 < elichai2> or is this recovery method secure even without a public key to compare to?
04:24 < elichai2> ohh beacuse r is the x of the nonce, not of the public key, nvm
04:25 < elichai2> (of the nonce multiplied by the generator)
05:26 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #secp256k1
05:27 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
05:51 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #secp256k1
06:53 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 268 seconds]
07:05 -!- afk11 [afk11@gateway/vpn/privateinternetaccess/afk11] has joined #secp256k1
07:54 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1
08:22 -!- codeguro [~tony@2601:82:c201:f46d:f829:4191:f5a:5ae5] has joined #secp256k1
08:22 < codeguro> Hello! I need some information. Is anyone online?
08:23 < andytoshi> just ask, don't ask to ask
08:30 < codeguro> Hi, I'm trying to get a high level understanding between the BrainPool and NIST curves. According to https://tls.mbed.org/kb/cryptography/elliptic-curve-performance-nist-vs-brainpool it says that The Brainpool curves use random primes, as opposed to the quasi-Mersenne primes used by the NIST curves. But in https://safecurves.cr.yp.to/field.html it says that the primes aren't random in either case but very specific prime fields.
08:30 < codeguro> So what's going on here? In what meaningful sense are BrainPool curves "random"?
08:31 < codeguro> And how do they differ from the NIST/secp curves?
08:33 < andytoshi> the brainpool primes were chosen by http://bada55.cr.yp.to/brainpool.sage
08:33 < andytoshi> they are fixed ofc as part of the curve definition, but the original choice was made at random
08:33 < andytoshi> also FYI secp is not a NIST curve - though it also uses a field order which is quasi-mersenne
08:36 < codeguro> Thanks andytoshi. Though, that's a bit funny since it's like int random(){ return 4; /*Truly random, rolled by a fair die IRL*/ }
08:38 < andytoshi> the point is that it clearly was not chosen deliberately to have some hidden structure
08:38 < andytoshi> (though i'm not aware of any "hidden structure" in the order of prime fields that has caused trouble for cryptosystems)
08:47 -!- afk11 [afk11@gateway/vpn/privateinternetaccess/afk11] has quit [Ping timeout: 250 seconds]
09:04 -!- afk11 [~afk11@unaffiliated/afk11] has joined #secp256k1
09:12 < codeguro> andytoshi: So I heard that the cofactors for prime field for NIST curves is 1, but the same isn't true for edwards curves (ed25519)... but having a prime field cofactor 1 means that any point 1<x<p can be picked and so you have that much security. Doesn't that make edwards curves weaker in that aspect? Or am I fundamentally not understanding something here?
09:17 < elichai2> andytoshi: djb has some interesting papers about nothing up my sleeve: https://bada55.cr.yp.to/bada55-20150927.pdf
09:22 < codeguro> I guess what I'm asking is, doesn't having a non-1 cofactor for a prime field hurt the cardinality and thus the security?
09:25 < elichai2> curve25519 has cofactor 8
09:25 < elichai2> it just means it's a stricter group
09:31 < codeguro> elichai2: I don't think I understand what that means.
09:32 < codeguro> I understand the bit about cofactor of 8 but what does it mean to have a stricter group?
09:34 < elichai2> the co factor of the group is the ratio between the size of the group and the prime order of the sub group, in secp256k1 it's the same so the cofactor is 1
09:34 < elichai2> this means that every result of the ec function is a valid point
09:35 < elichai2> if the prime order is lower then the size of the group it means that not any result of the EC function is a valid group because you need to mod it over the group order
09:40 < andytoshi> codeguro: cofactors have nothing to do with fields
09:49 < codeguro> I see there's this draft https://tools.ietf.org/html/draft-josefsson-tls-additional-curves-01 on the books somewhere, I wonder when gpg will implement something like Goldilocks or E-521.
10:08 < codeguro> It'd be nice to have a replacement to the NIST P-521 curve
10:12 < sipa> ed448 ?
10:17 < codeguro> Yeah, ed448 goldilocks I heard has some nice properties with the golden ratio
10:18 < codeguro> GPG only supports P-521 and BP-512 though which both have questionable seeds
10:24 < echeveria> codeguro: that's good though. means you have plausible deniability.
10:34 < codeguro> echeveria: Plausible deniability for what?
10:35 < echeveria> if the curve has questionable parameters, you're off the hook.
10:37 < sipa> echeveria: i don't understand what you're referring to
10:38 < echeveria> <codeguro> GPG only supports P-521 and BP-512 though which both have questionable seeds
10:39 < echeveria> the joke is where I refereed to known-questionable curve params as being plausible deniability.
10:39 < gmaxwell> I got the joke but it was still too obscure. :P
10:52 < codeguro> Well, at least TLS v1.3 implements Curve448 goldilocks so I'm happy with that. All that's left is GPG implement it and I'm satisfied with all my security needs
10:55 < sipa> gpg supports ed25519
10:56 < codeguro> Yeah, I know. But it'd be nice to have an "overkill" alternative to P-521.
11:53 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 250 seconds]
12:19 -!- codeguro [~tony@2601:82:c201:f46d:f829:4191:f5a:5ae5] has quit [Ping timeout: 276 seconds]
16:15 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-kmuwegoznfdvdxth] has quit [Quit: Connection closed for inactivity]
17:11 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1
17:31 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Read error: Connection reset by peer]
17:32 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1
17:44 -!- BlueMatt_ [~BlueMatt@ircb.bluematt.me] has joined #secp256k1
17:45 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 276 seconds]
18:01 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1
18:01 -!- BlueMatt_ [~BlueMatt@ircb.bluematt.me] has quit [Read error: Connection reset by peer]
23:50 -!- roconnor [~roconnor@host-104-157-228-210.dyn.295.ca] has quit [Quit: Konversation terminated!]
--- Log closed Tue Apr 30 00:00:59 2019