Re: [tor-dev] Proposal 262: Re-keying live circuits with new cryptographic material

2015-12-28 Thread Yawning Angel
On Mon, 28 Dec 2015 17:43:57 -0500 Nick Mathewson wrote: > 2. RELAY_REKEY cell operation > >To rekey, the circuit initiator ("client") can send a new > RELAY_REKEY cell type: > > struct relay_rekey { > u16 rekey_method IN [0, 1]; > u8 rekey_data[]; > } >

Re: [tor-dev] Proposal 261: AEZ for relay cryptography

2015-12-28 Thread Yawning Angel
[snipping liberally] On Mon, 28 Dec 2015 17:43:14 -0500 Nick Mathewson wrote: > 3.3. Why _not_ AEZ? > >There are also some reasons to consider avoiding AEZ, even if we do >decide to use a wide-block cipher. > >FIRST it is complicated to implement. As the specification says, >"

Re: [tor-dev] RFC: AEZ for relay cryptography, v2

2015-12-28 Thread Tim Wilson-Brown - teor
> On 23 Dec 2015, at 03:59, Nick Mathewson wrote: > > On Mon, Nov 30, 2015 at 2:12 AM, Tim Wilson-Brown - teor > wrote: >> Hi Nick, >> >> The AEZ paper says: >> >> "We impose a limit that AEZ be used for at most 2^48 bytes of data (about >> 280 TB); by that time, the user should rekey. This u

[tor-dev] Proposal 262: Re-keying live circuits with new cryptographic material

2015-12-28 Thread Nick Mathewson
[Proposal 261 probably needs this.] Filename: 262-rekey-circuits.txt Title: Re-keying live circuits with new cryptographic material Author: Nick Mathewson Created: 28 Dec 2015 Status: Open 1. Summary and Motivation Cryptographic primitives have an upper limit of how much data should be enc

[tor-dev] Proposal 261: AEZ for relay cryptography

2015-12-28 Thread Nick Mathewson
[Okay, I'm pulling this out of draft stage. Still not sure this is the right primitive, but I'm pretty sure this would be about the right way to do it.] Filename: 261-aez-crypto.txt Title: AEZ for relay cryptography Author: Nick Mathewson Created: 28 Oct 2015 Status: Open 0. History I wrote t

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

2015-12-28 Thread Nick Mathewson
On Mon, Dec 28, 2015 at 5:34 PM, Zhenfei Zhang wrote: > Hi list, > > This is a proposal to use quantum-safe hybrid handshake for Tor > communications. > Given NSA's recent announcement on moving towards quantum-safe cryptography, > it would be nice to have a quantum-safe feature for Tor. > > The i

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

2015-12-28 Thread Zhenfei Zhang
Hi list, This is a proposal to use quantum-safe hybrid handshake for Tor communications. Given NSA's recent announcement on moving towards quantum-safe cryptography, it would be nice to have a quantum-safe feature for Tor. The idea of the quantum-safe hybrid handshake is to combine both classical

[tor-dev] Scaling Tor Metrics, Round 2

2015-12-28 Thread Spencer
Hi, Karsten Loesing: Ah, I wasn't referring to anyone specifically. I'm also a fan of David McCandless' work and have his book on the shelf here :) There are two; a new one as of last year. (Next to the wonderful books of Edward Tufte and the great ggplot2 book of Hadley Wickham.) The

[tor-dev] metrics-lib 1.1.0 is released

2015-12-28 Thread Karsten Loesing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello devs, I just released metrics-lib 1.1.0: https://dist.torproject.org/descriptor/1.1.0/ - From the change log: # Changes in version 1.1.0 - 2015-12-28 * Medium changes - Parse flag thresholds in bridge network statuses, and parse the