Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

2016-01-04 Thread Zhenfei Zhang
Thanks Yawning. > Agreed. I like the QSH design, though I still want to use FIPS 202 > (SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're > changing things anyway, we may as well future proof here too". Yes. Will put that in the request too. Sorry missed this comment in

[tor-dev] Oops / Re: Proposal: Stop giving Exit flags when only unencrypted traffic can exit

2016-01-04 Thread n...@cock.li
Blah, what I said was already suggested, but I hadn't received the original mail when I'd replied ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

2016-01-04 Thread n...@cock.li
Tim Wilson-Brown - teor: > One consequence of this proposal is that relays that only exit to 443 > and 6667 will lose the Exit flag. But these relays do exit to an > encrypted port, so this somewhat contradicts the goal of the > proposal: "Exit flags can no longer be assigned to relays that exit >

[tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

2016-01-04 Thread Tom van der Woerdt
I've had this on my todo list for a while, finally wrote it down. Honestly, it's a minor change, but something that imho needs to be done. Torspec branch: https://github.com/TvdW/torspec/commits/exit-flag-not-all-plaintext Full text below, tldr first: replace [80,443,6667] with [80,443,5222]

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

2016-01-04 Thread Tim Wilson-Brown - teor
> On 5 Jan 2016, at 11:29, Tom van der Woerdt wrote: > ... > 2.1. Exit flagging > > By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit > flags can no longer be assigned to relays that exit only to unencrypted > ports. One consequence of this proposal is

Re: [tor-dev] Go version in Gitian descriptors

2016-01-04 Thread sycamoreone
isis: > Tim Wilson-Brown - teor transcribed 12K bytes: >> >> Note the go bootstrap process has changed now that go is entirely written in >> go: >> >> The new build process for Go 1.x (x ≥ 5) will be: >> >> • Build cmd/dist with Go 1.4. >> • Using dist, build Go 1.x compiler toolchain

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

2016-01-04 Thread Zhenfei Zhang
Hi all, Thanks for all the comments. Sorry I wasn't able to reply immediately. Please allow me to summarize the comments. I see mainly the following questions. 1. Quantum-safe authentication. As Yawning has pointed out, > I personally don't think that any of the PQ signature schemes are usable

Re: [tor-dev] tor-dev Digest, Vol 60, Issue 2

2016-01-04 Thread Zhenfei Zhang
Hi Flipchan, There are reference implementation of quantum-safe cryptographic algorithms, such as NTRU encryption algorithm (in libntruencrypt): https://github.com/NTRUOpenSourceProject/NTRUEncrypt and BLISS signature algorithm, http://bliss.di.ens.fr/ Those are independent softwares. But for

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

2016-01-04 Thread Yawning Angel
(Note: Snipping liberally for brevity) On Mon, 4 Jan 2016 11:56:54 -0500 Zhenfei Zhang wrote: > 2. On NTRU vs NTRU-Prime vs R-LWE and others. > The QSH is modular designed to suite any quantum-safe encryption > algorithm. So we can chose any one we want for trail.