Add (R)OLE to mpz #103

th4s · 2024-02-20T12:07:42Z

This PR adds OLE and ROLE to mpz by introducing two new crates and creates the building blocks, like e.g. traits and module structure, for future OLE flavors and additional implementations.

~~I still need to do some small improvements here and there, but thought it is a good idea to get it out now.~~
Ready for review.

th4s · 2024-03-04T09:44:47Z

This will need to be adapted/rebased to the new architecture for IO.

th4s · 2024-03-07T11:58:37Z

Rebased and adapted to new IO design. Should be ready for review.

th4s · 2024-03-07T17:24:01Z

Rebased onto threading-refactor. Ready for review.

themighty1 · 2024-03-08T07:36:37Z

Im happy to review this once we all agree on what specific approach we will be taking for E2F and GHASH. For now, we only tentatively agreed to use the PADO's approach with modifications to work around the 0 input issue.
I have not examined PADO's protocols in detail yet.
So, Im expecting the following sequence of events:

Jordan ACKs that he's ok with using PADO's E2F and GHASH with our 0-input fix
I'll review PADO's E2F and GHASH to make sure they make sense
I'll analyze the ROT->ROLE protocol again with greater scrutiny
I'll review the rest of this PR

sinui0 · 2024-04-26T22:42:01Z

I haven't gone very deep in review here yet, but lets address some high level points:

I don't think it is appropriate to describe this protocol as Random OLE. That would imply the protocol deals random shares to both parties, which is not the case here.
Looking at your write up, it appears that "Random OLE" is exactly MASCOT (COPEe KOS16) with an additional step where the parties adjust their shares. AFAICT this share adjustment is superfluous, as they already choose them once and can sample them randomly if that is what they want, eg for offline preprocessing. I suggest we remove this step and just implement KOS16 verbatim.

It recently occurred to me that the best approach is likely to just re-use the PRG seeds shared during the base OT for OT extension. Using the messages from ROT to seed the PRGs in COPEe seems unnecessary, and prevents us from preprocessing the OLEs in parallel with the OT extension.
We should stick with common nomenclature: OLE Sender and Receiver. Renaming these parties to Provider and Evaluator is bound to cause confusion. To help grok these terms: The Sender sends a linear function to the protocol and the Receiver receives an evaluation of that function at the index of their choice.
Regarding the "0-input fix" that should exist outside this OLE implementation entirely. It would be a sub-protocol of GHASH. Let's discuss that later, elsewhere.
The "with errors" suffix should not be present in any of the traits. We should just have an OleSender and OleReceiver trait, and users must understand the real functionality of the protocol they use which implements these traits.

sinui0

I had some WIP review here that I'll just post in addition to my previous comment.

Additionally, I was expecting to see the use of a PRF in the OLEe implementation, but saw it no where? It looked like you are operating directly on the ROT messages instead of using them as keys to the PRF.

I think we can avoid any mention of ROT in this crate, we simply use ROT to sample the PRF keys for KOS16.

sinui0 · 2024-03-07T17:31:10Z

crates/mpz-ole-core/src/ideal/ole.rs

