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 jvsg1303@gmail.com 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 := 0xFFFF [2 bytes] HLEN := 0x0000 [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 := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] - HDATA := SERVER_HDATA[1940,2112] [172 bytes] + HDATA := SERVER_HDATA[1940,2112] [174 bytes] }
Regards, Jaskaran
On Sat, 18 Feb 2017 14:07:40 +0530 Jaskaran Singh jvsg1303@gmail.com 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]
- 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 transcribed 3.0K bytes:
On Sat, 18 Feb 2017 14:07:40 +0530 Jaskaran Singh jvsg1303@gmail.com 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.
It will?
- 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).
Sorry, I'm being deliberately vague about this because I don't want to feed the patent trolls or provide a weapon to anyone who wants to fight against good crypto, but the patent exists, and it affects nearly all lattice-based handshakes. NewHope simple is not affected.
My (ongoing, but Nick asked me to stop last summer until there was funding for it) work on integrating standard NewHope is here:
https://gitweb.torproject.org/user/isis/tor.git/log/?h=feature/rebelalliance
Best,
On Thu, 23 Feb 2017 00:01:29 +0000 isis agora lovecruft isis@torproject.org wrote:
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.
It will?
Probably? If people take what I say out of context, or as a promise of anything, they may end up disappointed, but I don't really care.
- 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).
Sorry, I'm being deliberately vague about this because I don't want to feed the patent trolls or provide a weapon to anyone who wants to fight against good crypto, but the patent exists, and it affects nearly all lattice-based handshakes. NewHope simple is not affected.
I spoke with some people and got filled in. I'm not going to look at the claim, because that's something for a legal department somewhere to sort out, and not my problem.
Since the Simple variant is easier for others to implement, and sidesteps the random asshats issue, I don't think this is a big deal anyway.
Regards,
-
isis agora lovecruft -
Jaskaran Singh -
Yawning Angel