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.
A list of research/project ideas that I have no time to pursue fully, but which I would be very interested in helping out/mentoring. If any of these sound interesting then please reach out to me. I may also be able to help find funding for some of these.
1. File Metadata Removal - this is an area that I think needs additional reseach/experimentation. Existing solutions like exiftool and MAT/2 are great, but don't quite match the modern reality for when and how we would ideally like to integrate such processes into tooling (e.g. in a chat app file share flow) and I think suffer from a limited view of file metadata in light of the growing complexity and diversity of file types, and web based workflows - and how people realistically want to check/modify/remove metadata.
Further, we now have interesting approaches like Magica and other approaches that can perhaps be utilized to catch file types and metadata not strictly captured by a given tool.
Realistically I think there are like 4-5 distinct research projects here around UI/UX, requirements and expectations, and new technical work.
2. Reproducible Build Tool - I'd love to find someone interested in helping/expanding replqiate. I have some ideas about speeding it up further, pushing back the trust, and getting it to the point where it functions as a day-to-day build tool.
3. A better (mostly-static) source code repo/forge - One of my biggest sources of frustration right now is spam in source code repos: specifically issue spam, pull request spam - I think I delete at least 5-10 AI-generated nonsense a week. It's getting worse and the moderation tools to catch this are terrible. I would really like a mostly static git repo that also allows moderated public-issue creation and other nice features. I have a prototype but its been gathering dust.
4. Small Groups (multi)-Project Management - I work on a lot of projects where the primary team is small (either just me, or a small group of 2-4). I have used every project management tool under the sun and found none of them really fit the flow I want. A few notes:
- Kanban is great for restricting WIP but a tool that manages everything in terms of kanban/boards is terrible for managing longer term research
- I need a place to put papers/documents/artifacts that can be tied and referenced to active issues
- I'd like to be able to breakdown problems in addition to work. Capturing the problem structure is, to me, just as important as tracking the work needed to solve a particular instantiation of it
5+. While I am actively working on projects in the following areas, if any of them sound interesting please also get in touch: