[00:00.000 --> 00:02.060]  you
[00:30.000 --> 00:32.060]  you
[01:00.000 --> 01:02.060]  you
[01:30.000 --> 01:32.060]  you
[12:00.000 --> 12:02.060]  you
[12:30.000 --> 12:34.360]  So that's all from my side in this little review
[12:34.360 --> 12:36.720]  on the ellipticals itself and thinking
[12:36.720 --> 12:38.920]  and the implementations in free software.
[12:41.280 --> 12:42.120]  Hi.
[12:54.160 --> 12:57.080]  You were talking about standardization of curves,
[12:57.080 --> 13:02.080]  but with a lot of the new cryptography techniques
[13:02.760 --> 13:06.040]  like zero knowledge, homomorphic encryption,
[13:07.320 --> 13:09.480]  MPC, VDFs.
[13:09.480 --> 13:11.720]  And then even when you start to amount recursion
[13:11.720 --> 13:15.680]  and curve cycles and pairing friendly curves,
[13:15.680 --> 13:19.880]  each time it seems we will try to standardize curves,
[13:19.880 --> 13:22.800]  it then discover like, oh, there's some new property
[13:22.800 --> 13:26.200]  like maybe unknown order groups or hyper elliptic.
[13:26.200 --> 13:31.200]  I think the movement of this restrito and decath
[13:31.520 --> 13:34.000]  goes in the direction in instead of
[13:34.000 --> 13:36.800]  standardize an elliptic curve itself,
[13:36.800 --> 13:39.880]  it's just standardizing a variety of elliptic curves.
[13:39.880 --> 13:43.520]  Then you have the operations and the match
[13:43.520 --> 13:46.880]  to work with any elliptic curves in this variety.
[13:46.880 --> 13:50.800]  So this will bring us the possibility to have this,
[13:50.800 --> 13:53.440]  like another service that is providing random elliptic curves
[13:53.440 --> 13:56.920]  on the net and you can pick one over from there
[13:56.920 --> 14:00.000]  and forget about the thing that we are sharing
[14:00.000 --> 14:00.840]  the same elliptic curves.
[14:00.840 --> 14:05.840]  The way that the current standards that exist
[14:07.000 --> 14:09.760]  are fixing an elliptic curve one or another,
[14:09.760 --> 14:11.560]  but fixing it in a specific way.
[14:13.880 --> 14:16.600]  I have answered it because you say about homomorphic,
[14:16.600 --> 14:20.320]  but the homomorphic is huge.
[14:20.320 --> 14:25.320]  It's a very interesting field, but it's huge field.
[14:26.680 --> 14:29.960]  Okay, I can see another question.
[14:31.760 --> 14:35.840]  In many protocols and also in IoT devices,
[14:35.840 --> 14:40.160]  you are bottlenecked by speed and also by signature size.
[14:40.160 --> 14:42.520]  You said that with Jacobi Quartik curve,
[14:42.520 --> 14:45.320]  you can go faster and also smaller.
[14:45.320 --> 14:48.200]  How fast, how much faster and how much smaller?
[14:48.200 --> 14:53.200]  I haven't, the paper of the Jacobi Quartik people,
[14:54.800 --> 14:56.840]  it's the speed is explained.
[14:56.840 --> 14:59.200]  I don't have the numbers on mine now.
[14:59.200 --> 15:01.280]  I have the numbers on mine about the size
[15:01.280 --> 15:05.280]  because the sizes in signatures in elliptic curves
[15:05.280 --> 15:08.680]  are 64 bytes and the proposal,
[15:08.680 --> 15:11.040]  the schema they propose for the Jacobi Quartik,
[15:11.040 --> 15:15.200]  it's 84 bytes.
[15:15.200 --> 15:19.120]  So it's like a third smaller.
[15:19.120 --> 15:21.600]  But it's still bigger than BLS signatures
[15:21.600 --> 15:24.240]  who are about 32 to 48
[15:24.240 --> 15:27.520]  because you only need a single point on curve.
[15:28.680 --> 15:30.160]  In the signature, in the signature,
[15:30.160 --> 15:32.640]  you are not putting only the point.
[15:32.640 --> 15:35.960]  There are three, if I remember correctly, there are three.
[15:35.960 --> 15:38.120]  BLS signatures, it's only one point.
[15:39.120 --> 15:40.200]  Which signature?
[15:40.200 --> 15:42.040]  BLS from Dan Bonny.
[15:42.040 --> 15:47.040]  Mm-hmm, but it's longer than, it's shorter than 48 bytes.
[15:49.320 --> 15:51.720]  It depends on the base curve you use,
[15:51.720 --> 15:54.040]  but it's only, so if you use, well,
[15:54.040 --> 15:58.040]  32 bytes signatures are not deemed secure enough
[15:58.040 --> 16:00.080]  because you have pairing issues,
[16:00.080 --> 16:05.080]  but 48 provides 128 bytes of security, so, yeah.
[16:05.080 --> 16:10.080]  What I know is in the ethyl curbs variety,
[16:10.080 --> 16:13.080]  the signature is 64 bytes.
[16:16.080 --> 16:18.080]  Okay, are there any questions?
[16:26.080 --> 16:27.080]  No, then.
[16:27.080 --> 16:28.080]  Okay.
[16:30.080 --> 16:33.080]  Have you looked at jealous two curves
[16:33.080 --> 16:36.080]  because I saw that they actually outperformed
[16:36.080 --> 16:37.080]  a jealous two.
[16:37.080 --> 16:38.080]  Yeah.
[16:38.080 --> 16:40.080]  They outperformed the jealous one.
[16:40.080 --> 16:43.080]  I saw DJB was really into that.
[16:43.080 --> 16:45.080]  Hyper elliptic curves.
[16:45.080 --> 16:46.080]  Yeah, the Picard group.
[16:46.080 --> 16:49.080]  This is a very nice subject also.
[16:49.080 --> 16:52.080]  I think banks are the ones
[16:52.080 --> 16:55.080]  that are putting more money in hyper elliptic curves.
[16:55.080 --> 16:57.080]  They are not using points.
[16:57.080 --> 17:03.080]  They are using a matrix of the Jacobian of the point.
[17:03.080 --> 17:08.080]  By now, I only heard about banks putting money there.
[17:08.080 --> 17:13.080]  I haven't seen an implementation in open source.
[17:18.080 --> 17:19.080]  Any other?
[17:19.080 --> 17:24.080]  No, thank you.