[tor-dev] Re: Available implementation and report on quantum-safe fully encrypted protocols

[meskio via tor-dev <tor-dev@xxxxxxxxxxxxxxxxxxxx>]

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 (mail@xxxxxxxxxxxxxxxxxx) and
> Shannon Veitch (shannon.veitch@xxxxxxxxxxx), 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx