3 ms·

spiped is GREAT tech, and shares a lot of the same philosophy: small implementation, simplified protocol, no negotiation, key pinning, etc. It is really, reall

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.
cperciva 10y ago
and then on top of that think about perfect forward secrecy FYI, spiped provides perfect forward secrecy by default. (But you can turn it off if you want to; short-circuiting the handshake this way makes it possible to perform about 1000x more handshakes per second.)
Canada 10y ago
Also, how about this? https://cr.yp.to/tcpip/minimalt-20130522.pdf https://cr.yp.to/tcpip/minimalt-20130522.pdf

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.

cperciva 10y ago

and then on top of that think about perfect forward secrecy FYI, spiped provides perfect forward secrecy by default. (But you can turn it off if you want to; short-circuiting the handshake this way makes it possible to perform about 1000x more handshakes per second.)

Canada 10y ago

Also, how about this? https://cr.yp.to/tcpip/minimalt-20130522.pdf https://cr.yp.to/tcpip/minimalt-20130522.pdf