[tor-dev] Netflow padding

[grarpamp]

Are these the current / recommended paper refs for
eyeballing things on this to date?

torspec/proposals/251-netflow-padding.txt
torspec/proposals/254-padding-negotiation.txt
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposing "Post-Quantum safe handshake implementation" as GSoc Project

[Yawning Angel]

On Sat, 18 Feb 2017 14:07:40 +0530
Jaskaran Singh  wrote:
> I'm particularly interested to work on making TOR Handshakes
> Post-Quantum Safe. I feel that this should be implemented at the
> earliest because adversaries could store the network traffic and
> decrypt it later on using Quantum Computers when they're invented.

So there's good news and bad news.

The good news is that PQ handshake stuff will happen, sooner rather
than later.

The bad news is that, work on it is on going, and it does not make a
good GSOC project because, the bulk of the implementation work will
likely happen before the summer.

[snip]
> 2. Implement the NewHope-Simple algorithm[1] because we'll not be able
> to use the Vanilla NewHope as it is protected by some patents. I
> wasn't able to find any implementation of NewHope Simple. So can the
> Vanilla NewHope Implementation be tweaked to convert it into NewHope
> Simple? Or would we have to write it from ground up? I don't know
> about the patent laws regarding it.

I haven't talked to Peter in a while (and will ask him after I send
this), but I am not aware of any patent claims against the vanilla
NewHope algorithm (and the NewHope-Simple paper does not mention this
at all either).

That said, implementing NewHope-Simple is trivial given NewHope (an
afternoon if that), so it's not something that worries me much.

Regards,

-- 
Yawning Angel


pgpfwXt5HySuw.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposing "Post-Quantum safe handshake implementation" as GSoc Project

[Jaskaran Singh]

Hi,

My name is Jaskaran, and I'm an Electronics Engineering undergrad in
India. I'm a privacy, anonymity and FOSS supporter. I've worked in the
past with the Libreoffice project during the Google Summer of Code 2016.
This year I'm interested to work with the TOR project as a part of GSoC.

I'm particularly interested to work on making TOR Handshakes
Post-Quantum Safe. I feel that this should be implemented at the
earliest because adversaries could store the network traffic and decrypt
it later on using Quantum Computers when they're invented.

So here's what I think the task would comprise of :

1. Add a new CREATE2V and CREATED2V cell that can support 2240 bytes of
HDATA (according to NewHope-Simple algorithm[1]). Add facility for
multiple EXTEND2/EXTENDED2 cells to be sent when the handshake data
doesn't fit into a single cell.

2. Implement the NewHope-Simple algorithm[1] because we'll not be able
to use the Vanilla NewHope as it is protected by some patents. I wasn't
able to find any implementation of NewHope Simple. So can the Vanilla
NewHope Implementation be tweaked to convert it into NewHope Simple? Or
would we have to write it from ground up? I don't know about the patent
laws regarding it.

3. Finally, generate test vectors and check for any bottlenecks. Improve
efficiency and check for any vulnerabilities in the implementation that
could be exploited by the adversary.

I'd like to know your views on this. Suggestions, comments, criticism
are all welcome.

References

[1] https://eprint.iacr.org/2016/1157.pdf

PS: There's Something I noticed while reading the proposal. The portions
don't add up to the size of the cell. Here's aSigned fix for it.

commit a55692fcd93e3f064f1fffe24796dc747e4870e1
Author: Jaskaran Singh 
Date:   Sat Feb 18 13:32:32 2017 +0530

Fix HDATA sizes in proposal 270

diff --git a/proposals/270-newhope-hybrid-handshake.txt
b/proposals/270-newhope-hybrid-handshake.txt
index ccf3390..c0f36ae 100644
--- a/proposals/270-newhope-hybrid-handshake.txt
+++ b/proposals/270-newhope-hybrid-handshake.txt
@@ -432,7 +432,7 @@ Depends: prop#220 prop#249 prop#264 prop#270
   HTYPE   := 0x0003 [2 bytes]
   HLEN:= 0x0780 [2 bytes]
   HDATA   := CLIENT_HDATA   [1920 bytes]
-  IGNORED := 0x00   [194 bytes]
+  IGNORED := 0x00   [190 bytes]
 }

   [XXX do we really want to pad with IGNORED to make CLIENT_HDATA the
@@ -485,7 +485,7 @@ Depends: prop#220 prop#249 prop#264 prop#270
   NSPEC := 0x00   [1 byte]
   HTYPE := 0x [2 bytes]
   HLEN  := 0x [2 bytes]
-  HDATA := 0x00[172]  [172 bytes]
+  HDATA := 0x00[172]  [174 bytes]
 }

   The client sends this to the server to extend the circuit from, and that
@@ -525,7 +525,7 @@ Depends: prop#220 prop#249 prop#264 prop#270
   NSPEC := 0x00   [1 byte]
   HTYPE := 0x [2 bytes]
   HLEN  := 0x [2 bytes]
-  HDATA := SERVER_HDATA[1940,2112][172 bytes]
+  HDATA := SERVER_HDATA[1940,2112][174 bytes]
 }

Regards,
Jaskaran


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