Post-quantum security of OMEMO

Chris Tsichrinis via Standards <[email protected]> Tue, 21 Jul 2026 16:42:17 +0300
Newsgroups	gmane.network.jabber.standards-jig
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--===============1156614222406405503==
Content-Type: multipart/alternative;
 boundary="------------JySduV7y0HnsgjORpz0gI0Gl"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------JySduV7y0HnsgjORpz0gI0Gl
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello everyone,

I keep reading about recent developments in the quantum computing field,=20
with whatever this may mean for classic asymmetric encryption/key=20
exchange algorithms. More specifically, it appears that both Google=20
(Quantum frontiers may be closer than they appear=20
<https://blog.google/innovation-and-ai/technology/safety-security/cryptog=
raphy-migration-timeline/>)=20
and Cloudflare (Cloudflare targets 2029 for full post-quantum security=20
<https://blog.cloudflare.com/post-quantum-roadmap/>) have targeted 2029=20
for post-quantum migration. Both of these blog posts made me ponder=20
about the post-quantum security of the OMEMO. I am not an expert on the=20
field of asymmetric cryptography, but per XEP-0384=20
<https://xmpp.org/extensions/xep-0384.html>, OMEMO uses the X3DH key=20
agreement protocol for key exchange and the Double Ratchet Algorithm for=20
message encryption and decryption. From what I can grasp, Signal has=20
developed the=C2=A0PQXDH key agreement protocol as a post-quantum secure=20
variant of X3DH, while Double Rachet also seems to provide no=20
post-quantum protection=20
<https://signal.org/docs/specifications/doubleratchet/#harvest-now-decryp=
t-later-attacks>.

With that being said, I'd like to ask if there are any plans to update=20
the relevant OMEMO standard in the future to make OMEMO=20
post-quantum-proof and if not, whether OMEMO's post-quantum security is=20
considered trivial or not.

Thanks in advance

--------------JySduV7y0HnsgjORpz0gI0Gl
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body>
    <p>Hello everyone,</p>
    <p>I keep reading about recent developments in the quantum computing
      field, with whatever this may mean for classic asymmetric
      encryption/key exchange algorithms. More specifically, it appears
      that both Google (<a moz-do-not-send=3D"true"
href=3D"https://blog.google/innovation-and-ai/technology/safety-security/=
cryptography-migration-timeline/">Quantum
        frontiers may be closer than they appear</a>) and Cloudflare (<a
        moz-do-not-send=3D"true"
        href=3D"https://blog.cloudflare.com/post-quantum-roadmap/">Cloudf=
lare
        targets 2029 for full post-quantum security</a>) have targeted
      2029 for post-quantum migration. Both of these blog posts made me
      ponder about the post-quantum security of the OMEMO. I am not an
      expert on the field of asymmetric cryptography, but per <a
        moz-do-not-send=3D"true"
        href=3D"https://xmpp.org/extensions/xep-0384.html">XEP-0384</a>,
      OMEMO uses the X3DH key agreement protocol for key exchange and
      the Double Ratchet Algorithm for message encryption and
      decryption. From what I can grasp, Signal has developed the=C2=A0PQ=
XDH
      key agreement protocol as a post-quantum secure variant of X3DH,
      while Double Rachet also seems to <a moz-do-not-send=3D"true"
href=3D"https://signal.org/docs/specifications/doubleratchet/#harvest-now=
-decrypt-later-attacks">provide
        no post-quantum protection</a>.</p>
    <p>With that being said, I'd like to ask if there are any plans to
      update the relevant OMEMO standard in the future to make OMEMO
      post-quantum-proof and if not, whether OMEMO's post-quantum
      security is considered trivial or not.</p>
    <p>Thanks in advance</p>
  </body>
</html>

--------------JySduV7y0HnsgjORpz0gI0Gl--

--===============1156614222406405503==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============1156614222406405503==--