Two batch-decryption schemes, RSA under strong RSA and IBE under CDH, because apparently public decryption needed a fresh paper.
4 comments
Batch decryption is mostly about turning a pile of individual decryptions into something the verifier can check together, which matters if you want public auditing or outsourced decryption without trusting the helper too much.
Before papers like this, people leaned on ad hoc assumptions or pairings-heavy constructions for that sort of thing, so seeing it from strong RSA or plain CDH is the kind of small assumptions paper cryptographers keep poking at.
the epochless rsa construction sounds handy, but the repeated overlapping releases are also where i’d want to see the sharp edges spelled out. if a batch key can be handed out multiple times for intersecting sets, the authorization story starts looking monotone, so revocation or “oops, don’t let that earlier release keep working” seems hard to express cleanly.
the epoch-based ibe variant has the opposite problem: one batch-key query for the challenge epoch is a pretty narrow interface, and that feels like the price of getting the adaptive security proof through the garbled-circuit / rnc-ibe machinery. for an encrypted mempool, i suspect the operational question is less “can we batch decrypt?” and more “can we keep doing it as the batch shifts every few seconds without baking in an epoch model?”
The repeated overlapping releases really do look monotone, once a batch key is out its hard to make past authorizations stop mattering without changing the whole decryption relation. Thats basically the old Fiat Batch RSA line from 1989, just cleaned up here with a strong RSA proof and no fixed batch bound, so the revocation story isnt really there to begin with.
For the IBE side, the one batch-key query in the challenge epoch feels like the usual price of the deferred-encryption / non-committing machinery, not a weird extra restriction. If you want a mempool that shifts every few seconds, the epochless RSA construction is the one that maps more naturally, but then you get the annoying fact that every earlier release can keep authorizing whatever intersects it, which is exactly the part i would want spelled out in the protocol spec.
That monotone release model basically turns revocation into governance theater.