add ferret with io

[xiangxiecrypto]

• SPCOT with io
• MPCOT with io
• Ferret with io

Note that in the Ferret implementation, we need two random COTs. One for MPCOT (SPCOT), which can be IKNP-type (KOS) Random COTs. The other one is for the setup in Ferret, which will be Ferret with smaller parameters.

All the parameters will be chosen when the lpn estimator is done.

[sinui0]

Great, thanks! Will review soon.

[sinui0]

Excited to see it all come together! 🔥

I have some requests which should simplify things quite a bit.

1. For MPCOT, I believe we can eliminate a lot of duplication by encapsulating the different LPN types (regular/uniform). Instead of having two types you can add an argument to the constructor and handle it behind the API. The core types can remain separate but the IO wrapper can be unified.
2. The check and finalize methods should not be exposed in the public API. When calling extend the user should just provide the number of OTs they want and you handle the entire process for them. Additionally, extend should not return the OTs, it should buffer them internally because it is used during the preprocessing phase. This buffering should be performed in the core crate, the same as how we do it for KOS.

For example, here is what the public API could look like:

impl<RandomCOT> Sender<RandomCot> {
  pub fn new(lpn_type: LpnType, rcot: RandomCOT) -> Self { .. }

  pub async fn setup<Ctx: Context>(&mut self, ctx: &mut Ctx) 
    -> Result<(), SenderError> { .. }
  
  /// Preprocesses `count` OTs.
  pub async fn extend<Ctx: Context>(&mut self, ctx: &mut Ctx, count: usize)
    -> Result<(), SenderError> { .. }
}

This applies to SPCOT, MPCOT and Ferret

[sinui0]

left over

[sinui0]

Suggested change

	use rayon::iter::{
	IndexedParallelIterator, IntoParallelRefIterator, IntoParallelRefMutIterator, ParallelIterator,
	};
	#[cfg(feature = "rayon")]
	use rayon::iter::{
	IndexedParallelIterator, IntoParallelRefIterator, IntoParallelRefMutIterator, ParallelIterator,
	};

[sinui0]

Suggested change

	use rayon::iter::{
	IndexedParallelIterator, IntoParallelRefIterator, IntoParallelRefMutIterator, ParallelIterator,
	};
	#[cfg(feature = "rayon")]
	use rayon::iter::{
	IndexedParallelIterator, IntoParallelRefIterator, IntoParallelRefMutIterator, ParallelIterator,
	};

[sinui0]

Suggested change

	let iter = alphas
	.par_iter()
	.zip(ms_s.par_iter())
	.zip(sum_s.par_iter())
	.zip(hs.par_iter())
	.zip(ts_s.par_iter())
	.zip(trees.par_iter_mut())
	.map(|(((((alpha, ms), sum), h), ts), tree)| (alpha, ms, sum, h, ts, tree));
	let iter = alphas
	.par_iter()
	.zip(ms_s.par_iter())
	.zip(sum_s.par_iter())
	.zip(hs.par_iter())
	.zip(ts_s.par_iter())
	.zip(trees.par_iter_mut())
	.map(|(((((alpha, ms), sum), h), ts), tree)| (alpha, ms, sum, h, ts, tree));

[sinui0]

Suggested change

	let iter = alphas
	.iter()
	.zip(ms_s.iter())
	.zip(sum_s.iter())
	.zip(hs.iter())
	.zip(ts_s.iter())
	.zip(trees.iter_mut())
	.map(|(((((alpha, ms), sum), h), ts), tree)| (alpha, ms, sum, h, ts, tree));
	let iter = alphas
	.iter()
	.zip(ms_s.iter())
	.zip(sum_s.iter())
	.zip(hs.iter())
	.zip(ts_s.iter())
	.zip(trees.iter_mut())
	.map(|(((((alpha, ms), sum), h), ts), tree)| (alpha, ms, sum, h, ts, tree));

[sinui0]

Why is this passed in here? I would just call the instance we pass into MPCOT

[xiangxiecrypto]

can you please be more specific?
I think the MPCOT instance is determined by the lpn parameter chosen here.

[sinui0]

I mean that the MPCOT instance already owns an RCOT, so we shouldn't need to pass in another one here

[xiangxiecrypto]

That is what I mentioned in the PR comment. We will use a different RCOT here, i.e., Ferret with smaller parameters, to bootstrap.

[xiangxiecrypto]

Excited to see it all come together! 🔥

I have some requests which should simplify things quite a bit.

1. For MPCOT, I believe we can eliminate a lot of duplication by encapsulating the different LPN types (regular/uniform). Instead of having two types you can add an argument to the constructor and handle it behind the API. The core types can remain separate but the IO wrapper can be unified.

Yep, we can simplify mpcot to just one type.

2. The check and finalize methods should not be exposed in the public API. When calling extend the user should just provide the number of OTs they want and you handle the entire process for them. Additionally, extend should not return the OTs, it should buffer them internally because it is used during the preprocessing phase. This buffering should be performed in the core crate, the same as how we do it for KOS.

Maybe we can keep spcot and mpcot internal apis, since they are only called by ferret. In this case, we do not need to keep all the output in internal states, it is much easier to be integrated by ferret.

As to finalize, I meant to explicitly close the extension procedure of ferret. In KOS, the state will automatically turn to Complete after the check procedure (if I understand correctly). While in ferret, it will always allow us to extend, unless we manually turn it off with finalize.

For example, here is what the public API could look like:

impl<RandomCOT> Sender<RandomCot> {
  pub fn new(lpn_type: LpnType, rcot: RandomCOT) -> Self { .. }

  pub async fn setup<Ctx: Context>(&mut self, ctx: &mut Ctx) 
    -> Result<(), SenderError> { .. }
  
  /// Preprocesses `count` OTs.
  pub async fn extend<Ctx: Context>(&mut self, ctx: &mut Ctx, count: usize)
    -> Result<(), SenderError> { .. }
}

This applies to SPCOT, MPCOT and Ferret

[sinui0]

Maybe we can keep spcot and mpcot internal apis, since they are only called by ferret. In this case, we do not need to keep all the output in internal states, it is much easier to be integrated by ferret.

Yes, we can keep SPCOT and MPCOT private for now to simplify things.

As to finalize, I meant to explicitly close the extension procedure of ferret. In KOS, the state will automatically turn to Complete after the check procedure (if I understand correctly). While in ferret, it will always allow us to extend, unless we manually turn it off with finalize.

Ok, I see the intent now. I'm not sure if that is necessary though. For KOS we only do this because the consistency check is leaky and we did not see any proofs that leakage of Delta is bounded when running multiple extensions. For Ferret, my understanding is that extension can be performed indefinitely, is that correct?