What advantage does Signal protocol have over basic public key encryption?
Hi all, I'm the CEO a company called Expensify, developing a new open source chat application at https://Expensify.cash. I was pretty prolific on the p2p-hackers mailing list back in the day, but this is my first post to Cypherpunk, so... hi! I'm writing because I've read a bunch of overviews of *how* the protocol is designed, but I haven't really seen good sources explaining (in a dumbed-down enough manner for me to follow) *why* it was designed that way. In general, I'm trying to understand the reasoning behind the Signal protocol in terms of what real world attacks each of its features defends against, because on the surface it seems _really_ complicated in order to protect against only a very narrow range of attacks. However, I imagine every bit of that complexity has a purpose, and thus I figured this was the right place to try to get to the bottom of that purpose. If you have some other link that you think does a great job breaking it down, I'm all ears! Until then, here are some questions I'd love your help with: 1) This is perhaps an obvious question (I've got to start somewhere, after all), but what is the downside of the simplest possible solution, which I think would be for all participants to publish a public key to some common key server, and then for each participant in the chat to simply re-encrypt the message N-1 times -- once for each participant in the chat (minus themselves) using each recipient's public key? 2) I would think the most significant problem with this ultra-simple design is just performance: asymmetric encryption is just too expensive in practice to use for every single message, especially given the O(n) cost of re-encrypting for every single recipient. Accordingly, the vast majority of the complexity of the Signal protocol is really just a performance optimization exercise to securely create (and rotate) a shared symmetric key that enables high-performance encryption/decryption. Is that right? Said another way, if asymmetric encryption had adequate performance for a given use case, would that obviate most of the advantage of the Signal protocol? 3) The other problem with the ultra-simple design would be a lack of forward secrecy: if anyone's private key were compromised, all historical messages sent to them could be decrypted (assuming the attacker had stored them). But even with the Signal protocol, if someone's local device were compromised (the most likely way for an attacker to get the private key), they're screwed anyway, in two different ways: a. The act of compromising the private key would likely ALSO compromise nearly all past communications. So all that hard work to rotate historical keys is kind of pointless if the messages themselves are compromised on device. b. If the private key itself (which is *only* stored on the device) were compromised *without* also revealing the messages stored on that same device (though how this would happen I'm struggling to understand), then an attacker could still decrypt all past communications if they had a perfect record going back to the start. 4) So in summary, is it safe to say that the primary real-world advantages of the Signal protocol over the super-basic solution are: a. achieve high performance encryption using frequently rotated symmetric keys, and b. prevent an attacker who has compromised the device AND has a partial record of communications from decrypting messages that are no longer stored on that device. Is that the gist of it? Again, these are real high level questions, so I appreciate your patience with me! -david Founder and CEO of Expensify
On Sun, 24 Jan 2021 13:02:24 -0800 David Barrett <dbarrett@expensify.com> wrote:
Signal protocol ...on the surface it seems _really_ complicated in order to protect against only a very narrow range of attacks.
that is my impression as well. On the other hand signal has very serious propblems like requiring people to link their 'identity' to a retarphone and the fact that all messages are routed through signal-NSA servers. I.e. signal is fully centralized. you have to take into account that 'moxie' got 3 millions from the US govt. And a lot more from some other silicon valley oligarch.
Well, centralized routing and US government investment shouldn't change the math of the security itself. So long as the design is secure, that shouldn't really matter. Regardless, can you see any flaw in my reasoning regarding the signal protocol's advantage over simple public key encryption? Thank you! David On Sun, Jan 24, 2021, 1:53 PM Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Sun, 24 Jan 2021 13:02:24 -0800 David Barrett <dbarrett@expensify.com> wrote:
Signal protocol ...on the surface it seems _really_ complicated in order to protect against only a very narrow range of attacks.
that is my impression as well. On the other hand signal has very serious propblems like requiring people to link their 'identity' to a retarphone and the fact that all messages are routed through signal-NSA servers. I.e. signal is fully centralized.
you have to take into account that 'moxie' got 3 millions from the US govt. And a lot more from some other silicon valley oligarch.
On Sun, 24 Jan 2021 14:04:10 -0800 David Barrett <dbarrett@expensify.com> wrote:
Well, centralized routing and US government investment shouldn't change the math of the security itself. So long as the design is secure, that shouldn't really matter.
where do these fucktards come from?
On 2021-01-25 07:02, David Barrett wrote:
Hi all, I'm the CEO a company called Expensify, developing a new open source chat application at https://Expensify.cash. I was pretty prolific on the p2p-hackers mailing list back in the day, but this is my first post to Cypherpunk, so... hi!
I'm writing because I've read a bunch of overviews of *how* the protocol is designed, but I haven't really seen good sources explaining (in a dumbed-down enough manner for me to follow) *why* it was designed that way. In general, I'm trying to understand the reasoning behind the Signal protocol in terms of what real world attacks each of its features defends against, because on the surface it seems _really_ complicated in order to protect against only a very narrow range of attacks.
However, I imagine every bit of that complexity has a purpose, and thus I figured this was the right place to try to get to the bottom of that purpose. If you have some other link that you think does a great job breaking it down, I'm all ears! Until then, here are some questions I'd love your help with:
1) This is perhaps an obvious question (I've got to start somewhere, after all), but what is the downside of the simplest possible solution, which I think would be for all participants to publish a public key to some common key server, and then for each participant in the chat to simply re-encrypt the message N-1 times -- once for each participant in the chat (minus themselves) using each recipient's public key?
This does not work in itself, because what assurance do you have that you are seeing the same public key as everyone else? They could tell Ann that Bob's key was a key that in fact belonged to antifa, and tell Bob that Ann's public key was a key that in fact belonged to antifa. What assurance does Bob have that Ann is seeing the same "Bob's key" as Ann is seeing. To solve this you need a cryptographic primitive known as a reliable broadcast channel, which is typically implemented as a blockchain or something similar. Jitsi implements this, but I am not aware of anyone else implementing it. With Jitsi, Ann's software is guaranteed to see the same list of public keys as Bob's software. This is a distributed consensus problem, and distributed consensus is hard. I don't know if Signal's solution solves this problem. I have not checked them.
2) I would think the most significant problem with this ultra-simple design is just performance: asymmetric encryption is just too expensive in practice to use for every single message,
Nah, because its cost in human generated messages is absolutely insignificant, particularly if you are using ed25519 or, better, ristretto25519 Secondly you don't need to use it on every single message. Assume we have solved the public key distribution problem, perhaps the way Jitsi does it, and everyone is seeing the same set of public keys. When you join a room, you submit a transient public key to each of the participants in the room, and they respond with a transient public key, constructing a shared secret between each pair of participants. You then use symmetric encryption with that shared secret. And then, over the encrypted connection, set up a shared secret based on both the durable public and private keys, and the transient keys. So you now have, for each pair of participants, a shared secret that depends on both parties durable and transient keys. Possession of the shared secret proves you know the secret key corresponding to your public key, and you get perfect forward secrecy because the shared secret and the transient keys are abandoned when you leave the room. Assume Bob's secret key is b, and his public key is B, and similarly Carol's secret key is c and her public key is C. b*C=c*B. So, to construct a shared secret that can be used for symmetric encryption, Bob calculates b*C and Carol calculates c*B Suppose that Bob's transient private and public keys are b and B, and his durable private and public keys are _b_ and _B_, and similarly for Carol. Then to construct a shared secret that depends on both the transient and the durable keys, Bob calculates (_b_ + b)*(_C_ + C), and similarly Carol. (But this is only safe if both Bob and Carol have first proven that they also know the shared secret b*C = c*B, by first successfully decrypting and encrypting stuff symmetrically encrypted to that secret)
On Sun, Jan 24, 2021 at 9:15 PM <jamesd@echeque.com> wrote:
1) This is perhaps an obvious question (I've got to start somewhere, after all), but what is the downside of the simplest possible solution, which I think would be for all participants to publish a public key to some common key server, and then for each participant in the chat to simply re-encrypt the message N-1 times -- once for each participant in the chat (minus themselves) using each recipient's public key?
This does not work in itself, because what assurance do you have that you are seeing the same public key as everyone else?
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
2) I would think the most significant problem with this ultra-simple design
is just performance: asymmetric encryption is just too expensive in practice to use for every single message,
Nah, because its cost in human generated messages is absolutely insignificant, particularly if you are using ed25519 or, better, ristretto25519
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense. -david
Incidentally, for anyone following along, here's a great thread I had on Twitter regarding this: https://twitter.com/dbarrett/status/1353768706141163520 My current summary of Signal's primary design goal is:
Perhaps I'm looking at it the wrong way. Signal's primary design goal seems to be to *enable* truly effective self-destructing chats (which means enabling them to self-destruct at every layer), to limit the damage from device compromise. That is their primary differentiated feature.
Given that the device is the weak link (ie, the most likely place that a key would be compromised), and without self-destructing chats the device has a complete record of all past messages, then there's really no point to all the double-ratchet stuff (which exists purely to limit the damage of any individual key being compromised) because in the process of compromising any key, you also compromise *all messages* (obviating your need for the key in the first place). Does that seem a fair summary? -david On Mon, Jan 25, 2021 at 10:31 AM David Barrett <dbarrett@expensify.com> wrote:
On Sun, Jan 24, 2021 at 9:15 PM <jamesd@echeque.com> wrote:
1) This is perhaps an obvious question (I've got to start somewhere, after all), but what is the downside of the simplest possible solution, which I think would be for all participants to publish a public key to some common key server, and then for each participant in the chat to simply re-encrypt the message N-1 times -- once for each participant in the chat (minus themselves) using each recipient's public key?
This does not work in itself, because what assurance do you have that you are seeing the same public key as everyone else?
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
2) I would think the most significant problem with this ultra-simple design
is just performance: asymmetric encryption is just too expensive in practice to use for every single message,
Nah, because its cost in human generated messages is absolutely insignificant, particularly if you are using ed25519 or, better, ristretto25519
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
-david
On 1/25/21, David Barrett <dbarrett@expensify.com> wrote:
Incidentally, for anyone following along, here's a great thread I had on Twitter regarding this:
https://twitter.com/dbarrett/status/1353768706141163520
My current summary of Signal's primary design goal is:
Perhaps I'm looking at it the wrong way. Signal's primary design goal seems to be to *enable* truly effective self-destructing chats (which means enabling them to self-destruct at every layer), to limit the damage from device compromise. That is their primary differentiated feature.
Given that the device is the weak link (ie, the most likely place that a key would be compromised), and without self-destructing chats the device has a complete record of all past messages, then there's really no point to all the double-ratchet stuff (which exists purely to limit the damage of any individual key being compromised) because in the process of compromising any key, you also compromise *all messages* (obviating your need for the key in the first place).
Does that seem a fair summary?
Sorry for over-replying. I'm trying to catch up and don't want to figure out all the replies with strategically placed errors different from my errors. I would summarise Signal totally differently: Signal is the only popular cryptographic messaging system where actual norms that people care about are respected. Most message systems just do stupid things, and lie to you when you call them out on it, and it's frustrating and infuriating. It is obviious that Signal is not motivated by profit, but rather their users and functionality. They have an automated system that gives their donated money to people who contribute improvements.
On Mon, Jan 25, 2021 at 10:43:45AM -0800, David Barrett wrote:
Incidentally, for anyone following along, here's a great thread I had on Twitter regarding this:
For those of us unwilling to support Satanists, please paste in a copy of that convo.
On 2021-01-26 04:31, David Barrett wrote:
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works. It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes. Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds. And you then use the authenticated shared secret for the rest of the session.
Wow, these are (mostly) great responses, and exactly what I was looking for. Thank you! To call out a couple responses: 6, the ratchet protocol produces a hash of previous messages that provides
for detection of dropped data, among many other things. pgp does not do this.
It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode). We do this with https://bedrockdb.com/blockchain.html and it works great. However, I get your point that the double ratchet provides other benefits beyond just forward secrecy. Decryption of destroyed messages is a big thing that signal deters.
Journalists can get seriously physically injured when that happens.
Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal. Re Signal and Javascript, Signal offers its code in a signed binary, and
offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries. They [Signal] have an automated system that gives their donated money to
people who contribute improvements.
Wait really? I'm not really finding that mentioned anywhere; can you link me to this? The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribu... Arguably the simplest method is to do what you describe [encrypting every
message with the recipient's public key]. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher.
I'd really love to learn more about this, as I think I almost understand it, but not quite. Can you elaborate on what you mean by "If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret." I get that any encryption (symmetric or otherwise) works on blocks, so to encrypt anything larger than one block requires splitting the input up into many blocks. And I get that there are concerns with accidentally revealing information by encrypting the same exact block back to back (ie, it reveals "the same block appeared twice", without revealing the actual block content itself). (More on all that here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality... ) But I'm not quite understanding why you suggest that you couldn't just use a CBC strategy (where each block is derived from the block that preceded it) in conjunction with public key encryption to just encrypt every block with the recipient's public key, eliminating the need for the shared symmetric encryption key. Now, understand the performance advantages of symmetric over asymmetric encryption, and certainly the convenience (and bandwidth) advantages of having multiple parties all use the same key (ie, to avoid re-encrypting the same message separately for each recipient). But I don't see any actual security advantage to introducing the symmetric key (and arguably a disadvantage given the increased complexity it adds). Thanks for all these answers, I really appreciate them! -david On Tue, Jan 26, 2021 at 12:17 AM <jamesd@echeque.com> wrote:
On 2021-01-26 04:31, David Barrett wrote:
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works.
It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes.
Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds.
And you then use the authenticated shared secret for the rest of the session.
Hey all, I took the liberty of writing up this proposal and everything I've learned in more detail here: https://gist.github.com/quinthar/44e1c4f63f84556a9822ebf274dc510a I'd really welcome any feedback or (constructive) criticism on it. Thanks! -david On Fri, Jan 29, 2021 at 11:42 AM David Barrett <dbarrett@expensify.com> wrote:
Wow, these are (mostly) great responses, and exactly what I was looking for. Thank you! To call out a couple responses:
6, the ratchet protocol produces a hash of previous messages that provides
for detection of dropped data, among many other things. pgp does not do this.
It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode). We do this with https://bedrockdb.com/blockchain.html and it works great. However, I get your point that the double ratchet provides other benefits beyond just forward secrecy.
Decryption of destroyed messages is a big thing that signal deters.
Journalists can get seriously physically injured when that happens.
Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal.
Re Signal and Javascript, Signal offers its code in a signed binary, and
offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
They [Signal] have an automated system that gives their donated money to
people who contribute improvements.
Wait really? I'm not really finding that mentioned anywhere; can you link me to this? The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribu...
Arguably the simplest method is to do what you describe [encrypting every
message with the recipient's public key]. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher.
I'd really love to learn more about this, as I think I almost understand it, but not quite. Can you elaborate on what you mean by "If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret."
I get that any encryption (symmetric or otherwise) works on blocks, so to encrypt anything larger than one block requires splitting the input up into many blocks. And I get that there are concerns with accidentally revealing information by encrypting the same exact block back to back (ie, it reveals "the same block appeared twice", without revealing the actual block content itself). (More on all that here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality... )
But I'm not quite understanding why you suggest that you couldn't just use a CBC strategy (where each block is derived from the block that preceded it) in conjunction with public key encryption to just encrypt every block with the recipient's public key, eliminating the need for the shared symmetric encryption key.
Now, understand the performance advantages of symmetric over asymmetric encryption, and certainly the convenience (and bandwidth) advantages of having multiple parties all use the same key (ie, to avoid re-encrypting the same message separately for each recipient). But I don't see any actual security advantage to introducing the symmetric key (and arguably a disadvantage given the increased complexity it adds).
Thanks for all these answers, I really appreciate them!
-david
On Tue, Jan 26, 2021 at 12:17 AM <jamesd@echeque.com> wrote:
On 2021-01-26 04:31, David Barrett wrote:
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works.
It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes.
Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds.
And you then use the authenticated shared secret for the rest of the session.
On Sun, Jan 31, 2021 at 4:29 AM David Barrett <dbarrett@expensify.com> wrote:
Hey all, I took the liberty of writing up this proposal and everything I've learned in more detail here:
https://gist.github.com/quinthar/44e1c4f63f84556a9822ebf274dc510a
Hi all, I just skimmed through the whole thread and have one question, If you don't mind. I asssume when talking about design proposals, for secure comms, that always Android and iOS devices are used. Are people aware when using such devices, about zero-click exploits, from Pegasus (NSO Group, or FinFisher/FinSpy? I sold my smartphone exactly for that reason and switched to a dumb phone. What I miss in all those discussion is, when it comes to secure mobile comms, the usage and promotion of mobile devices running on OpenSource OS devices, which developers and users have more control of. Then IMHO it would be good to discuss such protocolls etc. Best regards Stefan
I'd really welcome any feedback or (constructive) criticism on it. Thanks!
-david
On Fri, Jan 29, 2021 at 11:42 AM David Barrett <dbarrett@expensify.com> wrote:
Wow, these are (mostly) great responses, and exactly what I was looking for. Thank you! To call out a couple responses:
6, the ratchet protocol produces a hash of previous messages that provides for detection of dropped data, among many other things. pgp does not do this.
It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode). We do this with https://bedrockdb.com/blockchain.html and it works great. However, I get your point that the double ratchet provides other benefits beyond just forward secrecy.
Decryption of destroyed messages is a big thing that signal deters. Journalists can get seriously physically injured when that happens.
Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal.
Re Signal and Javascript, Signal offers its code in a signed binary, and offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
They [Signal] have an automated system that gives their donated money to people who contribute improvements.
Wait really? I'm not really finding that mentioned anywhere; can you link me to this? The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribu...
Arguably the simplest method is to do what you describe [encrypting every message with the recipient's public key]. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher.
I'd really love to learn more about this, as I think I almost understand it, but not quite. Can you elaborate on what you mean by "If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret."
I get that any encryption (symmetric or otherwise) works on blocks, so to encrypt anything larger than one block requires splitting the input up into many blocks. And I get that there are concerns with accidentally revealing information by encrypting the same exact block back to back (ie, it reveals "the same block appeared twice", without revealing the actual block content itself). (More on all that here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality...)
But I'm not quite understanding why you suggest that you couldn't just use a CBC strategy (where each block is derived from the block that preceded it) in conjunction with public key encryption to just encrypt every block with the recipient's public key, eliminating the need for the shared symmetric encryption key.
Now, understand the performance advantages of symmetric over asymmetric encryption, and certainly the convenience (and bandwidth) advantages of having multiple parties all use the same key (ie, to avoid re-encrypting the same message separately for each recipient). But I don't see any actual security advantage to introducing the symmetric key (and arguably a disadvantage given the increased complexity it adds).
Thanks for all these answers, I really appreciate them!
-david
On Tue, Jan 26, 2021 at 12:17 AM <jamesd@echeque.com> wrote:
On 2021-01-26 04:31, David Barrett wrote:
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works.
It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes.
Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds.
And you then use the authenticated shared secret for the rest of the session.
On Sun, 31 Jan 2021 12:57:43 +0100 Stefan Claas <spam.trap.mailing.lists@gmail.com> wrote:
What I miss in all those discussion is, when it comes to secure mobile comms, the usage and promotion of mobile devices running on OpenSource OS devices, which developers and users have more control of. Then IMHO it would be good to discuss such protocolls etc.
exactly right. And the open source OS should be running on non-compromised hardware. Oh, wait.
On Sun, Jan 31, 2021 at 7:56 PM Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Sun, 31 Jan 2021 12:57:43 +0100 Stefan Claas <spam.trap.mailing.lists@gmail.com> wrote:
What I miss in all those discussion is, when it comes to secure mobile comms, the usage and promotion of mobile devices running on OpenSource OS devices, which developers and users have more control of. Then IMHO it would be good to discuss such protocolls etc.
exactly right. And the open source OS should be running on non-compromised hardware. Oh, wait.
Something like this, for smartphones, would be nice, I guess. https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-dete... Regards Stefan
On Sun, 31 Jan 2021 20:09:51 +0100 Stefan Claas <spam.trap.mailing.lists@gmail.com> wrote:
On Sun, Jan 31, 2021 at 7:56 PM Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Sun, 31 Jan 2021 12:57:43 +0100 Stefan Claas <spam.trap.mailing.lists@gmail.com> wrote:
What I miss in all those discussion is, when it comes to secure mobile comms, the usage and promotion of mobile devices running on OpenSource OS devices, which developers and users have more control of. Then IMHO it would be good to discuss such protocolls etc.
exactly right. And the open source OS should be running on non-compromised hardware. Oh, wait.
Something like this, for smartphones, would be nice, I guess.
https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-dete...
Well, there is this https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.bunniestudios.com/blog/?cat=71 Also notice from your link "Deactivated Intel Management Engine" Except, that piece of intel-nsa hardware malware CAN'T be deactivated.
Regards Stefan
On 1/29/21, David Barrett <dbarrett@expensify.com> wrote:
Wow, these are (mostly) great responses, and exactly what I was looking for. Thank you! To call out a couple responses:
6, the ratchet protocol produces a hash of previous messages that provides
for detection of dropped data, among many other things. pgp does not do this.
It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode). We do this with https://bedrockdb.com/blockchain.html and it works great. However, I get your point that the double ratchet provides other benefits beyond just forward secrecy.
There's a lot of value to using a protocol that is normalised and standardised and widely used in some way. It has many eyes looking at it and thinking about bugs and such. But yeah. And yeah, the ratchet protocol accomplishes more than just that.
Decryption of destroyed messages is a big thing that signal deters.
Journalists can get seriously physically injured when that happens.
Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal.
I see Signal's primary design goal as being easy to use, public, audited private communications, for everybody. It would make sense to contribute or work with a project like Signal rather than making a new messenger, to continue to try to get communications more secure, with more eyes looking at problems, making things easy to use, and getting people to use them, etc. A messenger only works if the people you want to talk to use it.
Re Signal and Javascript, Signal offers its code in a signed binary, and
offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
I don't see your argument here. The only reasonable way to sell something on an app store is to distribute a binary. Meanwhile with the source available, people can build their own clients, and share them via other channels. I visited expensify.cash but didn't notice an obvious link to the source code. It can be hard for me to see things, though.
They [Signal] have an automated system that gives their donated money to
people who contribute improvements.
Wait really? I'm not really finding that mentioned anywhere; can you link me to this? The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribu...
It looks like the autopayment system broke in 2017 and nobody fixed it: https://github.com/signalapp/Signal-Android/commit/258910504cc2fcc57b8868cb0... . Sorry for the outdated information. I post during psychotic breaks, so some of what I say may not be quite right. Thank you so much for your open source work. Please work with existing open source projects when you can both benefit from the work, so the community can grow.
Re Signal and Javascript, Signal offers its code in a signed binary, and
offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
I don't see your argument here. The only reasonable way to sell something on an app store is to distribute a binary. Meanwhile with the source available, people can build their own clients, and share them via other channels.
Sorry, I failed to notice what you were responding to. Here is information on signal's reproducible builds: https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds You actually can verify that the app from the play store is the one you have the source to. I am not a cryptographer and have no college degree.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, January 29, 2021 2:42 PM, David Barrett <dbarrett@expensify.com> wrote:
Wow, these are (mostly) great responses, and exactly what I was looking for. Thank you! To call out a couple responses:
6, the ratchet protocol produces a hash of previous messages that provides for detection of dropped data, among many other things. pgp does not do this.
It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode). We do this with https://bedrockdb.com/blockchain.html and it works great. However, I get your point that the double ratchet provides other benefits beyond just forward secrecy.
Decryption of destroyed messages is a big thing that signal deters. Journalists can get seriously physically injured when that happens.
Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal.
Re Signal and Javascript, Signal offers its code in a signed binary, and offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
They [Signal] have an automated system that gives their donated money to people who contribute improvements.
Wait really? I'm not really finding that mentioned anywhere; can you link me to this? The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribu...
Arguably the simplest method is to do what you describe [encrypting every message with the recipient's public key]. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher.
I'd really love to learn more about this, as I think I almost understand it, but not quite. Can you elaborate on what you mean by "If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret."
All public-key crypto systems (afaik) use some fixed-sized mathematical group. The size of the group, and the actual math operations involved differ depending on the system (RSA, DH, ECDH, ElGamal, etc). You cannot send messages of arbitrary size using these systems, because all operations involve a fixed number of elements (or bits). As an example, [0-11) is a mathematical field (and therefore group) consisting of 10 elements. Sending an arbitrary message requires a mapping function to/from these 10 elements. The mapping function must be isomorphic - the "inverse" is the tricky part because you cannot have a ciphertext that maps to 10,000 equally possible plaintexts. Even with fairly large groups, the number of possible plaintexts is typically far too large (usually infinite). Or very precisely, you can definitely develop an ElGamal system where plaintext messages map to a group element, but the number of possible messages must be limited to the size of the group (again, afaik). If messages are constrained to "secret keys", then public-key crypto systems can be used to "pass" or share secret bits. The next problem is ensuring that these secret bits are not accidentally leaked when encrypting messages. Symmetric ciphers are designed to prevent this type of leakage ("confusion"), which is probably why every system is a hybrid of public-key and symmetric crypto.
I get that any encryption (symmetric or otherwise) works on blocks, so to encrypt anything larger than one block requires splitting the input up into many blocks. And I get that there are concerns with accidentally revealing information by encrypting the same exact block back to back (ie, it reveals "the same block appeared twice", without revealing the actual block content itself). (More on all that here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality...)
But I'm not quite understanding why you suggest that you couldn't just use a CBC strategy (where each block is derived from the block that preceded it) in conjunction with public key encryption to just encrypt every block with the recipient's public key, eliminating the need for the shared symmetric encryption key.
One obvious problem is with known-plaintext attacks. If any bits are known in advance to an attacker - even if its "frame" data (JSON, etc.) - then this information is propagated to later blocks. There must be confusion+diffusion at every stage. In all major cipher block-modes, previous ciphertexts are only used if the result is put back through the cipher. In other words, block-cipher modes are designed to protect against small biases in the ciphertext itself, which is a round-about way of saying you probably don't want to attempt what you are suggesting. A public-key operation for every block is needed, or a hash function or cipher is needed. And using only a hash function is iffy because of the compression stage; (probably) only Keccak/SHA3 is recommended if the PRF is used directly (the authors have proposed this function for use as a stream-cipher).
Now, understand the performance advantages of symmetric over asymmetric encryption, and certainly the convenience (and bandwidth) advantages of having multiple parties all use the same key (ie, to avoid re-encrypting the same message separately for each recipient). But I don't see any actual security advantage to introducing the symmetric key (and arguably a disadvantage given the increased complexity it adds).
Current public-key systems have severe limitations in message size, so symmetric key systems make the public-key algorithms far more useful.
Thanks for all these answers, I really appreciate them! -david
On Tue, Jan 26, 2021 at 12:17 AM <jamesd@echeque.com> wrote:
On 2021-01-26 04:31, David Barrett wrote:
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works.
It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes.
Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds.
And you then use the authenticated shared secret for the rest of the session.
Lee
Thanks for all the great comments! Combining the responses: I asssume when talking about design proposals, for secure comms, that
always Android and iOS devices are used. Are people aware when using such devices, about zero-click exploits, from Pegasus (NSO Group, or FinFisher/FinSpy? I sold my smartphone exactly for that reason and switched to a dumb phone
Yes, I talk about this a bit here: https://gist.github.com/quinthar/44e1c4f63f84556a9822ebf274dc510a#the-feds, but... exactly right. And the open source OS should be running on non-compromised
hardware. Oh, wait.
That. In the real world, we can't all hand build and personally operate our own billion dollar fab to ensure atomic-level security of our entire vertical supply chain. And even if you could... who's to say the Feds don't sneak in and swap your device with a perfect duplicate when you aren't looking? Ultimately if you are trying to protect yourself from the combined might of, oh, 8 billion other people, you're going to have a tough time of it. I'm not building for that use case (nor is anyone else). I'm building for the billions of people who aren't trying to protect themselves from the Feds, but from other more common (even if more mundane) privacy threats. https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-dete... How do you know they aren't an NSA front? Ultimately, you can't. At some point you've got no choice but to trust someone. It would make sense to contribute or work with a project like Signal rather
than making a new messenger
Well my job is to secure the privacy of Expensify's millions of users, not just shut down shop and tell them to use Signal (especially since Signal doesn't offer the wide range of preaccounting functionality we do). The only reasonable way to sell something on an app store is to distribute
a binary. Meanwhile with the source available, people can build their own clients, and share them via other channels.
I totally agree, no real world system can grow if it presumes everyone builds their own binaries (and presumably inspects the source code personally to make sure nothing was slipped in via Github when pulling down the repo). My only point is real-world systems do not exist in a vacuum: the only way to realistically build a secure communication system used by billions is to rely upon trusting _the very people you don't want to monitor you_ to allow you to do so without interference. It's a harsh, brutal reality, but there it is.
I visited expensify.cash but didn't notice an obvious link to the source code. It can be hard for me to see things, though.
Ah, sorry! It's a new project so we're mostly focused on curating a small set of dedicated contributors before going too wide. But you can see it here: https://github.com/Expensify/Expensify.cash -- Sign up at https://Expensify.cash and enter your Github handle, and we'll invite you to the various testflights and such. We're also hiring freelancers to help out -- here are a bunch of open jobs, and we're adding more all the time: https://www.upwork.com/search/jobs/?q=Expensify%20React%20Native Thank you so much for your open source work. Please work with existing
open source projects when you can both benefit from the work, so the community can grow.
I 100% agree. We're major sponsors of SQLite, and have also open-sourced our BedrockDB.com, which was running a blockchain in production before it was cool: https://bedrockdb.com/blockchain.html Here is information on signal's reproducible builds:
https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds You actually can verify that the app from the play store is the one you have the source to.
Whoa, that's neat! But doesn't change my point: unless everyone is doing this -- and doing it for every single upgrade -- it doesn't really matter. This is a neat parlor trick to create a sense of trust, but I think it's a kind of disingenuous performance of security theatre: that's like shining a spotlight on Trump's 20 mile border wall while ignoring that it's a very incomplete protection. Verifying the APK that you are getting from Google Play never actually makes sense: 1. If the feds *have* identified your device AND you are a sufficiently interesting person of interest that they would force Google to ship you a compromised APK -- they could also just force Google to ship you a compromised, invisibly-installed system update. Verifying the APK doesn't prove anything. 2. If the feds *have not* identified your device, or you are NOT sufficiently interesting to warrant being compromised, then verifying the APK won't ever find anything. Whether you are or are not a target, if you are installing Signal via Google Play, you sorta have no choice but to assume that Signal and Google haven't been compromised: if you believe that, then there's no need to verify. But if you do NOT believe that, then verifying it isn't nearly enough. (Especially when no amount of securing your own device will secure the device of the person you are talking to -- who if you are a target, is probably also a target, or at least you shouldn't assume they aren't.) Current public-key systems have severe limitations in message size, so
symmetric key systems make the public-key algorithms far more useful.
Hm, but all encryption has severe limitations in message size -- even symmetric encryption works on relatively small block sizes. This is why the input is split up and something like CBC is used to prevent "known-plaintext" attacks, with each CBC block separately encrypted with the symmetric key. What I'm trying to figure out is why people don't use something like CBC directly on top of public key encryption. Again, I can see the performance advantages of using symmetric keys, but I'm not sure if there is any actual security advantage between: a. Use DH to generate a symmetric key X from my private key (A.priv) and your public key (B.pub), split input into N blocks, CBC encode and encrypt each block separately with that symmetric key b. split input into N blocks, CBC encode and encrypt each block separately with your public key (B.pub) In other words, block-cipher modes are designed to protect against small
biases in the ciphertext itself, which is a round-about way of saying you probably don't want to attempt what you are suggesting.
Can you elaborate on what you mean by this? I'm sorry, I'm not quite following it. Thank you all for your help, I really appreciate it! -david On Sun, Jan 31, 2021 at 2:26 PM Lee Clagett <forum@leeclagett.com> wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, January 29, 2021 2:42 PM, David Barrett <dbarrett@expensify.com> wrote:
Wow, these are (mostly) great responses, and exactly what I was looking for. Thank you! To call out a couple responses:
6, the ratchet protocol produces a hash of previous messages that provides for detection of dropped data, among many other things. pgp does not do this.
It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode). We do this with https://bedrockdb.com/blockchain.html and it works great. However, I get your point that the double ratchet provides other benefits beyond just forward secrecy.
Decryption of destroyed messages is a big thing that signal deters. Journalists can get seriously physically injured when that happens.
Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal.
Re Signal and Javascript, Signal offers its code in a signed binary, and offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
They [Signal] have an automated system that gives their donated money to people who contribute improvements.
Wait really? I'm not really finding that mentioned anywhere; can you link me to this? The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribu...
Arguably the simplest method is to do what you describe [encrypting every message with the recipient's public key]. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher.
I'd really love to learn more about this, as I think I almost understand it, but not quite. Can you elaborate on what you mean by "If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret."
All public-key crypto systems (afaik) use some fixed-sized mathematical group. The size of the group, and the actual math operations involved differ depending on the system (RSA, DH, ECDH, ElGamal, etc). You cannot send messages of arbitrary size using these systems, because all operations involve a fixed number of elements (or bits). As an example, [0-11) is a mathematical field (and therefore group) consisting of 10 elements. Sending an arbitrary message requires a mapping function to/from these 10 elements. The mapping function must be isomorphic - the "inverse" is the tricky part because you cannot have a ciphertext that maps to 10,000 equally possible plaintexts. Even with fairly large groups, the number of possible plaintexts is typically far too large (usually infinite). Or very precisely, you can definitely develop an ElGamal system where plaintext messages map to a group element, but the number of possible messages must be limited to the size of the group (again, afaik).
If messages are constrained to "secret keys", then public-key crypto systems can be used to "pass" or share secret bits. The next problem is ensuring that these secret bits are not accidentally leaked when encrypting messages. Symmetric ciphers are designed to prevent this type of leakage ("confusion"), which is probably why every system is a hybrid of public-key and symmetric crypto.
I get that any encryption (symmetric or otherwise) works on blocks, so to encrypt anything larger than one block requires splitting the input up into many blocks. And I get that there are concerns with accidentally revealing information by encrypting the same exact block back to back (ie, it reveals "the same block appeared twice", without revealing the actual block content itself). (More on all that here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality... )
But I'm not quite understanding why you suggest that you couldn't just use a CBC strategy (where each block is derived from the block that preceded it) in conjunction with public key encryption to just encrypt every block with the recipient's public key, eliminating the need for the shared symmetric encryption key.
One obvious problem is with known-plaintext attacks. If any bits are known in advance to an attacker - even if its "frame" data (JSON, etc.) - then this information is propagated to later blocks. There must be confusion+diffusion at every stage. In all major cipher block-modes, previous ciphertexts are only used if the result is put back through the cipher. In other words, block-cipher modes are designed to protect against small biases in the ciphertext itself, which is a round-about way of saying you probably don't want to attempt what you are suggesting.
A public-key operation for every block is needed, or a hash function or cipher is needed. And using only a hash function is iffy because of the compression stage; (probably) only Keccak/SHA3 is recommended if the PRF is used directly (the authors have proposed this function for use as a stream-cipher).
Now, understand the performance advantages of symmetric over asymmetric encryption, and certainly the convenience (and bandwidth) advantages of having multiple parties all use the same key (ie, to avoid re-encrypting the same message separately for each recipient). But I don't see any actual security advantage to introducing the symmetric key (and arguably a disadvantage given the increased complexity it adds).
Current public-key systems have severe limitations in message size, so symmetric key systems make the public-key algorithms far more useful.
Thanks for all these answers, I really appreciate them! -david
On Tue, Jan 26, 2021 at 12:17 AM <jamesd@echeque.com> wrote:
Yes, this does assume a central keyserver -- and I agree, it's
that it lies to you, establishing a connection with someone other
On 2021-01-26 04:31, David Barrett wrote: possible than who
you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works.
It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes.
Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds.
And you then use the authenticated shared secret for the rest of the session.
Lee
On Sun, 31 Jan 2021 16:28:59 -0800 David Barrett <dbarrett@expensify.com> wrote:
Thanks for all the great comments! Combining the responses:
I asssume when talking about design proposals, for secure comms, that
always Android and iOS devices are used. Are people aware when using such devices, about zero-click exploits, from Pegasus (NSO Group, or FinFisher/FinSpy? I sold my smartphone exactly for that reason and switched to a dumb phone
Yes, I talk about this a bit here: https://gist.github.com/quinthar/44e1c4f63f84556a9822ebf274dc510a#the-feds, but...
exactly right. And the open source OS should be running on non-compromised
hardware. Oh, wait.
That. In the real world, we can't all hand build and personally operate our own billion dollar fab to ensure atomic-level security of our entire vertical supply chain. And even if you could... who's to say the Feds don't sneak in and swap your device with a perfect duplicate when you aren't looking? Ultimately if you are trying to protect yourself from the combined might of, oh, 8 billion other people,
How is 'the feds' equivalent to 'the combined might of, oh, 8 billion other people'? You seem to have misuderstood my remark. I wasn't saying that you shouldn't focus on open source OSes AND more important, audited hardware. My whole point is that UNLESS you have audited hardware, then all your software is worthless. A point that should be pretty much self-evident on a list like this.
you're going to have a tough time of it. I'm not building for that use case (nor is anyone else).
So you're not doing anything useful. As to your comment about 'anyone else', it's factually wrong.
I'm building for the billions of people who aren't trying to protect themselves from the Feds,
the US 'feds' and their accomplices in other 'jurisdictions' are the only threat that people should really care about. Again, this fact should be obvious on this mailing list.
but from other more common (even if more mundane) privacy threats.
such as?
https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-dete...
How do you know they aren't an NSA front? Ultimately, you can't.
OK, so how do we know you're not an NSA agent?
At some point you've got no choice but to trust someone.
....
It would make sense to contribute or work with a project like Signal rather
than making a new messenger
Well my job is to secure the privacy of Expensify's millions of users,
what the hell is your site anyway? The name sounds like a joke, and it's a blank page unless people run your javashit malware.
Hi, David. Still crazy over here. I disagree on your view of handling technically powerful surveillance and compromise ("feds"). It is my belief that many other people are interested in handling this better, too, rather than discarding it, especially with politics so polarised in the USA. On 1/31/21, David Barrett <dbarrett@expensify.com> wrote:
That. In the real world, we can't all hand build and personally operate our own billion dollar fab to ensure atomic-level security of our entire vertical supply chain. And even if you could... who's to say the Feds
No, but the closer we come to doing that the more potential issues are handled by it. I don't know a lot about threat modeling, but I do understand that it is not black and white, but rather a spectrum of gray areas with complex patterns.
don't sneak in and swap your device with a perfect duplicate when you aren't looking? Ultimately if you are trying to protect yourself from the combined might of, oh, 8 billion other people, you're going to have a tough time of it. I'm not building for that use case (nor is anyone else). I'm
People are indeed building for this usecase. You say concern for nation-state adversaries more and more present in open source software.
https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-dete...
How do you know they aren't an NSA front? Ultimately, you can't. At some point you've got no choice but to trust someone.
This wasn't my message to reply, but in my opinion the fewer people you need to trust, the easier it is to verify their trustworthiness. Everyone is an NSA front so long as groups like the NSA can surveil and pressure them. - the nitropad is marketed to investigative journalists. even mentioning that investigative journalists _exist_ is a point of trust. - the nitropad supports qubes. qubes is a community-built operating system that upped the public norms of security. - the nitropad uses coreboot, and open source bootloader the community has been clammering for more use of. the boot-loader being open source makes it much more dangerous to put backdoors into it. I'm sure somebody with more familiarity with nitrokey could enumerate many more points of trustworthiness compared to what you normally see.
It would make sense to contribute or work with a project like Signal rather
than making a new messenger
Well my job is to secure the privacy of Expensify's millions of users, not just shut down shop and tell them to use Signal (especially since Signal doesn't offer the wide range of preaccounting functionality we do).
That wasn't what I said, but I'm quite happy you contributed to sqlite. Signal also offers standalone libraries in Java, C, and Javascript. See near the bottom of https://signal.org/docs/ . Signal is also one in a huge ecosystem of messengers, any of which may have done some of what you are trying to do already. I don't really understand the role of messaging in expensify to have ground to stand on here, of course.
The only reasonable way to sell something on an app store is to distribute
a binary. Meanwhile with the source available, people can build their own clients, and share them via other channels.
I totally agree, no real world system can grow if it presumes everyone builds their own binaries (and presumably inspects the source code personally to make sure nothing was slipped in via Github when pulling down the repo). My only point is real-world systems do not exist in a vacuum: the only way to realistically build a secure communication system used by billions is to rely upon trusting _the very people you don't want to monitor you_ to allow you to do so without interference. It's a harsh, brutal reality, but there it is.
I think of things like app stores as more a way to get the app known and used. It is also only one avenue of compromise. It only takes one compromised person to compare the downloaded binary to identify the compromise, and if they have a lawyer friend then things improve. In communities where people get messed with, often there is a techy person who can build things from source when relevant.
I visited expensify.cash but didn't notice an obvious link to the source code. It can be hard for me to see things, though.
Ah, sorry! It's a new project so we're mostly focused on curating a small set of dedicated contributors before going too wide. But you can see it here: https://github.com/Expensify/Expensify.cash -- Sign up at https://Expensify.cash and enter your Github handle, and we'll invite you to the various testflights and such. We're also hiring freelancers to help out -- here are a bunch of open jobs, and we're adding more all the time:
https://www.upwork.com/search/jobs/?q=Expensify%20React%20Native
Thanks for your welcoming reply.
Thank you so much for your open source work. Please work with existing
open source projects when you can both benefit from the work, so the community can grow.
I 100% agree. We're major sponsors of SQLite, and have also open-sourced our BedrockDB.com, which was running a blockchain in production before it was cool: https://bedrockdb.com/blockchain.html
Here is information on signal's reproducible builds:
https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds You actually can verify that the app from the play store is the one you have the source to.
Whoa, that's neat! But doesn't change my point: unless everyone is doing this -- and doing it for every single upgrade -- it doesn't really matter. This is a neat parlor trick to create a sense of trust, but I think it's a
It's not really a parlor trick. Developers have been working very, very hard to make reproducible builds a thing. Signal's approach is very nascent. It could be very easy to do this, the work just hasn't gone in there yet. Additionally, it really does help when only a single empowered person does this. With secure messaging, they can share the proof it happened with everybody else.
kind of disingenuous performance of security theatre: that's like shining a spotlight on Trump's 20 mile border wall while ignoring that it's a very incomplete protection. Verifying the APK that you are getting from Google Play never actually makes sense:
1. If the feds *have* identified your device AND you are a sufficiently interesting person of interest that they would force Google to ship you a compromised APK -- they could also just force Google to ship you a compromised, invisibly-installed system update. Verifying the APK doesn't prove anything.
I thought the system update is distributed by your phone's vendor, as opposed to google. I could be wrong. Many people do not install system updates, or run their own ROMs. These things can also be verified, themselves.
2. If the feds *have not* identified your device, or you are NOT sufficiently interesting to warrant being compromised, then verifying the APK won't ever find anything.
Far more avenues than just 'feds'. Your build machine could have malware that gets into the APK, or somebody could falsify your upload. Google's servers could be compromised. You could get personally coerced or bribed to spread a compromised APK. With reproducible builds, it offers trust and transparency, that people can see clearly what happens if something does.
Whether you are or are not a target, if you are installing Signal via Google Play, you sorta have no choice but to assume that Signal and Google haven't been compromised: if you believe that, then there's no need to verify. But if you do NOT believe that, then verifying it isn't nearly enough. (Especially when no amount of securing your own device will secure the device of the person you are talking to -- who if you are a target, is probably also a target, or at least you shouldn't assume they aren't.)
There is a huge, extensive system and network path between your source code, and the device of an end user. Any point on that path can be a point of compromise, given all the vulnerabilities we have seen over the years. I don't know a lot about threat modeling but I don't assume that the feds are the only people doing these compromises. I imagine anyone with a lot of money could find somebody to do this. Re insecure devices, secure messaging is kind of silly if the person you want to be private from is remotely observing what your screen is displaying. Everything is a puzzle with many pieces. We're responsible for our pieces of that puzzle.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 31, 2021 7:28 PM, David Barrett <dbarrett@expensify.com> wrote:
Thanks for all the great comments! Combining the responses:
I asssume when talking about design proposals, for secure comms, that always Android and iOS devices are used. Are people aware when using such devices, about zero-click exploits, from Pegasus (NSO Group, or FinFisher/FinSpy? I sold my smartphone exactly for that reason and switched to a dumb phone
Yes, I talk about this a bit here: https://gist.github.com/quinthar/44e1c4f63f84556a9822ebf274dc510a#the-feds, but...
exactly right. And the open source OS should be running on non-compromised hardware. Oh, wait.
That. In the real world, we can't all hand build and personally operate our own billion dollar fab to ensure atomic-level security of our entire vertical supply chain. And even if you could... who's to say the Feds don't sneak in and swap your device with a perfect duplicate when you aren't looking? Ultimately if you are trying to protect yourself from the combined might of, oh, 8 billion other people, you're going to have a tough time of it. I'm not building for that use case (nor is anyone else). I'm building for the billions of people who aren't trying to protect themselves from the Feds, but from other more common (even if more mundane) privacy threats.
https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-dete...
How do you know they aren't an NSA front? Ultimately, you can't. At some point you've got no choice but to trust someone.
It would make sense to contribute or work with a project like Signal rather than making a new messenger
Well my job is to secure the privacy of Expensify's millions of users, not just shut down shop and tell them to use Signal (especially since Signal doesn't offer the wide range of preaccounting functionality we do).
The only reasonable way to sell something on an app store is to distribute a binary. Meanwhile with the source available, people can build their own clients, and share them via other channels.
I totally agree, no real world system can grow if it presumes everyone builds their own binaries (and presumably inspects the source code personally to make sure nothing was slipped in via Github when pulling down the repo). My only point is real-world systems do not exist in a vacuum: the only way to realistically build a secure communication system used by billions is to rely upon trusting _the very people you don't want to monitor you_ to allow you to do so without interference. It's a harsh, brutal reality, but there it is.
I visited expensify.cash but didn't notice an obvious link to the source code. It can be hard for me to see things, though.
Ah, sorry! It's a new project so we're mostly focused on curating a small set of dedicated contributors before going too wide. But you can see it here: https://github.com/Expensify/Expensify.cash -- Sign up at https://Expensify.cash and enter your Github handle, and we'll invite you to the various testflights and such. We're also hiring freelancers to help out -- here are a bunch of open jobs, and we're adding more all the time:
https://www.upwork.com/search/jobs/?q=Expensify%20React%20Native
Thank you so much for your open source work. Please work with existing open source projects when you can both benefit from the work, so the community can grow.
I 100% agree. We're major sponsors of SQLite, and have also open-sourced our BedrockDB.com, which was running a blockchain in production before it was cool: https://bedrockdb.com/blockchain.html
Here is information on signal's reproducible builds: https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds You actually can verify that the app from the play store is the one you have the source to.
Whoa, that's neat! But doesn't change my point: unless everyone is doing this -- and doing it for every single upgrade -- it doesn't really matter. This is a neat parlor trick to create a sense of trust, but I think it's a kind of disingenuous performance of security theatre: that's like shining a spotlight on Trump's 20 mile border wall while ignoring that it's a very incomplete protection. Verifying the APK that you are getting from Google Play never actually makes sense:
1. If the feds *have* identified your device AND you are a sufficiently interesting person of interest that they would force Google to ship you a compromised APK -- they could also just force Google to ship you a compromised, invisibly-installed system update. Verifying the APK doesn't prove anything.
2. If the feds *have not* identified your device, or you are NOT sufficiently interesting to warrant being compromised, then verifying the APK won't ever find anything.
Whether you are or are not a target, if you are installing Signal via Google Play, you sorta have no choice but to assume that Signal and Google haven't been compromised: if you believe that, then there's no need to verify. But if you do NOT believe that, then verifying it isn't nearly enough. (Especially when no amount of securing your own device will secure the device of the person you are talking to -- who if you are a target, is probably also a target, or at least you shouldn't assume they aren't.)
Current public-key systems have severe limitations in message size, so symmetric key systems make the public-key algorithms far more useful.
Hm, but all encryption has severe limitations in message size -- even symmetric encryption works on relatively small block sizes. This is why the input is split up and something like CBC is used to prevent "known-plaintext" attacks, with each CBC block separately encrypted with the symmetric key.
A direct adaption of CBC with public-key crypto would be an ElGamal construction. This requires two group-elements per block and several operations per block: (1) one fixed-point DH, (2) one arbitrary-point DH, (3) one group-element operation, and (4) and some mapping function to a group-element. Ultimately, you double the message size and have an explosion of CPU time for this construction. Its certainly doable if the message size is small. Lookup DH computation time of x25519 for (1) and (2) for a rough estimation of maximum throughput (ECC will have highest throughput). If ElGamal is unacceptabe in performance, then the construction is loosely based on CBC but differs in the details significantly. There are several ways this can be accomplished, and a whole lot of ways it can go wrong. I've gone through several possible construction techniques in my head, and they all require doubling the message-size, or at least a hash function. Maybe you can come up with something else, but its definitely not easy.
What I'm trying to figure out is why people don't use something like CBC directly on top of public key encryption. Again, I can see the performance advantages of using symmetric keys, but I'm not sure if there is any actual security advantage between:
a. Use DH to generate a symmetric key X from my private key (A.priv) and your public key (B.pub), split input into N blocks, CBC encode and encrypt each block separately with that symmetric key
b. split input into N blocks, CBC encode and encrypt each block separately with your public key (B.pub)
In other words, block-cipher modes are designed to protect against small biases in the ciphertext itself, which is a round-about way of saying you probably don't want to attempt what you are suggesting.
Can you elaborate on what you mean by this? I'm sorry, I'm not quite following it.
Your current description is too vague. You'll need to come up with an actual plan and some rough numbers. And its possible that the construction is trivially busted in the end.
Thank you all for your help, I really appreciate it!
-david
On Sun, Jan 31, 2021 at 2:26 PM Lee Clagett <forum@leeclagett.com> wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, January 29, 2021 2:42 PM, David Barrett <dbarrett@expensify.com> wrote:
Wow, these are (mostly) great responses, and exactly what I was looking for. Thank you! To call out a couple responses:
6, the ratchet protocol produces a hash of previous messages that provides for detection of dropped data, among many other things. pgp does not do this.
It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode). We do this with https://bedrockdb.com/blockchain.html and it works great. However, I get your point that the double ratchet provides other benefits beyond just forward secrecy.
Decryption of destroyed messages is a big thing that signal deters. Journalists can get seriously physically injured when that happens.
Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal.
Re Signal and Javascript, Signal offers its code in a signed binary, and offers the source to that binary for anybody to build and check.
Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code. Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
They [Signal] have an automated system that gives their donated money to people who contribute improvements.
Wait really? I'm not really finding that mentioned anywhere; can you link me to this? The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribu...
Arguably the simplest method is to do what you describe [encrypting every message with the recipient's public key]. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher.
I'd really love to learn more about this, as I think I almost understand it, but not quite. Can you elaborate on what you mean by "If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret."
All public-key crypto systems (afaik) use some fixed-sized mathematical group. The size of the group, and the actual math operations involved differ depending on the system (RSA, DH, ECDH, ElGamal, etc). You cannot send messages of arbitrary size using these systems, because all operations involve a fixed number of elements (or bits). As an example, [0-11) is a mathematical field (and therefore group) consisting of 10 elements. Sending an arbitrary message requires a mapping function to/from these 10 elements. The mapping function must be isomorphic - the "inverse" is the tricky part because you cannot have a ciphertext that maps to 10,000 equally possible plaintexts. Even with fairly large groups, the number of possible plaintexts is typically far too large (usually infinite). Or very precisely, you can definitely develop an ElGamal system where plaintext messages map to a group element, but the number of possible messages must be limited to the size of the group (again, afaik).
If messages are constrained to "secret keys", then public-key crypto systems can be used to "pass" or share secret bits. The next problem is ensuring that these secret bits are not accidentally leaked when encrypting messages. Symmetric ciphers are designed to prevent this type of leakage ("confusion"), which is probably why every system is a hybrid of public-key and symmetric crypto.
I get that any encryption (symmetric or otherwise) works on blocks, so to encrypt anything larger than one block requires splitting the input up into many blocks. And I get that there are concerns with accidentally revealing information by encrypting the same exact block back to back (ie, it reveals "the same block appeared twice", without revealing the actual block content itself). (More on all that here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality...)
But I'm not quite understanding why you suggest that you couldn't just use a CBC strategy (where each block is derived from the block that preceded it) in conjunction with public key encryption to just encrypt every block with the recipient's public key, eliminating the need for the shared symmetric encryption key.
One obvious problem is with known-plaintext attacks. If any bits are known in advance to an attacker - even if its "frame" data (JSON, etc.) - then this information is propagated to later blocks. There must be confusion+diffusion at every stage. In all major cipher block-modes, previous ciphertexts are only used if the result is put back through the cipher. In other words, block-cipher modes are designed to protect against small biases in the ciphertext itself, which is a round-about way of saying you probably don't want to attempt what you are suggesting.
A public-key operation for every block is needed, or a hash function or cipher is needed. And using only a hash function is iffy because of the compression stage; (probably) only Keccak/SHA3 is recommended if the PRF is used directly (the authors have proposed this function for use as a stream-cipher).
Now, understand the performance advantages of symmetric over asymmetric encryption, and certainly the convenience (and bandwidth) advantages of having multiple parties all use the same key (ie, to avoid re-encrypting the same message separately for each recipient). But I don't see any actual security advantage to introducing the symmetric key (and arguably a disadvantage given the increased complexity it adds).
Current public-key systems have severe limitations in message size, so symmetric key systems make the public-key algorithms far more useful.
Thanks for all these answers, I really appreciate them! -david
On Tue, Jan 26, 2021 at 12:17 AM <jamesd@echeque.com> wrote:
On 2021-01-26 04:31, David Barrett wrote:
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works.
It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes.
Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds.
And you then use the authenticated shared secret for the rest of the session.
Lee
Lee
On 01/02/2021 20:56, Lee Clagett wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 31, 2021 7:28 PM, David Barrett <dbarrett@expensify.com> wrote:
GCM? SIDH? I haven't read much of this thread. The main reason for the use of a symmetric cipher is necessary resource conservation. Peter Fairbrother
Hello! Don't trust anything anyone says here unless you find somebody who says the opposite thing, and judge other statements from both people to see whether they are saying true stuff or not. I'm an ex-activist who posts during his delusional psychotic breaks, not a cryptographer. On 1/24/21, David Barrett <dbarrett@expensify.com> wrote:
Hi all, I'm the CEO a company called Expensify, developing a new open source chat application at https://Expensify.cash. I was pretty prolific on the p2p-hackers mailing list back in the day, but this is my first post to Cypherpunk, so... hi!
Punk's comment on javascript has merit. It's hard to secure javascript. It's gotten easier, but it's still designed for the web, where everything you do is handed to you by a stranger.
I'm writing because I've read a bunch of overviews of *how* the protocol is designed, but I haven't really seen good sources explaining (in a dumbed-down enough manner for me to follow) *why* it was designed that way. In general, I'm trying to understand the reasoning behind the Signal protocol in terms of what real world attacks each of its features defends against, because on the surface it seems _really_ complicated in order to protect against only a very narrow range of attacks.
It's been a while since I used signal, but it did these things amazingly well: 1. getting cryptography into a solid UI that anybody can use. ease-of-access is cryptography's biggest problem. 2. open source and demonstrating transparent honesty about open source going forward. most attempts fail this. 3. used modern cryptographic research to produce something that is above and beyond the current norm. because research is always advancing, this should happen with every product. 4. perfect forward secrecy. addresses the issue with pgp where future advancements decrypt all your messages 5. metadata encryption. pgp does not do this 6, the ratchet protocol produces a hash of previous messages that provides for detection of dropped data, among many other things. pgp does not do this. 7. the software is maintained and improved. pgp does not do this. 8. other stuff, i dunno. my focus was on #6. it's a big hole in pgp to not have a way to verify a message was read when replied to, in this modern environment.
However, I imagine every bit of that complexity has a purpose, and thus I figured this was the right place to try to get to the bottom of that purpose. If you have some other link that you think does a great job breaking it down, I'm all ears! Until then, here are some questions I'd love your help with:
I think if you break your questions into smaller parts, and ask those parts in ways that demonstrate you have an understanding of cryptography already somewhat, more people who are busy doing their jobs may take time to answer you, but really clear security is a topic where everyone lies for some reason, it seems.
1) This is perhaps an obvious question (I've got to start somewhere, after all), but what is the downside of the simplest possible solution, which I think would be for all participants to publish a public key to some common key server, and then for each participant in the chat to simply re-encrypt the message N-1 times -- once for each participant in the chat (minus themselves) using each recipient's public key?
Basically this approach has a huge number of problems that a real cryptographer would enumerate with extensive technical words. Some of them are plugged in signal. For example, the 'forward secrecy' which makes it hard to decrypt archived information when the cipher is compromised, later. In your example storing your message provides for straightforward decryption when technology advances.
2) I would think the most significant problem with this ultra-simple design is just performance: asymmetric encryption is just too expensive in practice to use for every single message, especially given the O(n) cost of re-encrypting for every single recipient. Accordingly, the vast majority of the complexity of the Signal protocol is really just a performance optimization exercise to securely create (and rotate) a shared symmetric key that enables high-performance encryption/decryption. Is that right? Said another way, if asymmetric encryption had adequate performance for a given use case, would that obviate most of the advantage of the Signal protocol?
Is performance really an issue when these algorithms were designed so long ago? Is this something addressed by the algorithms chosen in Signal? I think occasionally saying the word 'key rotation' is different from the concept of a 'ratchet protocol'. If you rotate your keys every message, then I would start reviewing the details of the protocol to see what other differences are.
3) The other problem with the ultra-simple design would be a lack of forward secrecy: if anyone's private key were compromised, all historical messages sent to them could be decrypted (assuming the attacker had stored them). But even with the Signal protocol, if someone's local device were compromised (the most likely way for an attacker to get the private key), they're screwed anyway, in two different ways:
a. The act of compromising the private key would likely ALSO compromise nearly all past communications. So all that hard work to rotate historical keys is kind of pointless if the messages themselves are compromised on device.
The hard work is effective on the network level. Other people on the same networks can capture the data in transit, and try to decrypt it.
b. If the private key itself (which is *only* stored on the device) were compromised *without* also revealing the messages stored on that same device (though how this would happen I'm struggling to understand), then an attacker could still decrypt all past communications if they had a perfect record going back to the start.
Not really an answer to your point, which seems similar ot the one before, but one of the things Signal does is it _gets the code and protocol out there_. It is totally possible to keep your key on an airgapped device in a shielded case you chain to your neck, and communicate with people's mobile phones in a secure manner by moving protocol data in and out of that box when you enjoy, without them ever having to set up PGP. Other people can build even more secure projects, on top of the code that already exists.
4) So in summary, is it safe to say that the primary real-world advantages of the Signal protocol over the super-basic solution are:
a. achieve high performance encryption using frequently rotated symmetric keys, and
b. prevent an attacker who has compromised the device AND has a partial record of communications from decrypting messages that are no longer stored on that device.
Decryption of destroyed messages is a big thing that signal deters. Journalists can get seriously physically injured when that happens.
Is that the gist of it? Again, these are real high level questions, so I appreciate your patience with me!
-david Founder and CEO of Expensify
I haven't visited your site, I'm sorry!
On 1/24/21, David Barrett <dbarrett@expensify.com> wrote:
Hi all, I'm the CEO a company called Expensify, developing a new open source chat application at https://Expensify.cash. I was pretty prolific on the p2p-hackers mailing list back in the day, but this is my first post to Cypherpunk, so... hi!
Punk's comment on javascript has merit. It's hard to secure javascript. It's gotten easier, but it's still designed for the web, where everything you do is handed to you by a stranger.
Re Signal and Javascript, Signal offers its code in a signed binary, and offers the source to that binary for anybody to build and check. I'm not aware that javascript has a way to provide cryptographic signatures of its code, but I've been out of the loop for a while. Basically a number of the design choices around signal demonstrate trust. Some do not. But more than most projects out there.
On Mon, 25 Jan 2021 14:06:51 -0500 Karl <gmkarl@gmail.com> wrote:
On 1/24/21, David Barrett <dbarrett@expensify.com> wrote:
Hi all, I'm the CEO a company called Expensify, developing a new open source chat application at https://Expensify.cash. I was pretty prolific on the p2p-hackers mailing list back in the day, but this is my first post to Cypherpunk, so... hi!
Punk's comment on javascript has merit. It's hard to secure javascript. It's gotten easier, but it's still designed for the web, where everything you do is handed to you by a stranger.
Re Signal and Javascript, Signal offers its code in a signed binary, and offers the source to that binary for anybody to build and check. I'm not aware that javascript has a way to provide cryptographic signatures of its code, but I've been out of the loop for a while.
yeah the 'javascript model' is : you automatically run un-audited, obfuscated random garbage from random arpanet websites. The way 'javascript' is used is of course insane...and malicious. It's funny to see people "developing a new open source chat application" who can't even make a basic website which isn't fucking malware. On the other hand it should be obvious that nobody should touch mr barrett's "app" even with a ten foot pole given the way he treats the visitors to his site.
Basically a number of the design choices around signal demonstrate trust. Some do not. But more than most projects out there.
On 1/25/21, Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Mon, 25 Jan 2021 14:06:51 -0500 Karl <gmkarl@gmail.com> wrote:
On 1/24/21, David Barrett <dbarrett@expensify.com> wrote:
Hi all, I'm the CEO a company called Expensify, developing a new open source chat application at https://Expensify.cash. I was pretty prolific on the p2p-hackers mailing list back in the day, but this is my first post to Cypherpunk, so... hi!
Punk's comment on javascript has merit. It's hard to secure javascript. It's gotten easier, but it's still designed for the web, where everything you do is handed to you by a stranger.
Whoops! I visited the website and it has nothing to do with secure communications, at all! Totally appropriate use of javascript.
What I think is important to understand is that signal is a centralized
I usually try to say "centralised", I'm kinda weird. Maybe we should leave these kinds of threads unreplied to longer or something.
On Mon, 25 Jan 2021 13:57:21 -0500 Karl <gmkarl@gmail.com> wrote:
4. perfect forward secrecy. addresses the issue with pgp where future advancements decrypt all your messages
As far as I understand it, what signal and other systems do is generate 'ephemeral' keys (per session or even per message). Now, if all traffic is recorded (which of course it is), and the key exchange broken thanks to say 'quantum computers', then the 'ephemeral' keys can be re-created. So as far as I can tell your claim is wrong, and 'perfect forward secrecy' is a misleading marketing term. But I might have got it wrong myself...
5. metadata encryption. pgp does not do this
neither does signal. Or rather https://en.wikipedia.org/wiki/Signal_Protocol#Metadata "In October 2018, Signal Messenger announced that they had implemented a "sealed sender" feature into Signal, which reduces the amount of metadata that the Signal servers have access to by concealing the sender's identifier." Not sure what that actually means. Also "The Signal Protocol does not prevent a company from retaining information about when and with whom users communicate." Of course the protocol does not prevent the server from KNOWING who talks to whom...
On 1/25/21, Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Mon, 25 Jan 2021 13:57:21 -0500 Karl <gmkarl@gmail.com> wrote:
4. perfect forward secrecy. addresses the issue with pgp where future advancements decrypt all your messages
As far as I understand it, what signal and other systems do is generate 'ephemeral' keys (per session or even per message).
Now, if all traffic is recorded (which of course it is), and the key exchange broken thanks to say 'quantum computers', then the 'ephemeral' keys can be re-created. So as far as I can tell your claim is wrong, and 'perfect forward secrecy' is a misleading marketing term.
But I might have got it wrong myself...
Well, I'm too foggy nowadays to understand the protocol, but I read it long ago. The term is mathematical rather than marketing. Obviously if you capture/recreate the private data when it is created you can decrypt everything, because you then are one of the phones.
5. metadata encryption. pgp does not do this
neither does signal. Or rather
https://en.wikipedia.org/wiki/Signal_Protocol#Metadata
"In October 2018, Signal Messenger announced that they had implemented a "sealed sender" feature into Signal, which reduces the amount of metadata that the Signal servers have access to by concealing the sender's identifier."
Not sure what that actually means. Also
"The Signal Protocol does not prevent a company from retaining information about when and with whom users communicate."
Of course the protocol does not prevent the server from KNOWING who talks to whom...
What's important to understand here is that these developers are cryptographers. When they say "metadata that the signal servers have access to" or "does not prevent a company from retaining information" they are talking about much smaller bits of data than people usually talk about. Email server: "your metadata is encrypted and private because our privacy policy says it is" Cryptographer: "your encrypted message could be read because there is a mathematical trail of the statistical distribution of keystrokes in the public record of battery use, so don't trust this with something important" But yeah, never trust what someone says. You have to look at the specificaiton and the implementation to know what's really going on. Signal said they do not prioritise nation-state anonymity back in the day. Back in that day, it was also reasonable to use a different network than Signal's for communications.
On Mon, 25 Jan 2021 14:58:24 -0500 Karl <gmkarl@gmail.com> wrote:
On 1/25/21, Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Mon, 25 Jan 2021 13:57:21 -0500 Karl <gmkarl@gmail.com> wrote:
4. perfect forward secrecy. addresses the issue with pgp where future advancements decrypt all your messages
As far as I understand it, what signal and other systems do is generate 'ephemeral' keys (per session or even per message).
Now, if all traffic is recorded (which of course it is), and the key exchange broken thanks to say 'quantum computers', then the 'ephemeral' keys can be re-created. So as far as I can tell your claim is wrong, and 'perfect forward secrecy' is a misleading marketing term.
But I might have got it wrong myself...
Well, I'm too foggy nowadays to understand the protocol, but I read it long ago.
The term is mathematical rather than marketing.
I don't thin the term is mathematical. Nothing is 'perfect' in cryptography.
Obviously if you capture/recreate the private data when it is created you can decrypt everything, because you then are one of the phones.
That's not what I said. What I said is that the *cyphertext* is intercepted and stored, and then the key exchange broken. Just like it's been done even without using 'quantum computers' https://weakdh.org/ So, I think your understanding of so misleadingly called 'perfect forward secrecy' isn't right.
5. metadata encryption. pgp does not do this
neither does signal. Or rather
https://en.wikipedia.org/wiki/Signal_Protocol#Metadata
"In October 2018, Signal Messenger announced that they had implemented a "sealed sender" feature into Signal, which reduces the amount of metadata that the Signal servers have access to by concealing the sender's identifier."
Not sure what that actually means. Also
"The Signal Protocol does not prevent a company from retaining information about when and with whom users communicate."
Of course the protocol does not prevent the server from KNOWING who talks to whom...
What's important to understand here is that these developers are cryptographers.
What I think is important to understand is that signal is a centralized service and the owners are not to be trusted, at all. Moxie morlonpoke perfectly fits the profile of 'progressive' pentagon agent. So maybe the 'end to end encryption' works, but signal remains a US metadata spying operation, 'endorsed' by the likes of the 'ceo' of twatter. Hard to get a bigger red flag than that by the way.
When they say "metadata that the signal servers have access to" or "does not prevent a company from retaining information" they are talking about much smaller bits of data than people usually talk about.
.....I think it's rather clear what 'metadata' we're talking about. Signal knows who talks to who and when.
Email server: "your metadata is encrypted and private because our privacy policy says it is" Cryptographer: "your encrypted message could be read because there is a mathematical trail of the statistical distribution of keystrokes in the public record of battery use, so don't trust this with something important"
But yeah, never trust what someone says. You have to look at the specificaiton and the implementation to know what's really going on. Signal said they do not prioritise nation-state anonymity back in the day. Back in that day, it was also reasonable to use a different network than Signal's for communications.
'perfect forward secrecy' is a misleading marketing term.
But I might have got it wrong myself...
Well, I'm too foggy nowadays to understand the protocol, but I read it long ago.
The term is mathematical rather than marketing.
I don't thin the term is mathematical. Nothing is 'perfect' in cryptography.
And neither are numbers any less imaginary than the square roots of their negatives. But yeah, the word "perfect" is really misleading when the way to identify secure systems is that they _don't_ advertise perfection, but rather are transparent about their limitations.
Obviously if you capture/recreate the private data when it is created you can decrypt everything, because you then are one of the phones.
That's not what I said. What I said is that the *cyphertext* is intercepted and stored, and then the key exchange broken. Just like it's been done even without using 'quantum computers'
So, I think your understanding of so misleadingly called 'perfect forward secrecy' isn't right.
I don't remember the protocol really well to hold up my end here, and i don't really trust that you're relating forthrightly to revisit it much. does signal use diffie-helman key exchange? does it do it in a way that website describes as known to be vulnerable?
"The Signal Protocol does not prevent a company from retaining information about when and with whom users communicate."
Of course the protocol does not prevent the server from KNOWING who talks to whom...
What's important to understand here is that these developers are cryptographers.
What I think is important to understand is that signal is a centralized service and the owners are not to be trusted, at all. Moxie morlonpoke
That's the whole point of end-to-end encryption. But obviously, don't use centalised hosts for anything if you can avoid. Certainly don't make anything new that uses them. Certainly _do_ accept bribes to do this and then donate the money somewhere and change your identity. Make sure you get evidence of something so you can get witness protection or whatnot.
perfectly fits the profile of 'progressive' pentagon agent. So maybe the
The only people who believe these people are real agents, and not just people secretly drugged and abused by agents, are acting more as the agents than they are.
'end to end encryption' works, but signal remains a US metadata spying operation, 'endorsed' by the likes of the 'ceo' of twatter. Hard to get a bigger red flag than that by the way.
Nah it's more like a bunch of people subjected to international spying operations figuring out the charades work that lets them escape a little bit. Also, free technology for others!
When they say "metadata that the signal servers have access to" or "does not prevent a company from retaining information" they are talking about much smaller bits of data than people usually talk about.
.....I think it's rather clear what 'metadata' we're talking about. Signal knows who talks to who and when.
It doesn't sound like it's clear to you. Metadata lives in bytes that travel over network protocols and are analysed by algorithms. Somebody has probably upgraded the concept now that deepfakes and such are normal.
Email server: "your metadata is encrypted and private because our privacy policy says it is" Cryptographer: "your encrypted message could be read because there is a mathematical trail of the statistical distribution of keystrokes in the public record of battery use, so don't trust this with something important"
But yeah, never trust what someone says. You have to look at the specificaiton and the implementation to know what's really going on. Signal said they do not prioritise nation-state anonymity back in the day. Back in that day, it was also reasonable to use a different network than Signal's for communications.
I suppose the normal-world equivalent of this would be to talk with the developers about a covered up atrocity or something over their network protocol, and see what happens, or somesuch.
On Mon, 25 Jan 2021 16:38:36 -0500 Karl <gmkarl@gmail.com> wrote:
So, I think your understanding of so misleadingly called 'perfect forward secrecy' isn't right.
I don't remember the protocol really well to hold up my end here,
this isn't only about the signal protocol but about any protocol that advertises 'perfect forward secrecy' and uses 'public key cryptography' of the kind that's vulnerable to attacks using 'quantum computers'.
and i don't really trust that you're relating forthrightly to revisit it much.
yeah well. I think I explained the basic problem twice. You don't need to 'trust' me but do your own research.
does signal use diffie-helman key exchange?
yes it does. You're the one pimping it, you shoud know.
does it do it in a way that website describes as known to be vulnerable?
...see your first unfounded claim about 'perfect' secrecy. DH is 'vulnerable' to 'advances in solving the discrete log problem' bla bla.
"The Signal Protocol does not prevent a company from retaining information about when and with whom users communicate."
Of course the protocol does not prevent the server from KNOWING who talks to whom...
What's important to understand here is that these developers are cryptographers.
What I think is important to understand is that signal is a centralized service and the owners are not to be trusted, at all. Moxie morlonpoke
That's the whole point of end-to-end encryption.
Not sure what you mean. So called end to end encryption only encrypts messages. It doesn't magically solve 'traffic analysis' problems.
But obviously, don't use centalised hosts for anything if you can avoid. Certainly don't make anything new that uses them. Certainly _do_ accept bribes to do this and then donate the money somewhere and change your identity. Make sure you get evidence of something so you can get witness protection or whatnot.
perfectly fits the profile of 'progressive' pentagon agent. So maybe the
The only people who believe these people are real agents, and not just people secretly drugged and abused by agents, are acting more as the agents than they are.
bullshit.
'end to end encryption' works, but signal remains a US metadata spying operation, 'endorsed' by the likes of the 'ceo' of twatter. Hard to get a bigger red flag than that by the way.
Nah it's more like a bunch of people subjected to international spying operations figuring out the charades work that lets them escape a little bit. Also, free technology for others!
more bullshit.
When they say "metadata that the signal servers have access to" or "does not prevent a company from retaining information" they are talking about much smaller bits of data than people usually talk about.
.....I think it's rather clear what 'metadata' we're talking about. Signal knows who talks to who and when.
It doesn't sound like it's clear to you. Metadata lives in bytes that travel over network protocols and are analysed by algorithms.
Somebody has probably upgraded the concept now that deepfakes and such are normal.
what are you talking about
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 24, 2021 4:02 PM, David Barrett <dbarrett@expensify.com> wrote:
Hi all, I'm the CEO a company called Expensify, developing a new open source chat application at https://Expensify.cash. I was pretty prolific on the p2p-hackers mailing list back in the day, but this is my first post to Cypherpunk, so... hi!
I'm writing because I've read a bunch of overviews of *how* the protocol is designed, but I haven't really seen good sources explaining (in a dumbed-down enough manner for me to follow) *why* it was designed that way. In general, I'm trying to understand the reasoning behind the Signal protocol in terms of what real world attacks each of its features defends against, because on the surface it seems _really_ complicated in order to protect against only a very narrow range of attacks.
However, I imagine every bit of that complexity has a purpose, and thus I figured this was the right place to try to get to the bottom of that purpose. If you have some other link that you think does a great job breaking it down, I'm all ears! Until then, here are some questions I'd love your help with:
1) This is perhaps an obvious question (I've got to start somewhere, after all), but what is the downside of the simplest possible solution, which I think would be for all participants to publish a public key to some common key server, and then for each participant in the chat to simply re-encrypt the message N-1 times -- once for each participant in the chat (minus themselves) using each recipient's public key?
Arguably the simplest method is to do what you describe. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher. And even if you drop the symmetric cipher, you cannot use the shared-number directly since bias in bits must be removed. Typically the process is public_key/secret_key->shared_secret->key_derivation(hash)->cipher You might be interested in reading the SpiderOak chat room open specification too.
2) I would think the most significant problem with this ultra-simple design is just performance: asymmetric encryption is just too expensive in practice to use for every single message, especially given the O(n) cost of re-encrypting for every single recipient. Accordingly, the vast majority of the complexity of the Signal protocol is really just a performance optimization exercise to securely create (and rotate) a shared symmetric key that enables high-performance encryption/decryption. Is that right? Said another way, if asymmetric encryption had adequate performance for a given use case, would that obviate most of the advantage of the Signal protocol?
If you had short messages and used ECC, then doing direct encryption without a cipher is arguably safer (less systems) and reasonably efficient. But every 32-bytes sent requires a 32-byte key and a reasonable bump in CPU time (assuming x25519). The protocol would still be annoying because of all of the keys involved but probably workable if the message size is constrained.
3) The other problem with the ultra-simple design would be a lack of forward secrecy: if anyone's private key were compromised, all historical messages sent to them could be decrypted (assuming the attacker had stored them). But even with the Signal protocol, if someone's local device were compromised (the most likely way for an attacker to get the private key), they're screwed anyway, in two different ways:
a. The act of compromising the private key would likely ALSO compromise nearly all past communications. So all that hard work to rotate historical keys is kind of pointless if the messages themselves are compromised on device.
The participants can delete messages. Without forward secrecy, an adversary that has collected+stored the ciphertext can recover the plaintext from their stored ciphertext copy once they obtain the shared-secret used in the chat. With forward secrecy, the participants delete older shared-secrets preventing an adversary from recovering deleted messages. Also, cracking the single public-key would allow the recovery of all plaintexts; with forward secrecy the adversary is forced to crack multiple keys. This helps with privacy as the crypto and bit-length ages.
b. If the private key itself (which is *only* stored on the device) were compromised *without* also revealing the messages stored on that same device (though how this would happen I'm struggling to understand), then an attacker could still decrypt all past communications if they had a perfect record going back to the start.
Once the participants delete the secret components of the key-exchange, recovery from ciphertext should not be possible without breaking the crypto primitives. Certainly possible, but there isn't a technique publicly known.
4) So in summary, is it safe to say that the primary real-world advantages of the Signal protocol over the super-basic solution are:
a. achieve high performance encryption using frequently rotated symmetric keys, and
I'm not sure you'd want to design a system without symmetric ciphers for the reasons I listed above. Although it could be an interesting experiment I guess.
b. prevent an attacker who has compromised the device AND has a partial record of communications from decrypting messages that are no longer stored on that device.
If you change "partial record" to "complete record" then this sentence is accurate.
Is that the gist of it? Again, these are real high level questions, so I appreciate your patience with me! -david Founder and CEO of Expensify
Lee
On Mon, 25 Jan 2021 22:25:22 +0000 Lee Clagett <forum@leeclagett.com> wrote:
With forward secrecy, the participants delete older shared-secrets preventing an adversary from recovering deleted messages. Also, cracking the single public-key would allow the recovery of all plaintexts; with forward secrecy the adversary is forced to crack multiple keys. This helps with privacy as the crypto and bit-length ages.
that's for karl. 'forward secrecy' simply adds more key exchanges, but if the key exchange mechanism itself is broken, then foward secrecy...doesn't exist.
participants (8)
-
David Barrett -
jamesd＠echeque.com -
Karl -
Lee Clagett -
Peter Fairbrother -
Punk-BatSoup-Stasi 2.0 -
Stefan Claas -
Zenaan Harkness