I'm somewhat perplexed by the new SecureDrop protocol
Specifically: "The server is “untrusted” in the sense [it] learn[s] nothing about users & messages besides what is inherently observable from its pattern of requests, and it should not have access to sensitive metadata, or sender or receiver information"
Seems like a very weak definition of "untrusted", especially when two comparison techniques explicitly attempt to restrict knowledge derived from access patterns.
Further...doesn't the servers ability to produce arbitrary valid ciphertexts (not really forgeries as it's an explicit requirement) allow a range of active attacks against recipients?
I'm not entirely sure of the consequences there, but it seems incompatible with the optimized decrypt-fetch message id (as it allows the server to test and trigger).
Removing the optimization effectively brings you back to download-all and trial decryption (with server forgeries there becoming effectively noise)
The motivation for private server state is "there isn't enough traffic going through the system to provide a reasonable anonymity set to any observer so we want to minimize observers"
Which is reasonable, but then the server is explicitly not "untrusted" - it can perform all the same statistical attacks...you effectively limit the adversary space to the server.
And if so (and you are unwilling to trust the server) then your risk model becomes that addressed by PIR or OMR.
But instead the protocol explicitly allows the server additional capabilities by granting it participation in generated receiver key material (and bloating the ideal communication cost)
Any optimization you make to reduce that cost grants the server additional information. Either making the server trusted in arbitrary ways or compromising one of the desired properties.
The protocol itself is interesting, involving the server in that way has that nice property of hiding valid ciphertexts from all other parties - I feel like I've seen a flow like it before, somewhere, but nothing immediate comes to mind.
I suspect you could probably hack in authentication into that flow somehow which could have useful applications.
But the protocol doesn't feel like it solves the problem? Or rather, the strengths of the protocol don't nicely map to desired properties.