+use rand::{rngs::ThreadRng, thread_rng};
+
+/// The OLE functionality
+pub struct OLEFunctionality<F> {


I recommend sticking to Ideal*, "functionality" is a mouthful for a type name.

sinui0 · 2024-03-07T17:48:31Z

crates/mpz-ole-core/src/ole/mod.rs

@@ -0,0 +1,3 @@
+//! Provides implementations of OLE with errors (OLEe) protocols.


Suggested change

//! Provides implementations of OLE with errors (OLEe) protocols.

//! Oblivious linear evaluation protocols

The "with errors" should be a caveat documented on the specific implementation, not at the module level

While we're at it, we can be more verbose in our comments "oblivious linear evaluation" is also a short-hand which may be confusing to the uninitiated. The full term "oblivious linear function evalution", i.e. there exists a linear function which gets evaluated obliviously.

sinui0 · 2024-03-07T17:59:07Z

crates/mpz-ole-core/src/ideal/mod.rs

@@ -0,0 +1,7 @@
+//! This module provides ideal functionalities for OLE and ROLE.


Suggested change

//! This module provides ideal functionalities for OLE and ROLE.

//! Ideal OLE functionalities.

They're all just variants of OLE, we can keep the module doc general

sinui0 · 2024-03-07T18:04:15Z

crates/mpz-ole-core/src/ideal/role.rs

@@ -0,0 +1,94 @@
+//! This module provides an ideal ROLE functionality.


Suggested change

//! This module provides an ideal ROLE functionality.

//! Ideal ROLE.

Style wise, I think I prefer very succinct module and type headlines. It just reads cleaner with rustdoc to avoid leading words like "this module provides..." etc. Of course, its totally fine to be more verbose in the following description

sinui0 · 2024-03-07T18:04:43Z

crates/mpz-ole-core/src/ideal/role.rs

+use mpz_fields::Field;
+use rand::{rngs::ThreadRng, thread_rng};
+
+/// The ROLE functionality


Suggested change

/// The ROLE functionality

/// Ideal ROLE.

sinui0 · 2024-03-07T18:06:33Z

crates/mpz-ole-core/src/lib.rs

+//! This crate provides implementations of different Oblivious Linear Evaluation with Errors (OLEe)
+//! flavors. It provides the core logic of the protocols without I/O.


Suggested change

//! This crate provides implementations of different Oblivious Linear Evaluation with Errors (OLEe)

//! flavors. It provides the core logic of the protocols without I/O.

//! Core implementations of various Oblivious Linear Evaluation protocols.

sinui0 · 2024-04-26T22:44:39Z

crates/mpz-ole-core/src/role/ot/mod.rs

+/// Workaround because of feature `generic_const_exprs` not available in stable.
+///
+/// This is used to check at compile-time that the correct const-generic implementation is used for
+/// a specific field.
+struct Check<const N: usize, F: Field>(std::marker::PhantomData<F>);
+
+impl<const N: usize, F: Field> Check<N, F> {
+    const IS_BITSIZE_CORRECT: () = assert!(
+        N as u32 == F::BIT_SIZE / 8,
+        "Wrong bit size used for field. You need to use `F::BIT_SIZE` for N."
+    );
+}


We should just add an associated const BYTE_SIZE to Field

sinui0 · 2024-04-26T22:53:47Z

crates/mpz-ole-core/src/role/mod.rs

Let's remove this entire module and focus on OLEe

The nice thing of going from ROLE -> OLE is that ROLE can be preprocessed. If we do not use ROLE to instantiate OLE then we probably go with Gilboa99, which does not allow preprocessing.

th4s · 2024-05-06T09:09:27Z

Thanks for the review.

Can you explain why you think that the parties are not dealt random shares?
The difference between KOS16 (which is a VOLE) and this ROLE implementation is that in KOS16 the Delta is fixed. So the "Extend" calls cannot be used as a basis for an OLE, because only one party can choose the input. But for E2F or Ghash we need this degree of freedom. Am I missing something?
Agree
The 0-fix is not implemented. It only exists in the research write-up and we probably won't need it.
Agree

th4s · 2024-05-06T09:13:39Z

I went the route of using PRNGs for ROLE. So that you also have a Setup call and Extend calls. I don't think that this works. Relevant PR tlsnotary/docs-mdbook#65

sinui0 · 2024-05-07T05:31:04Z

Can you explain why you think that the parties are not dealt random shares?

In steps 1 and 2 of your Extend the parties sample their target shares, then subsequently use them to adjust the VOLE from COPEe. The functionality is not dealing these shares, the parties are choosing them. There is no constraint on the distribution from which these shares are sampled. I suggest we just skip this step, which is equivalent to COPEe.

The difference between KOS16 (which is a VOLE) and this ROLE implementation is that in KOS16 the Delta is fixed. So the "Extend" calls cannot be used as a basis for an OLE, because only one party can choose the input. But for E2F or Ghash we need this degree of freedom. Am I missing something?

KOS16 indeed does implement VOLE, or in our case $l = 1$ which is a single OLE. You're correct though, we can't reuse the base OTs as I was suggesting earlier, so we can stick with using ROT from OT extension to sample/transfer the PRG seeds.

I'm not quite sure that your protocol is secure. Re-iterating, it looks to me to be COPEe where each extend call to COPEe is then followed by a share adjustment to convert the VOLE into an OLE. This would imply you can get n-OLE from VOLE simply with this share adjustment. Maybe that's true, but it's not self-evident to me that it's secure.

th4s · 2024-05-07T09:53:09Z

In steps 1 and 2 of your Extend the parties sample their target shares, then subsequently use them to adjust the VOLE from COPEe. The functionality is not dealing these shares, the parties are choosing them. There is no constraint on the distribution from which these shares are sampled. I suggest we just skip this step, which is equivalent to COPEe.

I'm not quite sure that your protocol is secure. Re-iterating, it looks to me to be COPEe where each extend call to COPEe is then followed by a share adjustment to convert the VOLE into an OLE. This would imply you can get n-OLE from VOLE simply with this share adjustment. Maybe that's true, but it's not self-evident to me that it's secure.

I am not sure what you mean by Extend. For ROLE in the current construction (https://github.com/tlsnotary/docs-mdbook/blob/main/research/ole-flavors.typ#L29-L43) there is no Extend call. The construction is pretty different from COPEe, which was only the starting point.

KOS16 indeed does implement VOLE, or in our case which is a single OLE. You're correct though, we can't reuse the base OTs as I was suggesting earlier, so we can stick with using ROT from OT extension to sample/transfer the PRG seeds.

When I designed this, I tried to come up with with a Setup, Extend approach for ROLE, too, but couldn't get this to work in a way which made me feel safe about it. I did not invest too much time into this, because we have preprocessed random OTs available, so I felt that the performance impact was negligible. I tried using PRG seeds for ROLE, but I was not sure that this is safe.

- also fixed bug in ideal functionality of role

sinui0

Algorithms LGTM 👍

I would suggest that you refactor a bit more to remove the *Sender and *Receiver types, as they have no internal state and complicate the API. Instead of an actor operating on data, we should instead provide newtypes for the data and implement the API directly on them. For example:

pub struct SenderShare<F>(F);

impl<F: Field> SenderShare<F> {
  pub fn new(share: F, corr: [[F; 2]; F::BIT_LENGTH]) -> (Self, MaskedInput<F>) {
    ...
  }
  
  pub fn adjust(self, target: F) -> (SenderAdjust<F>, ShareAdjust<F>) {
    ...
  }
}

pub struct ReceiverShare<F>(F);

impl<F: Field> ReceiverShare<F> {
  pub fn new(
    share: F,
    sender_input: MaskedInput<F>,
    corr: [F; F::BIT_LENGTH]
  ) -> Self {
    ...
  }
  
  pub fn adjust(self, target: F) -> (ReceiverAdjust<F>, ShareAdjust<F>) {
    ...
  }
}

pub struct ShareAdjust<F>(F);

pub struct SenderAdjust<F>(F);

impl<F: Field> SenderAdjust<F> {
  pub fn finish(self, receiver_adjust: ShareAdjust<F>) -> SenderShare<F> {
    ...
  }
}

pub struct ReceiverAdjust<F>(F);

impl<F: Field> ReceiverAdjust<F> {
  pub fn finish(self, sender_adjust: ShareAdjust<F>) -> ReceiverShare<F> {
    ...
  }
}

This would just be the core API, we can still add the sender and receiver types to store the preprocessed OLEs

sinui0 · 2024-05-10T17:07:02Z

crates/mpz-ole-core/src/cope/receiver.rs

+    pub fn generate(
+        &self,
+        delta_k: &[F],
+        t_delta_i: &[[u8; N]],


t_delta_i can instead be [F] and its up to the user to provide it in that format. We can add the bit iterator trait as a bound on F (not on the Field trait itself).

sinui0 · 2024-05-10T17:08:06Z

crates/mpz-ole-core/src/cope/receiver.rs

+            )));
+        }
+
+        let delta_i: Vec<bool> = delta_k.iter_lsb0().collect();


