Hacker News Reader

> This is not about stopping the bad people from encrypting their messages, this is about getting access to what everyone else is saying.

Thank you.

> The encryption part took about a day to build, without me needing to understand any of the maths I was using

You don't need to understand how ciphers work per se, but you do need to understand how to put the building blocks together and think about attacks, e.g. do you ever have the key in memory on your servers.

I love this picture; the data's encrypted, but with a bad mode of operation: https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb....

Well, by forcing the "bad people" into less popular apps they become much easier to identify through other metadata as the popular apps account for the vast majority of the "everyday person" traffic..

I think to get a balanced perspective we should appreciate the dilemma & work done by the govt security people. Their job is to fight the terrorists, pedophiles, forced sex traffickers, and many other "very bad people" - which is easier said than done. In the future WMDs will become cheaper, easier to produce and more powerful, so the issue is becoming more acute. They understandably want better tools to increase their chances of success & reduce likely traumatic failures. They seem to be doing ok with terrorists in the West at the moment, but failing badly with the other categories.

The risk of abuses against everyday civilians are there and I don't have the solutions. But I would presume that the majority of people will trade off a significant reduction to their privacy for a slight increase in physical safety, so that will likely happen. Vastly improving the governance & oversight of the security agencies is one way forward. Otherwise when the next disaster strikes, the security agencies will rapidly make a successful grab for more power.

There is an infinite number of encrypted chat apps that can be built. What is finite is the number of organizations that have a brand strong enough to launch one that becomes popular immediately. What’s also finite is the number of organizations that can get that funding to build popularity slowly (eg Signal). The governments may successfully be able to stomp out those services and just leave the tiny thousand-user apps alone. As soon as one of those becomes popular enough, rinse and repeat the above.

I think this raises the question: will governments eventually ask the Go authors to remove these tools from the language/ecosystem?

“Trivially easy” causes me to raise an eyebrow. Hubris and cryptography don’t mix well. Which libraries are you using?

Given any set of modern libraries encrypting the transporr end-to-end is trivial.

Still hard are verfication processes, for distributing certs/public keys and some secure memory handling if you want to protect the unencrypted message on the local machine in some way.

yeah, making sure the secret keys stay secret is harder than plumbing the encryption calls together

It isn't hubris. I've written a toy E2E encrypted messaging as well. I haven't had to write a single line of actual crypto - libraries like libsodium ensure I just have to tell it the kind of security I want, and it handles all the dirty work for me.

The hard part then shifts to the logic:

1. Ensuring the protocol doesn't allow accidentally leaking the data to an adversary somehow.

2. Ensuring the data is secured on the endpoints (the phone) - making sure the keys are secure and can't leak, and making sure the data is only decrypted when needed and for the time period it's needed.

Not that this is easy to get right either. But with crypto being an essentially "solved" problem, we get to spend more time ensuring those bits work properly.

Wouldn't you say the hard part is getting someone else's key reliably?

Yes, identity verification is certainly the hard part of setup for any secure communications system. But in modern systems the cute thing is that this only really matters at the moment it happens. It's a big problem if there is an active adversary attacking you when you try to communicate, but a moment later it doesn't matter at all.

Many governments are reluctant to just attack their own citizens 24/7. It's a bit too blatant. So they're obliged to try to attack most communications retrospectively.

Suppose I am an intelligence analyst and I just figured out that murderous terrorist Jenny Smith sent instructions for planting a bomb to another member of her cell on Saturday at 11:42:05 precisely using let's say Signal. I have a copy of the IP packets sending the instructions. I have essentially unlimited resources to dedicate to the task. And Jenny didn't even have a reliable way to assure herself she was sending the instructions to the right person. Surely I can do something? Right? Nope. I'm screwed. Since I wasn't actively attacking Jenny back when it happened, she got the right keys, and I can no more decrypt these IP packets now than I could travel back in time and stop her sending them.

I think there are a bunch of scenarios in the real world that complicate this (we spent a lot of time working around these at Keybase):

People get new phones all the time. If I've done a secure key exchange with you, and then you get a new phone, how do I know you're the same person after? Do you move key material between phones? Or do you get your old phone to sign the public key of the new phone?

