[HN Gopher] Stop Using Encrypted Email (2020)
___________________________________________________________________
Stop Using Encrypted Email (2020)
Author : cf100clunk
Score : 130 points
Date : 2021-09-11 18:32 UTC (4 hours ago)
(HTM) web link (latacora.micro.blog)
(TXT) w3m dump (latacora.micro.blog)
| dgan wrote:
| funny, it takes only 2 link hopes to find a contradictory
| statement ("Use PGP!")
| baybal2 wrote:
| This is a stealth Signal promotion, and self-promotion of
| Latacora in a style of Lennart Poettering.
|
| It's a bad advise, don't listen.
| approxim8ion wrote:
| The issue with encrypted email a-la PGP even beyond security
| issues is the laughably bad UX. I'm not going to be able to
| convince people to adopt the best practices involved in
| maintaining keys and using them to encrypt and decrypt the mail
| they send. Whether that is good or bad is immaterial- the cat is
| out of the bag and people are already used to the convenience of
| insecure incumbents.
|
| For messaging, we need something that is end to end encrypted by
| default, and is also only available in an e2ee format.
| Decentralization is an additional bonus, but really as long as
| the protocols are heavily audited and the clients are reasonably
| open (reproducible builds etc), it doesn't matter what your
| choice is and what networks your messages go through/who controls
| them.
| JohnJamesRambo wrote:
| Could Signal ever do an email service? I'd switch to it in a
| second. I realize I'd be sending it to insecure addresses but
| at least my end wouldn't spy on me? I just realized how
| dystopian that sentence is.
| mmerlin wrote:
| The guerilla growth marketers working for Signal would
| probably be unable to resist the viral temptation of spamming
| all your email address list who have already joined signal to
| "let them know" about your newly installed contact channel.
|
| I was super-annoyed when two people from my distant past
| started trying to contact me via Signal purely because of the
| unwanted and un-asked for behaviour of vacuum-and-spam
| notification of my phone contact list (which had accumulated
| from before 2000) who were in the subset of already-Signal-
| members.
|
| In particular one huckster I lost $22k to, and who I came
| close to being liable for taking illegal action on behalf,
| through his fraudulent lack of full disclosure, who I had
| thoroughly removed from all my social media, plus filtered
| his email straight to trash, and permanently blocked from
| calling my phone.
|
| Because his phone number was in my address book (so I could
| block him) Signal thought it had the right to let him know he
| can now contact me.
|
| Poor form there Signal...
| egberts1 wrote:
| write a big report?
| wizzwizz4 wrote:
| They already know about the problem; they've known for
| years now.
| egberts1 wrote:
| i am going to stop you there.
|
| The mere fact that you had a phone number in your address
| book is what made your locally client-side Signal app made
| the notification... locally.
|
| This newly discovered mechanism does not alert the remote
| Signal app.
|
| Just the mere fact that you allowed Signal app access to
| your local address book and actually ran all numbers
| against the central server is not clearly stated in their
| type of service (TOS).
|
| This is the primary reason why i never let Signal app have
| access to my Contacts/address-book.
|
| This is why we have no idea what else Signal is doing with
| remote phone numbers found in our address book. I was able
| to ascertain between two phones of this one-sided aspect
| (but for how long)?
| mmerlin wrote:
| Yes!
|
| I expect any app or service to at least warn me first
| before they instigate unsolicited actions on my behalf.
|
| Signal has no doubt already legally covered their ass
| with regards to me giving this consent.
|
| However in reality I never would have allowed this if I
| was asked or even given a fraction of a hint as to what
| was about to happen once I gave them the requested
| permissions to be installed.
| Anunayj wrote:
| even if they do, you have to maintain compatibility with
| "other" popular email providers. Protonmail encrypts all it's
| emails among it's own users. But at the end me with my gmail
| can't read them without jumping through hoops.
| mmerlin wrote:
| Mailvelope and it's browser plugin is fairly easy for
| encrypting gmail (and other major email providers)
| conversations:
|
| https://chrome.google.com/webstore/detail/mailvelope/kajibb
| e...
| approxim8ion wrote:
| Thing with email is that you'd also have to get everyone you
| talk to to move to it and ensure they don't fall back to any
| of the services they have been using for all this time for
| convenience's sake. At which point, it doesn't even matter if
| it is email behind the scenes or something else.
|
| There's also the issue of SMTP being very metadata heavy and
| there being no option to mitigate or encrypt any of the
| metadata. Which is why something like Delta Chat (if you
| haven't heard of it, it's basically Signal/WhatsApp like IM
| piggybacking over email) isn't very private.
| michaelcampbell wrote:
| Keeping your house safe from a dedicated intruder is impossible,
| so you shouldn't even try.
| supernintendo wrote:
| The author says not to use email encryption but what is the case
| for sending email in plain text? Is encrypted email detrimental
| to my privacy in some way that unencrypted email is not? Or if
| the argument is that encrypted email is useless and no better
| than unencrypted email (since it is always unencrypted at rest)
| then what is the point of avoiding it in favor of the
| alternative? Aren't they equivalent, making the distinction
| meaningless?
|
| This is my problem with the article. It feels like it suffers
| from a bit of zero-sum fallacy. The statement here is, "it can be
| broken therefore it's fundamentally broken." I think it's more
| useful to think in terms of probabilities. If I disable password
| authentication for SSH and require public key authentication on
| my web server, an attacker can still get in by stealing my
| private key. That isn't a reason to take the opposite approach
| however - botnets commonly employ password-guessing attacks
| against entire IP ranges so you're not actually safer by avoiding
| this practice just because it isn't a perfect solution. There is
| no silver bullet for security, only endless layers of strategies
| and adaptations to edge cases.
|
| I did enjoy some of the points about the limitations of email
| encryption (the email chain example is a great reminder of how
| security is often more about human behavior than software). But I
| think the article could have been more compelling had it
| presented a less dogmatic thesis - perhaps "Email Encryption
| Won't Save You" or something like that.
| ameliaquining wrote:
| The point being made is that, if something is sensitive enough
| that you would hesitate to send it in the clear, you should
| send it over Signal or some other system that doesn't have the
| security flaws that encrypted email has. Given that that option
| exists, and that encrypted email isn't suitable for many use
| cases that people are tempted to use it for (and is therefore
| an attractive nuisance securitywise), there's not much reason
| to use or support encrypted email at all.
| jrm4 wrote:
| This all day. I don't get why you'd take time out of your day
| to write "Stop Using Encrypted Email" instead of "Can Encrypted
| Email Be Done Right?" unless the answer is provable and obvious
| no.
| Aerroon wrote:
| The case the article is trying to make is "don't use email".
|
| Use something else to send messages you wish to not be
| compromised.
| yuvadam wrote:
| Encrypted email _maybe_ works if both you and your counterparts
| are power users that know how to use GPG, or how to properly
| configure it through Thunderbird or any other email client.
|
| The moment you have to implement encrypted emails in a high-
| risk organization or ad-hoc collective, it all goes out the
| window. There are simply way too many pitfalls to get it
| working properly. You have to continuously educate your users
| and ensure they don't shoot themselves in the foot.
| threshold wrote:
| I'm increasingly confident there's a campaign in progress to
| persuade abandoning standards the NSA can't crack and migrate us
| into projects using algorithms with built in backdoors. RSA is
| not cracked and PGP works fine.
| baybal2 wrote:
| It's been 8 years, and Eric Rescorla hasn't yet come clear how
| EC DRBG came his way, and why he kept changing his explanations
| about that.
| cs2733 wrote:
| Never heard of it, thanks
| https://blog.cryptographyengineering.com/2017/12/19/the-
| stra...
| serf wrote:
| PGP has been the target of everyone's ire for years and years,
| yet since we're still talking about it, I guess it works.
|
| Every thread that mentions PGP will eventually devolve into a
| discussion about how it's a foot gun and mere mortals will blow
| themselves up with it...
|
| ... but it works.
|
| Seriously though, I remember discussions in the mid to late 90s
| about UI/UX difficulties and about how every single person that
| doesn't understand the operation perfectly _IS_ going to be
| black-bagged by their local black-ops group; the same
| discussions that pop up in every PGP thread.
|
| It's like one of the oldest running jokes in CS at this point
| -- not that PGP is broken and failed but that it attracts tons
| of individuals to congregate and be upset en masse about the
| UX.
| lonjil wrote:
| > doesn't understand the operation perfectly IS going to be
| black-bagged by their local black-ops group
|
| More likely, they simply aren't noteworthy targets. If you
| rely on PGP to secure your emails, those emails will probably
| end up not actually secured, but you won't notice because
| your emails aren't valuable anyways and are probably secured
| by other stuff, like TLS, and Google's server security.
| bscphil wrote:
| An interesting point of comparison here is git, which is also
| widely claimed to have subpar UX.
| platz wrote:
| OP's post on PGP basically boils down to bad UX
| https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
| [deleted]
| kitkat_new wrote:
| I think it would make more sense to point to the Matrix protocol
| instead of Signal. Matrix is actually decentralized like Email,
| allows any service provider as well as app provider - free to
| choose as a user. It supports Perfect Forward Secrecy (based on
| the Signal Protocol), arbitrary many devices and "one
| verification for each individual".
|
| Well, you might argue Matrix stores meta data server side (the
| ones chosen), while Signal at least doesn't have to.
|
| But do you really want to give up all that freedom trusting a
| single service provider in that really no data is kept?
|
| Maybe you can wait until Matrix allows you to avoid signing up on
| a server using P2P[0], then you have got it all, and don't have
| to commit to an alternative that has advantages, but also big
| draw backs.
|
| [0] https://news.ycombinator.com/item?id=27077660
| daneel_w wrote:
| Or XMPP/Jabber.
| arcbyte wrote:
| I thought we all decided a decade ago that XMPP/Jabber was
| way too complicated to implement and not to use it?
| daneel_w wrote:
| I don't think so. Though it is possible that you decided so
| on your own.
| approxim8ion wrote:
| XMPP is good, great even, but it has the same issue as email
| where you could interface with someone not using OMEMO or
| whatever your encryption scheme is and it would fall back to
| plaintext.
| daneel_w wrote:
| With XMPP that's thankfully up to you to decide through
| client preferences, and in this way your choice also
| propagates across XMPP servers.
| MattJ100 wrote:
| The story is not quite the same for XMPP. For example, with
| XMPP you can determine ahead of time whether or not a
| contact has OMEMO. And clients configured to only use OMEMO
| won't "fall back".
| approxim8ion wrote:
| Apologies, clearly my understanding of XMPP is not the
| best.
|
| However, both points you mentioned are client dependent,
| right?
| giantrobot wrote:
| The fallback has to be client dependent. With E2EE the
| server can't decrypt messages. So there's no way for the
| server to decrypt the message to "downgrade" the channel.
| The client is also the node responsible for encrypting
| all messages for all recipients so it has to know if any
| of those recipients haven't done a key exchange.
| TedDoesntTalk wrote:
| I've not seen XMPP used for store-and-forward messaging, like
| email, but I suppose it could be done.
|
| Every single XMPP client I've used sucks. Really suck. And
| there are always quirks setting up group chat and image
| sharing with XMPP servers.
| daneel_w wrote:
| Roster/conversation capability (server holding message
| until recipient comes online) is a basic extension to XMPP.
| I don't think I've ever used a Jabber server _not_
| supporting it, and all the popular clients support it.
| approxim8ion wrote:
| I believe they mean the messages being held on a server
| even post delivery.
| daneel_w wrote:
| Yes. Same thing, same feature. This is what
| "conversation" mode is, also known as message archive
| management, or XEP-0313 (a standardized extension/feature
| of XMPP).
| mananaysiempre wrote:
| I love the idea behind Matrix and dearly want it to succeed,
| but unlike IRC and XMPP as well as (to a lesser extent) email
| and netnews, it has the inherent problem that it implements a
| genuinely difficult thing: a large partition-tolerant
| distributed database without a central authority and even a bit
| of mistrust between nodes. Now that I've put this in writing, I
| wonder if there were any attempts to do this at all before the
| current generation of systems. (IRC and netnews basically YOLO
| their consistency away because they can't afford it, which was
| indeed correct when they were designed, but people did a lot of
| distributed systems work between then and now...) That implies
| that a Matrix server is necessarily somewhat heavy _and_ rather
| difficult to implement.
|
| This makes me think that the federated network must by
| necessity exist in a fragile and tender state while Matrix is
| young, and need to be tended to with attention and care. The
| current stewards of the protocol don't seem to be giving it
| that, growing features (even if good and competently designed
| ones) while treating the surroundings with something of a "they
| will come" approach. (To put it uncharitably: Look, there are
| now a whole two comprehensive server implementations, and the
| second one you could even afford a server for! Yeah, the Gnome
| people gave up on independently implementing a secure client,
| but surely an Electron one should be enough?..)
|
| I've spent a very limited time studying the situation so I am
| not going to make any dire-sounding prophecies; besides, I
| actively don't _want_ any such prophecies to come true. What I
| am is worried. It doesn't take much for a protocol to become a
| non-interoperable tangle of implementation details, and Matrix
| is an extraordinarily ambitious one.
| remirk wrote:
| I agree that Matrix is quite complicated. However, adding new
| features doesn't have to make it that more complicated. I get
| the impression that it's not that bad as most new features
| are actually based on existing parts of the protocol.
| Everything is just based on events in a room. Most 'special'
| events have a fallback mechanism to text, to insure clients
| that haven't implemented the event type can still show the
| information to the user. Replies and stickers make use of
| this for instance.
| mananaysiempre wrote:
| Short and harsh (likely too harsh):
|
| My point is not that Matrix is complicated, thus we should
| avoid making it more so. My point is that the approach that
| Matrix chooses, even in its most minimal form, _requires_
| Matrix to be complex and resource-hungry, thus it seems
| prudent to direct attention and effort towards cultivating
| a multitude of implementations and deployments rather than
| enhancing marketability.
|
| A social argument against features, not the standard
| technical one.
| nimbius wrote:
| emphatically: no. the solution to things that are broken and hard
| is not to abandon them like a petulent child out of frustration.
|
| defeatist bullshit from the article:
|
| >Every long term secret will eventually leak.
|
| is not a valid excuse for abandoning PGP or encrypted email, its
| wishful thinking at best.
|
| >The standard and best answer here is Signal
|
| Signals github releases are sporadic at best and hard to compile
| consistently. its also centralized and has a dependency on google
| services to operate and lacks real transparency about its outages
| or plans to scale/operate, but at least its not too hard for you.
|
| >Hop-by-hop encryption is a good thing: it makes untargeted
| dragnet surveillance harder.
|
| the devices that handle this mail are commercial MTAs and are
| already largely backdoored by three letter agencies. a poison
| prime here, a weak cipher there, or even an opportune warrantless
| surveillance national security letter can sidestep this easily.
| companies will bend to the rule of US law.
|
| >PGP don't make this kind of surveillance any harder, and a
| targeted attacker will still get access to mail servers and
| messages.
|
| this is a tangible, almost white-hot ignorance i cant abide. yes.
| youll get a PGP message. that message is encrypted with an
| asymmetric key and with a strong passphrase will have your
| adversary guessing until the last star falls from the heavens*
| and the statute of limitations for what was once your proud
| nation finally expire. PGP was invented to secure things that
| were transmitted IN PLAINTEXT.
|
| trust was sacrosanct as you were expected to verify and know the
| person to which you were sending...you had keysigning parties and
| you used PGP to talk about important things with people you
| trusted. PGP is still valid and useful to this day.
|
| * quantum computing may make this easier, but if it does, post-
| quantum ciphers are still an option
| [deleted]
| [deleted]
| danShumway wrote:
| > the solution to things that are broken and hard is not to
| abandon them like a petulent child out of frustration.
|
| Are we trying to enable secure E2E encrypted messages, or are
| we trying to enable secure E2E _email_? Because those are two
| different goals.
|
| If we're worried about fixing unencrypted _messages_ , then I
| think it's completely valid to look at systems like Email and
| SMS and to say that they're just not suitable for secure
| conversations, and to advise people to move to other
| platforms/protocols for secure communication that doesn't have
| their flaws.
|
| Signal is currently a good solution for a lot of people. That
| doesn't mean it doesn't have problems, but it has great
| encryption that is almost impossible for an ordinary user to
| accidentally mis-configure. Matrix is also coming into its own
| as a good solution, and while I don't necessarily recommend
| Matrix over Signal if encryption is _absolutely_ important, it
| is very likely going to be a better solution in the future, and
| for casual encryption is a pretty good solution today.
|
| Both Matrix and Signal are easier to use than PGP for ordinary
| users. They are both (frankly) more reliable even for advanced
| users. And with the amount of effort we could put into fixing
| PGP-encrypted emails, we could also make a platform like Matrix
| _really good_ and push really hard for its adoption. Getting
| people to adopt Matrix is going to be easier than getting
| people to adopt encrypted emails. Incidentally Matrix also
| improves upon a number of other centralization and protocol
| problems with email as well, but we 're focusing specifically
| on encryption here.
|
| Sometimes working to a specific goal (encrypting plaintext
| communication) means recognizing when a strategy is bad, and
| pivoting to another strategy that's more pragmatic but that
| accomplishes the same goals. For example, I'm not going to
| waste time trying to "fix" SMS security for 2FA when I can tell
| people to install an Open Source 2FA app instead -- because the
| goal isn't to make email safe, and the goal isn't to make SMS
| safe, the goal is to make _people_ safe. Broadening out our
| strategies and building cleaner, more fundamentally secure
| technologies is part of that.
| bscphil wrote:
| I think you're both right. Email is subpar as a protocol for
| sending secure messages (what you said) and should therefore
| be abandoned as a protocol in favor of something better, and
| also many of the specific arguments made in the article are
| quite weak (what they said).
|
| E.g. PGP doesn't make dragnet surveillance harder?? Unless
| you assume that point-to-point encryption makes it entirely
| impossible (wrong), PGP clearly makes it much harder for
| anyone to read your message.
| [deleted]
| greenyoda wrote:
| Original HN discussion from 2020, for those who are interested:
| https://news.ycombinator.com/item?id=22368888
| daneel_w wrote:
| Browsers also expect plain-text. Is https by the same logic also
| pointless, and should no longer be used?
|
| (I get what the author is trying to say, I'm just reacting to the
| strange way the argument is phrased. I don't think they thought
| their wording and reasoning in that passage through enough.)
| pvg wrote:
| That's not the same logic because http is not a messaging
| protocol and it took many years to get to something resembling
| 'https by default'. Still, not being a messaging protocol https
| and browsers alone are not much better at exchanging end-to-end
| encrypted messages than plaintext since an https server sees
| plaintext content.
| IncRnd wrote:
| > Browsers also expect plain-text. Is https by the same logic
| also pointless, and should no longer be used?
|
| > (I get what the author is trying to say, I'm just reacting to
| the strange way the argument is phrased. I don't think they
| thought their wording and reasoning in that passage through
| enough.)
|
| Your question explicitely ignores the argument that was made
| and pretends a point to point protocol operates similarly to a
| store and forward protocol.
| daneel_w wrote:
| Your comment explicitly ignores the larger part within
| parentheses and continues with a false statement and a
| baseless assumption.
| IncRnd wrote:
| That's disingenous. I quoted the entire part within
| parenthesis, and pointed out what part of the stated
| argument from the article was being ignored.
|
| The issue is not that email or browsers can be configured
| to accept plain-text. What you incorrectly equate is two
| different protocol mechanisms, but you are focusing on the
| types of traffic.
| baybal2 wrote:
| > Browsers also expect plain-text. Is https by the same logic
| also pointless, and should no longer be used?
|
| > I'm just reacting to the strange way the argument is phrased.
|
| It's made so in a manner to provoke a lot of loud noises to
| make it to spread, and resonate across the blogosphere more
| than the original lacking substance message ever could. A
| publicity stunt.
|
| It's a self-promotion tactic - saying something outrageous
| often earns more notoriety for somebody unable to earn fame
| through virtue.
| Macha wrote:
| And HTTP has solved this with a hodgepodge of solutions like
| HSTS + preloading for producers and HTTPs everywhere/new
| browser settings for users but it has taken years.
|
| I think email could do this, but it require some dominant
| players (probably Google + Microsoft as providers for home +
| business users, or maybe Google/Apple/MS as dominant client
| producers) to participate actively.
| clipradiowallet wrote:
| I disagree with this author's take on PGP. Perhaps the people
| _they_ communicate with reply in plaintext, quoting the
| author...but that 's not my experience. That type of behavior is
| an opsec failure, not a PGP failure.
|
| A tool (like PGP) does not imply a privacy-guaranteed scenario.
| For an analogy, carrying a handgun does not make you James Bond,
| and carrying a lockpick does not make you a locksmith. They are
| just tools, and possessing one of them [like PGP] does not
| intrinsically include the knowledge and ability to use that tool
| properly.
| kuon wrote:
| Signal is suggested, but it requires a mobile phone, which is not
| an option for me.
|
| That's why I use matrix, but I fear it will not catch on enough,
| and email will be the only option people will have to contact me.
| But I somehow agree that encrypting email is not an option as
| there are too much complications to it.
| a-dub wrote:
| one big difference between email and the systems that the author
| suggests is that email is a standard and a protocol, where the
| systems referenced by the author are pretty much single
| implementation systems maintained by a single authority.
|
| some of these authorities have all sorts of structure to prevent
| corruption. passionate people, nonprofit or open governance.
| however, they are still single points of failure, or targets, or
| whatever you'd like to call them.
|
| it seems that after years of pain with poor effectiveness of
| specification or poor verification tools for implementations, it
| has become en vogue for modern cryptosystems to insist on tight
| centralized control of reference implementations to ensure
| correctness. (otherwise known as the apple computer model). while
| this does seem to work in terms of ensuring high quality and
| problem free implementations, it does open up the single point of
| failure issue.
|
| i'd argue that email's replacement must retain email's greatest
| quality: it's an open specification, not a system or
| implementation owned or controlled by a single entity and that
| the true challenge in bringing it to fruition won't be clever
| protocol and cryptographic design (although these will be
| crucial) but also substantial advances in protocol definition and
| implementation verification such that any competent developer can
| implement compatible components and plug them in.
| SV_BubbleTime wrote:
| I agree entirely. Now help me understand something... why have
| signal and telegram and everyone made proprietary formats and
| centralized implementations instead of an open email2.0 that
| they also support immediately?
|
| This isn't my field, so maybe someone has?
| remirk wrote:
| Signal says it's harder to innovate in a federated system.
| [1]
|
| [1] https://signal.org/blog/the-ecosystem-is-moving/
| d110af5ccf wrote:
| Cynically, because they are companies trying to turn a
| profit.
|
| Also many (most?) of the complaints raised in the article
| will be an issue for any federated system. The article is
| arguing _against_ end user control and decentralization. It
| just isn 't upfront about it.
| zaik wrote:
| > for example, it recently turned out to be possible for
| eavesdroppers to decrypt messages without a key
|
| Sadly without reference. Does anyone know more about this?
| sbuk wrote:
| They are referring to https://efail.de/ - works on both PGP and
| S/MIME, which was disclosed just over a year before the article
| was published. The article references this in a link to another
| post a few sentences before the one you quoted.
| megous wrote:
| Processing PGP messages where correctly signed MAC doesn't
| match the ciphertext should not be an option at all. Message
| was tapered with, so MUAs have no business processing it.
|
| So unless the attacker can also produce the correct MAC
| matching the ciphertext, which should not be possible with
| out knowing a private key, I don't see how this can't be
| easily fixed just by checking the ciphertext against the MAC.
| avodonosov wrote:
| LARP security stads for Live Action Role-Playing security?
| zamadatix wrote:
| Text Secure/The Signal Protocol the author praises was basically
| the SMS equivalent of PGP/what they spend the first half of the
| article bashing from all sides. Even in 2021 while it has
| switched from SMS transport for the encrypted streams (mostly
| because it's just a shit transport that cost users more money
| than data at that point anyways) it still allows comingling and
| sending messages as plain SMS instead of over the encrypted
| channel. If used properly Signal solves one or two of the main
| points listed but is just as guilty in the other half. It's also
| been found to be imperfect over time even though it hasn't been
| around as long as PGP.
| bitexploder wrote:
| Pretty sure I have never seen this behavior in Signal or any of
| my group chats in Signal. At least the way me and my peer
| groups use Signal this simply isn't possible as far as I can
| tell.
| klyrs wrote:
| On Android, Signal has an option to become your default SMS
| app. Last I looked, it gave big warnings about the insecurity
| of using that option.
| quicklime wrote:
| > So, for example, it recently turned out to be possible for
| eavesdroppers to decrypt messages without a key, simply by
| tampering with encrypted messages. Most technologists who work
| with PGP don't understand it at a low enough level to see what's
| wrong with it.
|
| This is news to me, but I'll admit I'm one of those technologists
| who doesn't understand it enough. Can anyone point me to more
| info on this?
| doomrobo wrote:
| https://efail.de/
| faeyanpiraat wrote:
| Okay, so PGP is not vulnerable.
| Lammy wrote:
| > Every long term secret will eventually leak.
|
| https://www.youtube.com/watch?v=FUPstXCqyus
|
| "You can't hide secrets from the future with math. You can try,
| but I bet that in the future they laugh at the half-assed schemes
| and algorithms amassed to enforce cryptographs in the past"
| tzs wrote:
| > Metadata is as important as content, and email leaks it
|
| There are a lot of cases where I don't have any reason to care
| about metadata leaks. I've written plenty of reports for example
| where it was no secret that I was writing the report, what it was
| about, about how long it would be, when it would be finished, and
| to whom it was to be delivered.
|
| As far as I can see delivering those reports as encrypted
| attachments to email would be fine.
|
| > Every archived message will eventually leak
|
| My encrypted attachment would be fine with this too. If some
| receiver archives the email the attachment will be encrypted in
| the archive.
| imglorp wrote:
| Yours is a rare usecase. The metadata is bad for two reasons.
|
| First, simply knowing who mailed whom and when, the powerful
| adversary can merely visit all participants and urge them to
| divulge the key and contents. If the adversary didn't know the
| participants beforehand, they do after seeing the helpful
| metadata.
|
| Second, even failing to read the mail, the powerful adversary
| can still apply guilt by association, so merely being on the
| email is enough to attract their attention.
| TillE wrote:
| I use PGP email for business communication. It's absolutely
| no secret that a business relationship exists between us,
| merely the content is sensitive.
|
| Obviously it's a problem for like, whistleblowers, but that's
| not most people.
| opan wrote:
| I was hoping this was recommending against protonmail and
| tutanota rather than recommending against PGP.
| intothemild wrote:
| Same. I thought it was going to be a "don't use some commercial
| encrypted email. Roll your own" kind of arguments.
| snotrockets wrote:
| I think it also argues against commercial encrypted email.
|
| But any complex enough system, you want it to run by folks
| with some expertise. Greater chance to have providers hire
| capable people than you being one (simply matter of size)
| lucideer wrote:
| This is a great article and I agree with the overall premise and
| ~90% of the individual points made.
|
| But.
|
| > _If messages can be sent in plaintext, they will be sent in
| plaintext._
|
| This format is such a common line of attack in critiques of
| technology that I think it needs a new logical fallacy coined to
| describe it. I've seen it used as the primary basis for entire "x
| considered harmful" essays (thankfully not the case here as the
| rest of the bullet points more than hold up without it).
|
| The idea that many people will use technology wrong is not an
| argument in itself against that technology. It's essentially an
| argument against UX, which is important (especially in the case
| of security) but while a false sense of security is much worse
| than no security, that doesn't justify advocating against correct
| application of that technology (or against efforts to improve the
| UX of said tech).
|
| As mentioned the point here is moot given encrypted email's other
| larger failings, but without them this point simply wouldn't
| stand.
| AussieWog93 wrote:
| >The idea that many people will use technology wrong is not an
| argument in itself against that technology.
|
| It absolutely is. Look at the shitshow that is Bluetooth. A
| good standard should be easy to implement properly.
| ufmace wrote:
| I think the serious issue around this would be not so much that
| a person in a secure email conversation can easily send a
| plaintext email, but that a person who does that could also
| easily include a plaintext copy of the entire rest of the
| formerly-secure conversation through automatic quotation.
| JumpCrisscross wrote:
| > _that many people will use technology wrong is not an
| argument in itself against that technology_
|
| Author makes this argument best when they say PGP leaves emails
| "at the mercy of the least secure person they've sent them to."
|
| You can have the best UX gating your PGP emails. But if you
| send them to me, and I have the option of replying on
| plaintext, there is a non-zero chance that I will eventually
| respond in plaintext. The blast radius of that compromise is
| the entire message thread. If what you're communicating about
| requires actual security, that is an unacceptable risk. If what
| you're communicating about doesn't, it's fine. Herego, it's a
| bad solution for secure messaging.
| jabbany wrote:
| Lacking any protocol changes in the near term, is the best
| (portable and somewhat secure) approach for an average person to
| just put sensitive stuff in an encrypted zip file or
| something...?
| approxim8ion wrote:
| Provided it is AES encryption, yeah it's not bad.
|
| For storage, I would recommend Veracrypt though since it's more
| specifically designed for this purpose.
| shawnz wrote:
| What about for communicating with darknet vendors, where PGP
| is the established standard?
| whartung wrote:
| So, then, what are the issues with S/MIME?
|
| Thunderbird supports it. Apple Mail supports it. Gmail does (but
| not for free accounts).
|
| It's the core of the DIRECT Messaging protocol we use in
| healthcare. There are millions of messages being sent via DIRECT
| every week.
|
| Mind, DIRECT is more than just S/MIME, it's a just a component of
| it (there's an entire trust system involved as well).
|
| I appreciate the issue with leakage, which are very real, mostly
| due to the UI of the systems. I honestly don't know how well the
| programs like Apple Mail et al keep you from shooting yourself in
| the foot with S/MIME encrypted mail (such as "You're about to
| forward an encrypted email in the clear, are you sure you want to
| do that?").
|
| The post bags on PGP, so I'm just curious if there are weaknesses
| inbuilt to S/MIME.
| normaler wrote:
| What I like most about PGP is message signing. A signed message
| can prove to the receiving party that it was really me who send
| the message. Also it does not require any setup on the receiving
| end.
| snotrockets wrote:
| In practice, I found future deniability to be more useful. PGP
| was never designed for a real security scenario, and it shows.
| burrows wrote:
| > Ordinary people don't exchange email messages that any powerful
| adversary would bother to read
|
| AFAIK Google (via GMail) reads emails from/to "normal people". Is
| Google not a "powerful adversary"?
| deadalus wrote:
| We need additional research, funding and development into the
| Darkmail (DMTP/DMAP) protocols.
|
| https://darkmail.info/
| lend000 wrote:
| And frankly a new name, if you want it to go anywhere.
|
| A lot easier for politicians to ban "Darkmail" than
| SecureMail/AdvancedMail or something of that sort.
| dylan604 wrote:
| SmartMail vs regular mail being DumbMail. Much easier to get
| people onbaord
| [deleted]
| theamk wrote:
| I don't think better email will help with the problems
| described in this essay. Two of the big problems the essay
| claims are forever archives and ease of forwarding to regular,
| non-encrypted email. From what I know of darkmail, it is not
| going to help with either of those.
| R0b0t1 wrote:
| Unsure that is a sound direction. https://www.mixminion.net/ is
| defunct but it and its predecessor paid close attention to
| metadata removal.
|
| It's basically Tor but with variable, high latency. It never
| took off, you need people to buy in and run nodes.
| gerikson wrote:
| There doesn't seem to have been any activity around that space
| since ~2015 at least according to Wikipedia:
| https://en.wikipedia.org/wiki/Dark_Mail_Alliance
| unethical_ban wrote:
| The author's tone is really grating; they insult anyone who
| disagrees with them. I think they're rude and need to learn how
| to write better. "LARP LARP LARP". How shitty.
|
| Essentially, their argument is: Metadata isn't protected, and
| mail gets archived when perhaps you want messages to disappear.
| If you're writing messages on any system with the assumption they
| aren't stored somewhere indefinitely, you're already failing,
| buckaroo.
___________________________________________________________________
(page generated 2021-09-11 23:00 UTC)