[tor-dev] [prop269] [prop270] Ideas from Tor Meeting Discussion on Post-Quantum Crypto

[isis agora lovecruft]

Hey hey,

In summary of the breakaway group we had last Saturday on post-quantum
cryptography in Tor, there were a few potentially good ideas I wrote down,
just in case they didn't make it into the meeting notes:

 * A client should be able to configure "I require my entire circuit to have
   PQ handshakes" and "I require at least one handshake in my circuits to be
   PQ".  (Previously, we had only considered having consensus parameters, in
   order to turn the feature on e.g. once 20% of relays supported the new
   handshake method.)

 * Using stateful hash-based signatures to sign descriptors and/or consensus
   documents, and (later) if state has been lost or compromised, then request
   the last such document submitted to regain state (probably skipping over
   all the leaves of the last used node in the tree, or the equivalent, to be
   safe).  (This requires more concrete design analysis, including the effects
   of the large size of hash-based signatures on the directory bandwidth
   usage, probably in a proposal or longer write up, should someone awesome
   decides to research this idea further. :)

Thanks to everyone involved in the breakaway group, and I apologise, but I
don't actually remember all the attendants off the top of my head.  If either
of these were your idea, please message me off-list and I'll ensure you're
credited in the eventual proposal(s)/documentation.

Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor in a safer language: Network team update from Amsterdam

[Sebastian Hahn]

Hi there tor-dev,

as an update to those who didn't have the chance to meet with us in
Amsterdam or those who haven't followed the efforts to rely on C less,
here's what happened at the "let's not fight about Go versus Rust, but
talk about how to migrate Tor to a safer language" session and what
happened after.

Notes from session:

We didn't fight about Rust or Go or modern C++. Instead, we focused on
identifying goals for migrating Tor to a memory-safe language, and how
to get there. With that frame of reference, Rust emerged as a extremely
strong candidate for the incremental improvement style that we
considered necessary. We were strongly advised to not use cgo, by people
who have used it extensively.

As there are clearly a lot of unknowns with this endeavor, and a lot
that we will learn/come up against along the way, we feel that Rust is a
compelling option to start with,  with the caveat that we will first
experiment, learn from the experience, and then build on what we learn.

You can also check out the session notes on the wiki (submitted, but not
posted yet).[1]

The real fun part started after the session. We got together to actually
make a plan for an experiment and to give Rust a serious chance. We
quickly got a few trivial things working like statically linking Rust
into Tor, integrating with the build system to call out to cargo for the
Rust build, and using Tor's allocator from Rust.

We're planning to write up a blog post summarizing our experiences so
far while hopefully poking the Rust developers to prioritize the missing
features so we can stop using nightly Rust soon (~months, instead of
years).

We want to have a patch merged into tor soon so you can all play with
your dev setup to help identify any challenges. We want to stress that
this is an optional experiment for now, we would love feedback but
nobody is paid to work on this and nobody is expected to spend more
time than they have sitting around.

We have committed to reviewing any patch that includes any Rust code to
provide feedback, get experience to develop a style, and actually make
use of this experiment. This means we're not ready to take on big
patches that add lots of tricky stuff quite now, we want to take it slow
and learn from this.

We would like to do a session at the next dev meeting to give updates on
this effort, but in the meantime, if team members would like to start
learning Rust and helping us identify/implement small and well-isolated
areas to begin migration, or new pieces of functionality that we can
build  immediately in Rust, that would be really great.

So, for a TLDR:

What has already been done:
- Rust in Tor build
- Putting together environment setup instructions and a (very small)
 initial draft for coding standards
- Initial work to identify good candidates for migration (not tightly
 interdependent)

What we think are next steps:
- Define conventions for the API boundary between Rust and C
- Add a non-trivial Rust API and deploy with a flag to optionally use
 (to test support with a safe fallback)
- Learn from similar projects
- Add automated tooling for Rust, such as linting and testing


Cheers
Alex, Chelsea, Sebastian

[1]: Will be visible here 
https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - Project "Crash Reporter for Tor Browser"

[Tom Ritter]

On 31 March 2017 at 10:27, Nur-Magomed  wrote:
>> I think we'd want to enhance this form. IIRC the 'Details' view is
>> small and obtuse and it's not easy to review. I'm not saying we
>> _should_ create these features, but here are a few I brainstormed:
>
> Yes, actually that form only shows "Key: Value" list, we can break it down
> in several GroupBoxes which consist of grouped data field and checkboxes to
> include.
>
>> Let's try and avoid GDocs if you don't mind :)
>
> Sorry :) I already registered on storm, but I had no access to create.
> Thanks for review, I'll update proposal accordint to your requiments.

No worries.

> And question: could we throw Windows or MacOS or both versions from
> timeline, and develop them after summer?

Yes, I think that's fine. I think getting one platform to completion
would be a great accomplishment and would lay the groundwork and
improve the momentum to getting the subsequent platforms there.

-tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - Project "Crash Reporter for Tor Browser"

[Nur-Magomed]

> I think we'd want to enhance this form. IIRC the 'Details' view is
> small and obtuse and it's not easy to review. I'm not saying we
> _should_ create these features, but here are a few I brainstormed:

Yes, actually that form only shows "Key: Value" list, we can break it down
in several GroupBoxes which consist of grouped data field and checkboxes to
include.

> Let's try and avoid GDocs if you don't mind :)

Sorry :) I already registered on storm, but I had no access to create.
Thanks for review, I'll update proposal accordint to your requiments.

And question: could we throw Windows or MacOS or both versions from
timeline, and develop them after summer?


2017-03-31 0:44 GMT+03:00 Damian Johnson :

> >> P.S. Have I to send proposal to GSoc as draft?
> >
> > I don't know the answer to this, but hopefully Damian does?
>
> It would be useful if you uploaded a draft to the site, but really the
> only hard requirement is that the proposal is uploaded before the
> deadline. ;)
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev