Request: Examples demonstrating IKNP Oblivious Transfer usage

[Smart-SangGe]

Hello,

Thank you for developing this library. The project structure and the cryptographic primitives implemented are very interesting and useful, particularly within the field of secure computation.

I am currently trying to understand how to correctly utilize the IKNP Oblivious Transfer implementation provided in the repository, specifically its application in larger protocols. While the protocol implementation itself appears sound, I am struggling to correctly instantiate and apply it in a meaningful way.

Would it be possible to add a minimal, runnable example demonstrating the following:

Setup: How to initialize and configure both the sender and receiver for an IKNP OT session.

Execution: A simple sequence showing the execution flow for a basic data transfer using the IKNP OT protocol.

These examples would be immensely helpful for postgraduate students and other researchers looking to leverage this specific implementation for practical projects. Code examples often illuminate the required initial state, state transitions, and expected inputs/outputs far better than documentation alone when dealing with complex primitives like this.

Thank you for your time and consideration.

[robinhundt]

Hi, thanks for trying out my library! Unfortunately I haven't had as much time to work on it lately as I'd like. There is definitely a lot to improve docs wise.

For the IKNP OT, you can see an example in the benches

CryProt/cryprot-ot/benches/bench.rs

Lines 295 to 323 in 2920852

	g.bench_function(format!("2**{p} random extension OTs"), |b| {
	b.to_async(&rt).iter_custom(|iters| {
	let c11 = c1.sub_connection();
	let c22 = c2.sub_connection();
	async move {
	let mut duration = Duration::ZERO;
	// setup not included in duration
	let mut sender = SemiHonestSilentOtSender::new(c11);
	let mut receiver = SemiHonestSilentOtReceiver::new(c22);
	for _ in 0..iters {
	let now = Instant::now();
	(sender, receiver) = tokio::try_join!(
	tokio::spawn(async move {
	sender.random_send(count).await.unwrap();
	sender
	}),
	tokio::spawn(async move {
	receiver.random_receive(count).await.unwrap();
	receiver
	})
	)
	.unwrap();
	duration += now.elapsed();
	}
	duration
	}
	})
	});

The tricky part is how you get the connection. In the test cases I'm using the local_conn() function of cryprot-net. This function is public when the internal __testing cargo feature is enabled:

CryProt/cryprot-net/src/testing.rs

Lines 17 to 59 in 2920852

	#[tracing::instrument]
	pub async fn local_conn() -> anyhow::Result<(Connection, Connection)> {
	// TODO sensible send buffer sizes and limits
	#[allow(non_upper_case_globals)]
	const MiB: usize = 1024 * 1024;
	let max_streams = 1 << 59;
	let limits = Limits::new()
	.with_max_send_buffer_size(12 * MiB as u32)?
	.with_max_open_local_unidirectional_streams(max_streams)?
	.with_max_open_remote_unidirectional_streams(max_streams)?;
	let addr = "127.0.0.1:0".parse()?;
	let io = || {
	s2n_quic::provider::io::Default::builder()
	.with_receive_address(addr)?
	.with_max_mtu(9000)?
	.build()
	};
	let mut server: Server = Server::builder()
	.with_tls((CERT_PEM, KEY_PEM))?
	.with_io(io()?)?
	.with_limits(limits)?
	.start()?;
	let server_port = server.local_addr()?.port();
	let client = Client::builder()
	.with_tls(CERT_PEM)?
	.with_io(io()?)?
	.with_limits(limits)?
	.start()?;
	let addr: SocketAddr = (Ipv4Addr::LOCALHOST, server_port).into();
	let connect = Connect::new(addr).with_server_name("localhost");
	let (server_conn, client_conn) = join!(server.accept(), client.connect(connect));
	let server_conn = server_conn.context("server_conn")?;
	let client_conn = client_conn?;
	let (server_conn, stream_manager) = Connection::new(server_conn);
	tokio::spawn(stream_manager.start());
	let (client_conn, stream_manager) = Connection::new(client_conn);
	tokio::spawn(stream_manager.start());
	Ok((server_conn, client_conn))
	}

You can have a look at the local_conn function to see how to create a cryprot-net::Connection from an s2n-quick::Connection.

If you just want to have a connection for local testing purposes, you can also enable the __testing feature on cryprot-net net and just use the function. But beware that everything exposed by the __testing feature is not subject to semver guarantees and might change or be removed at any moment.

Do you want to run two parties in separate processes on different machines or just testing in the same process?

[Smart-SangGe]

Thanks for the explanation regarding local_conn. I am planning to proceed with independent process testing, likely simulating it via loopback addresses. I have also been looking at the ALSZ implementation in swanky, but their Channel design relies heavily on synchronous TCP (implementing Read + Write traits), which I found difficult to adapt to my async context. I really appreciate that your library uses an async implementation, and I am eager to utilize the QUIC protocol.