I believe we can avoid this extra allocation using iterator combinators

sinui0 · 2024-05-10T17:23:58Z

crates/mpz-ole-core/src/cope/sender.rs

+    /// # Returns
+    ///
+    /// * `ui` - The correlations, which will be sent to the receiver.
+    /// * `t0k` - The sender's final OLE output summands.


These are simply "the Sender's shares", maybe ak, right?

I tried to use the MASCOT paper's notation for this module, so that understanding it and checking for correctness is as easy as possible.

sinui0 · 2024-05-10T17:37:52Z

crates/mpz-ole-core/src/ideal.rs

Rather than having multiple methods here which mutable some internal state of the functionality, I think it can simply provide a method like:

pub fn execute<F: Field>( &mut self, sender_input: Vec<F>, receiver_input: Vec<F> ) -> (Vec<F>, Vec<F>)

th4s · 2024-05-13T12:32:51Z

Alright, I tried it out and it seems to work out quite nicely.

- also use correct type for `adjust` methods.

- Shifted share logic to `core` module.

- Added tests. - Refactored test helper functions.

th4s · 2024-05-14T16:15:27Z

Closing in favor of #135.

th4s changed the base branch from dev to add-ot-core-ideal-rot February 20, 2024 12:09

th4s force-pushed the add-ot-core-ideal-rot branch from 47766a1 to 9e137d0 Compare February 20, 2024 12:10

