[HN Gopher] What end-to-end encryption should look like
___________________________________________________________________
What end-to-end encryption should look like
Author : lopespm
Score : 130 points
Date : 2020-04-22 18:15 UTC (4 hours ago)
(HTM) web link (jitsi.org)
(TXT) w3m dump (jitsi.org)
| kodablah wrote:
| I have a question on the definition of "end-to-end encryption"
| with regards to groups/rooms. Is it sufficient to have a single
| key shared by all "ends" for the room, or must each user have its
| own key? If a single group key is acceptable, must it be rotated
| as a member goes or comes?
|
| I'm just looking for common definition of the term wrt webrtc
| groups for fear of misusing it when describing a product. (for
| the purposes of this clarification, pretend I have key
| distribution/derivation figured out and I whether I use asymm or
| symm encryption doesn't apply to the question itself)
| crazygringo wrote:
| I think it's very much a gray area.
|
| True E2EE seems like each endpoint would have to have its own
| key. But the bandwidth realities of group videoconferencing
| make it entirely infeasible for each participant to be sending
| a separately encrypted stream to each other participant. So the
| only realistic solution is for all members to share the same
| key, which makes everything dependent on the security of the
| key distribution. But then... is it really E2EE? I'm not sure
| there's a generally accepted answer here.
| sarakayakomzin wrote:
| > So the only realistic solution is for all members to share
| the same key, which makes everything dependent on the
| security of the key distribution. But then... is it really
| E2EE?
|
| each member deriving their own key and coming to an agreement
| on the client side is e2ee; it's primarily about the server
| not having knowledge or being able to recreate the key. each
| client pair can do an individual agreement or the entire
| group can via exchanging public keys.
| oconnor663 wrote:
| If you already have pairwise E2E encryption working, you can
| use it to distribute a shared key. It's the first part that's
| hard.
| devit wrote:
| What matters is that the server or software provided and anyone
| not in the group can't obtain plaintext even if they can
| intercept and modify all traffic on the Internet.
|
| Obviously you need to rotate the session keys when someone
| leaves, since they must no longer be able to obtain plaintext.
| ccktlmazeltov wrote:
| > Is it sufficient to have a single key shared by all "ends"
| for the room, or must each user have its own key?
|
| It is enough that a single key is shared, that being said some
| systems do more because they want to provide additional
| properties to end-to-end encryption for groups.
| otachack wrote:
| I think it's a hot topic and the definition is divisive. Having
| 1 "secret" that end users share and use is technically end to
| end encryption, I'd say, but it's kind of like sending messages
| to yourself.
|
| It's kind of like setting up one private/public key pair, then
| sharing both with everyone in your group and writing each other
| messages with them. If one of your group become a malicious
| actor, or if a malicious actor manages to steal the pair, it
| can compromise the group communications. You also can't
| cryptographically distinguish between each other since you
| share one identity.
|
| Mix in video conferencing, though, and you really just have to
| trust what you see/hear from your peers video feed in addition
| to trusting your shared key pair isn't compromised.
|
| Ideally, each party member has their unique key pair, they
| share their public keys between the group, then communicate
| that way. But you got more overhead in starting a Jitsi meet
| room rather than just a link and a shared password.
| warkdarrior wrote:
| Separate keys means you need to have separately encrypted
| streams for each pair of participants. This is probably not
| scalable, and definitely does not play well with multicast or
| with a video-routing server.
| the8472 wrote:
| Not really. You can have internal per-packet keys which you
| throw away after your cryptographic setup and then only
| convey that key in separately in some encrypted form to
| each member along with a common payload which is amenable
| to multicast.
|
| I think that's a piece of signal's group chat protocol.
| kodablah wrote:
| I think it's fine if you don't re-encode (i.e. need to
| decode) the audio/video packets in any way. IIRC, you can
| broadcast RTP stream packets without knowing their contents
| if you settle on common codecs (e.g. opus and h264). But if
| you need to embed picture-loss-indicator messages or
| something, it might not work. I think this is the essence
| of "SFUs" (selective forwarding units) in WebRTC parlance.
| adrianmonk wrote:
| Is that really true?
|
| I'm not a cryptographer by any means, but it seems like
| every time you transmit a chunk of video over the network,
| you could generate a single-use key, encrypt the video with
| that key, and then encrypt the single-use key with every
| intended recipient's individual key.
|
| When the recipients get the message, they'd find their
| encrypted copy of the temporary key in the list, recover
| the single-use key, then decrypt the video.
|
| That way the only wasted bandwidth is in transmitting keys,
| which is a lot smaller than video.
|
| The recipients could give the single-use key (that they
| decrypted with their individual key) to someone who isn't
| supposed to have it, but that doesn't seem like a problem
| since they already have the decrypted data and could give
| that away.
|
| For a small performance improvement, you could re-use the
| temporary key a few times (for, say, 10 seconds) if the set
| of intended recipients doesn't change.
| hathawsh wrote:
| I like that idea. I think there might be some risk that
| because all recipients receive the same encrypted text
| (encrypted by a different key for each recipient), a
| recipient may be able to discover other recipients'
| encryption keys. To avoid that, I think I would pad each
| encrypted text with random data, where each recipient
| gets different random data.
|
| Then the problem boils down to key management, but
| Keybase has that figured out IMHO. :-) It would be
| amazing to see a collaboration between Jitsi and Keybase
| to build end-to-end encrypted video chat with high
| quality crypto.
| 0xBeefFed wrote:
| I am not sure if this relates, but this past year at
| Blackhat there was a talk on Messaging Layer Security and
| they broughtup a concept called TreeKEM, where users
| share keys in a tree heirachy to reduce the number of
| shared secrets.
|
| Again, not sure if this is applicable, but the comments
| made me think of this.
|
| [0] https://www.blackhat.com/us-19/briefings/schedule/ind
| ex.html... [1]
| https://i.blackhat.com/USA-19/Wednesday/us-19-Robert-
| Messagi...
| ccktlmazeltov wrote:
| This still uses a single shared secret for the whole
| group.
| 0xBeefFed wrote:
| Thank you for verfiying that
| ccktlmazeltov wrote:
| To add to that, the only goal of TreeKEM is to avoid
| latency/complexity when adding and removing group member
| frequently/quickly. Which is really not the use-case of
| most groups (so not sure why they're doing this).
| ccktlmazeltov wrote:
| You both are right, what is not scalable is not
| encrypting messages to all when there are multiple keys,
| what is not scalable is sharing this shared secret and
| rotating it when members are added and removed
| frequently.
|
| This scalability issue is a non-problem imo:
|
| * I don't expect large group VCs, and I don't expect the
| member set to be updated frequently
|
| * For large group VCs, the threat model is much different
| and you can do broadcasting (use the same key)
|
| For group chat I would say that confidentiality goes out
| of the window when you start having a large group, so
| having one key is just more simple to implement and makes
| sense.
| notduncansmith wrote:
| I think a strong cryptographic communications platform
| would offer the option of using either multi-party-shared-
| key or p2p key pairs depending on the use-case. Similar to
| how Slack has both private and public channels within an
| org.
| ghostpepper wrote:
| Signal has published some interesting material addressing this
| question.
|
| https://signal.org/blog/signal-private-group-system/
| john37386 wrote:
| Shouldn't they inspire the end to end encryption from openSSH. As
| far as I know it's used by many worldwide and it seems fairly
| secure. Maybe I am missing something though.
| ffk wrote:
| It looks like what they have now is openssh like. Client 1
| sends data to the server encrypted. Server decrypts. Server
| reencrypts and sends to client 2.
|
| This describes how to communicate in such a way where the
| client 1 and 2 can communicate with the server in the data path
| and The server being unable to see the contents of the message.
|
| The hard part is key management between clients in a secure
| way.
| edoceo wrote:
| You said "server decrypts" but then also "server being unable
| to see contents". How? If I decrypt, I see contents.
| SparkyMcUnicorn wrote:
| I think he's wrong. The server never receives the key. The
| bridge passes along the encrypted stream and
| encryption/decryption only happens client side.
|
| In the demos, you can see that the parameter is a #
| parameter and not a query parameter.
| blendergeek wrote:
| This is a dupe of https://news.ycombinator.com/item?id=22855407
|
| The URL is slightly different but it is the same.
| ccktlmazeltov wrote:
| > From this key we derive a 128bit key using PBKDF2. We use the
| room name as a salt in this key generation. This is a bit weak
| but we need to start with information that is the same for all
| participants so we can not yet use a proper random salt.
|
| 1) You do not need to use a password-based KDF if your key is a
| random bytearray of >= 16 bytes. I expect that most people would
| use their feature by copy/pasting the key in email or whatever
| channels they're using to communicate the room link.
|
| 2) I'm not sure about IV generation, maybe somebody with more
| knowledge on SSRC/etc. can look at that
|
| 3) decryption error do not kill the connection, that's untypical
| but I think that should be fine
| phoe-krk wrote:
| _> 3) decryption error do not kill the connection, that 's
| untypical but I think that should be fine_
|
| I assume that this is so you can deal with the fact that some
| individual frames have been lost and/or corrupted as long as
| the next ones decrypt just fine. That is important for video
| streams; I can imagine that the quality of life of people using
| E2EE streams would suffer if the stream was highly vulnerable
| to corrupting even a single bit within any of the frames.
| ccktlmazeltov wrote:
| In practice a bunch of layers under the application one have
| checksums: UDP already has a checksum, IP already has a
| checksum too, the data link layer too... so maybe you
| wouldn't even reach a naturally corrupted AES-GCM ciphertext?
| Not sure what are the probabilities for the UDP checksum
| though.
| sandov wrote:
| Tangential (and noob) question: Could there be an
| encryption+compression scheme where:
|
| 1. Sender sends an encrypted stream at K bps.
|
| 2. Server takes the encrypted stream and compresses it, without
| decrypting anything. It then sends encrypted+compressed stream at
| J bps (J<K) to end recipient.
|
| 3. The end recipient decrypts the compressed stream using a key
| provided by the original sender, not the server.
|
| This with reasonably secure encryption and reasonably size-
| efficient codecs, obviously. So the step 2 would add compression
| additional to the compression of the original codec.
|
| Is this mathematically possible?
| ww520 wrote:
| Usually you compress first then encrypt. Unencrypted data has
| better compression ratio.
|
| Also modern video data is already compressed where most frames
| are difference data.
| askvictor wrote:
| Generally speaking, video compression algorithms are 'lossy'
| (cause a reduction in quality) and need to be able to 'see' the
| video in order to compress it. The compression typically
| removes details that are not perceivable by humans (this is
| also the case for image and audio compression), and by sending
| just the changes from frame to frame, rather than each entire
| frame. For both of these, the compression algorithm needs
| knowledge of the video stream, which would be impossible if
| it's compressed.
|
| You could try to use a lossless compression algorithm (such as
| used by zip), but those are effectively useless on video in
| general, and even more so on encrypted data, which appears to
| be random.
| sandov wrote:
| Thanks for your answer.
|
| > the compression algorithm needs knowledge of the video
| stream, which would be impossible if it's compressed.
|
| That makes perfect sense and I guess my theory of secure
| encryption + post-re-compression fails because of this. But
| what if we didn't need perfectly secure encryption, but just
| per-block encryption. So the server knows that you've sent 60
| frames, but doesn't know what is in those frames.
|
| What if the codec was made in such a way that the server knew
| that certain blocks in the stream could be discarded to
| reduce size while the stream without those blocks still makes
| sense to the recipient.
|
| For example: the stream is composed of 64 byte blocks, but
| the codec says that every 2 blocks there's a discardable
| block that adds image quality but is not essential. So, with
| this knowledge, the server discards every 2 blocks when
| sending that data to people with low bandwidth and sends the
| original stream with all its blocks to those with high
| bandwidth.
|
| It's an extremely naive scheme, but maybe this principle
| could be applied to more complicated codecs, so the server
| only needs to know metadata about the stream (where each
| block is and whether it's essential), but not the content of
| the block itself (framebuffer and audio sample values).
|
| I'm sorry if this idea is too dumb (and my English skills are
| not the best).
| pronoiac wrote:
| You can't compress properly encrypted data.
| jstanley wrote:
| If the data is encrypted well, it should be indistinguishable
| from random noise.
|
| You can't compress random noise.
|
| Ergo, you can't compress encrypted data. It's a nice idea
| though.
| [deleted]
| abdullahkhalids wrote:
| Naively no, but I wonder if there is some variant of
| homomorphic encryption that does this? I would be surprised
| though if this was efficiently possible.
| sandov wrote:
| Yes, I think homomorphic encryption is what I was thinking
| about, although I didn't know its name until now.
| jdc wrote:
| In short:
|
| * currently the Jitsi Meet videobridge sees unencrypted
| conversations
|
| * they're changing that using a new WebRTC API called "Insertable
| Streams"
|
| * it's currently in alpha with an open RFC
|
| * they plan to use the double ratchet algorithm for key exchange
| in the future
___________________________________________________________________
(page generated 2020-04-22 23:00 UTC)