Hello Marc, Thanks for the work. It looks very interesting, I'm happy to see people looking into evolving FEPs.
I don't think for us make sense to replace obfs4 for now, as we see censors blocking all FEPs. But I think we still have spaces where they will be useful and we should keep in mind your work for future needs. Quoting Marc Himmelberger via tor-dev (2025-07-31 20:12:14) > Hi, > > > I have just concluded my Master's Thesis at ETH Zurich titled "Implementing > and Evaluating > > Quantum-Safe Fully Encrypted Protocols" and I believe the content is > relevant for this mailing list. > > > My thesis consists mainly of the implementation of the "Drivel" protocol > [1]. Two of the authors of [1], Felix Günther (m...@felixguenther.info) and > Shannon Veitch (shannon.vei...@inf.ethz.ch), supervised this thesis and are > also available for questions regarding the protocol design in this thread. > > > Drivel is an evolution of obfs4 [2] that: > > - > > allows for key encapsulation mechanisms, particularly the ones proposed > as part of the NIST standardization [3], > - > > has stronger obfuscation, providing more guarantees than obfs4 in the > scenario that censors should get ahold of bridge information such as NodeID > and long-term public key, > - > > contains a thin crypto-agility layer, allowing the replacement of > cryptographic algorithms as needed, > - > > provides more configuration options to bridge operators regarding > performance trade-offs by allowing for runtime-configuration of the > cryptographic algorithms, and > - > > allows for post-quantum traditional hybrid instantiations. Note:; my > thesis covers the “pure” post-quantum case (i.e., non-hybrid). Due to the > crypto agility, hybrids are relatively easy to add by implementing an > appropriate PQ/T hybrid combiner, such as OEINC [1]. > > Additionally, there are proposed changes to Drivel itself, evaluations of > the implementation's performance, and some security proofs in the thesis. > The main purpose of my proposed changes is to add more flexibility in > traffic shaping (minimize “quiet periods” previously discussed on this list > [4]) and to optimize performance. > > > The thesis PDF is available under: https://doi.org/10.3929/ethz-b-000746588 > > The chapters "Implementing Drivel" and "Experimental Evaluation" should be > most relevant to this list. > > I encourage everyone interested in pluggable transports to have a look if > this sounds intriguing. > > > The implementation is done as a fork of the lyrebird repository [5] and is > available under: https://github.com/marc-himmelberger/lyrebird-drivel > > The Tor Project is more than welcome to use my work for future changes to > lyrebird, although I do believe some changes to drivel and some > optimizations to my code may be beneficial for performance reasons before > the pluggable transport is used in production. > > > In case of any feedback or questions, do not hesitate to reach out. > > > Best regards, > > Marc Himmelberger > > > [1] https://eprint.iacr.org/2025/408.pdf > > [2] > https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/blob/main/doc/obfs4-spec.txt > > [3] https://csrc.nist.gov/projects/post-quantum-cryptography > > [4] > https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-dev/2017-June/012310.html > > [5] > https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. _______________________________________________ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
