[HN Gopher] iMessage with PQ3 Cryptographic Protocol
___________________________________________________________________
iMessage with PQ3 Cryptographic Protocol
Author : galad87
Score : 386 points
Date : 2024-02-21 13:43 UTC (9 hours ago)
(HTM) web link (security.apple.com)
(TXT) w3m dump (security.apple.com)
| soxicywn wrote:
| Does anyone know if this is still vulnerable to the iCloud
| Backups problem? The only solution to that right now is for you
| and your contact to turn on Advanced Data Protection. Curious if
| that's still required.
| etchalon wrote:
| That's still required.
| gjsman-1000 wrote:
| I don't anticipate this changing either - because, let's face
| it, losing all of your Photos and Messages is, to most
| people, a bigger deal than perfect security.
|
| I'm experienced with Apple products - but there was one time
| that I actually got stuck in an E2EE loop and was forced to
| reset all E2EE data on iCloud. I don't know what I did wrong
| - but if someone in tech, like myself, can get stuck in an
| E2EE lockout, I can't imagine other people.*
|
| *This was not Advanced Data Protection. This was stuff that
| was E2EE for all accounts - like passwords and health
| information. As such there's no recovery contact.
| mcny wrote:
| I thought the fix was trivial - all I need to do is go to
| settings > my face >> icloud >>> show all >>>> messages and
| make sure the toggle is off?
|
| doesn't that stop iCloud syncing, at least on my end? I
| understand I can't control what happens on the other end of
| the conversation but that is all I need to do on my end,
| right?
| gjsman-1000 wrote:
| Correct. I was referring to the OP asking if Apple would
| ever fix E2EE not protecting, by default, Photos and
| Messages and so forth.
| fh9302 wrote:
| You either have to enable E2EE or disable both Messages
| in iCloud and device backups. Otherwise the device
| backups contain a copy of your messages.
| galad87 wrote:
| The "Messages in iCloud" sync is end to end, so you can
| enable it and disable iCloud backup, or manually backup
| on your computer: https://support.apple.com/en-us/102651
| zchrykng wrote:
| Yeah, it is end to end encrypted, but the keys are part
| of your device's iCloud backup. So unless you turn on end
| to end encryption for that backup or disable it, Apple
| can access the keys required to decrypt the iMessage in
| iCloud messages.
| sneak wrote:
| iMessage's practical lack of e2ee isn't a matter of
| "perfect security". It's simply not e2ee because the keys
| are escrowed to the middle service. It's not even a little
| bit secure. The encryption has been fully backdoored by
| sharing the endpoint keys off of the device.
|
| Apple turns over customer data on over 70,000 customers per
| year _without a warrant_ under FISA /702 (prism) and NSLs.
| The number gets bigger every year. This isn't a theoretical
| threat. The number is even bigger if you include all the
| search warrants, too.
|
| EDIT: Even if you enable their optional e2ee for backups
| (which nobody does), iMessage the platform is still
| vulnerable because the conversations you have with others
| are insecure because the other end of the conversation is
| escrowing _their_ keys to Apple via non-e2ee backups. If
| you enable ADP iMessage only becomes secure for the case
| where you are only iMessaging yourself.
|
| It's simply not private or secure. You can't be "slightly
| encrypted" or "mostly private".
| gjsman-1000 wrote:
| Unless you enable Advanced Data Protection, which escrows
| the keys solely on your device. This is hardly a secret
| or a scandal.
| gruez wrote:
| >The only solution to that right now is for you and your
| contact to turn on Advanced Data Protection
|
| or don't use icloud backup. Also, confusingly "messages in
| icloud" is end to end encrypted, and enabling it disables
| messages for being included in icloud backup.
| tsunamifury wrote:
| Nothing is secure that goes to a server. Period.
|
| Apple turned over iMessage conversations between journalists
| and senators at Trumps request. They encrypt but give away
| the keys in many jurisdictions.
| gruez wrote:
| >Apple turned over iMessage conversations between
| journalists and senators at Trumps request.
|
| source?
| modeless wrote:
| > "messages in icloud" is end to end encrypted, and enabling
| it disables messages for being included in icloud backup.
|
| This is misleading at best. Careful reading of Apple's
| disclosures reveals that the "messages in iCloud" _encryption
| keys_ are still included in iCloud backups, giving Apple the
| capability to decrypt your messages on demand for law
| enforcement or for any other reason of their choosing. The
| messages may not be in your "iCloud backups", but that's
| just because they are stored on Apple's "Messages in iCloud"
| servers instead. Apple still has them _and_ the keys to
| decrypt them.
|
| https://support.apple.com/guide/security/security-of-
| icloud-...
|
| > When iCloud Backup is turned on, the backup includes a copy
| of the Messages in iCloud encryption key so Apple can help
| the user recover their messages even if they have lost access
| to iCloud Keychain and their trusted devices.
| snowwrestler wrote:
| Just a bit lower on the same page:
|
| > When iCloud Backup is turned on, everything inside it is
| end-to-end encrypted, including the Messages in iCloud
| encryption key.
|
| Meaning that Apple does not actually have access to that
| key, because it is encrypted before being saved to their
| servers.
| modeless wrote:
| This is misleading, again. The paragraph you quoted
| _only_ applies with optional "Advanced Data Protection".
| Advanced Data Protection is _off_ by default. In the
| default state Apple _does_ have access to the Messages in
| iCloud keys in iCloud Backup, as I said.
| sneak wrote:
| If everyone you iMessage with has iCloud Backup still enabled
| (and I guarantee you 100% that they do because it is the
| default), then you turning yours off does nothing, as all of
| your conversations remain readable by Apple via the escrowed
| keys of the other endpoints.
|
| iMessage is not e2ee.
| tptacek wrote:
| It does not appear to be the default.
| xoa wrote:
| > _Does anyone know if this is still vulnerable to the iCloud
| Backups problem? The only solution to that right now is for you
| and your contact to turn on Advanced Data Protection._
|
| This is such a strange two sentences as a "problem". E2EE
| security, as it says in the name, is about the protection of
| dara transmission between two trusted end points. That's it.
| What the trusted end points themselves choose to do with that
| data before and after is completely out of scope, and has
| nothing whatsoever to do with the data transmission aspect.
| This is true of everything ever. No communication service stops
| people from backing up with encryption or not, local or remote,
| or from copy/pasting or for that matter taking photos of the
| screen ("analog hole"). If you want to "protect" the data _from
| the trusted owners themselves_ now we 're in the realm of DRM.
|
| In this case what you wrote is "do non-e2ee remote backups
| still occur if users do not enable e2ee remote backups or
| backup locally?" to which the answer is yes. I definitely do
| blame Apple for not having APIs for backing up to arbitrary
| network servers when it comes to iDevices, but it's still
| orthogonal. And remember iMessage is on the Mac as well where
| people may be backing up anywhere.
| AnonC wrote:
| > No communication service stops people from backing up with
| encryption or not, local or remote, or from copy/pasting or
| for that matter taking photos of the screen ("analog hole").
|
| At least for the first part on backing up without copy
| pasting or using the "analog hole", Signal expressly
| prohibits and doesn't allow any kind of backup -- encrypted
| or not -- on iOS/iPadOS/macOS.
| zchrykng wrote:
| This lack of backups makes Signal less appealing to anyone
| who isn't a security/privacy enthusiast/nut. 99+% of people
| want their messages to work and not lose them when their
| phone is broken.
| codedokode wrote:
| No I do not agree with you. Majority of people never read
| their message history, want their messages to self-
| detruct and don't want to get into a situation like when
| a new partner reads chat history with all previous
| partners.
|
| Majority of people do not record their conversations and
| do not need this.
|
| And most messaging applications are designed countrary to
| what people need - they preserve history specially for
| that curious new partner. Or maybe for a marketing
| department to analyze user's interests.
| macintux wrote:
| I'm very, very skeptical that any of us can accurately
| assert that a majority of people want this specific
| behavior from their messaging apps.
| xoa wrote:
| > _Signal expressly prohibits and doesn't allow any kind of
| backup -- encrypted or not -- on iOS /iPadOS/macOS._
|
| I do not think you are correct, or perhaps alternatively
| this is a distinction without meaning. iDevices do indeed
| lock down against owner control unless the device is
| jailbroken. But Signal for Mac only requires 10.15 or
| later. Even if they wanted to, old Intel Macs simply do not
| offer the hardware guarantees to protect against the owner
| getting access to their own data if they want to, though
| even current ones will still let you turn off SIP etc if
| you wish. I don't even need to look to guarantee that if
| someone wants access to their own Signal data on the Mac
| (or Windows, or Linux which can be run with any 64-bit
| distributions supporting APT), or any of these virtualized
| (and thus on the BSDs which aren't formally supported [0]),
| they can get it. And again, this is somewhat a distinction
| without meaning. Like, how does someone read their messages
| on Signal for Desktop after setting it up and it's syncing
| going forward? They login to the system, and there is a
| saved key and that makes it work. If they then choose to
| backup said system or VM without encryption now what?
|
| I have heard that on iOS Signal has always been somewhat
| evil in attempting to steal people's data away from them,
| which is part of the reason I avoided it. But fortunately
| we don't yet live in a world where the same games can be
| pulled on regular computers. And hopefully eventually
| legislation will make it illegal on all computers,
| including handhelds, too.
|
| ----
|
| 0: 64-bit distributions supporting APT
| modeless wrote:
| It's not strange in the slightest. Apple deserves criticism
| until they fix this. They're going around claiming "end-to-
| end" and people don't understand that they are constantly
| handing over people's decrypted messages to law enforcement.
| It's misleading at best; I call it fraud. It's not as though
| Apple is merely failing to prevent a third party from
| breaking their end-to-end encryption here. Apple does it
| itself! iMessage and iCloud are not separate companies
| operating independently. The right hand knows what the left
| is doing!
|
| This is not a UX issue or an engineering issue. Apple already
| built end-to-end encryption for sensitive data types that is
| still recoverable from backups even if you lose all your
| devices _and_ forget your iCloud account password. They do it
| the same way Google does, and they already use it _by
| default_ for important stuff you don 't want to lose like
| passwords stored in Keychain and health data and a bunch of
| other stuff too. Literally all they need to do is store the
| iMessage encryption keys in this system by default. They
| continuously choose not to, and the reason is reported by
| Reuters to be a secret compromise agreement with the FBI. htt
| ps://web.archive.org/web/20200121123026/https://www.reute...
| xoa wrote:
| > _It 's not strange in the slightest._
|
| It very much is strange.
|
| > _Apple deserves criticism until they fix this._
|
| There's nothing to fix, or rather they already "fixed" it
| by offering an E2EE iCloud backup option to go along with
| local backups. As I said I think backups should simply be
| fully under owner control, but as it stands there is
| absolutely no need to backup without full key control
| should people wish. And even before that there was no need
| to use iCloud Backup. I never have. But that has tradeoffs,
| and it's perfectly reasonable people may choose to make
| different ones.
|
| > _They 're going around claiming "end-to-end"_
|
| Correctly. By your twisted definition, there is no such
| thing as E2EE for any transport in existence because the
| ends might then do something you don't approve of with the
| data they own. HTTPS? Not E2EE. SSH? Not E2EE. WireGuard?
| Not E2EE. Which is completely ludicrous and a total
| perversion of the specific, important role E2EE plays.
|
| > _They already built end-to-end encryption for sensitive
| data types that is still recoverable from backups even if
| you lose all your devices and forget your iCloud account
| password_
|
| No, if you use their full E2EE options, any of them, and
| you lose all your devices, your password, and recovery key
| (including any backups you've chosen to make on your own),
| you are hosed for any of the data that is E2EE protected.
| Like, by definition? Because otherwise it wouldn't be E2EE!
| The fallback when ADP is not turned on _and_ someone is
| using iCloud Backups is that Apple does have the keys, that
| 's the point.
|
| There is literally no way around this, it's just
| definitional. If Apple has, somewhere in the stack, the
| keys then it can be compelled (or choose) to share them or
| share access to the data, but they can also help the owner
| recover if all else is lost. If the owner has exclusive
| access to all keys then the owner has exclusive
| responsibility. You can certainly have the opinion that
| Apple should make that latter the default of only choice. I
| certainly have the opinion they should offer more choice
| period. But that's still all orthogonal to the transport
| mechanism. You can have ultra locked down encrypted
| devices, and then go to a plain vanilla HTTP website or use
| telnet for administration and any MITM can see what you're
| doing. There could be a rootkit on your system that's
| grabbing everything right out of memory. That doesn't mean
| random MITMs can see what you're doing either if the
| transport is E2EE. All of these are important components of
| the overall security picture, but they're all different
| ones.
|
| > _is reported by Reuters to be a secret compromise
| agreement with the FBI_
|
| Read your own articles you link. That's a 2020 piece on
| Apple dropping old plans for owner key control of all
| private iCloud data. But specifically following the outcry
| there two years later Apple introduced "advanced data
| protection" that does precisely what that article is
| complaining they didn't earlier [0]. It got lots of
| coverage at the time. They explicitly cover how data is
| stored afterwards [1]. So people can turn that on. The
| Reuters piece is obsolete.
|
| ----
|
| 0: https://www.apple.com/newsroom/2022/12/apple-advances-
| user-s...
|
| 1: https://support.apple.com/en-us/102651
| modeless wrote:
| > There's nothing to fix
|
| The default. They need to fix the default.
|
| > By your twisted definition, there is no such thing as
| E2EE for any transport in existence
|
| What a ridiculous misunderstanding of my position.
| iMessage and iCloud are inseparable parts of the whole of
| iOS, all from the same company, and their default
| configuration is not end-to-end encrypted. My position is
| that it is fraudulent to treat them as if they were
| separate to claim "end-to-end" encryption in only part
| when it's broken by the other part by default. Plenty of
| other systems are legitimately made of multiple parts by
| different companies and can claim end-to-end individually
| when their defaults are appropriate, even if they aren't
| when combined together by users in non-default
| configurations. There is no contradiction here, it's
| quite unambiguous.
|
| > No, if you use their full E2EE options, any of them,
| and you lose all your devices, your password, and
| recovery key (including any backups you've chosen to make
| on your own), you are hosed for any of the data that is
| E2EE protected.
|
| This is false. Apple and Google both now have a system
| that uses your phone passcode (distinct from your account
| password and practically impossible to forget as it is so
| short and you practice entering it literally every day)
| as the key to unlock your encrypted backups. They use
| secure elements in the datacenter to protect the weak
| passcode from brute force attacks, even from themselves.
|
| > The Reuters piece is obsolete.
|
| The Reuters piece is as relevant as ever until Apple
| changes the _default_ for iOS so that Apple can 't read
| the vast majority of all iMessages.
| xoa wrote:
| > _The default. They need to fix the default._
|
| No, they do not. That you don't give a shit about people
| losing data is a value tradeoff you believe in, but
| you've got a lot of work to argue it's an objective
| universal.
|
| > _What a ridiculous misunderstanding of my position._
|
| It's amazing how you can say this with a virtual straight
| face, then immediately go on to directly argue that yep,
| that's your position.
|
| > _iMessage and iCloud are inseparable parts of the whole
| of iOS_
|
| They literally are not. Local syncing of iDevices
| predates iCloud backups even existing as a feature. You
| do not need to use iCloud Backups or data syncing. I
| never have. But if this logic applies, then it applies to
| everything! You can sync Safari browsing history, state
| etc too. Apps can sync data as well. So that must mean
| HTTPS is somehow no longer E2EE either. Unless you turn
| it off. Then magically it becomes E2EE? Be consistent.
|
| > _and their default configuration_
|
| This is a goalpost shift and stupid.
|
| > _My position is that it is fraudulent to treat them as
| if they were separate to claim "end-to-end" encryption in
| only part when it's broken by the other part by default_
|
| Because somehow you don't understand what E2EE even is.
| E2EE in communications solves one, specific and very
| important problem, which is data in flight. iMessage,
| HTTPS, or whatever else being E2EE, is a meaningful and
| significant difference then SMS or HTTP. It changes which
| potential actors can access that data, and how. End point
| security is an entire different problem with different
| sets of tradeoffs.
|
| You're just objectively wrong and muddling an important
| distinction. Also, if you actually think it's
| "fraudulent" then by all means, sue them for false
| advertising, or contact your local authorities in charge
| of that. Good luck!
|
| > _This is false_
|
| Nope, it's correct, but there's a bit of a pattern here.
|
| > _Apple and Google both now have a system that uses your
| phone passcode (distinct from your account password and
| practically impossible to forget as it is so short and
| you practice entering it literally every day)_
|
| My phone password is 21 characters long and I almost
| never enter it because of Face ID. I'm starting to wonder
| if you actually own and use iDevices at all or if you're
| just regurgitating stuff you've read on the web? Even for
| people just using PINs, the vast super majority make
| heavy use of biometrics to the extent that Apple forces
| people to unlock once every few weeks just to try to help
| make sure they remember. But people forget anyway. Older
| people or those with other forms of memory loss forget a
| lot of simple stuff, including their own phone numbers,
| all the time. People have accidents. One of my cousins
| just got hit by a car while riding his bike and suffered
| a bad concussion followed by a long period of amnesia. At
| Apple's scale they absolutely need to, and should, care
| about such things.
|
| You just said it was wrong that if someone loses their
| passwords (and PINs are just a kind of password,
| "something you know"), they are hosed on the data
| because... uh... people don't forget! Wild.
|
| > _The Reuters piece is as relevant as ever_
|
| Nope, it was specifically about there not being an
| option, at all.
| modeless wrote:
| > You do not need to use iCloud Backups
|
| You do if you want cloud backups (as most people do),
| because Apple prohibits you from doing it any other way.
| You can't uninstall the iCloud backup software, you can't
| replace it, and you can't buy an iOS device without it.
| It's literally inseparable from iOS by Apple's design,
| and iMessage is too in exactly the same way.
|
| > So that must mean HTTPS is somehow no longer E2EE
| either
|
| Safari doesn't backup the _contents_ of your HTTPS
| connections to Apple, nor even the URLs for the vast
| majority (only top level page navigations are stored in
| history). The analogous situation would be if Safari
| would relay all the content of every HTTPS connection to
| Apple servers along with the keys to decrypt it. Maybe
| you would defend such a system as "end-to-end
| encrypted", but you would be in a very small minority.
|
| > My phone password is
|
| ... completely irrelevant. Who cares? You're not
| seriously arguing that 21 character phone unlock
| passcodes are typical? We're talking about defaults here.
|
| > I almost never enter it because of Face ID
|
| I was wrong. I thought that you had to enter the passcode
| at least once daily, but it's actually at least once
| weekly. However my point stands. It's extremely unlikely
| for the vast majority of people to forget their passcode,
| which is distinct from their account password, which is
| almost invariably _very short_ , and which they practice
| entering _at least_ weekly.
|
| As for the edge cases you mention, every system has edge
| cases. The non-E2EE account recovery case has edge cases
| too. It requires navigating Apple's support process and
| proving your identity via whatever means they request
| which not everyone will be able to do successfully. Also
| it's vulnerable to social engineering attacks on the
| support reps. No system is perfect. If the forgetting
| issues were so bad, then Apple wouldn't by default
| encrypt Keychain passwords with true E2EE. Losing those
| is actually super inconvenient too, but Apple has no
| problem with E2EE there. That's because law enforcement
| cares more about reading your messages than logging into
| your Reddit account (or they can just go to Reddit
| directly).
|
| > PINs are just a kind of password
|
| A very special kind of password which is by design much
| easier to remember and practiced more often. They are
| _very_ different in practice, don 't pretend there's no
| relevant difference.
|
| > I'm starting to wonder if you actually own and use
| iDevices at all
|
| I owned and loved the OG iPhone and many other
| generations too. Although my current phone is Android, I
| still use iPhones and iPads casually from time to time.
|
| Look, I could continue all day, but long experience has
| taught me that it's pointless to argue with someone so
| clearly stuck in the reality distortion field. I believe
| I've made my points clearly for any other reader of this
| thread. I won't be responding further.
| Andrew_nenakhov wrote:
| This is how Constantinople fell to the Ottomans: they had
| very high hard to penetrate walls, but forgot to lock one
| gate. *
|
| Replace the walls with highly secure encryption e2e
| algorithm, and the gate with easily accessible backup, and
| you'll see why things like this are _not_ out of scope.
|
| * - this story is disputed by some historians
| tw04 wrote:
| That will always be the case with Apple. Their default behavior
| is to cater to a user that will shoot themselves in the foot
| anytime they have the opportunity. I applaud them for giving
| users the option to be secure, but I don't blame them in the
| least for making you turn on the thing that can make grandma
| lose all of her message history.
| jacobgorm wrote:
| Will the code be available?
| xxmarkuski wrote:
| David Basin and his team have done really cool work in the past.
| I was lucky enough to see a talk by him about EMV Race, which are
| exploits in the EMV protocol used by credit cards. Their approach
| included modeling this protocol in Tamarin. Its website [0] shows
| demonstrative videos.
|
| [0] https://emvrace.github.io/
| yesimahuman wrote:
| Pretty great advertisement for Signal, as the sole cross-platform
| option in the PQC bucket. Does it seem likely they will match
| Apple here eventually?
| adamtaylor_13 wrote:
| In my experience, these markets can overlap but don't
| necessarily always do so.
|
| I message everyone via iMessage, and while I enjoy the feeling
| of security from the blue bubble it's not a must-have for me.
| Signal on the other hand seems like a must-have for many people
| living under oppressive regimes or whose data is significantly
| more valuable than mine.
|
| I am one data point, but that's what I've noticed in my bubble.
| yesimahuman wrote:
| For me, Signal is so much better for my friend or work group
| chats. My friends are on a mix of devices and platforms, and
| Signal is a lot nicer for embedded media sharing. And the
| auto disappearing feature is a must!
| adamtaylor_13 wrote:
| Hmm... Does signal only really work when everyone uses it?
| Or can you include people who are just using regular SMS?
| Jtsummers wrote:
| Only Signal users. The Android app used to work with
| SMS/MMS until a couple years ago.
| temp0826 wrote:
| I don't think any app besides iMessage can even get
| permission to read SMS on iOS, there are no alternative
| message apps I'm aware of like with android.
| bebopfunk wrote:
| It used to have SMS support but they yanked it maybe a
| year or so ago. The big issue on the user end was, if
| someone deleted Signal and you used Signal for your SMS,
| it would keep sending them signal messages and not SMS.
| So you were left not realizing you were texting
| essentially a dead number.
| issafram wrote:
| The regular SMS/MMS feature was removed and for good
| reason. Many people cried about it but it was the right
| call. Messages would not be E2EE and people could easily
| think all messages sent through Signal are safe when they
| weren't.
| jwells89 wrote:
| The main things holding back Signal usage in my case is
| practically nobody in my social circle using it and the
| desktop client not being as nice as that of Messages or
| Telegram, the latter being particularly relevant for myself
| and contacts who primarily message with their computers
| rather than their phones.
| WirelessGigabit wrote:
| Using Linux iMessages doesn't even have a client...
| godelski wrote:
| Sounds like time to become an evangelist then. I had to
| do this in my group and other than security a major
| benefit is just that getting potatos instead of pictures
| has significantly declined.
|
| Here's my advice: don't sell security as the foremost
| feature. Sell it as "iMessage, but for everyone." You got
| stickers, reactions, high quality videos and images. Then
| mention security, it is the cherry on top.
| pavon wrote:
| Every single person I converted to using Signal stopped
| using it when SMS support was removed.
|
| HN tends to be a younger crowd whose peers cycled through
| a number of social-networking and messaging apps as
| popularity waxed and waned. But older generations don't
| see any compelling reason why they should bother
| splitting their conversations over multiple apps, when
| literally everyone with a mobile has texting. Being a
| drop-in replacement for texting, so they could have
| additional features without additional hassle was the
| only thing that convinced them to switch and now it is
| gone.
|
| I've given up evangelizing Signal, and resigned to the
| idea that cross-platform RCS is the only thing that will
| bring encryption to the majority of my contacts.
| godelski wrote:
| Yeah I think this was a bad move for Signal, but I didn't
| see that happen to my group fortunately. In Signal's
| defense, my understanding is that this was really an
| Apple thing. That Apple only lets iMessage connect to SMS
| so the apps were differing significantly.
|
| I also get the fatigue. Moxie said centralized because
| they needed to move faster. But Signal has always moved
| very slow, so it does feel off. But to be fair, it's not
| like most messenger apps do much.
| zchrykng wrote:
| They were talking about on Android. Signal supporting SMS
| was never a thing on iOS.
| rootusrootus wrote:
| > HN tends to be a younger crowd whose peers cycled
| through a number of social-networking and messaging apps
| as popularity waxed and waned. But older generations
|
| What is your definition of younger and older? Anybody
| born in the 70s or later experienced an ongoing
| procession of instant messaging choices. I would tell you
| it is precisely that experience that informs my apathy
| towards the latest and greatest Hot Thing, and makes me
| appreciate boring old SMS (and by extension, iMessage)
| that I know will just work with anyone I meet.
| nicolas_17 wrote:
| Are you from the USA?
|
| I don't like splitting my conversations over multiple
| apps when literally everyone with a mobile in Argentina
| has WhatsApp. SMS costs money and having it in the same
| app as a free messaging platform sounds risky :P
| perardi wrote:
| I used Telegram during a time when I lived a cross-border
| and cross-platform lifestyle.
|
| Telegram, and really Telegram on desktop, was great. I am
| a stubborn old man at the age of 40, and I really prefer
| to type on a keyboard. It had a great UI, it always
| delivered messages, and syncing between devices was
| seemingly instant. iMessage, somehow, is still not
| perfect at syncing between devices, and while Signal is
| quite good at that, it's a pain to start using on a new
| device, as it doesn't bring along your message history.
| (For legitimate reasons, mind you.)
| jwells89 wrote:
| Yeah Telegram absolutely nails the desktop experience
| like few other chat apps do. The way they put all the
| functional bits into a library to make it easy to build
| high quality third-party clients helps, too; while the Qt
| client is quite good across platforms, users also have
| the option of a Swift-based client on Apple platforms, a
| WinUI/UWP client on Windows, GTK client for GTK-based
| Linux desktops, etc which takes it that extra mile. Heck
| there's even CLI clients for users of that inclination.
|
| Its security is questionable but it gets users by the
| boatload anyway because it doesn't consider _any_
| platform an afterthought, they _all_ get first-class
| treatment. Other cross platform messengers would do well
| to embrace a similar philosophy.
| tptacek wrote:
| Sure. Different projects, different goals. At every
| instant where Telegram had a decision to make between
| better user experience or user security & privacy,
| Telegram opted to make a better experience. Signal took
| significant UX hits to make the privacy promises it
| makes. The two projects are essentially not comparable.
| Like, the sane thing to compare Telegram to at this point
| is Matrix.
| jwells89 wrote:
| Of course, but it's not just UX that's being traded off
| but also potential for mass adoption, and evangelism is
| likely not enough to close the gap.
| tptacek wrote:
| Again: different projects, different goals. What Telegram
| is doing is inherently viral; the platform has an
| emphasis on bringing huge groups of people together, and
| the resulting design affordances, and that's a goal that
| basically works against privacy in the first place.
| Signal's original goal is to replace intimate messaging.
|
| People who love the Telegram affordances wish that the
| platform would also suffice for intimate messages. Why
| have two platforms, two UX's, and (most importantly) two
| user bases? People who live Signal wish the other thing.
|
| But you can't have both. They are incompatible design
| spaces. Telegram's security story is atrocious. It's best
| compared with Slack, not with Signal. If you're looking
| to compare a serious secure messenger with Telegram, look
| at Matrix, which has many of the same goals.
|
| It is important that there be a messaging platform in
| common (if not universal) use that is fit for purpose for
| secure messaging when it really matters: when the
| compromise a message could cost lives or fortunes. Most
| "secure messaging" is LARPing; it doesn't matter if the
| "E2EE" in a pseudonymous 500-person chat room is secure.
| By all means, make it harder to dragnet that channel,
| modernize the protocols, whatever. But you can see right
| away how little security _really_ matters to these
| groups, whether they 're on Telegram (with no group
| security) or Matrix (which at least tries), because
| messaging app affordances are all people talk about with
| them.
| skrowl wrote:
| Signal UX is AWFUL if you have a work PC, a home PC, a
| phone, and a tablet.
|
| Getting messages to flow across all of them is
| impossible.
| tptacek wrote:
| Getting messages to flow across lots of different
| platforms for a single account has been a source for a
| number of very bad security problems in other messengers.
| (Recent example: Matrix, Nebuchadnezzar). Different
| projects, different priorities.
| ramses0 wrote:
| Signal is actually pretty good for the occasional "cross-
| iOS/Android" video chat. Can't use iOS Facetime, don't want
| to use $META, google/meet is OK, but isn't quite as
| straightforward as "@Signal => CALL_ME".
| macshome wrote:
| Anyone can use FaceTime now. Non Apple devices will just
| join via a browser.
| issafram wrote:
| Which is ridiculous
| illiac786 wrote:
| What? how does that work? If you call the cell number of
| an Android device on facetime, what happens on the
| android end?
| snazz wrote:
| You text them a link to join the call. The Android user
| can't be the one to initiate.
| illiac786 wrote:
| Oh. Ok that's never going to work.
|
| "Hey there please click on this link to talk to me"
|
| => Malware! Blocked.
| simondotau wrote:
| It's how many Zoom and Teams calls terminate. Not saying
| it's a good idea, but it's not especially unusual.
| josephd79 wrote:
| thats how almost all video comm platforms work..
| kelnos wrote:
| > _The Android user can't be the one to initiate._
|
| That sounds like a bad joke. "Everyone can use Facetime,
| except if you're on a certain platform you have to ask
| someone on the 'real' platform to initiate the call."
| That's... not a viable communication method.
| simondotau wrote:
| Nobody is claiming that FaceTime is the singular
| universal communications method. Certainly not Apple.
| sneak wrote:
| https://arstechnica.com/tech-policy/2020/01/apple-
| reportedly...
|
| every iMessage you send and receive can be read by Apple (and
| the feds without a warrant). It is effectively not end to end
| encrypted at all. There is no security and there should be no
| "feeling of security" because it's a platform designed to aid
| illegal government surveillance.
| marcellus23 wrote:
| To clear up the FUD here, this is only true if you turn on
| iCloud backups (many users do, but still) and don't turn on
| Advanced Data Protection. ADP is off by default because it
| means you'll lose all your backups if you forget your
| iCloud password.
|
| > it's a platform designed to aid illegal government
| surveillance.
|
| Come on.
| sneak wrote:
| These are the defaults. You don't need to turn on iCloud
| Backup, it's already on. You don't need to turn off
| Advanced Data Protection, it's already off.
|
| Literally all you need to do is turn on a new iPhone and
| try to install any app. It will prompt for your Apple ID
| login (impossible to install apps without it) and will
| automatically enable iCloud, iCloud Backup, and iMessage
| (and will not enable ADP).
|
| https://www.forbes.com/sites/kateoflahertyuk/2020/01/21/a
| ppl...
|
| They explicitly killed the e2ee support for backups some
| time ago at the behest of the FBI to preserve the
| backdoor. It's still practically backdoored for nearly
| all iMessage users because it is off by default (and the
| UX sucks even if you turn it on). Approximately nobody is
| using it; the status quo is preserved. iMessage is
| backdoored and is not e2ee due to key escrow. If you
| message someone on iMessage, Apple will be able to read
| the message, even if you have ADP enabled (because the
| other endpoint does not). That's fact, today.
|
| Additionally, even if you turn on ADP, the hashes of
| unencrypted file content in iCloud are stored non-e2ee,
| so Apple can still see who has which unique files and
| when, and who else receives them and when. This allows
| them to monitor social graphs, too.
| overstay8930 wrote:
| iMessage is excluded by default on iCloud backups, that's
| what the other guy is saying
| rekoil wrote:
| Messages in iCloud (different thing, used for syncing
| iMessage conversations to all your devices) is off by
| default, to my knowledge backups of the iMessage database
| is on by default in the iCloud backup setting, but
| admittedly I haven't setup a new device without restoring
| an iCloud backup in many many years.
| rekoil wrote:
| > and will not enable ADP
|
| Not only will it not enable ADP, it won't even ask you
| about it.
| jorvi wrote:
| >> it's a platform designed to aid illegal government
| surveillance.
|
| > Come on.
|
| Whilst I agree with the general skepticism, Apple didn't
| add E2E encryption to (certain parts of) iCloud backups
| _at the explicit request of the FBI_.
|
| https://arstechnica.com/tech-policy/2020/01/apple-
| reportedly...
| marcellus23 wrote:
| That's still not the same as claiming that iMessage is
| designed specifically for the purpose of aiding
| government surveillance.
| jorvi wrote:
| Not adding E2E was a conscious design decision by Apple
| specifically to aid surveillance.
|
| Virtually every other big messaging service offered
| (optional) E2E at that point.
|
| I'm not sure how much clearer you want it.
|
| "Surveillance" doesn't have to mean that Apple allowed
| the FBI to jack directly into the iCloud servers.
| rootusrootus wrote:
| Wasn't it an attempt to take the fangs out of the FBI's
| push for encryption backdoors? As one of the largest
| messaging platforms in the US, what Apple does with E2E
| absolutely factors into public policymaking.
| artimaeis wrote:
| As far as I'm aware, iCloud for Messages is not enabled by
| default. Security-conscious users should know not to turn
| it on, though -- if iCloud servicing warrants is part of
| their threat model.
|
| Further, Apple ended up rolling out Advanced Data
| Protection for iCloud in 2023, so users who truly don't
| want Apple holding those keys can effectively take them
| from Apple.
|
| https://support.apple.com/guide/security/advanced-data-
| prote...
|
| EDIT: Just confirmed with a test device and test apple id,
| iCloud for Messages is not enabled on it.
| rekoil wrote:
| Messages in iCloud is separate from the inclusion of the
| iMessage database in the regular iPhone iCloud backups.
| Could you check what that setting is set to on your newly
| setup device?
| 0x457 wrote:
| I noticed an uptick in scams using iMessage. It's (almost)
| obvious that you are not talking to a real human. The scheme
| is pretty simple: lure you to iMessage, so you feel safe,
| then propose moving to another chat service that is easier to
| run bots on (telegram, whatsapp, etc) and start a regular
| programming.
| sunshowers wrote:
| Do you not send messages to any Android users? That is
| incredibly hard to imagine for me.
|
| My friend group is very mixed and Signal is what we use.
| markstos wrote:
| I thought it was a great advertisement for Signal because
| Signal and their protocol is public and their software is free,
| open source and cross-platform.
|
| In light of that Apple's message reads more like announcement
| that people who can afford iPhones will now have better
| security and privacy when they chat with themselves.
| bjoli wrote:
| I am not sure if I understand things correctly, but what apple
| did seems like a lot of work for little benefit. Symmetric
| encryption is not threatened nearly as much by quantum
| computers. Using a PQ key exchange should make adequately safe
| until someone breaks symmetric encryption, which seems like a
| high odds bet. The author of age wrote some time ago why aes128
| is good enough.
|
| But I am a classical musician so for the love of god don't
| listen to me.
| lapetitejort wrote:
| Advanced encryption, until it comes time to text 70% of the
| phones in the world, in which case it defaults to a protocol
| released 32 years ago.
| tsunamifury wrote:
| Yes but that would have meant giving up sales in exchange for
| actually backing up their words.
|
| They aren't even going to use the developed encrypted RCS
| protocol.
|
| Apple, when it comes to their values, is all lip service.
|
| I have intimate experience here with them both openly lying and
| purposefully deceiving their user base in this case.
| Jtsummers wrote:
| What word? They never said they'd open iMessage. FaceTime is
| what they intended (or at least Jobs announced the intent) to
| open, and then that got caught up in a patent dispute.
| tsunamifury wrote:
| No, they could have shipped a product on android, or they
| could have used secure RCS, or several other things.
|
| FaceTime is not really true either. This was a convenient
| mistruth. There were several way to remedy that situation.
|
| Also your misremembering iMessage there was no such issue.
| matchbok wrote:
| It's not Apple's fault that the carriers/RCS/Google don't
| know how to make messaging work. RCS sucks, it pales in
| comparison to anything but SMS.
| detourdog wrote:
| Google could have continued to support XMPP. If wishes
| were knishes doggies would eat.
| Jtsummers wrote:
| You wrote:
|
| > Yes but that would have meant giving up sales in
| exchange for actually backing up their words.
|
| What word did they not back up with respect to iMessage?
| When did they ever say they'd open it up?
| drcongo wrote:
| FaceTime is definitely true. I've used it.
| 0x457 wrote:
| I remember them saying releasing iMessage as an open
| standard.
| Jtsummers wrote:
| Can you point to a source for that outside your memory?
| layer8 wrote:
| They're confusing it with FaceTime:
| https://youtu.be/JOxf9tEXEKQ
| Jtsummers wrote:
| I figured that was the case. I just wanted one of these
| folks that keep claiming it to cough up some evidence.
| It's a tired thing. There are lots of things to criticize
| Apple (and most companies) for, at least pick something
| that isn't imaginary.
| jxdxbx wrote:
| That was FaceTime, and it was because it was a peer-to-
| peer protocol. Then Apple was sued over a patent and had
| to implement a more normal design, where it pays for and
| runs the servers. Apple didn't want to run the servers
| for Android people to talk to each other.
| matthew-wegner wrote:
| > They aren't even going to use the developed encrypted RCS
| protocol.
|
| End-to-end RCS encryption is via proprietary Google extension
| and not even available to other Android RCS messaging apps.
| tsunamifury wrote:
| It was made available to Apple.
| zchrykng wrote:
| Doesn't really help the argument that it is a proprietary
| Google technology. The fact that it had to be "made
| available" to Apple means that it isn't an open standard
| and requires trusting Google, which many of us don't.
| jxdxbx wrote:
| Encrypted RCS should be a standard. When it is Google
| should adopt the standard, not its proprietary version.
| In the meantime I want Apple to implement standards, not
| proprietary Google technologies.
| GeekyBear wrote:
| Citation?
|
| Beeper was explicitly told it was not available to others
| when they wanted to implement Google's encrypted RCS on
| their Android client.
|
| https://twitter.com/ericmigi/status/1557050351974420480
| GeekyBear wrote:
| > the developed encrypted RCS protocol
|
| Google's proprietary closed source fork of RCS?
|
| > Google's version of RCS... is definitely proprietary, by
| the way. If this is supposed to be a standard, there's no way
| for a third-party to use Google's RCS APIs right now. Some
| messaging apps, like Beeper, have asked Google about
| integrating RCS and were told there's no public RCS API and
| no plans to build one.
|
| If you want to implement RCS, you'll need to run the messages
| through some kind of service, and who provides that server?
| It will probably be Google... So the pitch for Apple to adopt
| RCS isn't just this public-good nonsense about making texts
| with Android users better; it's also about running Apple's
| messages through Google servers. Google profits in both
| server fees and data acquisition.
|
| https://arstechnica.com/gadgets/2022/08/new-google-site-
| begs...
| kergonath wrote:
| > Yes but that would have meant giving up sales in exchange
| for actually backing up their words.
|
| I saw that you moved the goalposts in your reply, but anyway:
| which words?
|
| > They aren't even going to use the developed encrypted RCS
| protocol.
|
| The protocol that was designed by Google and in which
| Google's infrastructure is crucial? It's not Apple's fault
| that RCS does not have mandatory end-to-end encryption.
|
| > I have intimate experience here with them both openly lying
| and purposefully deceiving their user base in this case.
|
| Do you mean that they lied to you personnally? You should
| write about that, it sounds much more interesting.
| tsunamifury wrote:
| I worked on several integration attempts between Apple and
| Google.
|
| They often presented specs that clearly showed security
| holes then simply would deny they were there or say "that's
| secure". It was a truly wild experience.
| kergonath wrote:
| This sounds fascinating, you really should write about
| this.
| Jtsummers wrote:
| RCS was not designed by Google. Google has (so far)
| embraced it after repeatedly self-sabotaging their own chat
| efforts. RCS is a carrier standard that the carriers had
| trouble deploying.
| rootusrootus wrote:
| > RCS was not designed by Google.
|
| Encrypted RCS was. And it is proprietary.
| para_parolu wrote:
| Why does 70% of world phones matter here? There are phones in
| the world that do not support any encryption when sending
| messages or doing calls.
| madeofpalk wrote:
| SMS/RCS
| browningstreet wrote:
| The top 7 phones sold last year were all iPhones.
|
| https://www.macrumors.com/2024/02/21/iphones-top-7-best-sell...
|
| Too bad the other vendors don't bother keeping up.
| not_a_real_56 wrote:
| There is a flaw with your thinking. Any given year there are
| only 5-6 iPhones to choose from, where there are plenty of
| Android phones. This leads to "top phone sold" being iPhones
| because it is 5 phones against hundreds of Android phones
| that people get to choose from.
|
| You should instead look at Market share.
| https://www.statista.com/statistics/272698/global-market-
| sha...
| browningstreet wrote:
| Actually my point was companies-responsible-for-encryption
| development. You could argue it's Google vs Apple on this
| front, but it could also be Apple vs Samsung, or Apple vs
| any of the other top tier android implementations.
|
| So you can either say Apple is reserving this development
| for a subset of the market, or Google is withholding it
| from a massive portion of the market share.
| danShumway wrote:
| Samsung is not the reason why iMessages can't be sent to
| Android users or to Windows devices. Samsung does not
| decide which platforms Apple will and won't support.
|
| Coordination with even Google would not be necessary for
| Apple to offer encrypted conversations with users on
| other devices. There's no rule saying they need to use an
| open standard or a Google standard or be cross-compatible
| with another app. It's not that Apple is trying
| desperately to get iMessage onto other phones and failing
| because Google and Samsung just won't let them do it.
|
| Of course, Google has its own problems[0]. But the
| inability to use the Messages app to communicate securely
| with Android users[1], is solely 100% Apple's decision.
| Apple does not need to ask permission or coordinate with
| any other company to increase that security, they would
| just need to throw a messaging app up on the app store.
|
| Heck, they wouldn't need to support _iMessage_ on
| Android. They could throw a messaging app up that had no
| encryption other than that it worked over HTTPS and data
| instead of SMS when messaging iOS users, changed nothing
| about the capabilities or features that they supported
| for non-iMessage users, and even only doing that -- if
| Android users could download it and set it as their
| default SMS client on Android then iPhone security would
| be better.
|
| ----
|
| As a comparison here, if Signal dropped support for iOS
| tomorrow, would you blame _Apple_ for not building
| support for Signal into iOS? No, that would be absurd to
| suggest. No one would claim that Apple had some
| obligation to support the Signal protocol or make Signal
| compatible with iMessage, or to build an open protocol --
| we would all correctly point out that Signal decides
| where to make its app available. The same is true of
| Apple. The fact that you literally can 't make many
| Messages conversations secure without completely
| abandoning the app and using a separate 3rd-party service
| for those conversations -- it is purely and entirely the
| result of a decision that Apple has made.
|
| ----
|
| [0]: And in fact their proprietary encryption standard is
| no better than Apple's and they're pulling the exact same
| crap as Apple is for the same flimsy reasons.
|
| [1]: Note that I don't say non-Apple users, you can have
| an iMessages account through other devices and you still
| won't be able to use it with an Android phone number.
| Terretta wrote:
| > _you should instead look at Market share._
|
| Unless your goal is to make money on the platform, then you
| should look at wallet share, not market share.
| danShumway wrote:
| The goal isn't to make money or calculate wallet share.
| The goal is to send encrypted messages to contacts.
|
| You should look at the _percentage of smartphone owners_.
| It does not matter in the slightest how many dollars they
| have in their pockets. The question is: is the average
| user going to have a significant number of Android
| contacts, with which Messages requires plain-text
| communication to contact.
|
| And the answer for most people is: undoubtedly yes. I
| would say that most people who are using Messages as
| their primary messenger for all of their contacts are
| sending unencrypted messages on the regular.
| Terretta wrote:
| Completely fair, I had shifted topics from phone owners,
| to platform relevance to makers on HN.
|
| Your point stands.
| throw0101c wrote:
| > _Any given year there are only 5-6 iPhones to choose
| from, where there are plenty of Android phones._
|
| There is such a thing as 'too much' choice:
|
| * https://en.wikipedia.org/wiki/Overchoice
|
| * https://en.wikipedia.org/wiki/Decision_fatigue
|
| * https://www.behavioraleconomics.com/resources/mini-
| encyclope...
|
| * https://thedecisionlab.com/biases/choice-overload-bias
| SSLy wrote:
| that's only 16% of total market.
| Terretta wrote:
| But 50% of revenue share (and has been as high as 110% of
| profit share):
|
| https://www.counterpointresearch.com/insights/iphone-hits-
| re...
|
| That's not the point if you're talking about who you can
| have an encrypted conversation with, but it matters if you
| want to know if you can afford building an encryption tool
| to serve phone buyers.
| Aaargh20318 wrote:
| They have already announced they will add support for RCS this
| year (https://9to5mac.com/2023/11/16/apple-rcs-coming-to-
| iphone/), so not exactly a protocol released 32 years ago. It's
| probably coming in iOS 18
|
| Still unencrypted though, because the RCS standard does not
| include encryption.
| yackback wrote:
| RCS is unencrypted unless you use Google's closed garden Google
| Messages' extensions.
|
| Apple is apparently working with GSMA to add encryption to the
| standard though. (They probably wouldn't add RCS otherwise.)
| astrange wrote:
| They would if a regulator made them. They're adding it
| because China requires it.
| danShumway wrote:
| This is getting downvoted, but it really does feel like a
| variant of the wrench problem: https://xkcd.com/538/
|
| It's already incredibly hard to get people to use secure
| messaging systems. Downgrading to SMS isn't necessarily wrong
| (it's become harder to get people to use Signal now that it's
| dropped support for SMS), but it's a huge hole and effectively
| means that many customers will never have a significant number
| of their conversations encrypted.
|
| That's a boring security hole, sure. But at some point you have
| to think about UX as being a part of security, and a messaging
| system that isn't cross-platform is hard to call secure,
| because good luck trying to get your contacts to all use it.
| People get upset about this, but the reality is it does not
| matter what encryption scheme a messenger is using if it's
| impossible for you to get your contacts to use it. The same way
| that it does not matter how secure your 2FA system is if you
| can't get people to turn it on.
|
| I felt like on net Signal's support for SMS was a boon for
| security more than a hindrance because it made it easier for me
| to get people to sign up for Signal. In contrast, Signal's take
| was that having a secure and insecure service bundled up into
| the same messenger would on average make people more lax about
| security and would make it harder for them to make strong
| security guarantees. They viewed SMS support essentially as a
| security vulnerability.
|
| I do wish Signal had kept SMS and tried harder on the UX, I
| honestly feel somewhat strongly that removing support made
| secure messaging harder -- but while we can debate the security
| downsides and the onboarding downsides, I also have grown to
| kind of see their point? And iMessage falls very squarely into
| that problem, except with Signal I can at least tell my
| contacts how to get it.
|
| I don't know, it feels petty but like... if you have secure
| encryption but it doesn't get turned on for a bunch of
| messages, then that does seem like it has a security impact. I
| don't think that's a complicated or controversial thing to say,
| it's no different from calling out that some chat services
| require E2EE to be opt-in instead of opt-out. Good security
| requires thinking about that kind of stuff.
|
| It's the wrench problem. You're not going to get spied on by a
| quantum computer. You're going to get spied on because there's
| a decent chance that ~50% of your contacts or more aren't on
| iPhone and you'll be talking to them in plain text. And
| realistically for most users, switching to a cross-platform
| E2EE messenger that allows them to use one consistent service
| for all of their encrypted conversations is going to be
| meaningfully more secure even if it doesn't have quantum-
| resistant encryption. The most important problem for any secure
| messenger to solve is how to get people to use it. Sometimes
| that means compromising on other security standards, sometimes
| it means being harsher about security standards that would
| otherwise be optional. Sometimes it means caring about
| availability and onboarding, and not sending the majority of
| messages in an easily intercepted plain-text format.
| smoldesu wrote:
| > It's the wrench problem. You're not going to get spied on
| by a quantum computer.
|
| I'll take that one step further; it's the trusting trust
| problem. In the words of Ken Thomson, "To what extent should
| one trust a statement that a program is free of Trojan
| horses?"
|
| You're not going to be spied on by a quantum computer because
| intelligence agencies already use classical computing for
| that. Some governments write Apple or Google a strongly
| worded email, others install a backdoor using iMessage.
| There's no need to crack your encryption because you're not
| going up against quantum adversaries; those people all have
| better options than bruteforcing Apple's lock. Sufficiently-
| motivated actors skip the wrench and pay Bob or Alice for
| your password.
|
| There's no perfect solution to this issue. Apple would sooner
| die than lower the drawbridge to iMessage, and Google can't
| be bothered to write an altruistic RFC to save their life.
| Now we get the worst of both worlds; divided and surveilled.
| carstenhag wrote:
| Barely anyone uses sms nowadays. People use WhatsApp, FB
| Messenger and co (outside of the USA).
| sandyarmstrong wrote:
| This is pretty fascinating. For easier reading, the Signal blog
| post [0] they link to is great.
|
| Both Signal and Apple went with CRYSTALS-Kyber [1] as their post-
| quantum algorithm. If you're interested in the math, and maybe
| learned at some point about how classic public key cryptography
| is built on the idea that it's easy to multiply two primes, but
| hard to factor them, and how this (or other math problems) can be
| used as a one-way function to make encryption hard to break, the
| hard math problem that backs Kyber is the "learning-with-errors"
| [2] problem.
|
| [0] https://signal.org/blog/pqxdh/
|
| [1] https://pq-crystals.org/kyber/
|
| [2] https://en.wikipedia.org/wiki/Learning_with_errors
| gjsman-1000 wrote:
| Was the CRYSTALS-Kyber name intentionally, or accidentally, a
| reference to Kyber Crystals (I.e. The Lightsaber energy
| source?)
| ZeWaka wrote:
| Absolutely a reference. Dilithium (from Star Trek) is name of
| their signature algorithm.
| throw0101c wrote:
| The trick to naming things is to first find a cool
| word/reference, and then 'reverse engineer' it as an
| acronym second:
|
| * https://en.wikipedia.org/wiki/Backronym
| ryukafalz wrote:
| Though you can easily take it too far; I think US
| legislators have been running out of reasonable
| backronyms :)
| andy_xor_andrew wrote:
| I'm way out of my depth in terms of the math here.
|
| But my 'software engineer brain' likes the ideal of using the
| prime factoring problem, because it's so simple to understand,
| and feels like some kind of universal primitive. "It's easy to
| multiply but hard to factor." It just seems so intuitive.
|
| But I'm reading the 'learning with errors' wiki page and it's
| beyond my comprehension.
|
| There's a weird fear in my mind that all these "post quantum
| algorithms" are so complicated, with such a large surface area,
| that they may hide flaws. While prime factoring, or even the
| elliptic key stuff, is so simple to comprehend.
|
| that said, obviously the experts know what they're doing, and
| I'll use what they suggest. just saying that this thought has
| crossed my mind.
| Retr0id wrote:
| The explanation in this video is what made it click for me:
| https://www.youtube.com/watch?v=K026C5YaB3A
| kevvok wrote:
| Same here: this video helped me finally understand the
| basics concepts underlying LWE
| tptacek wrote:
| Well, one way to think about this is: how much abstract
| algebra are you keeping in your head to reassure yourself of
| the security of classical asymmetric cryptography? It's
| surprisingly deep. Some programmers are "comfortable" with it
| because they've been brought up being taught that "factoring"
| is just the way asymmetric cryptography works, but that has
| never really been the whole case.
|
| Elliptic curve is not at all simple to comprehend! It's easy
| to implement, but the motivation for designing systems around
| them (the effectiveness of the index calculus on elliptic
| curve groups) and the discoveries made on attacking them
| (like the MOV attack that transforms ECDLP problems to FFDLP
| problems) are not at all simple.
|
| Arguably, elliptic curve is an odder corner of mathematics
| than lattices.
| pbsd wrote:
| The LWE problem is one level of abstraction away from the
| fundamental lattice problems it reduces to. It is somewhat
| analogous to the Diffie-Hellman problem that many
| constructions reduce to, which itself is related to the
| lower-level discrete logarithm problem.
|
| The lattice equivalent of integer factorization is the
| shortest vector problem: you're given n vectors of length m,
| and you have to find the sum of integer multiples of those
| vectors that comes closest to (or a small factor away from
| the closest) the zero vector. Say you have the 4 vectors
| [ 3 92 4 2] [54 0 92 41] [19 91 61 48]
| [39 59 40 14].
|
| The shortest vector that you can obtain from adding integer
| multiples of these vectors is [19 -8 -15 2], which you can
| obtain by 3*[39 59 40 14] + [19 91 61 48] - 2*[54 0 92 41] -
| 3*[ 3 92 4 2].
|
| With only 4 vectors it is easy to find the solution here. But
| the hardness grows exponentially with the dimension, and the
| dimensions in cryptographically relevant lattices are in the
| hundreds to thousands.
| hannob wrote:
| I know that thinking, but learning more about RSA, I came to
| realize that there's a flipside of this.
|
| People think "RSA is easy", because someone gave them a
| lecture of a simplified/wrong/insecure version of RSA. Pretty
| much all "simple introductions to RSA" you can find out there
| are wrong.
|
| The truth is: RSA isn't that simple. If you want to have RSA,
| and want to have it secure, there's a whole bunch of things
| to consider. But RSA looks simple.
|
| So lots of people go ahead and implement their RSA. And then
| you end up with, hey, I can break almost a third of the top
| 100 webpage's RSA implementations. (I'm not kidding, I did
| that -> https://robotattack.org/ .)
|
| I think the fact that crystals-kyber is obviously not that
| simple may actually protect us. Because hopefully most
| peopple will end up using some hopefully well audited
| optimized free implementation, because they won't even have
| the idea that they could do this on their own.
| a1369209993 wrote:
| > There's a weird fear in my mind that all these "post
| quantum algorithms" are so complicated, with such a large
| surface area, that they may hide flaws.
|
| That's correct (emphasis on "may", of course), and is why
| it's absolutely imperative to always use PQC/ECC hybrid
| cryptosystems rather than pure PQC. See eg [0] for a more
| detailed explanation.
|
| 0: https://blog.cr.yp.to/20240102-hybrid.html
| tptacek wrote:
| There are essentially no mainstream systems that don't do
| this. That's why new systems deploy things like PQ3.
| a1369209993 wrote:
| Do you mean:
|
| > There are essentially no mainstream systems that don't
| [use PQC/ECC hybrid cryptosystems?].
|
| If so, good. I'll admit my expectations are a bit biased
| from having to deal with projects that go out of their
| way to produce defective software (eg DRM, malicious
| abuse of undefined behaviour by compliers, cloudflare and
| other captcha-walls, etc) so I tend to assume the worst
| by default.
| tptacek wrote:
| Yes. So far as I know, there's no mainstream system that
| has even proposed to use solely Kyber and not Kyber+ECC.
| It's been a built-in assumption since the earliest Chrome
| PQC experiments.
| bjoli wrote:
| I was reading the NIST comments and djb is not very happy with
| how they present things, and the other commenters seem to think
| he is a prick.
| londons_explore wrote:
| I want an encryption algorithm composed of 2 parts chained,
| such that both parts need to be broken for the whole thing to
| be broken.
|
| And I'd like the US/The west to declare 1 part as secure, and
| I'd like Russia to declare the other part as secure.
|
| I'm fairly confident that Russia and the US won't collude to
| push a known-weak algorithm.
| InsomniacL wrote:
| I wonder if Apple will use this as an excuses to not comply when
| it comes to providing cross platform messaging in the EU.
| jitl wrote:
| The EU already decided that under the DMA, iMessage is too
| small to qualify for the interoperability requirement. Apple is
| however adding (unencrypted) RCS support to comply with Chinese
| government law, which requires that all 5G phones support RCS.
| olliej wrote:
| You don't need (unencrypted) in this. RCS is not encrypted.
| It never has been.
|
| Google has a proprietary extension that puts encrypted blobs
| into RCS messages, but that would be no different from apple
| shoving iMessage blobs into RCS and calling it RCS.
| madeofpalk wrote:
| Apple already has cross platform messaging in the EU. SMS!
|
| Besides, the EU doesn't care about iMessage.
| upofadown wrote:
| >When iMessage launched in 2011, it was the first widely
| available messaging app to provide end-to-end encryption by
| default,...
|
| Until very recently, iMessage provided no way to verify that you
| and your correspondent were not both connected to the server,
| rather than each other. So guaranteed end-to end encryption
| wasn't possible. Even now, with a recent version of iOS, they
| allow the users to blithely exchange messages without any
| identity verification. The identity numbers used to do this are
| hidden behind menus. So not really E2EE in any practical sense.
| maqp wrote:
| Same thing with Signal and most other messengers. Can you link
| to some documentation that shows iMessage even has the identity
| numbers?
| nicolas_17 wrote:
| https://support.apple.com/en-us/HT213465#verify
| upofadown wrote:
| Isn't all this post quantum stuff a little premature? The
| standards haven't settled. We don't even know if there _is_ a
| possible quantum threat to cryptography yet. The more we work on
| the problem the less likely it seems. Last I heard we were 1 or 2
| orders of magnitude away from physical noise performance that
| would make such a threat possible.
|
| Edit, added: Harvest now, decrypt later applies to _any_
| encrypted data. There is nothing special about the quantum
| threat. This all only makes sense if we can predict what the
| actual threat is ... and so far we can 't. This reminds me of
| Pascal's Wager[1]
|
| [1] https://en.wikipedia.org/wiki/Pascal%27s_wager
| dijit wrote:
| You'd be right except that anything encrypted now can be stored
| and cracked later.
|
| I remember as part of the snowden leaks there was documentation
| about this kind of delayed phase collection.
|
| Basically store as much signals data as you can and try to
| crack it later if there's a weakness discovered with the
| protocol or computing power starts being capable of wholesale
| attack.
|
| You might remember that hashes are significantly easier to
| crack with "rainbow tables", and so we added cryptographic
| "salts" to online password storage. We discovered that about 15
| years ago and started salting all our passwords, but for a
| large window of time all of those old leaked databases were
| suddenly extremely easy to crack.
|
| Now, Imagine the NSA is 10 years ahead of us (and you might be
| close with that estimation), so even if they can't crack RSA
| right now they're much closer than we are, and even _we_ get
| there we will likely have a large window of time before we fix
| it properly. (not that we 're talking RSA here, but you get my
| point).
|
| https://www.forbes.com/sites/andygreenberg/2013/06/20/leaked...
| astrange wrote:
| RSA isn't anywhere near 10 years away from being attackable
| with a classical computer. (More like eons.)
|
| It's not a matter of time, it's just a matter of quantum
| computers existing.
| upofadown wrote:
| That Forbes article is about a loophole involving encryption
| that could allow the NSA to collect and store data that they
| might not otherwise be able to. Now that everything is
| encrypted, that loophole might cover everything.
|
| Nothing in the article implies that the NSA can magically
| collect all the encrypted data in the world and keep it for
| many years.
| Octoth0rpe wrote:
| One reason to move sooner rather than later is to mitigate the
| threat of previously stored data. There may be a government
| entity simply storing all imessage traffic in the hopes of one
| day decrypting it when/if a breakthrough happens. If you
| transition sooner, you increase the age of the latest data that
| could be decrypted, thusly hopefully making it safer.
| whizzter wrote:
| Like the article says, it's protection from harvest-now-break-
| later.
|
| Apple users and communications are today a state-secret affair
| as shown by the impact of NSO/Pegasus.
|
| So even if Google,IBM,et al _might_ have approached feasibility
| in the open there is still a significant risk in state-level
| adversaries having poured enough funding to still be ahead,
| plus they will benefit from all open research in the hidden
| with extra funding to take more leaps.
|
| So no, it's not premature if there is hidden or open leaps just
| 10 years in the future.
| raccoonDivider wrote:
| > Edit, added: Harvest now, decrypt later applies to any
| encrypted data. There is nothing special about the quantum
| threat. This all only makes sense if we can predict what the
| actual threat is ... and so far we can't.
|
| But we know Shor's algorithm, and we've started building
| prototype quantum computers. Isn't that enough to build
| something that counters them? Worst case, we deploy new ciphers
| and realize that the threat was empty 50 years from now. What's
| the downside?
| SheinhardtWigCo wrote:
| > Last I heard we were 1 or 2 orders of magnitude away from
| physical noise performance that would make such a threat
| possible.
|
| The entities with the most to gain from such an advancement are
| not exactly known for publicizing their achievements.
| bprater wrote:
| From the article:
|
| >> Although quantum computers with this capability don't exist
| yet, extremely well-resourced attackers can already prepare for
| their possible arrival by taking advantage of the steep
| decrease in modern data storage costs. The premise is simple:
| such attackers can collect large amounts of today's encrypted
| data and file it all away for future reference. Even though
| they can't decrypt any of this data today, they can retain it
| until they acquire a quantum computer that can decrypt it in
| the future, an attack scenario known as Harvest Now, Decrypt
| Later.
| tptacek wrote:
| We have reason to believe that conventionally encrypted data
| isn't threatened within the next 50 years by anything other
| than quantum computing, which is what's special about the
| quantum threat.
| therealmarv wrote:
| Would be great if we could uninstall iMessage completely out of
| iPhone for security reasons or make it opt in by default.
| Unfortunately it's not possible and it will be a gateway for
| security issues and malware in the following years to come. Post
| quantum cryptography is nice but that's one of the smallest
| problems with iMessage.
| cyclecount wrote:
| iMessage can be disabled in Settings > Messages
| dijit wrote:
| You can very easily disable iMessage completely
| hu3 wrote:
| How?
| tiltowait wrote:
| Settings -> Messages -> Toggle iMessage off
| yosito wrote:
| Wouldn't SMS be more insecure?
| maqp wrote:
| For message security, absolutely. For endpoint security
| (iMessage as exploit surface), not so much.
| maqp wrote:
| Just gonna add here. Do not switch from iMessage to SMS no
| matter what. Only switch to something like Signal if you
| need the cross-platform support etc.
| barkerja wrote:
| I don't intend to dispute your stance here, but I am interested
| in understanding a bit more about it. Do you mind giving an
| example and what the alternative(s) are?
| therealmarv wrote:
| Search for "Pegasus, NSO, spyware, imessage" or
| https://archive.is/4fl6o
|
| One quote from the article: "Your iPhone, and a billion other
| Apple devices out-of-the-box, automatically run famously
| insecure software to preview iMessages, whether you trust the
| sender or not," said security researcher Bill Marczak, a
| fellow at Citizen Lab, a research institute based at the
| University of Toronto's Munk School of Global Affairs &
| Public Policy. "Any Computer Security 101 student could spot
| the flaw here."
| ummonk wrote:
| Have any zero-day vulnerabilities been found that work on
| devices in Lockdown Mode?
| sneak wrote:
| You can entirely disable iMessage (and FaceTime, and Siri, etc)
| via provisioning profiles on a managed device. Use Apple
| Configurator 2 to do so.
|
| (A very important privacy setting with no corresponding toggle
| in the UI that can only be set via a configuration profile is
| the option to _not_ auto sync your list of recently emailed
| people to iCloud ("Disable recents syncing"). This leaks your
| email contact history and social graph to Apple if you have
| iCloud turned on, even if you aren't using an Apple email
| account and aren't using iCloud Contacts. AFAIK there's no way
| to disable it other than via configuration profile.)
|
| This is what I do.
| therealmarv wrote:
| interesting!
| upget_tiding wrote:
| You can enable lockdown mode to decrease the attack surface.
|
| https://support.apple.com/en-us/105120
| azinman2 wrote:
| Just as a reminder making crack-proof encryption standard
| everywhere is a trade off. It's often discussed and presented in
| forums like this as the only and just choice (and I believe net
| it is), but in doing so WILL lead to bad outcomes. Terrible
| crimes, unsolvable murders, large scale terrorism, emboldened
| enemies attacking a country, more successful coups, etc. It would
| be nice as a community to acknowledge nothing comes for free and
| every technology is a double edged sword. I wish more of these
| double edge swords could be debated by the public it affects,
| although it's out of the scope of comprehension and
| thoughtfulness by most. And yet we all make the choices that will
| affect generations...
| gjsman-1000 wrote:
| Yeah, that's what the NSA has said forever - but it turns out
| that all encryption has that human factor.
|
| Imagine I'm planning something malicious. If I literally do
| anything other than talk about it, there's going to be
| evidence, and that evidence won't be encrypted.
|
| Plus, crack-proof encryption existed at least back to Roman
| times - simply because making a secure code was fairly easy and
| we didn't have codebreakers. We managed.
| kanbara wrote:
| people commit crimes with: cars, money, public transit,
| restaurants, food, bathrooms, roads, ... why don't we get rid
| of all that?
|
| we don't remove all rights to privacy for people in their homes
| because criminals use homes too. tech should be no different
| QuizzicalCarbon wrote:
| Those "bad outcomes" already existed pre encryption. If
| anything, it'll be more of the same.
| robjan wrote:
| Widely used unbreakable encryption has been available in chat
| apps for at least a decade and hasn't led us down that slippery
| slope yet. PQ3 is just future proofing what we already have.
| sunnybeetroot wrote:
| For a minute I thought you were only talking about non-state
| actors performing those terrible things, then remembered
| history is full of nations doing all those things.
| azinman2 wrote:
| It's all of the above. That's my point. Good, bad, ok if
| you're on their side, some never have a side to be on.
| olliej wrote:
| (1) crimes happen, and have happened forever
|
| (2) historically people simply did not create a huge written
| record (texts etc) detailing their crimes, so there's no change
| in available information
|
| (3) even before any of this tech police are not good a solving
| crimes, and generally rely on errors by criminals
|
| (4) and finally. Your argument is definitionally the slippery
| slope and is the reason the 4th and 5th amendments exist in the
| US. Your argument is trivially extended to literally
| everything: why shouldn't all communication be routed through
| government servers to find evidence of crimes? Why shouldn't
| all device locations be available to police at all times? Why
| shouldn't you have video and audio recorders in every home
| (most child abuse, the quintessential horror) is committed by
| family members in the home.
|
| Having actual privacy does not result in crime, and mandating
| that privacy should be illegal in only a single case is clearly
| nonsense. Either you have a right to privacy or you don't.
| maqp wrote:
| Did anyone figure out how MITM attacks are handled? How does the
| key transparency work and does it replace public key
| fingerprints?
| m3kw9 wrote:
| Replace this question with "how competent is the Apple security
| team"
| honzaik wrote:
| This (and Signal's solution as well) does not protect against
| active MITM attackers _with quantum computers_. They would need
| to incorporate post-quantum signatures into it as well.
|
| The reason why it is missing (but seemingly planned in the
| future) is because it is not as critical as this change. This
| change prevents attackers from recording conversations now and
| decrypting them when (in the next ?? years/decades) they get
| access to an actually powerful quantum computer. On the other
| hand, you can do MITM only after you factorized RSA key (or
| solved discrete log).
|
| The additional reason I presume is that this typically requires
| a change to the whole public key infrastructure (certificates,
| OCSP, etc.) which is a lot of additional work.
| maqp wrote:
| I'm a bit puzzled. Suppose you do single Kyber key exchange,
| and you then hash the shared secret with a domain separator
| to get a fingerprint, wouldn't that mean you now have a
| shared secret that you can verify wasn't under MITM.
|
| You then can build post quantum future secrecy / key rotation
| on top of that, by mixing in new key material and it remains
| secure from MITM, as long as the internal state of the
| endpoint isn't compromised. The endpoint compromise is
| outside networked TCB threat model, as such compromise could
| also be used to exfiltrate long term post-quantum identity
| keys for undetectable MITM).
| Retr0id wrote:
| Key exchange (whether it's a PQ scheme or more classical
| DH) does not prevent active-MITM on its own, you need
| authentication too.
| maqp wrote:
| Yeah that's what the fingerprint is for, you compare it
| to authenticate the key exchange.
| m3kw9 wrote:
| Is this country dependent?
| damnloveless wrote:
| Come help me work on an open source, P2P, PQ-resistant messaging
| app: https://github.com/kjloveless/ftw-cli
___________________________________________________________________
(page generated 2024-02-21 23:00 UTC)