Are you interested in how to bring secure, private, peer-to-peer distributable content to the fediverse that can survive nodes going down? I've finished writing the documentation for the Golem demo which explains how to do just that: gitlab.com/spritely/golem/blob

It also includes a running, workable demo which you can try yourself. Please do and let me know your thoughts!

Follow

I added a new "Encryption has a shelf life" section to the Caveats section of Golem's writeup. It's an important point I hadn't called out previously! gitlab.com/spritely/golem/blob

> Encryption has a shelf life. In general, secure ciphers from about 15 years ago aren’t secure today, so it’s possible that chunks that are currently only readable by intended recipients can eventually be read by anyone who gets their hands on them. [...]

This is also a concern with any of the "cryptography will save us!" stuff (including E2E)... yes, but with limits!

@cwebber indeed : it's in the end not a technical problem (it take x years to crack the cypher, with machines or... waiting) but a political one, where humans collectively have to ensure a structure of trust where they still can think and communicate ...
democracy won't be solved by technical trick, but yep, technology can be a tool to help and to think about it :D

@cwebber Good stuff!

Re: encryption "shelf life": would the URI scheme support multiple encryption?

Barring weaknesses in the actual ciphers (and the various other ways to undermine encryption), it's unlikely that data encrypted with modern ciphers at sufficient keysizes will ever be able to be decrypted without the key (Bremermann's limit, with the optimal brute-force post-quantum attack against symmetric ciphers being Grover's algorithm, which is mitigated by doubling the keysize).

So one option to mitigate the compromise of a cipher due to some sort of cryptanalytic attack is to use multiple ciphers, each with different keys.

Of course, if Alice is communicating an ephemeral symmetric key to Bob using a asymmetrically encrypted channel, the robustness of the symmetric algorithms won't matter much if attacker that can monitor network traffic between Alice or Bob may be able to decrypt that key exhcnage in the future. But that exchange could take place over a more trusted connection that is not available to the public, unlike the e.g. IPFS-stored encrypted messages themselves (though it may still be available to e.g. the NSA/GHCQ/etc). So there is still value in hardening the symmetrically encrypted message as much as Alice and Bob desire based on their threat model.

@mikegerwitz A good set of comments to which I don't honestly have a great reply. My crypto-math-fu is pretty weak here, but the observation of things weakening is partly based on warnings from more cryptographically astute people I know warning of such and also that so many cipher recommendations of yesteryear *have* weakened. But it's hard to tell if I'm over or under cautioning :)

That said if you wanted to compose ciphers, you could set the es= parameter to something that knows to do that

@cwebber To clarify, my second paragraph applies only to symmetric encryption.

You're absolutely not under-cautioning; I don't believe in such a thing in crypto. :) I was inquiring to see if multiple encryption was supported out of caution.

Certain ciphers have been weakened (or broken entirely), absolutely, which is what makes multiple encryption attractive. I didn't mean to suggest otherwise.

Thanks for your reply. I'm hoping to have the time to look into Spritely more deeply after LP2019.

@cwebber I can highly recommend MC Frontalot's "Secrets from the future" for a near-perfect and entertaining musical performance of this argument. :)

@cwebber @raucao Gotcha. Certainly apropos. Was almost jealous of you getting to hear a lot of good music for the first time.

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!