apps/speed: fix weird EC arrays usage#6133
apps/speed: fix weird EC arrays usage#6133FdaSilvaYY wants to merge 2 commits intoopenssl:masterfrom
Conversation
6fe79d9 to
9983953
Compare
apps/speed.c
Outdated
There was a problem hiding this comment.
Useless indirection through retval
apps/speed.c
Outdated
There was a problem hiding this comment.
was an useless indirection through retval
apps/speed.c
Outdated
There was a problem hiding this comment.
Hopefully, there is no OOB because of the values that are used
apps/speed.c
Outdated
There was a problem hiding this comment.
two last elements were not initialized and used
9983953 to
2d7e6a5
Compare
249481a to
3e149f7
Compare
680340e to
f2c2343
Compare
apps/speed.c
Outdated
There was a problem hiding this comment.
Fixed, I just change the signature of found() method, and it is less intrusive.
f2c2343 to
b67296a
Compare
|
Hi,
Renamed in a few locations (not all) just to shutoff a signed/unsigned pointer cast warning when calling 'found' method.
Feel free to suggest a better naming.
… Le 30 avr. 2018 à 12:06, Kurt Roeckx ***@***.***> a écrit :
@kroeckx commented on this pull request.
In apps/speed.c:
> const char *engine_id = NULL;
const EVP_CIPHER *evp_cipher = NULL;
double d = 0.0;
OPTION_CHOICE o;
int multiblock = 0, pr_header = 0;
int doit[ALGOR_NUM] = { 0 };
- int ret = 1, i, k, misalign = 0;
+ int ret = 1, ix, misalign = 0;
Any reason you rename i to ix?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
a171db0 to
63f0afe
Compare
63f0afe to
83a4d32
Compare
apps/speed.c
Outdated
There was a problem hiding this comment.
I wonder what would people think of following pattern
static const char *names[] = {
#define D_MD2 0
"md2",
#define D_MDC2 1
"mdc2",
...
It's still ugly, but at least it gives you right idea about relationship between names and indices....
There was a problem hiding this comment.
Other suggestion :
enum { D_MD2, D_MDC2, D_MD4, ...
static const char *names[] = {
"md2", /* D_MD2 */
"mdc2", /* D_MDC2 */
"md4", /* D_MD4 */
...
Shorter and more speaking form and format, IMHO
There was a problem hiding this comment.
Another suggestion (if this is really important) is to have an enum and then a "pair" typedef that has value/string-name. We do that in many other places.
There was a problem hiding this comment.
I add these suggestions to the many more ideas I have to simplify and document this code.
|
It appears that it would be dependent on #6132 in sense that it would require re-base, so that final review would have to be postponed... |
|
This could possibly have a merge issue with #6132, but it will be easy to fixed. |
5096d32 to
4a648c3
Compare
|
Aehm, I would need some performance numbers for brainpool vs. nist vs. Ed25519 |
apps/speed.c
Outdated
There was a problem hiding this comment.
If additional empty line is meant to delimit prime and 2m fields, then how come there is no one prior brainpool chunk?
apps/speed.c
Outdated
There was a problem hiding this comment.
Hmm, this is not right. Basically the difference between these values is approximate difference between speeds, so I'd suggest count / 8000 for X448.
There was a problem hiding this comment.
The brp numbers are unreasonable too. The brp256 should be ~3-5 smaller than they are, then loop condition is totally wrong for chosen indices. Indeed, the R and T are interleaved, so it should be i+=2, and it should be <= R_EC_BRP512[RT]1...
There was a problem hiding this comment.
I change my mind twice about interleaving or not : that's why this change is awkward.
You know that this juggle around estimating iteration counts is mostly useless, because SIGALRM define and support is the main use-case ...
There was a problem hiding this comment.
If you interleave, then it's i+=2, if you ++i, then there should be no interleave. If argument is that it's not non-main use case, then it's argument in favour of whole thing removal, not for suggesting code that is visibly (and verifiably) wrong. There is no excuse for that.
apps/speed.c
Outdated
There was a problem hiding this comment.
Why? Original condition was correct.
db44e20 to
f389005
Compare
apps/speed.c
Outdated
apps/speed.c
Outdated
There was a problem hiding this comment.
Suggestion was that x448 coefficient would be 8 times larger than x25519. I.e. if X25519 was 1000, then X448 would be 8000. Slower algorithm -> higher coefficient. X448 is slower than X25519, 8 times (on x86_64). Well, one can argue that it's not really fair comparison, and it should be approximately square of key lengths' ratio, all right, let's say 4. So if you choose 2200 for X25519, then it should be 8800 for X448.
There was a problem hiding this comment.
I made some measurements of X25519/X499 against ecdhb163 to deduce these ratios, but I inverse my calculation Oups ;(
I get a x3 ratio on my computer between X25519 and X499, but ok for a x4 ratio.
because there is actually 18 curves defined, but only 16 are plugged for ecdsa test Deduce directly array size using OSSL_NELEM and so remove various magic numbers. Require some declarations moving. Implement OPT_PAIR list search without a null-ending element. Fix some comparison between signed and unsigned integer expressions.
f389005 to
07ee0ad
Compare
|
As for 1.1.0, does it cherry-pick? [No, I didn't test.] |
because there are actually 18 curves defined, but only 16 are plugged for ecdsa test. Deduce array size using OSSL_NELEM and so remove various magic numbers, which required some declarations moving. Implement OPT_PAIR list search without a null-ending element. Fix some comparison between signed and unsigned integer expressions. Reviewed-by: Andy Polyakov <[email protected]> Reviewed-by: Rich Salz <[email protected]> (Merged from #6133)
Reviewed-by: Andy Polyakov <[email protected]> Reviewed-by: Rich Salz <[email protected]> (Merged from #6133)
|
Merged. Thanks! |
because there are actually 17 curves defined, but only 16 are plugged for ecdsa test. Deduce array size using OSSL_NELEM and so remove various magic numbers, which required some declarations moving. Implement OPT_PAIR list search without a null-ending element. Fix some comparison between signed and unsigned integer expressions. cherry-picking from commit 5c6a69f. Partial Back-port of openssl#6133 to 1.1.0
because there are actually 17 curves defined, but only 16 are plugged for ecdsa test. Deduce array size using OSSL_NELEM and so remove various magic numbers, which required some declarations moving. Implement OPT_PAIR list search without a null-ending element. Fix some comparison between signed and unsigned integer expressions. cherry-picking from commit 5c6a69f. Partial Back-port of #6133 to 1.1.0 Reviewed-by: Andy Polyakov <[email protected]> Reviewed-by: Rich Salz <[email protected]> (Merged from #6245)
because there is actually 18 curves defined, but only 16 are plugged for ecdsa test
Deduce directly array size using OSSL_NELEM and so remove various magic numbers.
Require some declarations moving.
Implement OPT_PAIR list search without a null-ending element.
IMHO, this PR deserves a backport to 1.1.0
Checklist