mirror of
https://github.com/simplex-chat/simplex-chat.git
synced 2026-04-14 13:55:54 +00:00
deploy: dd75d30c08
This commit is contained in:
@@ -375,7 +375,7 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<p>This post also covers various aspects of end-to-end encryption, compares different messengers, and explains why and how quantum-resistant encryption is added to SimpleX Chat:</p>
|
||||
<ul>
|
||||
<li><a href="#why-do-we-need-end-to-end-encryption">Why do we need end-to-end encryption?</a></li>
|
||||
<li><a href="#why-encryption-is-even-allowed">Why encryption is even allowed?</a></li>
|
||||
<li><a href="#why-is-encryption-even-allowed">Why is encryption even allowed?</a></li>
|
||||
<li><a href="#end-to-end-encryption-security-attacks-and-defense">End-to-end encryption security: attacks and defense.</a>
|
||||
<ul>
|
||||
<li>Compromised message size - mitigated by padding messages to a fixed block size.</li>
|
||||
@@ -397,7 +397,7 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<p>Achieving the latter requires a lot of mathematical precision in both the cryptographic algorithms and in how they are used, and effectively makes encrypted messages indistinguishable from random noise, without any discoverable patterns or statistical irregularities that a computer could use to break the message encryption any faster than it it would take to try every possible combination of bits in the key.</p>
|
||||
<p>End-to-end encryption is an important component of our individual and business security, privacy and sovereignty. Having our private communications protected from any observers is both the natural condition and our inalienable human right.</p>
|
||||
<p>It's very sad to see the same people who keep their financial affairs private to protect from financial crimes, lock their doors to protect from thieves, and curtain their windows to protect from the occasional prying eyes, when it comes to protecting their personal lives from the data criminals say "we don't care about privacy, we have nothing to hide". Everybody's safety depends on keeping their affairs and relations private, not visible to a vast and ruthless data gathering machines, that abuse our data for commercial gain, without any regard to our interests or even <a href="https://nmdoj.gov/press-release/attorney-general-raul-torrez-files-lawsuit-against-meta-platforms-and-mark-zuckerberg-to-protect-children-from-sexual-abuse-and-human-trafficking/">the safety of our families and children</a>.</p>
|
||||
<h2 id="why-encryption-is-even-allowed" tabindex="-1">Why encryption is even allowed?</h2>
|
||||
<h2 id="why-is-encryption-even-allowed" tabindex="-1">Why is encryption even allowed?</h2>
|
||||
<img src="./images/20240314-djb.jpg" class="float-to-right">
|
||||
<p>If encryption is such a powerful tool to protect our lives, it also can be used to conceal crimes, so why the governments don't consider it similar to arms, and don't heavily regulate its use?</p>
|
||||
<p>Prior to 1996 the cryptography was considered munition, and its export from the United States was controlled under this category, <a href="https://cr.yp.to/export/1995/0303-eff.txt">alongside flamethrowers and B-1 bombers</a>. When <a href="https://en.wikipedia.org/wiki/Daniel_J._Bernstein">Daniel J. Bernstein</a> (DJB), then a student of Mathematics at University of California, Berkeley, wanted to publish the paper and the source code of his Snuffle encryption system, the Office of Defense Trade Controls of the Department of State (DOS) after more than a year of correspondence requested that DJB registers as the arms dealer.</p>
|
||||
@@ -420,7 +420,7 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<li>if a messenger conceals the routing of the messages to hide the transport identities (IP addresses) of senders and recipients, message sizes can be used by traffic observers to confirm the fact of communication with a much higher degree of certainty.</li>
|
||||
</ul>
|
||||
<p>The only effective mitigation to these attacks is to pad all messages to a fixed size. Using space-efficient schemes like Padme, or padding to encryption block size is ineffective for mitigating these attacks, as they still allow differentiating message sizes.</p>
|
||||
<p>To the best of our knowledge the only messenger other than SimpleX Chat that padded all messages to a fixed packet size was <a href="https://github.com/agl/pond">Pond</a> - SimpleX design as an evolution of it.</p>
|
||||
<p>To the best of our knowledge, the only messengers other than SimpleX Chat that pad all messages to a fixed packet size are Cwtch and no longer developed <a href="https://github.com/agl/pond">Pond</a> - SimpleX design can be seen as an evolution of Pond design.</p>
|
||||
<h3 id="2-compromised-confidential-messages-mitigated-by-repudiation-deniability" tabindex="-1">2. Compromised confidential messages - mitigated by repudiation (deniability)</h3>
|
||||
<p>Many users are very interested in having ability to irreversibly delete sent messages from the recipients devices. But not only would this ability violate data sovereignty of device owners, it is also completely ineffective, as the recipients could simply put the device offline or use a modified client app to ignore message deletion requests. While SimpleX Chat provides such features as <a href="20230103-simplex-chat-v4.4-disappearing-messages.html#disappearing-messages">disappearing messages</a> and the ability to <a href="20221206-simplex-chat-v4.3-voice-messages.html#irreversible-message-deletion">irreversibly delete sent messages</a> provided both parties agree to that, these are convenience features, and they cannot be considered security measures.</p>
|
||||
<p>The solution to that is well known to cryptographers - it is the quality of the encryption algorithms called "repudiation", sometimes also called "deniability". This is the ability of the senders to plausibly deny having sent any messages, because cryptographic algorithms used to encrypt allow recipients forging these messages on their devices, so while the encryption proves authenticity of the message to the recipient, it cannot be used as a proof to any third party.</p>
|
||||
@@ -431,11 +431,11 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<p>The attacker who obtained or broke the keys used to encrypt individual messages, may try to use these keys to decrypt past or future messages. This attack is unlikely to succeed via message interception, and it is likely to require breaking into the device storage. But in any case, if the key was broken or obtained in some other way it's important that this key cannot be used to decrypt other messages - this is achieved by forward secrecy.</p>
|
||||
<p>This property is well understood by the users, and most messengers that focus on privacy and security, with the exception of Session, provide forward secrecy as part of their encryption schemes design.</p>
|
||||
<h3 id="4-compromised-long-term-or-session-mitigated-by-break-in-recovery" tabindex="-1">4. Compromised long-term or session - mitigated by break-in recovery</h3>
|
||||
<p>This attack is much less understood by the users, and forward secrecy does not protect from it. Arguably, it's almost impossible to compromise individual message keys without compromising long-term or session keys. So the ability of the encryption to recover from break-in (attacker making a copy of the device data without retaining the ongoing access) is both very and pragmatic - break-in attacks are simpler to execute on mobile devices during short-term device access than long-term ongoing compromise.</p>
|
||||
<p>Out of all encryption algorithms known to us only Signal double ratchet algorithm provides the ability to encryption security after break-ins. This recovery happens automatically and transparently to the users, without them doing anything special even knowing about break-in, by simply sending messages. Every time one of the communication parties replies to another party message, new random keys are generated and previously stolen keys become useless.</p>
|
||||
<p>Signal double ratchet algorithm is used in Signal, Cwtch and SimpleX Chat. This is why you cannot use SimpleX Chat profile on more than one device at the same time - the encryption scheme rotates the long term keys, randomly, and keys on another device become useless, as they would become useless for the attacker who stole them. Security always has some costs to the convenience.</p>
|
||||
<p>This attack is much less understood by the users, and forward secrecy does not protect from it. Arguably, it's almost impossible to compromise individual message keys without compromising long-term or session keys. So the ability of the encryption to recover from break-in (attacker making a copy of the device data without retaining the ongoing access) is both very important and pragmatic - break-in attacks are simpler to execute on mobile devices during short-term device access than long-term ongoing compromise.</p>
|
||||
<p>Out of all encryption algorithms known to us only <em>Signal double ratchet algorithm</em> (also referred to as <em>Signal algorithm</em> or <em>double ratchet algorithm</em>, which is not the same as Signal messaging platform and protocols) provides the ability for the encryption security to recover after break-ins attacks. This recovery happens automatically and transparently to the users, without them doing anything special or even knowing about break-in, by simply sending messages. Every time one of the communication parties replies to another party message, new random keys are generated and previously stolen keys become useless.</p>
|
||||
<p>Double ratchet algorithm is used in Signal, Cwtch and SimpleX Chat. This is why you cannot use SimpleX Chat profile on more than one device at the same time - the encryption scheme rotates the long term keys, randomly, and keys on another device become useless, as they would become useless for the attacker who stole them. Security always has some costs to the convenience.</p>
|
||||
<h3 id="5-man-in-the-middle-attack-mitigated-by-two-factor-key-exchange" tabindex="-1">5. Man-in-the-middle attack - mitigated by two-factor key exchange</h3>
|
||||
<p>Many people incorrectly believe that security of end-to-end encryption cannot be broken by communication provider. But end-to-end encryption is as secure as key exchange. While any intermediary passing the keys between senders and recipients cannot recover the private keys from the public keys, they can simply replace the passed public keys with their own and then proxy all communication between the users having full access to the original messages. So instead of having an end-to-end encrypted channel, users would have two half-way encrypted channels - between users and their communication intermediary.</p>
|
||||
<p>Many people incorrectly believe that security of end-to-end encryption cannot be broken by communication provider. But end-to-end encryption is only as secure as key exchange. While any intermediary passing the keys between senders and recipients cannot recover the private keys from the public keys, they can simply replace the passed public keys with their own and then proxy all communication between the users having full access to the original messages. So instead of having an end-to-end encrypted channel, users would have two half-way encrypted channels - between users and their communication intermediary.</p>
|
||||
<p>Pictures below illustrate how this attack works for RSA encryption.</p>
|
||||
<h4 id="1-alice-sends-the-key-to-bob-eg-via-p2p-network-or-via-the-messaging-server" tabindex="-1">1) Alice sends the key to Bob (e.g. via p2p network or via the messaging server).</h4>
|
||||
<p><img src="./images/20240314-mitm1.jpg" alt="Public key is shared"></p>
|
||||
@@ -458,7 +458,7 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<li>many of post-quantum algorithms have known patent claims, so any system deploying them accepts the risks of patent litigation.</li>
|
||||
<li>the silver lining to these limitations is that the risk of appearance of commercially viable quantum computers in the next decade may be exaggerated.</li>
|
||||
</ul>
|
||||
<p>So, to put it bluntly and provocatively, post-quantum cryptography can be compared with a remedy against the illness that nobody has, without any guarantee that it will work. The closest analogy in the history of medicine is <em>snake oil</em>.</p>
|
||||
<p>So, to say it provocatively, post-quantum cryptography can be compared with a remedy against the illness that nobody has, without any guarantee that it will work. While there is a reasonable hope that it <em>might</em> work, so it's not exactly a <em>snake oil</em>, these limitations and risks have to be much better communicated to the end users than they are.</p>
|
||||
<img src="./images/20240314-datacenter.jpg" width="400" class="float-to-right">
|
||||
<p>Does it mean that post-quantum cryptography is useless and should be ignored? Absolutely not. The risks of "record now, decrypt later" attacks are real, particularly for high profile targets, including millions of people - journalists, whistle-blowers, freedom-fighters in oppressive regimes, and even some ordinary people who may become targets of information crimes. Large scale collection of encrypted communication data is ongoing, and this data may be used in the future. So having the solution that <em>may</em> protect you (post-quantum cryptography), as long as it doesn't replace the solution that is <em>proven</em> to protect you (conventional cryptography), is highly beneficial in any communication solution, and has already been deployed in many tools and in some messengers.</p>
|
||||
<h2 id="how-secure-is-end-to-end-encryption-in-different-messengers" tabindex="-1">How secure is end-to-end encryption in different messengers?</h2>
|
||||
@@ -471,8 +471,8 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<ul>
|
||||
<li>when messages are padded, but not to a fixed size.</li>
|
||||
<li>when repudiation does not include client-server connection. In case of Cwtch it appears that the presence of cryptographic signatures compromises repudiation (deniability), but it needs to be clarified.</li>
|
||||
<li>when 2-factor key exchange is optional, via security code verification.</li>
|
||||
<li>when post-quantum cryptography is only added to the initial key agreement, does not protect break-in recovery.</li>
|
||||
<li>when 2-factor key exchange is optional (via security code verification).</li>
|
||||
<li>when post-quantum cryptography is only added to the initial key agreement and does not protect break-in recovery.</li>
|
||||
</ul>
|
||||
<h2 id="adding-quantum-resistance-to-signal-double-ratchet-algorithm" tabindex="-1">Adding quantum resistance to Signal double ratchet algorithm</h2>
|
||||
<p>We have been exploring post-quantum cryptography since early 2022, when SimpleX Chat was first released, and we did not want to be pioneers here - cryptography is critically important to make it right.</p>
|
||||
@@ -498,7 +498,7 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<li>enable <em>Show developer options</em> toggle.</li>
|
||||
<li>now you will see <em>Post-quantum E2EE</em> toggle - enable it as well.</li>
|
||||
</ul>
|
||||
<p>Now all new contacts you add to the app will use quantum resistant Signal double ratchet algorithm.</p>
|
||||
<p>Now all new contacts you add to the app will use quantum resistant double ratchet algorithm.</p>
|
||||
<p>Once you have enabled it for the new contacts, you can also <strong>enable it for some of the existing contacts</strong>:</p>
|
||||
<ul>
|
||||
<li>open the chat with the contact you want to upgrade to be quantum resistant.</li>
|
||||
@@ -507,7 +507,7 @@ window.addEventListener('scroll',changeHeaderBg);
|
||||
<li>exchange several messages back and forth with that contact - the quantum resistant double ratchet will kick in after 3-5 messages (depending on how many messages you send in each direction), and you will see the notice in the chat once it enables.</li>
|
||||
</ul>
|
||||
<h2 id="next-for-post-quantum-crypto-all-direct-chats-small-groups-and-security-audit" tabindex="-1">Next for post-quantum crypto - all direct chats, small groups and security audit</h2>
|
||||
<p>We will be making quantum resistance default for all direct chats in v5.7, and they will be upgraded for all users without any action.</p>
|
||||
<p>We will be making quantum resistance default for all direct chats in v5.7, and we plan that all existing direct chats will be automatically upgraded when both contacts install v5.7.</p>
|
||||
<p>We will also be adding quantum resistance to small groups up to 10-20 members. Computing cryptographic keys is much slower, in comparison, and it would be very inefficient (and completely unnecessary) for large public groups.</p>
|
||||
<p>We have also arranged a 3rd party cryptographic review of our protocol and encryption schemes design for June/July 2024 - it will cover the additions to SimpleX protocols since <a href="20221108-simplex-chat-v4.2-security-audit-new-website.html">the previous security audit</a> in November 2022, including <a href="20230301-simplex-file-transfer-protocol.html">XFTP protocol</a> we use for file transfers and quantum resistant Signal double ratchet algorithm we just released in this beta version.</p>
|
||||
<p>In November 2024 we will be conducting further implementation audit, with double the scope of our 2022 audit.</p>
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 136 KiB After Width: | Height: | Size: 134 KiB |
24
feed.atom
24
feed.atom
@@ -1976,7 +1976,7 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<p>This post also covers various aspects of end-to-end encryption, compares different messengers, and explains why and how quantum-resistant encryption is added to SimpleX Chat:</p>
|
||||
<ul>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#why-do-we-need-end-to-end-encryption">Why do we need end-to-end encryption?</a></li>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#why-encryption-is-even-allowed">Why encryption is even allowed?</a></li>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#why-is-encryption-even-allowed">Why is encryption even allowed?</a></li>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#end-to-end-encryption-security-attacks-and-defense">End-to-end encryption security: attacks and defense.</a>
|
||||
<ul>
|
||||
<li>Compromised message size - mitigated by padding messages to a fixed block size.</li>
|
||||
@@ -1998,7 +1998,7 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<p>Achieving the latter requires a lot of mathematical precision in both the cryptographic algorithms and in how they are used, and effectively makes encrypted messages indistinguishable from random noise, without any discoverable patterns or statistical irregularities that a computer could use to break the message encryption any faster than it it would take to try every possible combination of bits in the key.</p>
|
||||
<p>End-to-end encryption is an important component of our individual and business security, privacy and sovereignty. Having our private communications protected from any observers is both the natural condition and our inalienable human right.</p>
|
||||
<p>It's very sad to see the same people who keep their financial affairs private to protect from financial crimes, lock their doors to protect from thieves, and curtain their windows to protect from the occasional prying eyes, when it comes to protecting their personal lives from the data criminals say &quot;we don't care about privacy, we have nothing to hide&quot;. Everybody's safety depends on keeping their affairs and relations private, not visible to a vast and ruthless data gathering machines, that abuse our data for commercial gain, without any regard to our interests or even <a href="https://nmdoj.gov/press-release/attorney-general-raul-torrez-files-lawsuit-against-meta-platforms-and-mark-zuckerberg-to-protect-children-from-sexual-abuse-and-human-trafficking/">the safety of our families and children</a>.</p>
|
||||
<h2 id="why-encryption-is-even-allowed" tabindex="-1">Why encryption is even allowed?</h2>
|
||||
<h2 id="why-is-encryption-even-allowed" tabindex="-1">Why is encryption even allowed?</h2>
|
||||
<img src="https://simplex.chat/blog/images/20240314-djb.jpg" class="float-to-right" />
|
||||
<p>If encryption is such a powerful tool to protect our lives, it also can be used to conceal crimes, so why the governments don't consider it similar to arms, and don't heavily regulate its use?</p>
|
||||
<p>Prior to 1996 the cryptography was considered munition, and its export from the United States was controlled under this category, <a href="https://cr.yp.to/export/1995/0303-eff.txt">alongside flamethrowers and B-1 bombers</a>. When <a href="https://en.wikipedia.org/wiki/Daniel_J._Bernstein">Daniel J. Bernstein</a> (DJB), then a student of Mathematics at University of California, Berkeley, wanted to publish the paper and the source code of his Snuffle encryption system, the Office of Defense Trade Controls of the Department of State (DOS) after more than a year of correspondence requested that DJB registers as the arms dealer.</p>
|
||||
@@ -2021,7 +2021,7 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<li>if a messenger conceals the routing of the messages to hide the transport identities (IP addresses) of senders and recipients, message sizes can be used by traffic observers to confirm the fact of communication with a much higher degree of certainty.</li>
|
||||
</ul>
|
||||
<p>The only effective mitigation to these attacks is to pad all messages to a fixed size. Using space-efficient schemes like Padme, or padding to encryption block size is ineffective for mitigating these attacks, as they still allow differentiating message sizes.</p>
|
||||
<p>To the best of our knowledge the only messenger other than SimpleX Chat that padded all messages to a fixed packet size was <a href="https://github.com/agl/pond">Pond</a> - SimpleX design as an evolution of it.</p>
|
||||
<p>To the best of our knowledge, the only messengers other than SimpleX Chat that pad all messages to a fixed packet size are Cwtch and no longer developed <a href="https://github.com/agl/pond">Pond</a> - SimpleX design can be seen as an evolution of Pond design.</p>
|
||||
<h3 id="2-compromised-confidential-messages-mitigated-by-repudiation-deniability" tabindex="-1">2. Compromised confidential messages - mitigated by repudiation (deniability)</h3>
|
||||
<p>Many users are very interested in having ability to irreversibly delete sent messages from the recipients devices. But not only would this ability violate data sovereignty of device owners, it is also completely ineffective, as the recipients could simply put the device offline or use a modified client app to ignore message deletion requests. While SimpleX Chat provides such features as <a href="https://simplex.chat/blog/20230103-simplex-chat-v4.4-disappearing-messages.html#disappearing-messages">disappearing messages</a> and the ability to <a href="https://simplex.chat/blog/20221206-simplex-chat-v4.3-voice-messages.html#irreversible-message-deletion">irreversibly delete sent messages</a> provided both parties agree to that, these are convenience features, and they cannot be considered security measures.</p>
|
||||
<p>The solution to that is well known to cryptographers - it is the quality of the encryption algorithms called &quot;repudiation&quot;, sometimes also called &quot;deniability&quot;. This is the ability of the senders to plausibly deny having sent any messages, because cryptographic algorithms used to encrypt allow recipients forging these messages on their devices, so while the encryption proves authenticity of the message to the recipient, it cannot be used as a proof to any third party.</p>
|
||||
@@ -2032,11 +2032,11 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<p>The attacker who obtained or broke the keys used to encrypt individual messages, may try to use these keys to decrypt past or future messages. This attack is unlikely to succeed via message interception, and it is likely to require breaking into the device storage. But in any case, if the key was broken or obtained in some other way it's important that this key cannot be used to decrypt other messages - this is achieved by forward secrecy.</p>
|
||||
<p>This property is well understood by the users, and most messengers that focus on privacy and security, with the exception of Session, provide forward secrecy as part of their encryption schemes design.</p>
|
||||
<h3 id="4-compromised-long-term-or-session-mitigated-by-break-in-recovery" tabindex="-1">4. Compromised long-term or session - mitigated by break-in recovery</h3>
|
||||
<p>This attack is much less understood by the users, and forward secrecy does not protect from it. Arguably, it's almost impossible to compromise individual message keys without compromising long-term or session keys. So the ability of the encryption to recover from break-in (attacker making a copy of the device data without retaining the ongoing access) is both very and pragmatic - break-in attacks are simpler to execute on mobile devices during short-term device access than long-term ongoing compromise.</p>
|
||||
<p>Out of all encryption algorithms known to us only Signal double ratchet algorithm provides the ability to encryption security after break-ins. This recovery happens automatically and transparently to the users, without them doing anything special even knowing about break-in, by simply sending messages. Every time one of the communication parties replies to another party message, new random keys are generated and previously stolen keys become useless.</p>
|
||||
<p>Signal double ratchet algorithm is used in Signal, Cwtch and SimpleX Chat. This is why you cannot use SimpleX Chat profile on more than one device at the same time - the encryption scheme rotates the long term keys, randomly, and keys on another device become useless, as they would become useless for the attacker who stole them. Security always has some costs to the convenience.</p>
|
||||
<p>This attack is much less understood by the users, and forward secrecy does not protect from it. Arguably, it's almost impossible to compromise individual message keys without compromising long-term or session keys. So the ability of the encryption to recover from break-in (attacker making a copy of the device data without retaining the ongoing access) is both very important and pragmatic - break-in attacks are simpler to execute on mobile devices during short-term device access than long-term ongoing compromise.</p>
|
||||
<p>Out of all encryption algorithms known to us only <em>Signal double ratchet algorithm</em> (also referred to as <em>Signal algorithm</em> or <em>double ratchet algorithm</em>, which is not the same as Signal messaging platform and protocols) provides the ability for the encryption security to recover after break-ins attacks. This recovery happens automatically and transparently to the users, without them doing anything special or even knowing about break-in, by simply sending messages. Every time one of the communication parties replies to another party message, new random keys are generated and previously stolen keys become useless.</p>
|
||||
<p>Double ratchet algorithm is used in Signal, Cwtch and SimpleX Chat. This is why you cannot use SimpleX Chat profile on more than one device at the same time - the encryption scheme rotates the long term keys, randomly, and keys on another device become useless, as they would become useless for the attacker who stole them. Security always has some costs to the convenience.</p>
|
||||
<h3 id="5-man-in-the-middle-attack-mitigated-by-two-factor-key-exchange" tabindex="-1">5. Man-in-the-middle attack - mitigated by two-factor key exchange</h3>
|
||||
<p>Many people incorrectly believe that security of end-to-end encryption cannot be broken by communication provider. But end-to-end encryption is as secure as key exchange. While any intermediary passing the keys between senders and recipients cannot recover the private keys from the public keys, they can simply replace the passed public keys with their own and then proxy all communication between the users having full access to the original messages. So instead of having an end-to-end encrypted channel, users would have two half-way encrypted channels - between users and their communication intermediary.</p>
|
||||
<p>Many people incorrectly believe that security of end-to-end encryption cannot be broken by communication provider. But end-to-end encryption is only as secure as key exchange. While any intermediary passing the keys between senders and recipients cannot recover the private keys from the public keys, they can simply replace the passed public keys with their own and then proxy all communication between the users having full access to the original messages. So instead of having an end-to-end encrypted channel, users would have two half-way encrypted channels - between users and their communication intermediary.</p>
|
||||
<p>Pictures below illustrate how this attack works for RSA encryption.</p>
|
||||
<h4 id="1-alice-sends-the-key-to-bob-eg-via-p2p-network-or-via-the-messaging-server" tabindex="-1">1) Alice sends the key to Bob (e.g. via p2p network or via the messaging server).</h4>
|
||||
<p><img src="https://simplex.chat/blog/images/20240314-mitm1.jpg" alt="Public key is shared" /></p>
|
||||
@@ -2059,7 +2059,7 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<li>many of post-quantum algorithms have known patent claims, so any system deploying them accepts the risks of patent litigation.</li>
|
||||
<li>the silver lining to these limitations is that the risk of appearance of commercially viable quantum computers in the next decade may be exaggerated.</li>
|
||||
</ul>
|
||||
<p>So, to put it bluntly and provocatively, post-quantum cryptography can be compared with a remedy against the illness that nobody has, without any guarantee that it will work. The closest analogy in the history of medicine is <em>snake oil</em>.</p>
|
||||
<p>So, to say it provocatively, post-quantum cryptography can be compared with a remedy against the illness that nobody has, without any guarantee that it will work. While there is a reasonable hope that it <em>might</em> work, so it's not exactly a <em>snake oil</em>, these limitations and risks have to be much better communicated to the end users than they are.</p>
|
||||
<img src="https://simplex.chat/blog/images/20240314-datacenter.jpg" width="400" class="float-to-right" />
|
||||
<p>Does it mean that post-quantum cryptography is useless and should be ignored? Absolutely not. The risks of &quot;record now, decrypt later&quot; attacks are real, particularly for high profile targets, including millions of people - journalists, whistle-blowers, freedom-fighters in oppressive regimes, and even some ordinary people who may become targets of information crimes. Large scale collection of encrypted communication data is ongoing, and this data may be used in the future. So having the solution that <em>may</em> protect you (post-quantum cryptography), as long as it doesn't replace the solution that is <em>proven</em> to protect you (conventional cryptography), is highly beneficial in any communication solution, and has already been deployed in many tools and in some messengers.</p>
|
||||
<h2 id="how-secure-is-end-to-end-encryption-in-different-messengers" tabindex="-1">How secure is end-to-end encryption in different messengers?</h2>
|
||||
@@ -2072,8 +2072,8 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<ul>
|
||||
<li>when messages are padded, but not to a fixed size.</li>
|
||||
<li>when repudiation does not include client-server connection. In case of Cwtch it appears that the presence of cryptographic signatures compromises repudiation (deniability), but it needs to be clarified.</li>
|
||||
<li>when 2-factor key exchange is optional, via security code verification.</li>
|
||||
<li>when post-quantum cryptography is only added to the initial key agreement, does not protect break-in recovery.</li>
|
||||
<li>when 2-factor key exchange is optional (via security code verification).</li>
|
||||
<li>when post-quantum cryptography is only added to the initial key agreement and does not protect break-in recovery.</li>
|
||||
</ul>
|
||||
<h2 id="adding-quantum-resistance-to-signal-double-ratchet-algorithm" tabindex="-1">Adding quantum resistance to Signal double ratchet algorithm</h2>
|
||||
<p>We have been exploring post-quantum cryptography since early 2022, when SimpleX Chat was first released, and we did not want to be pioneers here - cryptography is critically important to make it right.</p>
|
||||
@@ -2099,7 +2099,7 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<li>enable <em>Show developer options</em> toggle.</li>
|
||||
<li>now you will see <em>Post-quantum E2EE</em> toggle - enable it as well.</li>
|
||||
</ul>
|
||||
<p>Now all new contacts you add to the app will use quantum resistant Signal double ratchet algorithm.</p>
|
||||
<p>Now all new contacts you add to the app will use quantum resistant double ratchet algorithm.</p>
|
||||
<p>Once you have enabled it for the new contacts, you can also <strong>enable it for some of the existing contacts</strong>:</p>
|
||||
<ul>
|
||||
<li>open the chat with the contact you want to upgrade to be quantum resistant.</li>
|
||||
@@ -2108,7 +2108,7 @@ file ---&gt; | XFTP | ------&gt; XFTP ----&
|
||||
<li>exchange several messages back and forth with that contact - the quantum resistant double ratchet will kick in after 3-5 messages (depending on how many messages you send in each direction), and you will see the notice in the chat once it enables.</li>
|
||||
</ul>
|
||||
<h2 id="next-for-post-quantum-crypto-all-direct-chats-small-groups-and-security-audit" tabindex="-1">Next for post-quantum crypto - all direct chats, small groups and security audit</h2>
|
||||
<p>We will be making quantum resistance default for all direct chats in v5.7, and they will be upgraded for all users without any action.</p>
|
||||
<p>We will be making quantum resistance default for all direct chats in v5.7, and we plan that all existing direct chats will be automatically upgraded when both contacts install v5.7.</p>
|
||||
<p>We will also be adding quantum resistance to small groups up to 10-20 members. Computing cryptographic keys is much slower, in comparison, and it would be very inefficient (and completely unnecessary) for large public groups.</p>
|
||||
<p>We have also arranged a 3rd party cryptographic review of our protocol and encryption schemes design for June/July 2024 - it will cover the additions to SimpleX protocols since <a href="https://simplex.chat/blog/20221108-simplex-chat-v4.2-security-audit-new-website.html">the previous security audit</a> in November 2022, including <a href="https://simplex.chat/blog/20230301-simplex-file-transfer-protocol.html">XFTP protocol</a> we use for file transfers and quantum resistant Signal double ratchet algorithm we just released in this beta version.</p>
|
||||
<p>In November 2024 we will be conducting further implementation audit, with double the scope of our 2022 audit.</p>
|
||||
|
||||
24
feed.rss
24
feed.rss
@@ -14,7 +14,7 @@
|
||||
<p>This post also covers various aspects of end-to-end encryption, compares different messengers, and explains why and how quantum-resistant encryption is added to SimpleX Chat:</p>
|
||||
<ul>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#why-do-we-need-end-to-end-encryption">Why do we need end-to-end encryption?</a></li>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#why-encryption-is-even-allowed">Why encryption is even allowed?</a></li>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#why-is-encryption-even-allowed">Why is encryption even allowed?</a></li>
|
||||
<li><a href="https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#end-to-end-encryption-security-attacks-and-defense">End-to-end encryption security: attacks and defense.</a>
|
||||
<ul>
|
||||
<li>Compromised message size - mitigated by padding messages to a fixed block size.</li>
|
||||
@@ -36,7 +36,7 @@
|
||||
<p>Achieving the latter requires a lot of mathematical precision in both the cryptographic algorithms and in how they are used, and effectively makes encrypted messages indistinguishable from random noise, without any discoverable patterns or statistical irregularities that a computer could use to break the message encryption any faster than it it would take to try every possible combination of bits in the key.</p>
|
||||
<p>End-to-end encryption is an important component of our individual and business security, privacy and sovereignty. Having our private communications protected from any observers is both the natural condition and our inalienable human right.</p>
|
||||
<p>It's very sad to see the same people who keep their financial affairs private to protect from financial crimes, lock their doors to protect from thieves, and curtain their windows to protect from the occasional prying eyes, when it comes to protecting their personal lives from the data criminals say &quot;we don't care about privacy, we have nothing to hide&quot;. Everybody's safety depends on keeping their affairs and relations private, not visible to a vast and ruthless data gathering machines, that abuse our data for commercial gain, without any regard to our interests or even <a href="https://nmdoj.gov/press-release/attorney-general-raul-torrez-files-lawsuit-against-meta-platforms-and-mark-zuckerberg-to-protect-children-from-sexual-abuse-and-human-trafficking/">the safety of our families and children</a>.</p>
|
||||
<h2 id="why-encryption-is-even-allowed" tabindex="-1">Why encryption is even allowed?</h2>
|
||||
<h2 id="why-is-encryption-even-allowed" tabindex="-1">Why is encryption even allowed?</h2>
|
||||
<img src="https://simplex.chat/blog/images/20240314-djb.jpg" class="float-to-right" />
|
||||
<p>If encryption is such a powerful tool to protect our lives, it also can be used to conceal crimes, so why the governments don't consider it similar to arms, and don't heavily regulate its use?</p>
|
||||
<p>Prior to 1996 the cryptography was considered munition, and its export from the United States was controlled under this category, <a href="https://cr.yp.to/export/1995/0303-eff.txt">alongside flamethrowers and B-1 bombers</a>. When <a href="https://en.wikipedia.org/wiki/Daniel_J._Bernstein">Daniel J. Bernstein</a> (DJB), then a student of Mathematics at University of California, Berkeley, wanted to publish the paper and the source code of his Snuffle encryption system, the Office of Defense Trade Controls of the Department of State (DOS) after more than a year of correspondence requested that DJB registers as the arms dealer.</p>
|
||||
@@ -59,7 +59,7 @@
|
||||
<li>if a messenger conceals the routing of the messages to hide the transport identities (IP addresses) of senders and recipients, message sizes can be used by traffic observers to confirm the fact of communication with a much higher degree of certainty.</li>
|
||||
</ul>
|
||||
<p>The only effective mitigation to these attacks is to pad all messages to a fixed size. Using space-efficient schemes like Padme, or padding to encryption block size is ineffective for mitigating these attacks, as they still allow differentiating message sizes.</p>
|
||||
<p>To the best of our knowledge the only messenger other than SimpleX Chat that padded all messages to a fixed packet size was <a href="https://github.com/agl/pond">Pond</a> - SimpleX design as an evolution of it.</p>
|
||||
<p>To the best of our knowledge, the only messengers other than SimpleX Chat that pad all messages to a fixed packet size are Cwtch and no longer developed <a href="https://github.com/agl/pond">Pond</a> - SimpleX design can be seen as an evolution of Pond design.</p>
|
||||
<h3 id="2-compromised-confidential-messages-mitigated-by-repudiation-deniability" tabindex="-1">2. Compromised confidential messages - mitigated by repudiation (deniability)</h3>
|
||||
<p>Many users are very interested in having ability to irreversibly delete sent messages from the recipients devices. But not only would this ability violate data sovereignty of device owners, it is also completely ineffective, as the recipients could simply put the device offline or use a modified client app to ignore message deletion requests. While SimpleX Chat provides such features as <a href="https://simplex.chat/blog/20230103-simplex-chat-v4.4-disappearing-messages.html#disappearing-messages">disappearing messages</a> and the ability to <a href="https://simplex.chat/blog/20221206-simplex-chat-v4.3-voice-messages.html#irreversible-message-deletion">irreversibly delete sent messages</a> provided both parties agree to that, these are convenience features, and they cannot be considered security measures.</p>
|
||||
<p>The solution to that is well known to cryptographers - it is the quality of the encryption algorithms called &quot;repudiation&quot;, sometimes also called &quot;deniability&quot;. This is the ability of the senders to plausibly deny having sent any messages, because cryptographic algorithms used to encrypt allow recipients forging these messages on their devices, so while the encryption proves authenticity of the message to the recipient, it cannot be used as a proof to any third party.</p>
|
||||
@@ -70,11 +70,11 @@
|
||||
<p>The attacker who obtained or broke the keys used to encrypt individual messages, may try to use these keys to decrypt past or future messages. This attack is unlikely to succeed via message interception, and it is likely to require breaking into the device storage. But in any case, if the key was broken or obtained in some other way it's important that this key cannot be used to decrypt other messages - this is achieved by forward secrecy.</p>
|
||||
<p>This property is well understood by the users, and most messengers that focus on privacy and security, with the exception of Session, provide forward secrecy as part of their encryption schemes design.</p>
|
||||
<h3 id="4-compromised-long-term-or-session-mitigated-by-break-in-recovery" tabindex="-1">4. Compromised long-term or session - mitigated by break-in recovery</h3>
|
||||
<p>This attack is much less understood by the users, and forward secrecy does not protect from it. Arguably, it's almost impossible to compromise individual message keys without compromising long-term or session keys. So the ability of the encryption to recover from break-in (attacker making a copy of the device data without retaining the ongoing access) is both very and pragmatic - break-in attacks are simpler to execute on mobile devices during short-term device access than long-term ongoing compromise.</p>
|
||||
<p>Out of all encryption algorithms known to us only Signal double ratchet algorithm provides the ability to encryption security after break-ins. This recovery happens automatically and transparently to the users, without them doing anything special even knowing about break-in, by simply sending messages. Every time one of the communication parties replies to another party message, new random keys are generated and previously stolen keys become useless.</p>
|
||||
<p>Signal double ratchet algorithm is used in Signal, Cwtch and SimpleX Chat. This is why you cannot use SimpleX Chat profile on more than one device at the same time - the encryption scheme rotates the long term keys, randomly, and keys on another device become useless, as they would become useless for the attacker who stole them. Security always has some costs to the convenience.</p>
|
||||
<p>This attack is much less understood by the users, and forward secrecy does not protect from it. Arguably, it's almost impossible to compromise individual message keys without compromising long-term or session keys. So the ability of the encryption to recover from break-in (attacker making a copy of the device data without retaining the ongoing access) is both very important and pragmatic - break-in attacks are simpler to execute on mobile devices during short-term device access than long-term ongoing compromise.</p>
|
||||
<p>Out of all encryption algorithms known to us only <em>Signal double ratchet algorithm</em> (also referred to as <em>Signal algorithm</em> or <em>double ratchet algorithm</em>, which is not the same as Signal messaging platform and protocols) provides the ability for the encryption security to recover after break-ins attacks. This recovery happens automatically and transparently to the users, without them doing anything special or even knowing about break-in, by simply sending messages. Every time one of the communication parties replies to another party message, new random keys are generated and previously stolen keys become useless.</p>
|
||||
<p>Double ratchet algorithm is used in Signal, Cwtch and SimpleX Chat. This is why you cannot use SimpleX Chat profile on more than one device at the same time - the encryption scheme rotates the long term keys, randomly, and keys on another device become useless, as they would become useless for the attacker who stole them. Security always has some costs to the convenience.</p>
|
||||
<h3 id="5-man-in-the-middle-attack-mitigated-by-two-factor-key-exchange" tabindex="-1">5. Man-in-the-middle attack - mitigated by two-factor key exchange</h3>
|
||||
<p>Many people incorrectly believe that security of end-to-end encryption cannot be broken by communication provider. But end-to-end encryption is as secure as key exchange. While any intermediary passing the keys between senders and recipients cannot recover the private keys from the public keys, they can simply replace the passed public keys with their own and then proxy all communication between the users having full access to the original messages. So instead of having an end-to-end encrypted channel, users would have two half-way encrypted channels - between users and their communication intermediary.</p>
|
||||
<p>Many people incorrectly believe that security of end-to-end encryption cannot be broken by communication provider. But end-to-end encryption is only as secure as key exchange. While any intermediary passing the keys between senders and recipients cannot recover the private keys from the public keys, they can simply replace the passed public keys with their own and then proxy all communication between the users having full access to the original messages. So instead of having an end-to-end encrypted channel, users would have two half-way encrypted channels - between users and their communication intermediary.</p>
|
||||
<p>Pictures below illustrate how this attack works for RSA encryption.</p>
|
||||
<h4 id="1-alice-sends-the-key-to-bob-eg-via-p2p-network-or-via-the-messaging-server" tabindex="-1">1) Alice sends the key to Bob (e.g. via p2p network or via the messaging server).</h4>
|
||||
<p><img src="https://simplex.chat/blog/images/20240314-mitm1.jpg" alt="Public key is shared" /></p>
|
||||
@@ -97,7 +97,7 @@
|
||||
<li>many of post-quantum algorithms have known patent claims, so any system deploying them accepts the risks of patent litigation.</li>
|
||||
<li>the silver lining to these limitations is that the risk of appearance of commercially viable quantum computers in the next decade may be exaggerated.</li>
|
||||
</ul>
|
||||
<p>So, to put it bluntly and provocatively, post-quantum cryptography can be compared with a remedy against the illness that nobody has, without any guarantee that it will work. The closest analogy in the history of medicine is <em>snake oil</em>.</p>
|
||||
<p>So, to say it provocatively, post-quantum cryptography can be compared with a remedy against the illness that nobody has, without any guarantee that it will work. While there is a reasonable hope that it <em>might</em> work, so it's not exactly a <em>snake oil</em>, these limitations and risks have to be much better communicated to the end users than they are.</p>
|
||||
<img src="https://simplex.chat/blog/images/20240314-datacenter.jpg" width="400" class="float-to-right" />
|
||||
<p>Does it mean that post-quantum cryptography is useless and should be ignored? Absolutely not. The risks of &quot;record now, decrypt later&quot; attacks are real, particularly for high profile targets, including millions of people - journalists, whistle-blowers, freedom-fighters in oppressive regimes, and even some ordinary people who may become targets of information crimes. Large scale collection of encrypted communication data is ongoing, and this data may be used in the future. So having the solution that <em>may</em> protect you (post-quantum cryptography), as long as it doesn't replace the solution that is <em>proven</em> to protect you (conventional cryptography), is highly beneficial in any communication solution, and has already been deployed in many tools and in some messengers.</p>
|
||||
<h2 id="how-secure-is-end-to-end-encryption-in-different-messengers" tabindex="-1">How secure is end-to-end encryption in different messengers?</h2>
|
||||
@@ -110,8 +110,8 @@
|
||||
<ul>
|
||||
<li>when messages are padded, but not to a fixed size.</li>
|
||||
<li>when repudiation does not include client-server connection. In case of Cwtch it appears that the presence of cryptographic signatures compromises repudiation (deniability), but it needs to be clarified.</li>
|
||||
<li>when 2-factor key exchange is optional, via security code verification.</li>
|
||||
<li>when post-quantum cryptography is only added to the initial key agreement, does not protect break-in recovery.</li>
|
||||
<li>when 2-factor key exchange is optional (via security code verification).</li>
|
||||
<li>when post-quantum cryptography is only added to the initial key agreement and does not protect break-in recovery.</li>
|
||||
</ul>
|
||||
<h2 id="adding-quantum-resistance-to-signal-double-ratchet-algorithm" tabindex="-1">Adding quantum resistance to Signal double ratchet algorithm</h2>
|
||||
<p>We have been exploring post-quantum cryptography since early 2022, when SimpleX Chat was first released, and we did not want to be pioneers here - cryptography is critically important to make it right.</p>
|
||||
@@ -137,7 +137,7 @@
|
||||
<li>enable <em>Show developer options</em> toggle.</li>
|
||||
<li>now you will see <em>Post-quantum E2EE</em> toggle - enable it as well.</li>
|
||||
</ul>
|
||||
<p>Now all new contacts you add to the app will use quantum resistant Signal double ratchet algorithm.</p>
|
||||
<p>Now all new contacts you add to the app will use quantum resistant double ratchet algorithm.</p>
|
||||
<p>Once you have enabled it for the new contacts, you can also <strong>enable it for some of the existing contacts</strong>:</p>
|
||||
<ul>
|
||||
<li>open the chat with the contact you want to upgrade to be quantum resistant.</li>
|
||||
@@ -146,7 +146,7 @@
|
||||
<li>exchange several messages back and forth with that contact - the quantum resistant double ratchet will kick in after 3-5 messages (depending on how many messages you send in each direction), and you will see the notice in the chat once it enables.</li>
|
||||
</ul>
|
||||
<h2 id="next-for-post-quantum-crypto-all-direct-chats-small-groups-and-security-audit" tabindex="-1">Next for post-quantum crypto - all direct chats, small groups and security audit</h2>
|
||||
<p>We will be making quantum resistance default for all direct chats in v5.7, and they will be upgraded for all users without any action.</p>
|
||||
<p>We will be making quantum resistance default for all direct chats in v5.7, and we plan that all existing direct chats will be automatically upgraded when both contacts install v5.7.</p>
|
||||
<p>We will also be adding quantum resistance to small groups up to 10-20 members. Computing cryptographic keys is much slower, in comparison, and it would be very inefficient (and completely unnecessary) for large public groups.</p>
|
||||
<p>We have also arranged a 3rd party cryptographic review of our protocol and encryption schemes design for June/July 2024 - it will cover the additions to SimpleX protocols since <a href="https://simplex.chat/blog/20221108-simplex-chat-v4.2-security-audit-new-website.html">the previous security audit</a> in November 2022, including <a href="https://simplex.chat/blog/20230301-simplex-file-transfer-protocol.html">XFTP protocol</a> we use for file transfers and quantum resistant Signal double ratchet algorithm we just released in this beta version.</p>
|
||||
<p>In November 2024 we will be conducting further implementation audit, with double the scope of our 2022 audit.</p>
|
||||
|
||||
Reference in New Issue
Block a user