What if I got a new phone because I lost my previous phone? Do I just repeat the handshake from scratch with everyone? This is very important, because people losing their phone is pretty common. If there's an "it looks like so-and-so got a new phone" dialog, any user with enough friends will see it pretty frequently. People will get used to tapping "ok". And then an active adversary can attack them, by pretending to be a new phone.

In the other direction, say I do use my old phone to sign my new phone's key, and then later my old phone is stolen. How do I tell people that my old phone isn't me anymore? Do I publish another signature of some kind? How do I make sure that all my contacts receive that signature? Does this part require trusting the server to send messages faithfully?

I was mostly thinking about the generic out-of-box capabilities you'd get these days, which include Forward Secrecy, rather than compromises made in the name of usability for software like Keybase.

But since you're a Keybase person let's consider Keybase's compromises in particular, do they mean Jenny's bomb gets found? What can I determine: Who Jenny sent the message to? The contents of the message? Don't you consider that a pretty bad screw-up considering what your users expect?

I'm not super keen on your chosen example of helping terrorists, since some folks (like my dear AG) act like that's all crypto is good for, and sometimes these things get taken out of context. But that said, I'll run with it.

> do they mean Jenny's bomb gets found?

No, private messages are private like you expect.

> What can I determine: Who Jenny sent the message to?

Yes, as with all end-to-end encrypted chat apps, the server knows who is talking to whom, because it's responsible for routing. Even if you consider a message service based on Tor, an attacker who controls the entire network can often figure things out by looking at sender and receiver timing.

> The contents of the message?

No, but you can see the length. Again this is true of all all end-to-end encrypted chat apps.

> Don't you consider that a pretty bad screw-up considering what your users expect?

You might be misunderstanding how Keybase works. You're right that Keybase messages are not forward-secret by default. (Forward secrecy is available, however. Keybase calls these "exploding messages".) In part, you could call this a usability decision. But it's also related to the fact that Keybase lets you have multiple devices on your account. When you sign on a new device, it would be kind of weird to be in all these conversations where you have no view of the message history. On one device, you can scroll back, but on the other device, you can't? Most users wouldn't understand why, and they'd consider it broken. (You could implement a history transfer protocol, but it's easy to imagine how you could wind up in a partially-transferred state by losing WiFi at the wrong time. Also there's no way for adding a new device from a paper key to transfer chat history.)

Forward secrecy also gets more complicated when you consider multiple devices. The typical Signal ratchet setup is designed for each user having a single device. You can treat multiple devices as separate participants in a conversation, but that doesn't work well if one of my devices is "in the drawer". If I never turn on that old laptop for months at a time, do we keep encrypting every message for its current key? Do we still have forward secrecy in that case? At what point do we evict it from the conversation? Exploding messages are a better solution for this problem, but they're also not a great default for most users. (For typical messages, you generally want them to still be there if I don't read them for X hours.)

Anyway, enough about forward secrecy. You were asking about security. Keybase solves the key distribution problem in a totally different way from other end-to-end apps, by having you use social media to prove you own your key. There is no TOFU. And because there is no TOFU, there are also no routine dialogs telling the user "oops, this person lost their phone, we need to renegotiate keys." Instead, a full account reset is a big deal, and it breaks lots of things. As it should! Otherwise, adversaries in the middle can pretend to be me and act like I've reset my account. All end-to-end apps are vulnerable to this absolutely practical attack, except (to my knowledge) Keybase.

Forgive the wall of text :)

> I'm not super keen on your chosen example of helping terrorists

It's a motivating example. You don't want to help Jenny and neither do I, but if the technology actually works that shouldn't matter, we have no discretion. If we have discretion in protecting Jenny, you can be assured that the governments sending these open letters will lean on that discretion for everybody, not just Jenny.

> No, private messages are private like you expect.

That's very confident considering the later caveats you introduce.

> Even if you consider a message service based on Tor, an attacker who controls the entire network can often figure things out by looking at sender and receiver timing.

