[HN Gopher] Secure Messaging Apps and Group Protocols, Part 2
___________________________________________________________________
Secure Messaging Apps and Group Protocols, Part 2
Author : transpute
Score : 52 points
Date : 2022-06-16 14:41 UTC (3 days ago)
(HTM) web link (blog.quarkslab.com)
(TXT) w3m dump (blog.quarkslab.com)
| motohagiography wrote:
| So useful to talk about protocols like this and a pleasure to
| read. I look forward to going through these protocols later
| today.
|
| However, to take it there, I'd conjecture that the limit on the
| best possible group security is being able to verify the
| integrity of group membership on a per-message basis, and use
| some kind of forward secrecy / ratchet whereby the given message
| key can _only_ be derived from being a verified member of the
| group of the time of the message.
|
| The only way I think we know how to do that is with consensus
| proofs about the composition of the group membership. For each
| message, you would need to encrypt it with a group message key
| that is derived with an authenticated proof of group membership
| that includes only all authorized members. It's like there is a
| direct trade off between the complexity class of the
| protocol/algorithm, and the security guarantees of the protocol.
|
| The best secuirty outcome is that only a member during the period
| of that message can recieve and disclose the plaintext, and
| without some way of diverisfying the plaintext per user, you
| don't know which user leaked it. The other limit appears to be
| that if you get a message from the group, you can't know who else
| is in the reciever group - only that the complete group may have
| r ecieved it.
|
| Just for discussion sake, I think there may be some high level
| lemmas about the necessary trade offs in these protocols.
| snarf21 wrote:
| Yeah, it seems like we'd be safer with groups just being a
| convenience layer on top of peer-to-peer messaging and when you
| send to the group you are always just sending N messages to the
| group as you know it at that moment.
| motohagiography wrote:
| It seems like a totally different use case than p2p, not a
| matter of scaling a bidirectoinal one, but designing a
| multiparty one from scratch. The key management for push,
| poll, or pubsub are each totally different as well.
|
| Imo, the threat models for most protocols aren't well
| defined, so we get this collection of techniques and features
| without a specific set of guarantees and caveats or
| limitations (even though that's what a formal protocol spec
| is supposed to be, afaik).
|
| The group protocol threat model can be really diverse, with
| radically different solutions to it. Features like deniable
| participation, forward secrecy, persistant identity,
| anonymity, dynamic group size, sender authentication,
| recipient authentication, proof of delivery, proof of
| receipt, steganographic capabilities, key rotation, single
| vs. limited use keys, message key persistance, and then
| combining that into key derivation with sufficient entropy to
| provide assurances - are almost unique to each threat actor.
|
| The attack mitigations are also a function of the threat
| model, and even talking about threat models without actively
| acknowledging them and conspiring against their actors can be
| a very nuanced and oblique discussion.
| iforgotpassword wrote:
| A few messengers like threema do that already. It's simple
| and boring, but so much easier to get right. If you don't
| have crazy large groups, this is fine.
| Terry_Roll wrote:
| If you can get code to run on a server which can trigger
| Hertzbleed, beit a virtual server where you have no control over
| what other people run on their virtual server instance, or you
| can employ a virtual cpu like the NSO iMessage gif exploit but
| program virtual gif cpu to do more than whats detailed in the NSO
| iMessage gif exploit, do private messaging platforms like
| WhatsApp have much privacy? I know people like evidence including
| the legal system, most of the time, but stealth weapons have to
| be captured in order to obtain the evidence.
| Aachen wrote:
| Yes. Being able to target specific systems with specific
| exploits that are worth hundreds of thousands of euros, and
| using it risks the vulnerability being fixed, is very very
| different from people on encrypted messengers having no privacy
| at all (compare it to slack or IRC). Encryption still serves a
| propose here. The /NS[OA]/ is not the only attacker we're
| defending from and they, too, have the aforementioned
| restrictions.
| Terry_Roll wrote:
| You mean to say, you cant build this yourself?
|
| https://googleprojectzero.blogspot.com/2021/12/a-deep-
| dive-i...
|
| Have you even tried this on other platforms and other
| devices?
|
| the x86 instructions can be found here
| https://en.wikipedia.org/wiki/X86_instruction_listings
|
| Intel provide an instruction trace facility
| https://blog.cubieserver.de/publications/Henschel_Intel-
| PT_2...
|
| You've got this one from Intel https://www.intel.com/content/
| dam/www/public/us/en/documents...
|
| Other methods described here using JTAG with chips
| https://microchipdeveloper.com/emhead:eep-rt-hw-
| instruction-...
|
| How do you think this was found?
| https://en.wikipedia.org/wiki/Pentium_F00F_bug
| Aachen wrote:
| And now the whatsapp exploit code too please?
|
| It's really not as simple as you pose it.
| Terry_Roll wrote:
| Its why the bests hacks get bought for millions.
___________________________________________________________________
(page generated 2022-06-19 23:02 UTC)