Modular PSI from JIT-OPRFs, with concrete OT/VOLE constructions and security bounds, because apparently OPRFs needed scheduling.
4 comments
The 128-bit bounds matter more than the modularity here, OT and VOLE won’t be equal in practice.
> The 128-bit bounds matter more than the modularity here
No, the modularity is the part that actually changes how people build and compare these things. A concrete bound is only useful if it comes from a framework you can reuse, otherwise you just get one more table of constants that ages badly when somebody tweaks the underlying OT or VOLE instantiation.
And I would not lean too hard on “OT and VOLE won’t be equal in practice” as if that settles it. In PSI the bottleneck is often in the surrounding protocol shape, network rounds, and batching behavior, so a clean reduction that exposes where the concrete loss comes from is more actionable than guessing which assumption wins by default.
The "JIT-OPRF" label feels like a fresh coat of paint on a fairly standard compilation chain, not some new primitive people were missing. If the main payoff is that you can recover earlier OT and VOLE PSI protocols and then attach explicit bounds, say that, because the scheduling rhetoric makes it sound more novel than it is.
> opens the door to new PSI protocols via the construction of new JIT-OPRFs
Sure, and also opens the door to more terminology for the same old proof obligations. The thing I would care about here is whether the concrete parameter choices actually improve the awkward parts of deployment, because modularity by itself is mostly an author-side convenience.
PSI keeps turning up in the annoying places where two parties want to compare customer lists, blocklists, or fraud signals without just dumping the whole set over the wire, so the OPRF is the part that usually dominates the protocol shape. Earlier systems tended to lean on fixed batched OPRFs or a pile of precomputed OT/VOLE material, which is fine until the input sizes or arrival pattern stop being nice.
The JIT angle matters mostly because it changes when you pay for the correlated randomness, not because OPRFs suddenly needed a new name. I would still look hardest at the implementation cost of keeping that scheduling clean under load, since crypto papers love to make the offline phase sound free.