Report Information leakage vulnerability in the protocols of RSS in Crypten

[GuopengLin]

Description:

The "mul", "matmul", "conv1d", "conv2d", "conv_transpose1d", "conv_transpose2d" protocols based on RSS in Crypten are not implemented correctly, which introduces the risk of information leakage.

The issue arises because the code misses a critical step—adding a zero-sum value to mask the result shares. This omission allows for potential leakage. Take mul as an example, if the shares of y are [1, 1, 1] and a multiplication of x * y * y is performed, a corrupted party (e.g., P0) can infer the value of x.

To explain, P0 initially knows x0, and during the first multiplication, P0 learns x1. Then, during subsequent multiplications, P2 sends z2 = 2 * x2 + x1 to P0. Consequently, P0 ends up with knowledge of x0, x1, and x2, allowing it to reconstruct x.

The correct implementation can refers the paper ABY3: A Mixed Protocol Framework for Machine Learning.

Below is the relevant code:

def mul(x, y):
return __replicated_secret_sharing_protocol("mul", x, y)

def __replicated_secret_sharing_protocol(op, x, y, *args, **kwargs):
"""Implements bilinear functions using replicated secret shares.
Shares are input as ArithmeticSharedTensors and are replicated
within this function to perform computations.

The protocol used here is based on section 3.2 of ABY3
.
"""
assert op in {
"mul",
"matmul",
"conv1d",
"conv2d",
"conv_transpose1d",
"conv_transpose2d",
}
x_shares, y_shares = replicate_shares([x.share, y.share])
x1, x2 = x_shares
y1, y2 = y_shares

z = x.shallow_copy()
z.share = getattr(torch, op)(x1, y1, *args, **kwargs)
z.share += getattr(torch, op)(x1, y2, *args, **kwargs)
z.share += getattr(torch, op)(x2, y1, *args, **kwargs)

return z

Impact:

This vulnerability may result in the leakage of private data when using CrypTen's replicated secret sharing protocols.

Version:

commit:  32be920c3891112dcc5c6079477364630b069d64

Credit

Guopeng Lin (Fudan University)

[lvdmaaten]

Oh interesting! I don't think the RSS protocol is used anywhere in CrypTen, but it lives in the codebase because @jeffreysijuntan used it to implement CryptGPU.

@jeffreysijuntan -- Can you have a look at this and also check what it means (if anything) for your CryptGPU paper?