SecFld253(GF(7237005577332262213973186563042994240' has no attribute 'modulus'

[prog-Noon]

While trying to write a threshold version of DSA demo I am getting this error when call
random_split(self.field, [self.x], self.threshold, self.num_parties)
even that I defined the modulus explicitly
self.field = mpc.SecFld(order=n, modulus=n)
the code is below:

async def keygen(self):
        """Threshold DSA key generation."""
        self.x, self.y = await self._keygen(self.group.generator)
        self.shares = random_split(self.field, [self.x], self.threshold, self.num_parties)


async def _keygen(self, g):
        """Threshold ElGamal key generation."""
        group = type(g)  # Determine the group type (e.g., elliptic curve)
        secgrp = mpc.SecGrp(self.group)
        n = self.group.order
        if n is not None and is_prime(n):  # If the order is prime
            secnum = mpc.SecFld(order=n, modulus=n)  # Use prime field
        else:
            l = isqrt(-group.discriminant).bit_length()  # Compute the bit length of the group's discriminant
            secnum = mpc.SecInt(l)  # Use a fixed-length integer field
    
        self.field = mpc.SecFld(order=n, modulus=n)
        while True:
            x = mpc._random(secnum)  # Generate a random secret key
            h = await secgrp.repeat_public(g, x)  # g^x
            if h != self.group.identity:
                return x, h

[lschoe]

I'm not sure what you mean with "While trying to write a threshold version of DSA demo" because both the demos dsa.py and elgamal.py already operate as threshold schemes. For instance, the line

self.x, self.y = await self._keygen(self.group.generator)

ensures that self.x will be the secret share of the private key held by the party running this copy of the program, while self.y will be the public key seen by all parties. The secret shares will be random if you run the program with $m\geq3$ parties, e.g., using the -M3 switch on the command line. If you run the program with 1 or 2 parties (or, if you set threshold $t=0$), then the secret shares will be trivial, meaning that all parties see the same value.

So, you don't need to manipulate the shares yourself like you want to do above, with self.shares = random_split(...). Everything is already taking care of.

You should keep the creation of the secure finite field as in the original demos: secnum = mpc.SecFld(n). For a prime number n this will give a field with modulus n. Specifying both order=n, modulus=n is redundant in this case.

To access the modulus, you would first need to access the underlying field:

>>> secnum = mpc.SecFld(257)
>>> secnum
<class 'mpyc.sectypes.SecFld9(GF(257))'>
>>> secnum.field
<class 'mpyc.finfields.GF(257)'>
>>> secnum.field.modulus
257 

[prog-Noon]

First of all, thank you very much for answering my question.
what I meant is actually still an idea I thought it could be done.
The idea is in short : Think about the two parties as two teams and from each team we need at least t out of n players to play.
in my case I have two parties and I want from the first party 5 shares for example and from the second party 5 shares where each share can be given to a different persons.
I hope I could clarify my idea.

[lschoe]

Oh, thx, I see. In principle you can program this yourself but things may get rather complicated as you probably have to deal with quite a few low-level details, details which MPyC otherwise takes care of.

[prog-Noon]

The thing that the shares in general in my case can't be considered all the same, there is a "two teams" concept.
So, if we want to follow the approach that I mentioned self.shares = random_split(...) can't do the share split for each private key?
If so, it there any suggestion about how we can approach this problem?
thank you very much in advance!!

[lschoe]

You can see if functions like random_split(field, s, t, m) can be used for your purposes, and otherwise you have write such functions yourself (and then things can get pretty complicated).