[HN Gopher] Zoom rolled their own encryption scheme, transmit ke...
___________________________________________________________________
Zoom rolled their own encryption scheme, transmit keys through
servers in China
Author : gasull
Score : 453 points
Date : 2020-04-03 12:30 UTC (10 hours ago)
(HTM) web link (citizenlab.ca)
(TXT) w3m dump (citizenlab.ca)
| AshamedCaptain wrote:
| Seriously, all people who are surprised about this type of news
| should really understand that most "successful" (as in, popular)
| tech/.com/SV "startups" these days are like this.
|
| If you "waste" time on the real important stuff such as a good
| design, user security, or the like, you will lose over to a
| competitor who didn't and therefore was able to spend more time
| on marketing.
|
| If you waste your time on user privacy you will be totally
| crushed by that competitor whose definition of "privacy" was "how
| much can I pester this user until he gives me access to his
| address book so I can spam his friends?".
|
| I don't think this is good. I think this is very sad. But it is
| what it is.
|
| I still remember the Whatsapp founders coming into the jabber
| mailing lists with "please let me configure my server"-type
| questions, for god's sake.
| munk-a wrote:
| I agree this isn't uncommon, but that does nothing to make it
| acceptable.
|
| Bad security design is unacceptable and this is sort of
| indicative of a large dissonance when it comes to SV startups.
| "Disruption" isn't ignoring requirements - if you are able to
| under price your competitors because you fail to adhere to good
| practices (or, more importantly, regulations[1]) you're not
| building a lean and useful product - you've just built a half-
| assed competitor that can undercut prices because it is
| incomplete... You're selling something as a competing solution
| when it only does half the stuff.
|
| There is a lot of good to be said about identifying the 90/10
| value components of a problem space and discarding expensive
| features that would just add complexity for little value - but
| if those features are requirements you're just failing to
| actually meet the points consumers (or markets ala regulations)
| expect and making your profit off of deceit.
|
| 1. Looking at you Uber.
| josho wrote:
| But, the parent's point is that it is acceptable. Zoom has
| become a $300mm company all the while flatly lying (or being
| very generous in statements). What is the consequence for
| them? They made rapid market growth because they didn't waste
| constrained resources on security/privacy concerns.
|
| No consequences means their behavior is acceptable. Which
| means this will repeat until there is a reason that makes
| this behaviour not acceptable.
| herodotus wrote:
| Agree, but I want to add something: the usability of Zoom is
| good, even for casual computer users. Strategically, they
| focussed on what they considered to be the things that would
| give them sales. Not saying it is good, but it certainly worked
| for them (at least until now).
| sdoering wrote:
| I agree. My SO ist currently studying from home due to the
| pandemic. A lot of professors and tutors use what they find
| first. There is no standard.
|
| She already had to use MS Teams, Slack, Jitsu and Zoom. Her
| take was that Zoom was by far the most usable tool. And most
| of her 20 years younger co-students agree.
|
| Sadly most people don't even know about the problematic
| status of Zoom. And if one tells them, most do not understand
| what's so problematic about that.
| sneak wrote:
| The students are all forced to agree to these abusive third
| party TOS simply to receive the education to which they are
| entitled/for which they have already paid.
|
| That's a bait and switch on the part of the university.
| "You've already paid, but now you have to give up your
| civil rights against this third party you've never heard of
| to get the service."
|
| There should be liability for the schools for doing this. A
| class action, perhaps?
| fossuser wrote:
| Partly because it isn't really problematic for students and
| teachers that are trying to use VTC.
|
| When the alternatives don't work, it doesn't really matter
| how secure the alternatives are.
| restingrobot wrote:
| This is a bad point. The difference between using AES-128 and
| AES-256 from a code standpoint is trivial. The only explanation
| for this is either gross incompetence or malevolence.
| Personally I don't use Zoom, nor would I recommend its use for
| even personal conversation.
| lukeschlather wrote:
| Have you studied the performance implications of different
| key sizes on real-time video applications? A little bit of
| reading suggests AES-256 carries a significant performance
| penalty vs. AES-128. I would be keen to hear from someone who
| has tried it in real-world situations and can demonstrate
| AES-256 working well on e.g. low-end android devices/cheap
| laptops without issue.
|
| I use Zoom regularly. Their video works well. I would like to
| have AES-256 but also I suspect this is not a casual choice,
| and I'm not sure it's as clear-cut as you're assuming.
| dpeck wrote:
| the difference is a copy and paste from an older
| StackOverflow post.
| restingrobot wrote:
| Using code without understanding its implications would
| fall in the gross incompetence category.
| AshamedCaptain wrote:
| And my point is that this happens all the time. Natural
| selection seems to favor the type of company that would
| just copy&paste from SO (then spend their resources on
| some fancy viral marketing) instead of the one that would
| stop to think about it.
| catalogia wrote:
| People shouldn't be surprised, but they _should_ be
| upset.
| etaioinshrdlu wrote:
| More generally, there is a culture of celebrating rule-breaking
| or even law breaking within the startup community. As long as
| you get away with it, and make money off it, then it's totally
| cool...
| philwelch wrote:
| That's also partially a reaction to so many rules and laws
| being utterly counterproductive and/or corrupt. Respect for
| rules and regulations depends on those rules and regulations
| having respectable motivations and effects in the first
| place.
| WalterBright wrote:
| I more suspect it is a problem stemming from hiring people who
| are all new to professional programming. Avoiding these issues
| means hiring some older, experienced professionals.
| api wrote:
| Those cost more.
| WalterBright wrote:
| Much cheaper than trying to put out the fires caused by not
| using them.
|
| Experience costs more because it pays off.
| AshamedCaptain wrote:
| There is little to no penalty if your software is crap
| from a security or privacy point of view and you are
| popular enough.
|
| The example I used is Whatsapp. On the early days, but
| definitely after their popularity was already high in
| Europe, you could still impersonate any user on the
| platform trivially. Their only real security was
| obfuscation of the client source code, obfuscation of the
| protocol. Doesn't help much when you still have a Java
| (J2ME) client that is trivial to decompile. They still
| became hugely popular.
|
| People quickly forget about this type of issues, or they
| don't assign blame where it belongs. They will just shrug
| over it and start believing that it is normal for
| computers to get hacked from time to time. After all, it
| appears all the time on TV.
| WalterBright wrote:
| There's a reason airlines don't put a freshly minted,
| cheap pilot in command of a 747.
| ComputerGuru wrote:
| Yes, but people are short sighted. They also probably
| think "I'd rather grow quickly and be able to afford this
| down the line than do it right and risk missing out."
| WalterBright wrote:
| > Yes, but people are short sighted.
|
| Which comes from being inexperienced as well. And an
| experienced hand can save you money immediately. Such as
| selecting a more appropriate programming language to
| implement the project in. Suggesting an appropriate
| library to use rather than rolling one's own. Avoiding
| multithreaded coding disasters. Having a backup system
| that works. Having a revision control system that works.
| Knowing that unit tests have an immediate payoff.
| Avoiding stupid metrics like paying people based on lines
| of code written. Avoiding rolling your own encryption.
| Don't transmit passwords in plaintext. Don't do illegal
| things. Don't leave yourself wide open to lawsuits. Use a
| real CPA to do your taxes. Keep proper business records
| so the IRS doesn't hang you. And on and on.
|
| My CPA makes lots of money when some young entrepreneur
| comes in all terrified that the IRS is auditing him and
| he kept no records and didn't even file returns.
|
| An experienced hand will tell you to never ignore and
| never mess with the tax man.
|
| Check out what happened to Will Smith when he paid no
| attention to the IRS. All his proceeds from "Fresh Prince
| of Bel Air" went to the IRS as taxes, interest, and
| penalties.
| munk-a wrote:
| Is this maybe a side effect of leadership in these
| startups being more junior themselves and not realizing
| the value they're missing out on by not pulling in some
| of that experience?
| president wrote:
| Or hiring people solely based on Leetcoding interviews.
| Seriously, every interview I've had in the last decade
| focused on algorithms/data structures but it was very rare to
| get any questions on security. This applies to startups and
| larger enterprise companies alike.
| monksy wrote:
| Security implies experience. They don't care anything about
| that. Just hire cogs to grind away and fire when they burn
| out.
| dhosek wrote:
| But when I see "roll their own encryption," it tells me that
| they went out of their way to create something subpar. There
| are some things that one should never* roll one's own of, and
| encryption has to be the top of the list.
|
| * OK, if you're an encryption expert, you obviously would roll
| your own to advance the state of the art, but Zoom are quite
| obviously not encryption experts.
| Justsignedup wrote:
| "Roll your own" is such a oversimplification.
|
| Usually it is: I can spend all this time making things right,
| or bob here knows how to do this other simple way that is
| good enough in a week.
| uoaei wrote:
| It's so much more important to make things right than to
| have something "good enough" (which is never actually good
| enough) that reducing it to that simplistic binary is not
| all that drastic.
| jonmartinwest wrote:
| I think you might be missing the bigger picture. You have a
| company that the "Ministry of State Security of the People's
| Republic of China" can easily hack to spy on American children
| and businesses. What could go wrong?
| reaperducer wrote:
| Not just American. Someone posted a screenshot on HN
| yesterday or the day before of the prime minister of the
| United Kingdom having a video chat with about 16 other top
| government officials over Zoom.
|
| Anyone want to wager how many of their computers are now
| p0wned.cn?
| Justsignedup wrote:
| It is easier for Zoom to apologize and fix than for zoom to
| have no customers but a solid stack.
| api wrote:
| Why can't people bother to construct a minimally secure
| encryption system given that there are so many good documents and
| code examples out there?
|
| I don't mean anything with ratcheting, forward secrecy, replay
| protection, nonce reuse resistance, or any other bells and
| whistles, just basic competent symmetric encryption without
| gaping holes or ridiculous bizarre design choices?
|
| It's not hard!
|
| (1) Generate 12 bytes of random nonce using a good secure random
| source, prepend to message.
|
| (2) Use nonce to initialize AES-GCM.
|
| (3) Run it through AES-GCM, append tag.
|
| (4) Done.
|
| That's not hard and it's secure enough for common use cases.
| rzimmerman wrote:
| The only thing I can think if is that _maybe_ the protocol Zoom
| is using precludes prepending the nonce due to the packet
| format. But surely there 's some way to do this with packet
| counters and user IDs. It's possible this was an intermediate
| step but I'm really stretching for excuses here.
| api wrote:
| Yes you can construct an IV from other state, though it's not
| ideal. Another good fit might be modes designed for disk
| encryption as those are designed for cases where you can't
| pad (e.g. disk blocks).
|
| There's also AES-GCM-SIV and its relatives which construct
| the nonce from a MAC of the plaintext and _technically_ do
| not require a separate IV, though if you don 't use one any
| duplicate message will be obvious.
|
| Those are somewhat more complex but honestly even if you
| don't get those perfect it's almost definitely better than
| ECB.
| restingrobot wrote:
| Or use TLS end to end like a normal company...
| api wrote:
| Yeah I wasn't saying that because it's obvious. I was just
| saying if you really want to DIY crypto it's not that hard to
| do better than dumb ECB.
| thinkingemote wrote:
| On Ubuntu would installing Zoom via Snap be preferable than as a
| normal package when it comes to security / sandboxing, should the
| case be that they turn evil?
| dang wrote:
| The Intercept article about this has a thread here:
| https://news.ycombinator.com/item?id=22767807
| bedros wrote:
| always wondered why zoom.us url not zoom.com which they both own.
|
| it's basically to give the perception it's US company and assumed
| trustworthy.
| dstroot wrote:
| Zoom deserves a lot of animosity for its _privacy_ issues like
| sharing data with Facebook.
|
| On the other hand I am mystified by all the security hype. Yes I
| might be able to guess a Zoom meeting ID, just as if I might
| guess your phone number and prank call you. In a Zoom meeting
| _you can see who is connected_. In the old days of conference
| calls do you remember asking "who's on the line?". What are you
| talking about that requires encryption?
|
| If so there are tools for that - signal, etc.
| ikiris wrote:
| Oh please. They used the fb auth sdk without realizing the
| implications. That's hardly malicious just incompetent and
| rushed.
| catalogia wrote:
| Didn't realize? Or didn't care, and then lied and claimed
| they didn't realize only after they got called out?
|
| There is really no reason to give this company the benefit of
| the doubt in any regard.
| stordoff wrote:
| > What are you talking about that requires encryption?
|
| The UK are using it for Cabinet meetings -
| https://www.bbc.co.uk/news/technology-52126534
| NikolaeVarius wrote:
| > In a crisis, communication at speed is the priority.
|
| And UK officials say the risks of not communicating in the
| middle of fast-moving events far outweigh the possible
| security risks of using such a system.
|
| They add most government work to do with the coronavirus is
| unclassified and anything highly classified is communicated
| over secure systems
|
| Government meetings use the paid-for version of the system
| and are password protected to prevent "Zoom-bombing", when
| uninvited individuals intrude on calls.
|
| The UK Ministry of Defence also said Zoom should not be used
| for classified conversations.
|
| And it is understood Nato's policy not to use Zoom for any
| meetings, briefings or conversations between member state
| ambassadors if classified or sensitive information is shared.
|
| Nato staff are understood to be using "more stable and
| secure" means of communication.
|
| =====
|
| They seem to be perfectly well aware of their threat model
| songshuu wrote:
| Could we fix the title of this post please? There is a GULF of
| difference between 'transmit keys through servers in China' and
| the actual text from the article, " We suspect that keys may be
| distributed through these servers."
|
| Implication is fine, but it should not be declarative without
| proof.
| dmitrygr wrote:
| The article is quite direct: key directly sent to client in USA
| directly from a server in china. what is unclear?
| songshuu wrote:
| Have read the whole article myself, I did not see that
| explicitly stated. Could you provide the quote?
| saagarjha wrote:
| > In addition, we identify potential areas of concern in
| Zoom's infrastructure, including observing the transmission
| of meeting encryption keys through China.
| songshuu wrote:
| Thanks! Indeed that was in their opener, but their
| clarifying statement is broader.
|
| FTA "We suspect that keys may be distributed through
| these servers. A company primarily catering to North
| American clients that sometimes distributes encryption
| keys through servers in China is potentially concerning,
| given that Zoom may be legally obligated to disclose
| these keys to authorities in China."
|
| "We suspect" is not the same as "we are certain".
| gen3 wrote:
| This is honestly the best "Zoom is bad" summery I've seen so far.
| While I certainly believe some of the Zoom hate is blown out of
| proportion, this article does a good job explaining to someone
| who isn't a security expert what the issues are. I've been
| getting questions about the company from family and friends, and
| will be forwarding this to them. Well done.
| consonaut wrote:
| This is a great article, but as an educational provider it
| fails to answer one question: Why should I care?
|
| The only concerning thing for me is, why would they lie about
| using AES-256 when none of my users (and I assume most of their
| users) would care in any way about AES-256 vs. AES-128 in ECB
| mode. Why would they lie?
|
| Even after this, having my users conducting university lessons
| over something that might be decrypted in China is honestly not
| that big of an issue. I would of course prefer it if these
| meetings would be private from the PRCs scrutiny but at least
| in my situation (and I think most educational contexts) this is
| not really that important.
| eanzenberg wrote:
| You should care because Zoom is a company run by and within
| China. What's troubling for the west is having so much IP and
| information flowing through a bad state actor without knowing
| about it.
| basch wrote:
| Because a company doing an RFP with a checklist of features
| is going to rank them against their competitors, and it would
| look bad in the spreadsheet.
| consonaut wrote:
| I assume this is your answer to "why would they lie?". It
| does not answer the question to why should an educational
| provider care though.
|
| And assuming I'll consider switching to webex the response
| to encryption in webex is this: https://www.webex.com/conte
| nt/dam/Webex/eopi/Americas/USA/en...
|
| Which 404's and basically represents my experience with
| Cisco: "We don't give a shit about you, you already payed
| us.". Frankly Webex could host the next coming of Jesus and
| I would not give them any more money.
| google234123 wrote:
| lol, nice job finding a link that 404s and basing your
| entire argument on it. Here is another one for your next
| post: https://www.webex.com/sdvfebdwq3433t8hjaxcxqadxe
| consonaut wrote:
| Frankly, Cisco can post whatever they like I will not
| give them any more money. You are certainly right that I
| was disingenuous and I do not care what they do with
| Webex. My link was cherry picked from their press release
| for encryption in Webex that I though it was funny that
| that link would 404.
|
| Good job discrediting my post though. It's not like Cisco
| basically told everybody in a KB that if you want to use
| the same features Zoom provides (or a Linux client, or
| desktop sharing or breakout rooms or audio transcription
| or waiting rooms or...) you would have to give up every
| encryption feature Webex provides. But I assume you are a
| seasoned Webex admin and can provide us some insight into
| why you are using webex in contrast any other solution.
| Or you are trolling, whatever.
| gerdesj wrote:
| "... and then they came for me". Obviously that poem was
| written about something rather more serious than your privacy
| but the point stands.
| consonaut wrote:
| As I alluded to in another post I am from Germany and
| certain people I work with actually went through the "...
| they came for me" phase.
|
| Your point does not stand on its own.
| gerdesj wrote:
| I (en_GB) lived in that weird place called West Germany
| for about 10 years on and off back in the 70s and 80s. We
| have many friends (Hi Wurms, int al) who also have
| family, friends and acquaintances that lived through
| those days directly, shall we say, and of course my own
| family members who did from another side and perspective.
| You may want to take another look at my username and make
| of that what you will.
|
| My point really does stand. You might gradually allow
| erosion of your rights until you find that none are left.
| It is so easy to say "I have nothing to hide" until you
| find that actually you do have something to hide for
| reasons that are not immediately obvious.
|
| I am not saying that using Zoom will have nasty
| consequences but I am saying that the attitude that
| abrogates responsibility for your own privacy might have
| unintended consequences. If it becomes common place to
| simply say "meh" we might not like the world we get
| instead of the world we might wish for.
|
| My Old Saxon friends have a rather more robust attitude
| to privacy concerns than you mate!
| consonaut wrote:
| I'm not going to play "guess what my username means" with
| you, sorry. I'm also not going to play "who knows more
| people that lived through the 3rd reich" with you.
|
| Me administering a Zoom account for my fellow employees
| and my students does not erode anybodies right. For me it
| is a choice between a GDPR compliant vendor and a vendor
| that does not care about the GDPR. Personally I have had
| good experiences with the GDPR (Facebook finally having
| to delete my account even though I would not verify it
| with a personal ID and cell phone number after I went
| through the irish data protection authority) and Zoom
| claims to be GDPR compliant.
|
| So, frankly I'm not sure what you are talking about. It
| seems like you are going for a slippery slope argument I
| don't agree with.
| CamperBob2 wrote:
| _Your point does not stand on its own._
|
| No, but it will when the next generation of Nazi,
| Stalinist, and Maoist regimes arise and gain access to
| the data in question because we weren't fanatical enough
| about E2E privacy today.
|
| And just as Niemoeller's verse warns, by then it will be
| too late.
| eyegor wrote:
| > Why would they lie?
|
| I kind of doubt it was intentional. Developers are not
| marketing, typically, and it seems reasonable to assume that
| a technical person said "aes" when a marketing person asked
| "do we have encryption?". And then the marketing person
| searched for "aes" and assumed that meant "aes-256".
| jasonv wrote:
| I think of it as a warning to future companies who take these
| kind of liberties...
| thedudeabides5 wrote:
| I mean, isn't this stuff they can fix?
|
| Like good that the market is stressing them on their
| security, at $30bn they should be able to engage with that
| feedback and then loop.
|
| On the other hand, tried to use Skype lately? Product has
| barely evolved since they were bought out by MSFT.
|
| Guess google does videoconferencing too, but they know enough
| about us all already....
| lutorm wrote:
| They can fix the code, but would people trust them when
| they say that the code is fixed? Trust needs to be earned.
| dividedbyzero wrote:
| People trust them even though their security is broken.
| Lots of people don't know, lot don't care, quite a few
| probably don't get it anyway.
| matthewaveryusa wrote:
| The warning being that it doesn't matter because it doesn't
| affect their share price right? So far I haven't seen any
| tangible damage to them when it comes to $$.
| snazz wrote:
| It's been a somewhat noticeable hit, but they're still
| doing great overall:
| https://www.google.com/search?q=zm+stock
| daffy wrote:
| Is it possible to use Zoom on Linux from an ordinary user without
| sudo rights?
| nerdkid93 wrote:
| Use or install? I can run Zoom post installation without sudo.
| a-nikolaev wrote:
| I just downloaded their binary build and it worked without sudo
| (you need to run "ZoomLauncher" file).
|
| That being said, I did not get the impression of an easy to use
| app that "just works" (at least with my tiling window manager),
| things were confusing, clunky and rather idiosyncratic (e.g.
| sharing a screen was weird, and the whiteboard did not work).
| rzimmerman wrote:
| Using AES in ECB mode is clearly a bad choice, but honestly it's
| not that horrible for high entropy data like compressed
| audio/video. I'm sure someone could prove me wrong one day, but
| it seems hard to extract any useful patterns out of compressed
| audio/video. It does check the box of "uses encryption" for
| regulatory reasons (while missing the intent). It's pretty
| egregious considering how easy this is to get right.
|
| The 128-bit key is not inherently wrong if they were rotating
| these out during the stream. That being said, there's no reason
| not to do it right and use a mode like GCM with a longer key -
| most hardware supports acceleration for AES-256 these days. It
| can actually be slower to use a 128-bit key on 64-bit systems.
|
| While I respect the decision not to disclose the waiting room
| vulnerability, it's pretty obvious what's going on given the
| context. They probably shouldn't have mentioned where the
| vulnerability is.
|
| I'm honestly surprised anyone with technical knowledge thought
| that Zoom was actually doing end-to-end encryption given how the
| software works. All of the video transcoding/downconversion is
| clearly happening on the server. Your client is not sending
| multiple compressed streams for varying connection bandwidths.
| That's the main reason a lot of people like Zoom - it actually
| works well with dozens or hundreds of participants.
| [deleted]
| phendrenad2 wrote:
| Is compressed audio/video actually high-entropy (in the time
| domain) though?
| rongenre wrote:
| Compressed anything is high entropy
| jldugger wrote:
| Depends on the compression. Lossy compression discards a
| lot of noise vs the signal we care about and would in a
| sense reduce entropy.
| rzimmerman wrote:
| I'm actually not sure - that's a good point. The whole point
| of compressing audio for video conferencing is to preserve
| human speech, so things that produce radically different
| waveforms but "sound the same" to us might show up as
| patterns. I guess it's better to avoid the question entirely
| and use an appropriate stream cipher!
| kop316 wrote:
| > Using AES in ECB mode is clearly a bad choice, but honestly
| it's not that horrible for high entropy data like compressed
| audio/video. I'm sure someone could prove me wrong one day, but
| it seems hard to extract any useful patterns out of compressed
| audio/video.
|
| ...you're joking right? The Wikipedia example for why ECB is
| not recommended is literally an image:
|
| https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
|
| Edit: This applies to compression too. Please refer to
| Shannon's source coding theorem.
| colanderman wrote:
| No comment on the original claim, but that example is
| encryption applied to an uncompressed image. (Adjacent
| identical pixels are not typically represented individually
| when compressed, and thus encryption could not cause the
| banding patterns seen in those regions of the image if it
| were compressed prior to encryption.)
| DevKoala wrote:
| Seriously. The main argument of this article is assuming
| Zoom encrypts uncompressed video data. That is not what is
| happening here.
| kop316 wrote:
| The point is that any pattern in the plaintxt data shows up
| in encrypted data if you use AES-ECB.
|
| Compression does not introdoce entropy to a stream. So
| assuming that saying the stream is compressed and calling
| it good is a very bad idea. Please refer to Shannon's
| source coding theorem. If anything, compression reduces the
| entropy in the information.
| rzimmerman wrote:
| It's definitely a terrible choice for _uncompressed_ images
| or video. I 'm arguing it _probably_ isn 't that bad for
| highly compressed video. That being said, if you're
| encrypting any data stream you should use an appropriate
| stream cipher.
| miked85 wrote:
| If the encryption scheme is poor, why would the data being
| compressed or not matter?
| fennecfoxen wrote:
| "The use of ECB mode is not recommended because patterns
| present in the plaintext are preserved during
| encryption."
| rzimmerman wrote:
| AES-ECB isn't necessarily insecure, it's just very easy
| to misuse (and I agree what the article described is a
| misuse). I think the argument is that if there are
| patterns in the input data, the same patterns will show
| up in the AES-ECB encrypted data, just with different
| values. Compressed data should be high entropy and hard
| to predict, so there really shouldn't be structure or
| patterns to the input data. There's no guarantee that any
| given compression algorithm provides sufficient
| randomness, though.
| stouset wrote:
| Compression already makes a compressed file roughly
| indistinguishable from random noise (module access to the
| decompressor). So the patterns have been removed.
|
| That doesn't make this _good_ , but it means that one
| specific example isn't immediately applicable.
| monocasa wrote:
| There's more in the stream than just compressed data.
| There'll be metadata info that you can make reasonable
| guesses about. ECB mode lets you take that information
| and apply it to other blocks in the ciphertext.
| _jal wrote:
| This thread is an _excellent_ illustration of why you don
| 't want your encryption implemented by merely good
| coders. You need people who know what they are doing.
| staticassertion wrote:
| It's harder to extract patterns from high entropy data. I
| don't think anyone's saying that this is even an OK thing
| to rely on, at all, just that the nature of the data
| means that this specific weakness is likely more
| difficult to take advantage of.
|
| If zoom were transmitting text this would be relatively
| more serious.
| anaphor wrote:
| What about the chat system? I doubt they're intentionally
| compressing the text there in order to increase the
| entropy. I guess they could be using gzip or whatever,
| but we'd need to look at how the protocol works in more
| detail. Or do they use a different system for the chat
| protocol altogether?
| [deleted]
| kardos wrote:
| Zoom does screen sharing, right? Surely it's not
| transmitted uncompressed, but it is stationary for a long
| time and perhaps only small parts changing when they do
| (eg, switching slides). Is there an ECB-based weakness
| here?
| kop316 wrote:
| Compression does not introdoce entropy to a stream. Please
| refer to Shannon's source coding theorm.
|
| If anything, it reduces entropy.
| hackinthebochs wrote:
| But it does increase the entropy per byte, thus making
| patterns harder to spot.
| kop316 wrote:
| ....so your argument us to hope an adversary only sees
| part of your video and not all of it?
| ouid wrote:
| communications on the platform aren't encrypted at all. That's
| what the article says.
| 013a wrote:
| > Zoom's most recent SEC filing shows that the company (through
| its Chinese affiliates) employs at least 700 employees in China
| that work in "research and development."
|
| Wow. What could all of these people possibly be doing? It can't
| be development and QA; what's going on over there?
| ziyao_w wrote:
| You do realize development include software engineering, right?
| 700 people doing programming isn't even remotely surprising.
|
| Not to defend them against the recent security fiasco, but
| innuendos such as this that links "employees working in China"
| directly with "shady business" makes me at least uncomfortable.
| blunte wrote:
| I didn't read it as suggesting it was "shady business". I
| read it as an insinuation that the company didn't know what
| it was doing from the top down, so they didn't hire smartly
| or manage well; they just threw numbers of people at the
| problem (and got predictably bad results).
|
| With good management, a team of 50 should be able to provide
| what Zoom provides.
| ziyao_w wrote:
| Yeah, moments after replying I realized there is a more
| charitable read :-)
|
| Of course, with this read comes the age old question of "I
| can build Google/FB with 20 good men, what are they doing?"
| thaumasiotes wrote:
| > Of course, with this read comes the age old question of
| "I can build Google/FB with 20 good men, what are they
| doing?"
|
| Well, this would explain Google's pattern of constantly
| churning out new products on the theory that hey, maybe
| someone somewhere wants it.
|
| If you need 20 people to run your actual operations but
| you've hired 20,000 people, what are the other 20,000
| people supposed to do?
| fxtentacle wrote:
| The answer might be that truly good people are not
| willing to work for FAANG, so they have to make do with
| 100 so-so instead.
| jtdev wrote:
| For one product...? I'm sure they have a great deal of
| internal software and versions for numerous OS and platforms
| - but we're not talking about a company with hundreds of
| consumer facing software products.
| nostrademons wrote:
| Zoom's core product development is in China. Their Bay Area
| office is apparently support roles.
|
| 700 engineers for a software company the size of Zoom is
| actually pretty small.
| Leary wrote:
| "Wow. What could all of these people possibly be doing?"
|
| There are 20,000 google engineers working in "research and
| development", what could all of these people possibly be doing?
| derision wrote:
| Google is many orders of magnitudes larger than Zoom. Zoom
| has one product, Google has thousands of products, many more
| complex than Zoom.
| BurningFrog wrote:
| Google has maybe 5 products that matter.
| kaesar14 wrote:
| Yeah, 28x the engineers for research at Google makes sense
| -- I'd say the work Google is doing is at least 28x more
| expansive, complex, etc. 700 engineers is quite a lot for a
| company of this size!
| harumph wrote:
| Violating humanity's privacy?
| cjhopman wrote:
| Skype had 500 employees in 2010 a year before they were
| acquired. 700 doesn't seem clearly out of proportion.
| polishdude20 wrote:
| Machine learning on everyone's video feeds to make better deep
| fakes of common people?
|
| You get the face and the voice of people talking directly to
| the camera. You get the people who they constantly talk to so
| you know their relations. You know the content of what they are
| saying.
| otachack wrote:
| Deep fakes can only work for so long. When it becomes
| ubiquitous people will naturally learn that anything can be
| deep faked. We would need some process of verification, then.
| crazygringo wrote:
| That's actually the most interesting fact about Zoom I feel
| like I've learned so far!
|
| Edit: I looked it up... thought it seemed crazy high but it
| obviously includes all the support staff too. So they might
| have only 300 engineers total, for example. I guess that's more
| reasonable. [1]
|
| "As of January 31, 2020, we had 2,532 full-time employees. Of
| these employees, 1,396 are in the United States and 1,136 are
| in our international locations."
|
| "We also operate research and development centers in China,
| employing more than 700 employees as of January 31, 2020."
|
| [1] https://investors.zoom.us/static-
| files/09a01665-5f33-4007-8e...
| 013a wrote:
| Is "Support" traditionally categorized under research &
| development? Possibly enterprise support or solutions
| engineers?
| BurningFrog wrote:
| Why can't 700 people do development and QA?
| NikolaeVarius wrote:
| I really don't think this counts as rolling your own crypto. They
| just used a weak implementation of existing methods.
|
| No more rolling your own crypto than if I were to use DES.
| wrs wrote:
| It's "rolling your own _crypto_ ", not "rolling your own
| encryption algorithm". That includes using "secure" low-level
| primitives incorrectly to build an insecure higher-level
| protocol. In this case, using ECB mode has been known for years
| (decades?) to be a bad move regardless of the underlying
| encryption algorithm.
|
| As the classic article says, if you type the letters A-E-S,
| you're doing it wrong.
| Enginerrrd wrote:
| Yeah, in fact, that is USUALLY the way people screw up and
| roll their own crypto.
| rzimmerman wrote:
| I agree - all security is assembled from lower level primitives
| and can be insecure despite using good building blocks. AES
| (even AES-128) is a fine choice, ECB mode is even okay in some
| contexts, but using that a stream cipher is not appropriate.
| Skunkleton wrote:
| Search for images encrypted with aes-CBC. This is pretty much
| the definition of rolling your own crypto.
| jtdev wrote:
| Is it possible that China is actually gleaning foreign IP from
| Zoom customers?
| HashThis wrote:
| Zoom has betrayed us all! Congress must require zoom to explain
| why they are sending encryption keys to China when all
| participants are USA citizens. Zoom is betraying USA citizens and
| their customers. We must pressure USA zoom execs to explain
| exactly why they are doing this.
| dang wrote:
| Matthew Green's article on this is has a thread here:
| https://news.ycombinator.com/item?id=22771193
|
| The Intercept article on it has a thread here:
| https://news.ycombinator.com/item?id=22767807
|
| It's probably too much of a stretch to merge all these, because
| many comments are about specifics of those posts, and the ones
| that aren't are kind of generic and so maybe not worth merging
| anyway (https://hn.algolia.com/?dateRange=all&page=0&prefix=false
| &qu...).
| Judgmentality wrote:
| Hi dang,
|
| Thanks in advance for all your moderation efforts that make HN
| the site we all love to use on a regular basis.
|
| I'm curious if you've ever considered writing a blog post about
| some of the things you've learned from your years of
| moderation? You spend so much time on HN, you must have seen
| lots of patterns and have lots of insights on...well,
| everything that gets posted on HN to everybody that posts on
| HN. I'd genuinely be interested in reading it if you ever did.
|
| Cheers, a semi-anonymous HN user
| Leary wrote:
| While you wait for his response:
|
| https://www.newyorker.com/news/letter-from-silicon-
| valley/th...
| pvijeh wrote:
| https://classicprogrammerpaintings.com/post/148027314949/we-...
| smsm42 wrote:
| Looks like Zoom to video conference security is like Flash to web
| browser security.
| WheelsAtLarge wrote:
| "Zoom, a Silicon Valley-based company, appears to own three
| companies in China through which at least 700 employees are paid
| to develop Zoom's software. This arrangement is ostensibly an
| effort at labor arbitrage: Zoom can avoid paying US wages while
| selling to US customers, thus increasing their profit margin.
| However, this arrangement may make Zoom responsive to pressure
| from Chinese authorities."
|
| I'm not here to defend zoom but any and all companies that can do
| this have and are doing the very same thing to minimize costs.
| It's not great but it's the expected way of managing a software
| company in 2020. It would be hard to do business otherwise.
|
| Whether it's good or bad that's a question that will need to be
| reexamined given the current situation.
| maest wrote:
| Was this done in the interest of convenience, as most Zoom
| appologists have been clamining?
| api wrote:
| This looks like either incompetence or intentionally weak
| crypto.
| rzimmerman wrote:
| I agree, it's probably lack of appropriate expertise. There
| are much more subtle and useful ways to make this
| intentionally weak (like subtle nonce reuse with GCM). Or
| just giving Chinese authorities access to the key like the
| article implies.
| stefan_ wrote:
| Keynote:
|
| _Zoom's encryption and decryption use AES in ECB mode_
| [deleted]
| ummonk wrote:
| Jesus, that's a textbook example of a bad encryption mode.
| cassalian wrote:
| Makes you wonder how someone could approve that pull
| request...
| tibbydudeza wrote:
| Zoom just works great ... just focus on making a better product
| (aggh Google Hangouts) than hyping up the hysteria by adding
| China to the mix.
|
| It is rather suspicious to see all the articles of late.
| umeshunni wrote:
| Nothing suspicious.
|
| Zoom is in the news lately, so there are more researchers and
| others looking at their security practices.
|
| Bloggers know that they'll get clicks by writing about Zoom.
|
| China is just thrown in since they're the Boogieman in the US
| these days.
| tptacek wrote:
| The serverside key handling stuff is bad, but generally known
| (Zoom has features whose natural implementation require them to
| keep keys serverside).
|
| People are dunking on Zoom for rolling their own crypto and
| coming up with AES-128-ECB. This is also bad, but people should
| be aware that it's a lot more complicated than "you can see
| penguins through it".
|
| You can see penguins through an ECB-encrypted bitmap because
| discrete blocks of the bitmap image repeat, and thus have the
| same ciphertext, and these correspondences carry obvious meaning
| in a bitmap. The same is not automatically true of video or audio
| data with normal codecs. Aaron Toponce points out that sensor
| noise will likely scramble ECB ciphertexts, for instance.
|
| Colm MacCarthaigh makes an even more important point, which is
| that it's already very trick to reliably encrypt voice tracks,
| because common encoding and transmission techniques make them
| susceptible to traffic analysis. So, for instance, you can
| quickly find papers about exploiting silence suppression to make
| predictions about speech in an encrypted audio channel. The point
| here being, cryptanalytic attacks on ECB are unlikely to be
| anyone's first recourse.
|
| Obviously, the 128 bit AES key thing doesn't really have any
| practical impact.
|
| Designers should religiously avoid ECB mode, but the real danger
| of ECB is in interactive settings, where we as attackers get to
| _induce_ plaintext patterns, and use chosen boundaries to isolate
| targeted ciphertext. Bulk video and audio transmission isn 't
| that kind of interactive setting. You still don't want to read
| people saying that ECB is OK; it's bad.
|
| Essentially: it seems like Zoom's cryptography is bad, but not in
| a way that really matters compared to brochure-level badness of
| non-end-to-end-encryption.
| ghostpepper wrote:
| As a total novice to crypto stuff, is there any way that
| someone with access to unencrypted audio/video from the sensor
| could work out some sort of "baseline" and then factor it into
| their cryptanalysis of encrypted content produced from the
| characterized sensor?
| remarkEon wrote:
| Is there any reasonable explanation for why this scheme was
| designed in this manner?
| jonmartinwest wrote:
| Maybe, it makes the "Ministry of State Security of the People's
| Republic of China" job easier? It would allow them to easily
| access lots of data.
| rzimmerman wrote:
| It's possible some protocol issues prohibit the use of other
| stream cipher modes like AES-GCM. I can't think of any but
| maybe:
|
| * Dropped packets/out of order packets. You should be able to
| include the IV/counter with the packet but maybe the protocol
| prohibits that.
|
| * Avoiding reusing counters between participants - seems like
| you could just use the participant ID as part of the counter
| and avoid this
|
| * Concerns about partial packet loss - shouldn't happen with
| UDP and GCM would handle this just as well
|
| I'm trying but I can't think of a good reason to do it this
| way.
___________________________________________________________________
(page generated 2020-04-03 23:00 UTC)