Encrypted Spaces: An architecture for collaborative applications | Hacker News Reader

Encrypted Spaces: An architecture for collaborative applications

encryptedspaces.org

85 points_____k13 comments

In its day (1997-2005) Groove was quite a sophisticated architecture and implementation of encrypted collaborative workspaces, using a decentralized P2P architecture augmented by optional store-and-forward relays that enabled fully offline use.

For endpoint authentication it supported direct peer key signing, or org-signed certs, or any combination.

Arbitrary collab apps could be built on a blockchain-like signed/encrypted transaction log with decentralized global ordering and automatic rollback, transaction insertion, and play forward. The most used apps were file folders, discussions, chat (with PTT), calendars, sketchpad, collaborative browsing, and more.

Interestingly, for several years, it was a "killer app" for those who needed confidentiality: USAID and numerous NGO's, US DoD, joint and coalition forces operating in Iraq, all the three letter agencies trying to collaborate across silos immediately post-9/11.

Quite a testament that decentralized architectures truly work when security is paramount. And also, concrete proof that even after immense investment, there is little appetite for decentralized solutions in enterprise and consumer domains.

Engineering always involves trade-offs. The right architecture for the military in Iraq might not be the right architecture for sharing cookie recipes with your family

Truly loved it. Hated that Microsoft killed it.

So it seems this is a system where the server only does encrypted storage and minimal processing on plaintext that it is allowed to decrypt. I was hoping it was a FHE implementation where the server does computation on the encrypted data. Still waiting for that.

I don't understand the hype around FHE. FHE sounds like a fancy way to say my data is only partially encrypted and we can still gain all the insights we want without technically unencrypting it.

I don't want my encrypted payloads to betray me in any of the ways FHE wants it too.

> FHE sounds like a fancy way to say my data is only partially encrypted and we can still gain all the insights we want without technically unencrypting it.

Does it just sound like it or is it? Cause it sure as hell didn't "sound like that" to me last I checked, so that's 1:1 so far.

Consider 2 researchers, Alice and Bob. Lets say that Alice has developed a cool way to analyze gene data, and she uses it on her gene data and gets cool information, so naturally Bob would like to do the same analysis. How does Bob securely get his data analyzed with Alice's intellectual property (which she wants to keep secret as well), enter homomorphic encryption! Bob can encrypt his data in such a way that Alice can run her analysis on it, without Alice ever knowing the content of Bob's data. Alice can get neither Bob's data nor the analysis of it.

So, maybe we should change the name from Fully Homomorphic to something else. The schema your describing sounds like leaving the key under the mat for only parts of the data.

Fully sounds like Alice could process the data in absolutely anyway she would like. This schema sounds to complex to become useful for anything but a narrow set of capabilities. It sounds like it would be more effective for Alice and Bob to sign an agreement with each other than for bob to shape his data in a format useful for Alice to run her processes on it.

Why do we need to muddy the water of what encryption means to make the FHE schema work.

Am I paranoid or does this comment feels like what an LLM would write to imitate an HN comment?

“Users verify cryptographic proofs to ensure that servers behave properly.”

If this is one of the defining tenets of this data system, is it not DOA? See also: the PGP key-signing parties that never were…

It’s just waiting for the killer app, the Pokemon Go of cryptographic signing.

I'm sceptical of verifying or generating ZKPs due to the cost of running a RISC-V program. But I guess if we have LLM inference in protocols, this might be acceptable. I'm not sure how it's fully used in the protocol and whether it sits on a critical path.

"what the server can see to support rich queries" is the whole ballgame, right? Anything queryable is metadata that can leak or be subpoenaed... membership, access patterns, query frequency. For the activist/journalist threat idea, that's usually the sensitive part.

Reply on news.ycombinator.com