implement Uint256 and modular add

[hextrust-0]

This PR implements the Uint256 and AddMod function.

[hextrust-0]

@markkurossi @rozag Please review

[hextrust-0]

@markkurossi

Do you have any better ideas for calculating modular addition for MPC, especially for generating the Garble Circuit? You may not like this line of code, as it only works for large prime numbers (modulus). For small modulus, it may not return the correct value.

[markkurossi]

The MPCL language does not have fixed integer sizes but you can specify any bit size from 1-n bits. So it is possible to define variables, for example, of type uint256 directly in the code:

package main

type Garbler struct {
	val uint256
	mod uint256
}

func main(g Garbler, e uint256) uint {
	sum := g.val + e
	if sum > g.mod {
		sum -= g.mod
	}
	return sum
}

The compiler uses half and full adders and subtractors to create circuits for the specified parameter size. The example above computes modular addition assuming that g.val and e are smaller than g.mod. This produces circuit of size:

circuit: #gates=4341 (XOR=2549 XNOR=768 AND=1023 OR=0 INV=1 xor=3317 !xor=1024 levels=771 width=256) #w=5109

The same example can be converted to support input sizes bigger than g.mod by using the % operator:

package main

type Garbler struct {
	val uint256
	mod uint256
}

func main(g Garbler, e uint256) uint {
	return (g.val + e) % g.mod
}

However, this produces significantly bigger circuit:

circuit: #gates=525823 (XOR=394238 XNOR=0 AND=131583 OR=1 INV=1 xor=394238 !xor=131585 levels=197888 width=259) #w=526591

[hextrust-0]

@markkurossi Thanks for the explanation. I try to write an example and compare both approaches.
Do we have any built-in operator to convert int1-n into bytes?

[markkurossi]

The encoding/binary/PutUint(d []byte, offset int, v uint) []byte is parameterizable and can be instantiated to any integer size v (1-n bits). It encodes the value into buffer d in MSB-order. LSB-order encoding would be an easy addition if needed.

[hextrust-0]

@markkurossi Thanks for the explanation.

[hextrust-0]

@markkurossi
Both ways have potential issues: they can overflow.
That's why in native implementations, they check for overflow.
Technically, to sum two uint256 numbers, we need 257 bits. One bit accounts for overflow.

[hextrust-0]

@hextrust-0
I closed this pull request. If any part of it is worth keeping, please let me know, and I'll create a new pull request for that part.

[markkurossi]

The GetUint64() and PutUint64() functions are valid ones so happy to merge those.

…

On Tue, May 7, 2024 at 9:19 AM hextrust-0 ***@***.***> wrote: @hextrust-0 <https://github.com/hextrust-0> I closed this pull request. If any part of it is worth keeping, please let me know, and I'll create a new pull request for that part. — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYFJDZBFYORZRZE6LFQKATZBB56HAVCNFSM6AAAAABG55YMI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJXGYYTKNZXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Markku Rossi +358 40 729 0115 ***@***.*** | www.markkurossi.com

[hextrust-0]

It's here: #26
But based on your explanation, PutUint and GetUint alone are enough to convert any bytes to corresponding uint1-n value.