th4s force-pushed the ole-crate branch 4 times, most recently from 3af76ed to 8661279 Compare February 21, 2024 22:28

th4s requested review from sinui0 and themighty1 February 22, 2024 11:35

th4s force-pushed the add-ot-core-ideal-rot branch from ccce5dd to ad39a0a Compare February 27, 2024 09:35

th4s force-pushed the ole-crate branch from ccf1137 to 2146275 Compare February 27, 2024 09:37

th4s force-pushed the add-ot-core-ideal-rot branch from ad39a0a to c70c750 Compare March 7, 2024 09:52

th4s force-pushed the ole-crate branch from 4887d1c to 2de0b5a Compare March 7, 2024 10:00

th4s force-pushed the add-ot-core-ideal-rot branch from c70c750 to 950c87b Compare March 7, 2024 17:02

th4s force-pushed the ole-crate branch from 794a779 to 22da72c Compare March 7, 2024 17:22

th4s changed the base branch from add-ot-core-ideal-rot to threading-refactor March 7, 2024 17:23

sinui0 requested changes Apr 26, 2024

View reviewed changes

sinui0 force-pushed the threading-refactor branch from 00cd519 to 73441ff Compare April 30, 2024 00:35

th4s force-pushed the ole-crate branch from 26a3658 to 5e40fa6 Compare May 7, 2024 09:29

th4s added 3 commits May 10, 2024 09:41

Create ole crate

5611c16

Added drafts for ole traits (OLEe, ROLEe) and implementations

38b8087

Reorganize crate structure

1e7007e

th4s added 16 commits May 10, 2024 09:41

Added functionality for OLE in mpz-ole-core

afda8b4

Add ideal runctionality for role in mpz-ole core.

92e26fb

Added test for ole based on role in mpz-ole-chore

f2cbefd

- also fixed bug in ideal functionality of role

Make clippy happy.

8324933

Improve code quality for mpz-ole-core.

3263497

Improve error handling and trait documentation in mpz-ole

21f1a36

Remove chacha dependency in mpz-ole

2181e33

Improve code quality and documentation in mpz-ole

3d675de

WIP: Adapting mpz-ole to new OT traits...

5b2810b

Finish adapting mpz-ole to new IO model.

1a15344

Fix imports of mpz-fields

234caa0

Adapt OLE trait definitions

5cbe034

Adapt OLE crates to new threading

6ba4d97

Remove leftover from rebasing

