Might this be a more worthy goal than replacing X25519 with X448?
Can we have a naive PQ hybrid double ratchet without too much difficult by simply applying some small modifications?
It seems like it would be pretty easy to add a SIDH or CSIDH ratchet that sits next to the ECDH ratchet where both ratchets always step forward at the same time. And every time a DH public key is shared then a SIDH/CSIDH public key is also shared. Likewise when the DH shared secret is feed into the root KDF chain then so should the SIDH/CSIDH shared secret also be feed into the root KDF chain.
This the ratchet byte size overhead would only be 64 bytes in the case of using CSIDH. But the performance cost would probably be a lot worse although that shouldn't matter that much since it's only on the client... and our latency for this "chat" application is quite high already... to the point where it probably cannot be called a real-time chat application. Using it might feel more like agl's pond in terms of message latency.
Might this be a more worthy goal than replacing X25519 with X448? Can we have a naive PQ hybrid double ratchet without too much difficult by simply applying some small modifications?
It seems like it would be pretty easy to add a SIDH or CSIDH ratchet that sits next to the ECDH ratchet where both ratchets always step forward at the same time. And every time a DH public key is shared then a SIDH/CSIDH public key is also shared. Likewise when the DH shared secret is feed into the root KDF chain then so should the SIDH/CSIDH shared secret also be feed into the root KDF chain.
This the ratchet byte size overhead would only be 64 bytes in the case of using CSIDH. But the performance cost would probably be a lot worse although that shouldn't matter that much since it's only on the client... and our latency for this "chat" application is quite high already... to the point where it probably cannot be called a real-time chat application. Using it might feel more like agl's pond in terms of message latency.