deprecate mp_n_root_ex and mp_expt_d_ex

[minad]

These functions were introduced to give some timing guarantees.
However the guarantees are too weak to be useful.
The functions seem to be essentially unused by downstream users.

I checked https://github.com/heimdal/heimdal and ltc.

See the discussion in #243. See also #202 which will give us a better root algorithm.

[czurnieden]

The functions seem to be essentially unused by downstream users.

The original was unusable, that was probably one of the main reasons.

It is always hard to get out to the users that we have "a new and improved" algorithm, it takes some time.

BTW: I have the smaller but slower one still as the default in #202 (did I update it to the current one? Have to take a look) but I think it should be the other way around. Maybe remove the Halley alternative, too, because it is only faster with numbers of a size beyond good and evil and otherwise a waste of memory.

[czurnieden]

I overlooked that you removed the constant time version of expt_d instead of repairing it. Intentional?

[minad]

Yes, I think most users don't want the constant time version. It is not even constant time I think. But even if it was, I've not seen it being used in the crypto applications ltc and heimdal.

We could however also keep expt_d as "constant time" and add another non constant time function instead of the _ex version. But I think it is the wrong default and we shouldn't make false promises. I certainly would not vouch for expt_d being side channel free...

[minad]

@czurnieden If you have a better idea, please let me know. What I thought - we could maybe also deprecate both mp_expt_d and mp_expt_d_ex and introduce another mp_expt_int + mp_expt (as in #240) with the prototypes:

mp_err mp_expt(const mp_int*, const mp_int*, mp_int*);
mp_err mp_expt_int(const mp_int*, uint32_t, mp_int*);

This way we would avoid any complaints regarding changed behavior and would end up with a good api after the deprecated stuff has been removed.

[czurnieden]

[slow expt_d] is not even constant time I think.

It isn't as it is but can be made at least constant-branching by adding the necessary multiplications (just multiply by one) but I don't think it would make a large difference.
Hence you're right in getting rid of it.

Have you changed the documentation? >;->

[czurnieden]

(Sometimes the javascript on this page works, sometimes not, feels as if MS has finally taken over ;-) )

mp_expt_int is a bit off of your naming scheme?

I would support it but others here think that a full bigint mp_expt would be too much of a niche product and that is not a bad argument. But we have a user who likes to have it, if I rember it correctly?

[minad]

mp_expt_int is a bit off of your naming scheme?

Yes, we can use a _u32 name.

I would support it but others here think that a full bigint mp_expt would be too much of a niche product and that is not a bad argument. But we have a user who likes to have it, if I rember it correctly?

As discussed before - I would not support a full bigint mp_expt, but only a reduced version which extracts the low bits from the bigint exponent for special cases. There was at least an argument for that in #240. But I am not really convinced tbh.

I would personally happy with mp_expt_u32 only. And I would prefer that over mp_expt_d since this gives us api consistency across platforms.

[minad]

@czurnieden @sjaeckel Here we can check for soon to be deprecated functions being in use - https://codesearch.debian.net/search?q=mp_expt_d_ex

(mp_expt_d_ex is not in use in the debian package archives for example)