a7a0aa5

Adapt to new crate structure

10449e0

Get rid of unneeded feature flag

67cf946

th4s force-pushed the ole-crate branch from 5e40fa6 to 67cf946 Compare May 10, 2024 07:41

th4s added 2 commits May 10, 2024 11:53

Add support for generic ideal ROT.

4e6d80e

Rewrite mpz-ole-core to use COPEe.

410b6f8

sinui0 reviewed May 10, 2024

View reviewed changes

th4s added 6 commits May 13, 2024 17:30

Rewrote mpz-ole-core to use share types.

6cd3a07

Bugfix for OLE.

938c45e

- also use correct type for `adjust` methods.

Add test for share adjustment.

9eb6c4e

Added sender/receiver modules.

6fc1bbb

- Shifted share logic to `core` module.

Added OLESender.

442511f

Added OLEReceiver.

36f42f3

- Added tests. - Refactored test helper functions.

th4s closed this May 14, 2024

sinui0 deleted the ole-crate branch June 6, 2024 16:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add (R)OLE to mpz #103

Add (R)OLE to mpz #103

th4s commented Feb 20, 2024 •

edited

Loading

th4s commented Mar 4, 2024

th4s commented Mar 7, 2024

th4s commented Mar 7, 2024

themighty1 commented Mar 8, 2024

sinui0 commented Apr 26, 2024 •

edited

Loading

sinui0 left a comment

sinui0 Mar 7, 2024

sinui0 Mar 7, 2024

themighty1 Apr 29, 2024

sinui0 Mar 7, 2024

sinui0 Mar 7, 2024

sinui0 Mar 7, 2024

sinui0 Mar 7, 2024

sinui0 Apr 26, 2024

sinui0 Apr 26, 2024

th4s May 6, 2024

th4s commented May 6, 2024 •

edited

Loading

th4s commented May 6, 2024

sinui0 commented May 7, 2024

th4s commented May 7, 2024

sinui0 left a comment •

edited

Loading

sinui0 May 10, 2024

sinui0 May 10, 2024

sinui0 May 10, 2024

th4s May 13, 2024

sinui0 May 10, 2024

th4s commented May 13, 2024

th4s commented May 14, 2024

		@@ -0,0 +1,3 @@
		//! Provides implementations of OLE with errors (OLEe) protocols.

	//! Provides implementations of OLE with errors (OLEe) protocols.
	//! Oblivious linear evaluation protocols

		@@ -0,0 +1,7 @@
		//! This module provides ideal functionalities for OLE and ROLE.

	//! This module provides ideal functionalities for OLE and ROLE.
	//! Ideal OLE functionalities.

		@@ -0,0 +1,94 @@
		//! This module provides an ideal ROLE functionality.

	//! This module provides an ideal ROLE functionality.
	//! Ideal ROLE.

		//! This crate provides implementations of different Oblivious Linear Evaluation with Errors (OLEe)
		//! flavors. It provides the core logic of the protocols without I/O.

	//! This crate provides implementations of different Oblivious Linear Evaluation with Errors (OLEe)
	//! flavors. It provides the core logic of the protocols without I/O.
	//! Core implementations of various Oblivious Linear Evaluation protocols.

Add (R)OLE to mpz #103

Add (R)OLE to mpz #103

Conversation

th4s commented Feb 20, 2024 • edited Loading

th4s commented Mar 4, 2024

th4s commented Mar 7, 2024

th4s commented Mar 7, 2024

themighty1 commented Mar 8, 2024

sinui0 commented Apr 26, 2024 • edited Loading

sinui0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

th4s commented May 6, 2024 • edited Loading

th4s commented May 6, 2024

sinui0 commented May 7, 2024

th4s commented May 7, 2024

sinui0 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

th4s commented May 13, 2024

th4s commented May 14, 2024

th4s commented Feb 20, 2024 •

edited

Loading

sinui0 commented Apr 26, 2024 •

edited

Loading

th4s commented May 6, 2024 •

edited

Loading

sinui0 left a comment •

edited

Loading