1. 8

I was thinking about writing a GPG-based chat service. Users register with a public key and can send messages to other users, but the message is encrypted with the public key of the recipient and then stored on a server as the encrypted message (.asc?). I have to do a lot more reading on this idea since I’m not even 50% familiar with the technology. I wanted to get some feedback from the community first, though.


  2. 4

    I’m working on this - commercially - as a “behind the firewall” for companies that want to use an “IM” service like e.g. Slack but are not allowed to due to e.g. SOx.

    PGP/GPG is a viable option for this; although it imposes some usability limits which are entirely acceptable when you clearly communicate to your users that these are due to security and privacy limitations.

    E.g.: When “joining” a room/group-chat you’re not able to see earlier messages since these are not encrypted for you to read. This is actually a feature since it ensures the privacy of all earlier messages. Otherwise you would have to ‘unanimously agree’ on inviting a user into a channel.

    Key verification is still a thing of course; actually checking fingerprints etc. This can be assisted - in our use case - by also using a companies “directory service” to store said pubkeys.

    1. 2

      How would it scale with many users in a channel, though?

      1. 2

        Multiple recipients; users can only read messages sent after they joined a channel. If performance becomes a problem might also consider multiparty diffie-hellman with “renegotiation” after a new users joins (same issue; can only read messages after a user joins).

        Usecase allows us to define a max number of users in a channel. I.e. More than 128 users in a channel is not considered a use case.

        edit: it this what you meant with “scale”?

        1. 1

          Yes, it is.

          1. 1

            Please let me know if you have any further considerations/concerns! Would love to discuss this further since it’s an active development/r&d project for me.

    2. 4

      Forward secrecy and plausible deniability are all the rage these days. PGP offers neither.

      1. 3

        OP: OTR and the axolotl rachet are things you should be looking at!

      2. 3

        Although there’s not wide agreement on what security and privacy properties a future cryptography-enhanced chat service should have, I personally feel that metadata privacy - who’s talking to who - should be a top priority, in fact even above content privacy although it’s hard to have the one without the other so that’s not a real conflict.

        Existing architectures do not do this. Nothing where your list of contacts is stored server-side does this, and nothing where there’s any sort of recipient identifier by which messages can be retrieved does this. The important property is not actually that any identifier be opaque - that’s useful but not sufficient. It’s that third parties not be able to correlate the identifier with itself over time.

        To meaningfully address the problem, one wants to get into onion routing protocols, graph-rendezvous algorithms, content-addressable storage, … but there’s not an obvious solution; those just seem likely to be involved. Also, the group-chat case is substantially harder than the 1:1.

        Another commenter mentioned a different point in the problem-space, where it’s acceptable that there be some centralized party as long as it’s one who doesn’t have regulatory or strategic implications. That’s also legitimate, and serves some people’s needs; full metadata privacy is somewhat of a holy grail, and not necessarily a good use of time right now given the difficulty. But any discussion has to start by identifying a local optimum that serves somebody’s needs, and (once these efforts actually start to get anywhere…), there are going to be multiple attempts going on in parallel because any feasible choice is excluding somebody.

        1. 1

          Storing metadata on a server is completely plausible (edit: HERE BE OPINION!!!) when performed encrypted and when using one-time “tokens” for your identity for every other identity (i.e. contact). As long as these tokens are derivable from something you-and-only-you have (i.e. a pbkdf like construct) you should be able to “figure it out securely”. Kinda like “anonymous pgp-subkeys”.

          n.b. I’ve been toying around with this and would love some validation on these “thoughts”; I decided not to implement ‘anonymity’ in app mentioned in my other reply since it’s… “not a use case” (gotta love commercial interests ;-)).

        2. 1

          Any secure messaging client should be 100% unable to be cracked by the actual providers. If the government tells you to hand in the keys, it should be as absurd as them telling you to stop customers from blinking.