So what should we use for public/private asymmetric encryption then?
The PGP Problem
141–150 of 369 posts
Re: The PGP Problem
#142With the rapid churn of various chat clients it's hard to get something to stick, and I attempted to settle on XMPP+OMEMO (or OTR), since it's a protocol, not an "app" (eww). Not a single person I know still uses XMPP, and it's easier to just tell people "Download Signal". However, that requires a phone number, and is useless on a desktop if your phone's off. Despite being Free Software, it's fairly locked down. Secu…
Signal Desktop has never required your phone to be on. It's completely independent once set up (apart from the occasional contact list sync). It has been this way since the first version of Signal Desktop. You're probably thinking of WhatsApp Web, which works the way you describe. I've seen this incorrect information spread on HN too many times, and I'm not sure how so many people came to think that. It's been 100% wrong from the beginning.
Re: The PGP Problem
#143Whent talking about alternatives, Signal and WhatsApp get mentioned because they're easy to use. They are. Signal is pretty secure. WhatsApp probably is as well but we can't be sure. That is, until it isn't anymore. WhatsApp already has a key extraction protocol built right in for its Web interface. Signal has a web (Electron) interface as well, and a shitty one at that, where the messages also get decrypted. For Wha…
I think the real problem is that nobody has ever created a decent PKI, and I doubt a sufficiently secure PKI is even possible. CAs require you to trust people that aren’t supposed to be party to the communication (trust both not to be hostile, and not to be insecure themselves). All other forms of PKI offer entirely impractical authentication mechanisms. With signal and the like, your options are 1) Verify keys by be…
I would regard the Web PKI as the only decent global public PKI, but sure, whatever.
You don't seem to have understood what's going on in Signal. Ordinary key rotations, which happen automatically, do not change the verified status. What can happen is that another participant changes phone or wipes it, and so obviously trust can't survive that change.
The problem isn't that somebody else may know the correct key, the Double Ratchet takes care of that. The problem is that a Man-in-the-middle is possible. Alice thinks Mallory is Bob, and Bob thinks Mallory is Alice. Mallory can pass messages back and forth seamlessly, reading everything. Only actually verifying can prevent this.
You don't verify the encryption keys, that's useless because those change constantly, the verification compares the long term identity value ("Safety Number") for the conversation between two parties, which will be distinct for every such conversation. Mallory can't fake this, so if Alice and Bob do an in person verification step Mallory can't be in their conversation.
Re: The PGP Problem
#144Earlier quoted context omitted.
> I think all use cases boil down to 'encrypt and/or sign a file' for one of the stages. In the article, 'talking to people', 'sending files', 'encrypting backups' are all really just 'encrypt/sign a file' followed by transmission. But they aren't the same thing. That's the whole point the article is making. Yes, if all you have is a tool that does "encrypt+sign a file", then all crypto problems will look like "encry…
For securely talking to people, often you may want non-repudiation, which is the exact opposite of deniability and anonymity. There are very different, incompatible needs for slightly different usecases.
Signal -- and all other OTR-like protocols -- have deniability (or if you prefer it has repudiation rather than non-repudiation). Neither conversation participant can prove to a third party that the other party said something in a conversation. Moxie wrote a blog post about this in 2013[1].
The only circumstance in which you want non-repudiation is if you are really sure that you are okay with the recipient of your message later posting cryptographic proof that you said something in a chat with them. I bet most people (if you asked them) would effectively never want that "feature" for private chats.
Re: The PGP Problem
#145Earlier quoted context omitted.
You can violate the wishes of the other party by taking a screenshot or, in the extreme, a photo of the screen. You're only preventing the very lazy/unmotivated from retaining messages.
Correct, screenshots are a viable attack against both closed and open source platforms. Preventing casual retention is the best you can hope for, and is a worthy goal regardless that it does not result in the perfection of a Faraday cage’d clean room
So, your threat model includes MITM servers, but not cameras? It seems a little silly to worry about the MITM problem when you can simply snap a photo already.
Re: The PGP Problem
#146I would suggest using restic over TarSnap for encrypted backups -- it gives you more flexibility with where your backups will be stored since TarSnap is pretty integrated with Colin Percival's online service and is also unfortunately not free software. But it's also an as-simple-as-possible cryptosystem. Filippo did a quick lookthrough and said that it seemed sane from a crypto perspective[1]. [1]: https://blog.filip…
Any opinions about rclone?
It seems to be fine for my mediocre backup needs
Re: The PGP Problem
#147Earlier quoted context omitted.
Re: magic-wormhole's 16 bits: I don't think you should be worried about that, because SPAKE2 will give you proof positive if the attacker attempts to guess. Are you saying 2*-16 success isn't good enough?
> Are you saying 2 -16 success isn't good enough? I really don't think it is, because it might be worthwhile for a particular sort of attacker, say one who runs the default rendezvous server: observe global activity, attempt to MitM every connexion for 30 seconds, then write up a spurious blog post about a 'network issue' or 'bug' or whatever which caused a brief outage. N:2^16 is okay* against targeted attacks, most…
(magic-wormhole author here)
It's probably worth pointing out that the 2^-16 chance is per invocation of the protocol.. it's not an offline attack. So you'd have to be reeeealy patient to run it enough times to give the attacker a decent chance of success.
The best attack I can think of would be for me (or someone who's camped out on my rendezvous server) to make an MitM attempt on like one out of every 100 connections. Slow enough to avoid detection, but every once in a while maybe you get a success. Of course you don't get much control over whose connection you break (if you did, you'd be back in the detectable category again).
FWIW, some numbers. The rendezvous server that I run gets reports from clients about the success/failure of the key establishment phase. Over the last year, there were 85k sessions, of which 74% resulted in success, 22% in timeouts, and 2.5% in bad key-confirmation messages (meaning either a failed attack, or someone typoed the code). So in the worst case where every one of that last category was really a failed attack, there's roughly a 2130/2^16 = 3% chance that someone managed a single successful attack last year.
But I tried to make it easy to choose a different tradeoff. `alias wormhole-send=wormhole send --code-length=4` gets you to 2^-32 and gives codes like "4-absurd-almighty-aimless-amulet", which doesn't look too much harder to transcribe.
Re: The PGP Problem
#148I would suggest using restic over TarSnap for encrypted backups -- it gives you more flexibility with where your backups will be stored since TarSnap is pretty integrated with Colin Percival's online service and is also unfortunately not free software. But it's also an as-simple-as-possible cryptosystem. Filippo did a quick lookthrough and said that it seemed sane from a crypto perspective[1]. [1]: https://blog.filip…
Any opinions about rclone? It seems to be fine for my mediocre backup needs
rclone is fine (in fact I use rclone with restic to synchronise my restic backup repository on BackBlaze B2) but it doesn't encrypt or deduplicate your backups -- it's just a synchronisation tool like rsync.
Re: The PGP Problem
#149Earlier quoted context omitted.
In modern practice, email is sent over TLS sockets already. Any good email client should prohibit you from using SMTP, POP, or IMAP with TLS, and for the past few years, even the MX-MX transfers in the backend have started to become protected (albeit mostly opportunistically at this point, I believe) with TLS. So the only people who can read email are you, your counterparty, your ESP, and your counterparty's ESP, ass…
This is an excellent explanation overall, I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm. Since this would have to be a mitm of e.g. Gmail it's not trivial by any means, but neither is it completely out of reach (see for example the periodic rerouting of the internet caused by odd BGP advertisements). One further note is that you can know post-hoc…
This is often explained in a needlessly confusing way.
STARTTLS isn't a problem, the problem is if a user checks a box (or moral equivalent) saying it's optional obviously bad guys will opt for "No". If your client is set to _require_ STARTTLS, then an adversary blocking STARTTLS has the same effect as if they just blocked the IP address of the mail server, you get an error and it doesn't work.
There's no reason to use "opportunistic" STARTTLS for your own mail servers (ie IMAP or SMTP to an outbound relay). Nobody should be configuring their own gear, or corporate gear, to just let somebody else decide whether it uses encryption.
Opportunistic encryption still has a place in server-to-server SMTP relaying, but if you're choosing options like "if available" in a desktop/phone mail client that's wrong.
Re: The PGP Problem
#150Earlier quoted context omitted.
Yeah-ish, but what I mean is an actual set of different tools (so, not one-size-fits-all) but all part of the same suite, rather than a bunch of different implementations of mostly the same idea — i.e., *BSD rather than Linux. One of my numerous hobby projects is exactly that, but … I simply don't have enough Round Tuits.
OK, so you're saying something like: magic send magic receive magic encrypt magic sign ... that ideally all have NaCl at the base but are otherwise one binary that you have to remember? The tricky one there is probably chat.
Incidentally, the real goal of magic-wormhole is to provide the initial secure introduction between two people's communication tools. Get your public key into my address book safely, and then all those other modes have something to work from. Keybase.io is kinda in the same direction except they're binding key material to de facto identity services (github, twitter, etc) rather than pairwise introduction.