Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Opmsg – A GPG Alternative

github.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Opmsg – A GPG Alternative

#91

Post by chacha2 »

tptacek wrote: post #51
DarkWiiPlayer wrote: post #4

Earlier quoted context omitted.

If you know what you're doing, PGP can improve security. The real problem is that, the moment you're sending information to someone, you're giving that information away, out of your control. If I understand it correctly, all the above points seem to address mostly the technical aspect, that someone who means well may too easily leak previously encrypted information out of ignorance. A possible counter argument could…

No. Secure Messengers are designed to be hard to use unsafely. Nobody accidentally sends plaintext to a counterpart with Signal, because there's no feature in Signal that does that.

Strange example. Signal does support unencrypted sms which would make it easy for someone to forward a previously encrypted message as plain text.

Re: Opmsg – A GPG Alternative

#92

Post by tptacek »

bscphil wrote: post #89
tptacek wrote: post #85

Earlier quoted context omitted.

Why do you want asymmetric file encryption? * If it's to send messages to people, you want a forward-secure ratcheting secure messenger (regardless of your message lengths or the duration of conversations). * If it's to back things up, you want a secure backup system like Tarsnap, and even if you don't, your system's sector-level symmetric encryption also does this. Asymmetric encryption is relatively high-risk! You…

Thank you for taking the time to give a thoughtful response, in this and your other comment. Here is what I take to be the use case - it concerns whistleblowers, who have among the most serious real world security needs. I'm thinking of sending files to people. Large dumps of documents and other data from several GB to several TB. Imagine that any of the following apply: * The data is in a secure location and can onl…

I guess what I don't see here is the case where (1) you can safely upload a .PGP file to Google Drive (or anywhere across the organization's network perimeter) without immediately triggering an investigation (PGP files being particularly easy to spot) and (2) you can't use Signal and Signal's built-in file transfer.

Re: Opmsg – A GPG Alternative

#93

Post by cwyers »

chacha2 wrote: post #91
tptacek wrote: post #51

Earlier quoted context omitted.

No. Secure Messengers are designed to be hard to use unsafely. Nobody accidentally sends plaintext to a counterpart with Signal, because there's no feature in Signal that does that.

Strange example. Signal does support unencrypted sms which would make it easy for someone to forward a previously encrypted message as plain text.

If you can't trust the recipient, there's nothing you can do. The point isn't to protect yourself from an untrustworthy recipient, it's to protect yourself from inadvertent disclosure.

Re: Opmsg – A GPG Alternative

#94

Post by tptacek »

AnaniasAnanas wrote: post #83
Mediterraneo10 wrote: post #68

Earlier quoted context omitted.

Doesn’t To and From metadata leak on encrypted-message apps, too? WhatsApp, Telegram and Signal use mobile phone numbers as identifiers. In many countries now, you cannot buy a SIM card unless you show the vendor proof of identity, a copy of which is then provided to the state for its records. Therefore, any state actor that can put pressure on those encrypted-messaging services can reveal which phone numbers are tal…

> WhatsApp, Telegram and Signal use mobile phone numbers as identifiers One notable exception (which as I understand is tptacek-approved) is Wire, which only needs an email.

I concede that Wire has essentially lifted the core crypto bones from Signal. But metadata collection is a clear distinction between Signal and Wire, so if what 'jcranmer is saying about email metadata is persuasive to you, your choice between Wire and Signal should be clear: use Signal, not Wire.

Re: Opmsg – A GPG Alternative

#95

Post by someguydave »

tptacek wrote: post #88
tptacek wrote: post #81

Earlier quoted context omitted.

