30
Revery v0: identity-less, ephemeral, deniable messaging. (github.com)
submitted 1 year ago by to c/opensource@lemmy.ml
2 comments fedilink hide all child comments
 

i’ve been working on this for a bit, finally got a proof of concept worked out with a desktop app. would love some feedback, mostly on the concept and protocol.

it hasn’t been security audited so don’t use it for anything crazy.

all 2 comments

sorted by: hot top controversial new old
[–] 5 points 1 year ago (1 child)

I wonder what the logic was behind dual-licensing this under both a copyleft and non-copyleft license.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • 7 comments in c/privacy@lemmy.ml view that post
    [–] 6 points 1 year ago (1 child)

    Couldn't you use HMAC with shared secret key to authenticate messages while keeping plausible deniability? Since the key is only supposed to be known to the 2 parties, the recipient can deduce that a message was actually sent by the sender if he did not create it himself. I think that's what OTR was using.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] [S] 5 points 1 year ago

    also, i’m new to lemmy, so if there are any communities i should cross post this to that may be interested, please let me know!

  • permalink
  • fedilink
  • source
    •
    [+] 3 points 1 year ago* (last edited 1 year ago) (2 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 1 year ago (1 child)

    interesting point! i chose symmetric shared key because it means you can’t prove who sent what message.

    the shared secret does add some authentication, which i think is necessary. the goal is it only creates enough to be practical (a random person can’t eavesdrop), but not enough to prove things. messages themselves still aren’t authenticated by any one person.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [+] 2 points 1 year ago* (last edited 1 year ago) (1 child)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 1 year ago

    you’re not wrong, but that’s just the trade off that has to be made, i think. it’s the only way i can think to do it, at least. need -some- authentication for practical usability.

    your gpg example removes the deniability since it proves who wrote the message.

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (-1 replies)
    • [–] 2 points 1 year ago (1 child)

    Same encryption key can create "alternative facts" - impossible to prove which conversation really happened

    Can you elaborate on what this means?

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 1 year ago

    sure!

    during or after a conversation, anyone with the keys can create fake transcripts by creating messages with the same metadata, same nonce, different content.

    because of this, no transcript can be proven to be the correct transcript. the trade-off is you don’t get forward secrecy on the per-message level, but you get it per-conversation.

    another detail is that there is no identity, so all the above aside, there’s also no way to prove who sent which message.

  • permalink
  • fedilink
  • source
  • parent