issue with creating Input class for P256Element::Scalar

[jiaaaarui]

Hi,

I am trying to use the P256 interface for another project which includes having to share scalar elements. As a result, I tried to make an input class with the following:

typedef T<P256Element::Scalar> scalarShare;
typename scalarShare::mac_key_type mac_key;
scalarShare::read_or_generate_mac_key("", P, mac_key);

typename scalarShare::Direct_MC output(mac_key);

typename scalarShare::LivePrep preprocessing(0, usage);

SubProcessor<scalarShare> processor(output, preprocessing, P);
typename scalarShare::Input input(output, preprocessing, P);

This created an ambiguous function, which I solved by changing Share::mul to

template<class T, class V>
inline void Share_<T, V>::mul(const Share_<T, V>& S,const clear& aa)
{
  a = S.a * aa;
  mac = aa * S.mac;
}

in Share.h.

However, when I use the code with the following snippet

vector<P256Element::Scalar> random_inputs;
for (int i = 0; i < INPUTSIZE; i++){
    P256Element::Scalar rand;
    rand.randomize(G);
    random_inputs.push_back(rand);
    cout << rand << endl;
}

vector<scalarShare> random_inputs_share[2];

input.reset_all(P);

for (int i = 0; i < INPUTSIZE; i++)
    {
        input.add_from_all(random_inputs[i]);
    }

I get a segfault on input.add_from_all. Doing some trouble shooting, I believe the issue occurs on prep.get_input(share, rr, player); in Input.hpp in the function void Input<T>::add_mine(const open_type& input, int n_bits).

I am not sure if this is an issue or if I wrote in a bug. Any feedback is appreciated.

[mkskeller]

This might be because you haven't initialized usage with the number of players.

[jiaaaarui]

Thank you for your response! After fixing this, I ran into the following error mascot-ecdsa-party.x: ./Protocols/MAC_Check.hpp:162: void MAC_Check_<T>::Check(const Player&) [with U = Share<gfp_<3, 4> >]: Assertion `this->coordinator' failed. which I fixed by adding output.setup(P); to my code. I just wanted to check that this isn't just a monkey patch since I don't remember seeing this happen in other programs.

[mkskeller]

No, this is regularly expected, and it is done here in the ECDSA benchmark: https://github.com/data61/MP-SPDZ/blob/4675cba4e76bac77da3a16fc0d46cdb8ff1b22c3/ECDSA/ot-ecdsa-party.hpp#L104

[jiaaaarui]

Thank you again for your response. I tried doing this with another type and am receiving a different error. From our other discussion, I attempted to add another type to represent the affine coordinates of the curve. I added the following to P256Element.h

typedef gfp_<2, 4> Scalar;
typedef gfp_<4, 4> Coord;

which are initialized with

Scalar::init_field(mod, false);
Coord::init_field("115792089210356248762697446949407573530086143415290314195533631308867097853951", false);

however, when I try setting up the input and output with the following

typedef T<P256Element::Scalar> scalarShare;
typedef T<P256Element::Coord> coordShare;

typename coordShare::mac_key_type mac_key;
coordShare::read_or_generate_mac_key("", P, mac_key);
coordShare::MAC_Check::setup(P);
typename coordShare::Direct_MC output(mac_key);

typename coordShare::LivePrep preprocessing(0, usage);

SubProcessor<coordShare> processor(output, preprocessing, P);
typename coordShare::Input input(output, preprocessing, P);



typename scalarShare::mac_key_type scal_mac_key;
scalarShare::read_or_generate_mac_key("", P, scal_mac_key);
scalarShare::MAC_Check::setup(P);
typename scalarShare::Direct_MC scal_output(scal_mac_key);

typename scalarShare::LivePrep scal_preprocessing(0, usage);

SubProcessor<scalarShare> scal_processor(scal_output, scal_preprocessing, P);
typename scalarShare::Input scal_input(scal_output, scal_preprocessing, P);

I receive an error

terminate called after throwing an instance of 'IO_Error'
what():  Connection id coordinate-SPDZ gfp256P0 already used

I believe this is caused by the line coordShare::MAC_Check::setup(P);.

[jiaaaarui]

I did some more investigating and I believe this is due to the fact that gfp<2,4> and gfp<4,4> are not distinguished between when setting up a coordinator. This is because the Tree_MAC_Check class only takes into account the type string and bit length when setting up the coordinator and does not pass through the label. Is there a workaround to this?

[mkskeller]

You should be able to add a something that distinguishes the two. Try fake_opts(). It's a bit of a hack but should do the job because there just needs to be something different, and the output includes the prime.