Regarding the instantiation, I noticed that swanky requires manually specifying a Base OT (such as Chou-Orlandi). In your example code, the SemiHonestSilentOtSender seems to not require this explicitly. Does your implementation handle the Base OT phase implicitly with a default protocol (e.g., during the setup phase), or is it abstracted away entirely in the constructor?

[robinhundt]

Yes, swanky is using synchronous interfaces, which makes it a bit annoying in an async context. But their implementation abstracts the communication channel, which also has benefits. I had a previous OT library which also used a trait for communication, but for cryprot-ot I really wanted to make use of the multiplexing built-in into QUIC. At some point I might also introduce a generic Channel trait with a default implementation based on QUIC, but it's a bit tricky to design.

Yes, the semi-honest OT implementation uses maliciously secure CO15 base OTs by default. Currently there is no way of using other base OTs or semi-honestly secure ones, but usually the base OTs are not the bottleneck. If you want, you can explicitly call the do_base_ots() methods on the sender and receiver. This will initialize 128 base OTs and use them on subsequent OT calls. If you don't explicitly call this, it will be called in the first OT call (send/receive), not in the constructor. The implementation is based on this libOTe implementation with the mUniformOts = true option. If I remember correctly, this is needed in the malicious case when uniformly random OTs are required and is a slight change from the original CO15 protocol.

[Smart-SangGe]

#[tokio::main]
async fn main() -> Result<()> {
    let cli = Cli::parse();
    let addr: SocketAddr = "127.0.0.1:4433".parse()?;

    match cli.command {
        Commands::Sender => {
            let (cert_pem, key_pem) = load_or_generate_cert(true)?;

            let mut server = Server::builder()
                .with_tls((cert_pem.as_str(), key_pem.as_str()))?
                .with_io(addr)?
                .start()?;

            println!("Sender (Server) listening on {}", addr);

            if let Some(connection) = server.accept().await {
                println!("Client connected!");

                let (mut conn, stream_manager) = CryConn::new(connection);
                tokio::spawn(stream_manager.start());

                println!("Starting OT Sender...");
                let mut sender = SemiHonestSilentOtSender::new(conn.sub_connection());
                sender.random_send(1024).await?;
                println!("OT Send complete!");
            }
        }
        Commands::Receiver => {
            let (cert_pem, _) = load_or_generate_cert(false)?;

            let client = Client::builder()
                .with_tls(cert_pem.as_str())?
                .with_io("0.0.0.0:0")?
                .start()?;

            println!("Receiver (Client) connecting to {}", addr);

            let connect = Connect::new(addr).with_server_name("localhost");
            let connection = client.connect(connect).await?;

            let (mut conn, stream_manager) = CryConn::new(connection);
            tokio::spawn(stream_manager.start());

            println!("Starting OT Receiver...");
            let mut receiver = SemiHonestSilentOtReceiver::new(conn.sub_connection());
            receiver.random_receive(1024).await?;
            println!("OT Receive complete!");
        }
    }
    Ok(())
}

I wrote this basic code. Is this correct? My expected result will be that a message selection bit needs to be provided? Like this code.

Channel::with(stream, |channel| {
                let mut ot_receiver: AlszReceiver<ChouOrlandiSender> =
                    AlszReceiver::init(channel, &mut rng)
                        .wrap_err("Failed to initialize OT receiver")?;

                let choices = vec![false, true];
                let results = ot_receiver
                    .receive(channel, &choices, &mut rng)
                    .wrap_err("Failed to receive blocks")?;

                println!("Bob received blocks: {:?}", results);
                Ok(())
            })

[robinhundt]

The first code snippet looks good.

The second snippet looks like code using the swanky OT library. I assume you're asking about providing the choice bits? The current silent-OT API doesn't allow providing the choice bits yourself (this is due to the protocol, where these choice bits are sampled internally). The random_receive method on the SilentOtReceiver returns a tuple of the OTs and the sampled choice bits.

If you need to provide the choice bits yourself, you can either use the non-silent OT extension protocol or use silent OT with randomly sampled choice bits and send a correction bitvector from the receiver to the sender so that they can swap their OTs.

For the second option using silent OT, you can look at the implementation in libOTe here: receiver and sender. This does add an overhead of one bit per OT of communication, but this is unavoidable with silent OT as far as I'm aware.

[robinhundt]

Oh, I just realized that the library already provides a way of using silent OT with chosen choice bits. There is the ChosenChoice adapter which can be used with the silent OT implementation and implements exactly what I linked in the previous comment.

[Smart-SangGe]

Thank you, I'll take another look when I have time in the next few days.