Do you think humans (this is a service for humans) need sub-second delivery accuracy? No? So, why would you ensure this when as you realise this just helps an adversary? By throwing away everything better than second precision you make essentially no difference to the user experience but you mix everything up into 3600 events per hour that all have lots of indistinguishable participants.

> No, but you can see the length. Again this is true of all all end-to-end encrypted chat apps.

Again this is a service for humans. You can _choose_ to send exactly 1326 bytes over the wire out of some desire for brevity, but for humans padding everything to the nearest whole packet (~1500 bytes) greatly improves their privacy at essentially zero cost.

> If I never turn on that old laptop for months at a time, do we keep encrypting every message for its current key?

Well do you? My understanding is that in the Keybase design the answer is "Yes" and so most likely your confident "No" earlier will be wrong. Somewhere I can probably find keys that let me read Jenny's message and I am motivated to search for them.

> Exploding messages are a better solution for this problem, but they're also not a great default for most users.

Keybase's exploding messages are greatly fictionalized for the user experience. It reminds me of Mission Impossible. What the user sees is the message vanish instantly after a short timer, like a tape seemingly consumed in flame before their eyes on the TV show

https://www.youtube.com/watch?v=8VQfhyDP6vw

The reality is more like making Mission Impossible, the visual effect is achieved in a separate shot and pasted on, you could actually trivially recover the message for some time after it "explodes" across a variety of devices which each have their own keys. A month or two later the message is gone largely because nobody cares any more, not because it really "exploded" as depicted after just a few minutes.

> Keybase solves the key distribution problem in a totally different way from other end-to-end apps, by having you use social media to prove you own your key.

So, given my involvement with the Ten Blessed Methods (the means by which a Certificate Authority decides that ycombinator.com is really ycombinator.com in the Web PKI) you might expect me to be very sympathetic to this approach. But I'm not.

It ends up as a very woolly "Web-of-trust" type system and we know humans don't reason about those well. The technical argument may be "You can be confident that this Keybase account is controlled by someone who also controls the oconnor663 account on Hacker News or by someone who controls Hacker News itself or by someone at Keybase" but the human understanding is invariably just "This is Jack O'Connor" which is... misleading if I'm generous.

Forcing humans to do in person verification if they care, and allowing them to just not care is, in my not at all humble opinion, a better choice. I am very confident that messages from Al are really from Al having verified that our Signal numbers match, and not in the least bit confident that messages saying they're from Carol are really from Carol, and all the clever work at Keybase can't make a dent in that anyway because Carol leaves her phone unlocked on her desk.

> Forgive the wall of text

I'm the very last person who should criticise anybody on that front.

> you could actually trivially recover the message for some time after it "explodes" across a variety of devices which each have their own keys. A month or two later the message is gone largely because nobody cares any more, not because it really "exploded" as depicted after just a few minutes.

This is worth clarifying because it's complicated.

What happens when the "fuse burns down" is that the server and all running devices delete the message immediately. This matches what the user thinks is happening, and it's what really matters in the vast majority of real world use cases.

Now, one of the recipient devices could choose not to delete the message, and there's nothing we can do about that. They could be running a modified version of Keybase. Or the user could just photograph the message. The exploding messages in small Keybase groups are in fact cryptographically repudiable, but almost no one in the real world knows what that means or cares about it.

More likely, the server itself could be compromised. It might be running evil code, or have a bug, or perhaps all its databases just get vacuumed up by a few different nation states. Who knows. So suppose the server side messages never get deleted. What's next? Like normal messages, exploding messages are end-to-end encrypted, so if the adversary never gets their hands on a recipient device, they can't read anything. Also like normal messages, if the adversary had a compromised recipient device before the message was sent, they can read everything, and there's nothing we can do about that. So the question is, what is their window to compromise a device after the message is sent?

This is where the ephemeral key schedule is relevant. An active device issues a new ephemeral key each day. Each ephemeral key is retained for a week after its successor key is issued. (So if a device goes offline for a few days, its current ephemeral key will have its lifetime extended by a similar amount.) So a typical active devices has an array of live ephemeral keys, with remaining lifetimes of 7 days, 6 days, 5 days... If I send an exploding message with a lifetime less than 1 day, I will use an ephemeral key with a day or so remaining. For a longer message lifetime, I will use one of the longer-lived keys. (In fact there is a hierarchy of user ephemeral keys and team ephemeral keys, but the idea is the same.)

