I would expect that correct results would be provided for all valid inputs (including those inputs that are not otherwise constrained). As such, I would class this as a bug in OpenSSL. -Kyle H On Mon, Jan 7, 2019 at 7:44 PM Patrick Steuer <psteuer@xxxxxxx> wrote: > > Dear Bo-Yin Yang, > > I looked into your felem_square counterexample: > > There is an overflow in the result's least significant 128-bit limb such > that the computed result is 2^128 smaller than the actual result. > > The general problem is the following.. > > The function's comment says: > /*- > * felem_square sets |out| = |in|^2 > * On entry: > * in[i] < 2^62 > * On exit: > * out[i] < 17 * max(in[i]) * max(in[i]) > */ > > If you look at the function's code youll notice that given the entry > assumption, the exit assertion's "less than" should actually be a > "less than or equal to" for in the case of all in[i]s being equal to say > x, max(in[i])=x and out[0]=17*x^2. > > So out[0] is stored in 128-bits, but for e.g. x=2^62-1, out[0]>2^128. > > If its a bug depends on the contexts from which felem_square is called. > If for some reason its inputs are guaranteed to satisfy some stricter > entry condition than stated in the above comment (such that there is no > overflow) things might be alright. > > I didnt look at your other examples but id expect something similar. > > Best Regards, > > Patrick Steuer > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