I'm sorry for being snippy this morning. Read the /r/linux response to the PGP post to get an idea of what my baseline assumptions are about technologist disengaged with cryptography who have strong opinions about which cryptosystems people should use. But I shouldn't be projecting that on random people on HN, and I apologize for doing that to you. My take is this (unless otherwise stated, "you" is the rhetorical "yo…

By the way: why Signal/Wire/WhatsApp? (That being your earlier question): * End-to-end encrypted by default, to the point that it's difficult to send plaintext. * Radically simplified UX that doesn't meaningfully involve key management, which lawyers and activists cannot handle. * By-default support for message log grooming / "disappearing messages". * Modern cryptographic primitives. * Extensively vetted cryptograph…

I can see the case for a central server w.r.t. matching conversation pairs.

My objection is this: Signal (and others) seem to only support smartphone clients well. There's a genuine use-case for a more advanced user who wants to control every aspect of the platform he is using, including exactly when and what packets are being sent to whom. More importantly, the user may not want to process data on a von Neumann machine designed & administered by Apple/Google/Samsung. It would be nice if there were a supported command line interface, where the plaintext & encryption aspect of the protocol were handled separately from the ciphertext network traffic.

Re: Opmsg – A GPG Alternative

#96

Post by claudius »

zucker42 wrote: post #78
claudius wrote: post #26

Earlier quoted context omitted.

> It relies on existing mail standards This is a feature, not a bug. Nobody actually wants to rely on a single entity (for or non-profit) for their communication. Nobody wants to be stuck in crappy Electron and mobile clients. I had some hope that Matrix may be able to alleviate those concerns and provide a modern, federated chat solutions. Unfortunately their quality of implementation seems to be rather low with slo…

Have you used Riot on mobile recently? Sure it's not perfect, but it consistently outperforms FB Messenger on my very poor phone.

No, mostly because the Matrix homeserver still needs ridiculous amounts of memory. Apparently 1GB if you want to join one of the more crowded channels – what for could a chat server actually use 1GB of memory?! That's a billion characters you can store in there, even at hundreds of messages per second (which I suppose would make the channel unusable anyways?) you don't get to a billion characters very quickly.

Re: Opmsg – A GPG Alternative

#97

Post by lifeisstillgood »

tptacek wrote: post #53
lifeisstillgood wrote: post #9

Earlier quoted context omitted.

My understanding is quite different. Email is inherently insecure and there is nothing you can do about it. PGP is insecure for everything else as well The Latacora article was eye-opening for me on the email problem - quite simply if I send an encrypted mail to a friend / collegue - which I intend them to read, and they read it and quote it to someone else in plain text then that's it - my plaintext and my cipher ar…

Wait, what? No. Leaking plaintext doesn't reveal your long term key. I definitely didn't write that.

I finally got that when someone pointed out that the long term key is not used to encrypt the mail content - i made that leap incorrectly and went from there.

I made the change down thread - was too late to edit the original - and i hope clearly pointed out that your article did not say that

It takes me several run ups to understand most security issues and I got all excited before having my coffee that day.

Re: Opmsg – A GPG Alternative

#98

Post by throw0101a »

AnaniasAnanas wrote: post #86
throw0101a wrote: post #69

Earlier quoted context omitted.

> There are still some differences. NIST provides some curves and doesn't explain much about them. You can read up how DJB choose the curves. It's a very neat and tidy process that is easy to follow and very reasonable. You're not wrong, but to paraphrase a famous quotation: No body every got fired for following Suite B. AES, SHA-2, and the NIST curves are approved for government crypto, and are also probably in many…

Nobody was ever fired for using DJB. Meanwhile I would gladly fire someone for using AES128 or the NSA-sponsored curves, despite being in Suite B.

> Meanwhile I would gladly fire someone for using AES128 or the NSA-sponsored curves, despite being in Suite B.

Why? Pointing SSL Labs at my bank, it's what they use (ECDH secp256r1). What does your bank use? Or is there a site that you consider more important than that one?

Would you fire the folks at Let's Encrypt, who only offer certs of RSA and P-{256,384}? Gmail, where they do offer x25519, but where most browsers use secp256r1?

Re: Opmsg – A GPG Alternative

#99

Post by tinus_hn »

masklinn wrote: post #3
cwyers wrote: post #2

I am not qualified to review how it implements forward security, for instance. But this shares a lot of the problems that GPG has. It relies on existing mail standards, so it leaks metadata all over the place, and security can easily be defeated by "accidentally replying without encrypting." It's configurable -- every choice you have to make is a chance to make the wrong one. It implements RSA, which nobody should be…

Indeed, from Latacora's recent "The PGP Problem": > Encrypting Email > Don’t. > Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is f…

Well that settles it. Better do nothing then!

Re: Opmsg – A GPG Alternative

#100

Post by AnaniasAnanas »

throw0101a wrote: post #98
AnaniasAnanas wrote: post #86

Earlier quoted context omitted.

Nobody was ever fired for using DJB. Meanwhile I would gladly fire someone for using AES128 or the NSA-sponsored curves, despite being in Suite B.

> Meanwhile I would gladly fire someone for using AES128 or the NSA-sponsored curves, despite being in Suite B. Why? Pointing SSL Labs at my bank, it's what they use (ECDH secp256r1). What does your bank use? Or is there a site that you consider more important than that one? Would you fire the folks at Let's Encrypt, who only offer certs of RSA and P-{256,384}? Gmail, where they do offer x25519, but where most browse…

Banks are not known for using the best/safest solutions. Just take 4 digit pins and 3DES into account for example.

> who only offer certs of RSA and P-{256,384}?

I am pretty sure that nginx and openssl only recently added support for ed25519 certificates. Although to be honest I don't really like the idea of let's encrypt. The addressing system that tor uses has solved that issue already.

> but where most browsers use secp256r1?

This is an issue. Browser vendors should prioritize the djb algorithms.

Post reply on HN