Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread bancfc
Some great developments in lattice-based crypto. DJB just released a paper on NTRU Prime: 1. Competitively fast compared to the leading lattice-based cryptosystems including New Hope. 2. Safer implementation of NTRU that avoids vulnerable ring structures and runs in constant-time. 3. The

[tor-dev] Fewer Failures in Shared Random

2016-05-12 Thread Tim Wilson-Brown - teor
Hi All, Currently, the shared random system treats the first vote of the next commit phase specially - it's the only time it tries to agree on a new shared random value. This makes one consensus in each day particularly attractive to adversaries (or particularly vulnerable to failures), because i

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread Yawning Angel
On Thu, 12 May 2016 20:31:56 +0200 Jeff Burdges wrote: > On Thu, 2016-05-12 at 15:54 +0200, Peter Schwabe wrote: > > Can you describe a pre-quantum attacker who breaks the non-modified > > key > > exchange and does not, with essentially the same resources, break > > the modified key exchange? I'm

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread Jeff Burdges
On Thu, 2016-05-12 at 15:54 +0200, Peter Schwabe wrote: > Can you describe a pre-quantum attacker who breaks the non-modified > key > exchange and does not, with essentially the same resources, break the > modified key exchange? I'm not opposed to your idea, but it adds a bit > of complexity and I

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread Peter Schwabe
Yawning Angel wrote: Hi Yawning, Thanks for the more detailed description; I think I understand now what you're saying. I also agree that the cost is small (only some extra symmetric stuff happening). I don't like the use of AES-GCM as an authenticated-encryption algorithm, but as far as I und

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread Yawning Angel
On Thu, 12 May 2016 14:18:41 +0200 Jeff Burdges wrote: > On Thu, 2016-05-12 at 11:17 +, Yawning Angel wrote: > > Well, if we move the handshake identifier inside the AE(AD) > > envelope, we can also add padding to normalize the handshake length > > at minimal extra CPU cost by adding a length

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread Jeff Burdges
On Thu, 2016-05-12 at 11:17 +, Yawning Angel wrote: > Well, if we move the handshake identifier inside the AE(AD) envelope, > we can also add padding to normalize the handshake length at minimal > extra CPU cost by adding a length field and some padding inside as > well. > > It would remove so

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread Yawning Angel
On Thu, 12 May 2016 11:58:56 +0200 Jeff Burdges wrote: > On Thu, 2016-05-12 at 05:29 +, Yawning Angel wrote: > > and move the handshake > > identifier into the encrypted envelope) so that only the recipient > > can see which algorithm we're using as well (So: Bad guys must have > > a quantum c

[tor-dev] RFC-ish: basket2 (aka obfs5)

2016-05-12 Thread Yawning Angel
Hello, So I've been somewhat productive as of late and have been working on the successor to obfs4. I have a "oh my god, you wrote how much code, with no documentation" minimum-viable-product-ish release that appears to work, though ABSOLUTELY NO ONE SHOULD USE IT YET, because I will break bridge

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

2016-05-12 Thread Jeff Burdges
On Thu, 2016-05-12 at 05:29 +, Yawning Angel wrote: > and move the handshake > identifier into the encrypted envelope) so that only the recipient > can see which algorithm we're using as well (So: Bad guys must have > a quantum computer and calculate `z` to figure out which post quantum > algo