no comments (yet)

sorted by: hot top controversial new old
there doesn't seem to be anything here
11 comments in c/privacy@lemmy.dbzer0.com view that post
[–] 5 points 10 months ago (10 children)

This looks interesting but it's horrendously long and my eyes glazed over (need more coffee...). Is there a shorter description of what it does? I.e. what are the keys used for and how are they generated? What is it that's getting encrypted? It sounds like it's supposed to be E2EE for PM's. A two or three sentence description saying how the E2EE works and how the private keys are stored would be very helpful.

  • source
  • hideshow 10 child comments
  • [–] 4 points 10 months ago (6 children)

    If you want E2EE for Mastodon, you need key management to be solved first.

    This solves a lot of the key management pain. It's not v1.0 stable yet, but it's finally implemented. I've been working on the spec for nearly 2 years.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 2 points 10 months ago (5 children)

    I'll take a look when I get a chance, but like you said, it's a public key directory. I thought you were claiming to have a solution to client side keys. Is there trouble with using some existing PK directory scheme?

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 10 months ago (4 children)

    No, if you read the post it will make more sense.

    Or the specification if you're more technical.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 10 months ago (3 children)

    I'll see if I can read the post but when I tried this morning, it was way too long. I'll look at the specification. I've been involved in crypto implementation since forever, which is why this looked interesting. But I think the client side also has to be figured out, if it hasn't been yet.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 10 months ago (2 children)

    The client side is its own beast. See https://github.com/soatok/mastodon-e2ee-specification?tab=readme-ov-file#components from my initial project (the "key transparency" thing from today slots neatly into the "Federated PKI" hole).

  • source
  • parent
  • hideshow 2 child comments
  • [–] -3 points 10 months ago (2 children)

    White text on a black background ... I didn't even try to read it.

  • source
  • parent
  • hideshow 2 child comments
  • 9 comments in c/technology@lemmy.world view that post
    [–] 22 points 10 months ago*

    Very cool!

    I can't wait for the entire Fediverse to be E2EE (soon™)

    For those who did not read the article yet, please do. It's very interesting

  • source
  • [–] 12 points 10 months ago* (last edited 10 months ago)

    What would world do without furries? ☺️

  • source
  • [–] 8 points 10 months ago (1 child)

    Biggest issue is that people do not understand encryption. Even Matrix has same issue and they try to add hidden encryption. Though ye e2e will make web more secure. BTW great blog post was nice to read.

  • source
  • hideshow 1 child comment
  • [–] 7 points 10 months ago (1 child)

    Is this e2ee or just public signing? Signing sounds most doable to make sure a message came from the server it claims is from. 

  • source
  • hideshow 1 child comment
  • [–] [S] 15 points 10 months ago

    It's a building block to make E2EE possible at Fediverse scale.

    I've written about this topic pretty extensively: https://soatok.blog/category/technology/open-source/fediverse-e2ee-project/

    If you can build in Federated Key Transparency, it's much easier to reason about "how do I know this public key actually belongs to my friend?" which in turn makes it much easier to get people onboarded with E2EE without major risks.

  • source
  • parent
  • [–] 6 points 10 months ago

    Great post. Looking forward to a more secure fediverse. This more important now than ever.

  • source
  • [–] 1 point 10 months ago (1 child)

    I read the post, its very exhaustive and future seems promising. I might have missed the section but why it this separate mechanism needed in the first place? Is it just because of the key lifecycle management? If so, naiive approach of publishing public key on your profile falls short because of this and without public key management everything falls apart sooner than later?

  • source
  • hideshow 1 child comment
  • 2 comments in c/privacy@programming.dev view that post
    [–] 2 points 10 months ago

    If I'm getting this correct, would it be something similar to AT Protocol's relay servers, except just for keys? If so, it could have some interesting (positive) repercussions to a chain of trust, as then mismatches could more easily indicate suspicious servers.

  • source
  • [–] 2 points 10 months ago

    I wonder why they didn't build on top of matrix...

  • source
  • 1 comment in c/crypto@infosec.pub view that post
    [–] 2 points 10 months ago