4 ms·

Shameless self-promotion, as this article is one of several that inspired me to work on this. I have been secretly working for several years on a drop-in iOS t

Shameless self-promotion, as this article is one of several that inspired me to work on this. I have been secretly working for several years on a drop-in iOS technology based on the latest peer-reviewed crypto research, pinned certificates, PFS, and implemented in a safe language that doesn't buffer overflow. It's invitation-only right now but many customers are running it in production. We have to position it as a performance technology (and it's very very fast) since security doesn't make sales. But my personal goal is to Make Things Dark Again™. Unfortunately the hardest part of security work is funding it–performance and business concerns drive a lot of the conversations which limit how much time is left to work on making bulletproof transport security dead simple for app developers. And it needs to be dead simple to get deployed in enough apps to protect the average user from pervasive surveillance. But if you believe in the problem, and your employer can create a budget for the problem, I would love to chat with you (email in my profile). There is still time to rewrite the future and keep totalitarian governments out of our communication. We just have to decide we actually care enough to make it happen.

Canada 10y ago
How does your idea compare to noise protocol or QUIC?
- drewcrawford 10y ago
  Noise is not really a protocol but a toolkit to build one. It's really a symptom of the problem. We expect individual developers to take these tools and figure it out, when they won't because they don't care enough. If by some miracle they care they will probably screw it up unless they like reading crypto papers. It also has various practical problems (e.g. the 64k message limit) that you have to deal with some way, probably at the expense of performance which is a useful vehicle to sell security technology, possibly at the expense of security (e.g. early session termination). QUIC is more interesting and I'm evaluating if we can deploy a modified form of it into our transport layer. The key problem with QUIC alone is that in practice many networks block UDP traffic, so you need a TCP fallback solution so customers don't complain that every other app works except yours. But when your threat model is "government compels certificates" then you can't fallback to TLS. The government will just block UDP traffic at the router, downgrade you to TLS, and now they've got you. This is one consequence of a larger design issue: QUIC is trying to provide "equivalent" security to TLS, but if your threat model is "something is wrong with TLS" that's not enough.
  - Canada 10y ago
    How about something like spiped?
    - drewcrawford 10y ago
      spiped is GREAT tech, and shares a lot of the same philosophy: small implementation, simplified protocol, no negotiation, key pinning, etc. It is really, really solid for the problem it solves. However, it's designed around a simplified threat model. In spiped, you use pre-shared keys (the same key on client and server), that "somehow" you got a copy onto both systems without anyone seeing them. But you can't just drop your key into a mobile app binary, submit to the app store, and expect people not to reverse-engineer it and start reading other people's traffic. So now you need to figure out how to derive spiped keys on a per-session basis in a cryptographer-approved way™ and distribute them securely and verify the key someone told you to use is not actually from the NSA, and then on top of that think about perfect forward secrecy and certificate pinning and various other "beyond TLS" guarantees. There are solutions to all those problems, tarsnap ships really cool solutions, but we are not talking about spiped anymore, we're talking about spiped and a long list of other things, and the other things are easy to get wrong if your name is not cpervia. Another practical problem with spiped is the performance degrades for small messages. This doesn't matter if your use case is doing backups, but if your use case is "I typed the letter 'c' in the search bar and where are my search results? I thought this was supposed to be a performance technology" it matters a LOT.
      - Canada 10y ago
        What about Axolotl, with the addition of the server signing a hash of the master key with an ed25519 private key whose corresponding public key is shipped with the app? Perhaps with a fixed 2 step "CA" trust path so each individual server can have its own signing key. The server would be authenticated to the client, but not vice versa. Clients would have to provide some credential in band, but it could be bound to their identity key after that so it shouldn't need to be done again even when creating a new session (eg. fresh connection with different server) If a server is compromised its signing and identity keys can be replaced. The DH ratchet heals the compromised session keys, compensating for the lack of an out of band key revocation mechanism. Sessions could be time bounded to mitigate the damage of clients sending with compromised message keys in between DH ratchets. Where that fails the server could reply with a message disclosing the compromise, forcing DH, limiting the damage of continuing to use the compromised hash ratchet. For additional security clients could sign all their messages with their identity key. If the server logged all of them, then it would be possible to check after a server compromise that the attacker didn't forge anything. You'd have to do something to break up big messages into chunks for UDP transport. There's a BSD licensed ratchet implementation from Silent Circle.
mwcampbell 10y ago
Is this iOS-only? If so, then I think you're fighting even more of an uphill battle, because many (most?) companies will want something cross-platform. Android has huge market share, after all.

Canada 10y ago

How does your idea compare to noise protocol or QUIC?

drewcrawford 10y ago
Noise is not really a protocol but a toolkit to build one. It's really a symptom of the problem. We expect individual developers to take these tools and figure it out, when they won't because they don't care enough. If by some miracle they care they will probably screw it up unless they like reading crypto papers. It also has various practical problems (e.g. the 64k message limit) that you have to deal with some way, probably at the expense of performance which is a useful vehicle to sell security technology, possibly at the expense of security (e.g. early session termination). QUIC is more interesting and I'm evaluating if we can deploy a modified form of it into our transport layer. The key problem with QUIC alone is that in practice many networks block UDP traffic, so you need a TCP fallback solution so customers don't complain that every other app works except yours. But when your threat model is "government compels certificates" then you can't fallback to TLS. The government will just block UDP traffic at the router, downgrade you to TLS, and now they've got you. This is one consequence of a larger design issue: QUIC is trying to provide "equivalent" security to TLS, but if your threat model is "something is wrong with TLS" that's not enough.
- Canada 10y ago
  How about something like spiped?
  - drewcrawford 10y ago
    spiped is GREAT tech, and shares a lot of the same philosophy: small implementation, simplified protocol, no negotiation, key pinning, etc. It is really, really solid for the problem it solves. However, it's designed around a simplified threat model. In spiped, you use pre-shared keys (the same key on client and server), that "somehow" you got a copy onto both systems without anyone seeing them. But you can't just drop your key into a mobile app binary, submit to the app store, and expect people not to reverse-engineer it and start reading other people's traffic. So now you need to figure out how to derive spiped keys on a per-session basis in a cryptographer-approved way™ and distribute them securely and verify the key someone told you to use is not actually from the NSA, and then on top of that think about perfect forward secrecy and certificate pinning and various other "beyond TLS" guarantees. There are solutions to all those problems, tarsnap ships really cool solutions, but we are not talking about spiped anymore, we're talking about spiped and a long list of other things, and the other things are easy to get wrong if your name is not cpervia. Another practical problem with spiped is the performance degrades for small messages. This doesn't matter if your use case is doing backups, but if your use case is "I typed the letter 'c' in the search bar and where are my search results? I thought this was supposed to be a performance technology" it matters a LOT.
    - Canada 10y ago
      What about Axolotl, with the addition of the server signing a hash of the master key with an ed25519 private key whose corresponding public key is shipped with the app? Perhaps with a fixed 2 step "CA" trust path so each individual server can have its own signing key. The server would be authenticated to the client, but not vice versa. Clients would have to provide some credential in band, but it could be bound to their identity key after that so it shouldn't need to be done again even when creating a new session (eg. fresh connection with different server) If a server is compromised its signing and identity keys can be replaced. The DH ratchet heals the compromised session keys, compensating for the lack of an out of band key revocation mechanism. Sessions could be time bounded to mitigate the damage of clients sending with compromised message keys in between DH ratchets. Where that fails the server could reply with a message disclosing the compromise, forcing DH, limiting the damage of continuing to use the compromised hash ratchet. For additional security clients could sign all their messages with their identity key. If the server logged all of them, then it would be possible to check after a server compromise that the attacker didn't forge anything. You'd have to do something to break up big messages into chunks for UDP transport. There's a BSD licensed ratchet implementation from Silent Circle.

mwcampbell 10y ago

Is this iOS-only? If so, then I think you're fighting even more of an uphill battle, because many (most?) companies will want something cross-platform. Android has huge market share, after all.