If a device never generates a new ephemeral key for (currently as far as I know) 1.25 months, its active key expires with no replacement, and it no longer receives exploding messages at all. Thus each mothballed device exposes a limited window of exploding messages, and only if the adversary physically gets their hands on that specific device. If the device is ever legitimately reactivated, it will immediately delete all the expired keys.

I'm not sure what to make of your summary that "a month or two later the message is gone largely because nobody cares any more." Do you have any questions about the design I just described above?

> You can be confident that this Keybase account is controlled by someone who also controls the oconnor663 account on Hacker News or by someone who controls Hacker News itself or by someone at Keybase

Keybase cannot lie about about who controls oconnor663 on Hacker News, because each Keybase client independently fetches the proof from my profile. This is the whole point of the Keybase security model.

Now the Hacker News admins could post a proof as me, and maybe create some bogus 0c0nn0r663 account on Keybase to try to impersonate me there. But they can't replicate my GitHub proof, or my proof on jacko.io. Perhaps they register 0c0nn0r663 on GitHub too, and buy the jack0.io domain, and post lookalike proofs there. But at that point, if we're assuming that other users can be tricked by lookalikes, does it even matter that they compromised my real Hacker News account?

The current state of the art in this space is Signal, which offers participant consistency, destination validation, forward secrecy, post-compromise security, causality preservation, message unlinkability, message repudiation, participation repudiation, asynchronicity, speaker consistency, out-of-order resilience, dropped message resilience, computational equality, trust equality, subgroup messaging, and contractible and expandable group membership. [1]

Which of these properties do you get out-of-the-box from Go’s standard library and/or libsodium? Almost none of them. The gap is enormous and not at all “trivial”.

So, yes, it is hubris for OP to state that they can build a competitive protocol in “about a day”, “without me needing to understand any of the maths”, by simply stringing together Go standard library calls. I think the engineers and cryptographers who work on Signal, Keybase, etc would have a good chuckle at the suggestion that this stuff is “pretty simple and hard to get wrong”.

[1] https://en.m.wikipedia.org/wiki/Signal_Protocol#Properties

few things:

I'm not building a competitor to Signal, so most (if not all) of that list is completely irrelevant for my application.

I'm also totally paranoid that I have, indeed, got some of this wrong. I'm trying to find people I can trust who know more about this than I do so they can look at my code and test my application. So far everyone I've approached to look at it has said it looks OK. I've come to accept that I'll never "know" completely for sure that this is bombproof, because there just isn't any single person out there that can verify that this is bombproof.

And, as Bruce Schneider puts it; security is not absolute, it's about delaying the bad people for long enough so you can catch them. Bank vaults are rated in hours (the number of hours that a competent attacker will need to get into the vault). No software implementation is 100% secure, but it can be secure enough to be useful.

But building a basic protocol out of Go's standard library building blocks is pretty simple, and hard to get wrong, for given values of "simple" and "wrong". These aren't absolute, and depending on your application, may be quite low.

Before someone becomes a terrorist they are recruited and cultivated. It might be trivial for existing contacts to install Signal, it's not trivial for people to recruit when they put up extra barriers to communication. I don't know if this is going to matter in the long run, since one way or another the NSA is going to get in, but in the short run it will damage our ability to track how extremism is spreading.

> since one way or another the NSA is going to get in

This is not even remotely a foregone conclusion.

> but in the short run it will damage our ability to track how extremism is spreading

If the only way the intelligence community can "track how extremism is spreading" is by violating the privacy of everyone on the planet, then so be it. Liberty trumps security.

You seem to have read the GP's comment very differently than me.

I took it to mean that using encrypted apps could potentially reduce the spread of extremism, by simple virtue of the fact that it's a barrier to entry?

Yes I think we did. I reread it and I think the "it" that will damage our ability to track extremism is E2EE. Based on that interpretation I took that the GP was against E2EE for this reason and felt that allowing the government access to these communications was ok if it was for the right reasons. I could definitely be wrong, though!