On Fri, 29 Apr 2016 20:54:18 +0200
Jeff Burdges wrote:
> On Sun, 2016-04-03 at 15:36 +, Yawning Angel wrote:
> > http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf
> >
> > Is "optimized" in that, it is C with performance critical parts in
> > assembly (Table 3 is presumably the source
On Sun, 2016-04-03 at 15:36 +, Yawning Angel wrote:
> http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf
>
> Is "optimized" in that, it is C with performance critical parts in
> assembly (Table 3 is presumably the source of the ~200 ms figure from
> the wikipedia article). As i said,
Yawning Angel transcribed 4.3K bytes:
> On Fri, 22 Apr 2016 14:58:45 +0200 Jeff Burdges wrote:
> > On Fri, 2016-04-22 at 11:10 +, Yawning Angel wrote:
> > > On Fri, 22 Apr 2016 11:41:30 +0200 Jeff Burdges
> > > wrote:
> > > > There is some chance SIDH might wind up being preferable for key
On Fri, 22 Apr 2016 14:58:45 +0200
Jeff Burdges wrote:
> On Fri, 2016-04-22 at 11:10 +, Yawning Angel wrote:
> > On Fri, 22 Apr 2016 11:41:30 +0200
> > Jeff Burdges wrote:
> > > I'd imagine everyone in this thread knows this, but New Hope
> > > requires that "both parties use fresh secrets
On Fri, 2016-04-22 at 11:10 +, Yawning Angel wrote:
> On Fri, 22 Apr 2016 11:41:30 +0200
> Jeff Burdges wrote:
> > I'd imagine everyone in this thread knows this, but New Hope requires
> > that "both parties use fresh secrets for each instantiation".
>
> Yep. Alice can cache the public 'a'
> I'd imagine everyone in this thread knows this, but New Hope requires
> that "both parties use fresh secrets for each instantiation".
NTRUEncrypt, which has also been proposed for this, can be used with
ephemeral or long-lived keys safely.
Cheers,
William
__
On Fri, 22 Apr 2016 11:41:30 +0200
Jeff Burdges wrote:
> I'd imagine everyone in this thread knows this, but New Hope requires
> that "both parties use fresh secrets for each instantiation".
Yep. Alice can cache the public 'a' parameter, but everything else
needs to be fresh, or really really
I'd imagine everyone in this thread knows this, but New Hope requires
that "both parties use fresh secrets for each instantiation".
I suppose any key exchanges designed around this meshes well enough with
ntor, so that's okay. It leaves you relying on ECDH for the key
exchange with long term k
Thanks Yawning.
> Most of the changes since the paper has been released have been minor.
> The last major algorithmic change I'm aware of was 20151209 which
> altered the reconciliation mechanism (I don't particularly count the
> March changes that changed the on-the-wire encoding format to be
>
On Wed, 20 Apr 2016 18:30:14 + (UTC)
lukep wrote:
> Beware that the definition of newhope has changed! The authors have
> published a new version of this paper and some of the numbers are
> different. The parameter for the binomial distribution has changed
> from 12 to 16, the probability of f
Yawning Angel writes:
>
> On Sat, 2 Apr 2016 18:48:24 -0400
> Jesse V wrote:
> > Again, I have very little understanding of post-quantum crypto and I'm
> > just starting to understand ECC, but after looking over
> > https://en.wikipedia.org/wiki/Supersingular_isogeny_key_exchange and
> > skimmi
On 04/03/2016 10:37 AM, Jeff Burdges wrote:
> I should read up on this compression business since I'd no idea they
> were so small. At first blush, these SIDH schemes must communicate
> curve parameters of the curve the isogeny maps to and two curve points
> to help the other party compute the iso
On Sun, 03 Apr 2016 16:37:45 +0200
Jeff Burdges wrote:
> On Sun, 2016-04-03 at 06:52 +, Yawning Angel wrote:
> > Your definition of "reasonably fast" doesn't match mine. The
> > number for SIDH (key exchange, when the thread was going off on a
> > tangent about signatures) is ~200ms.
>
>
On Sat, 2016-04-02 at 18:48 -0400, Jesse V wrote:
> I just wanted to resurrect this old thread to point out that
> supersingular isogeny key exchange (SIDH) is the isogeny scheme that
> that you're referring to. Using a clever compression algorithm, SIDH
> only needs to exchange 3072 bits (384 byt
On 04/03/2016 02:52 AM, Yawning Angel wrote:
> Your definition of "reasonably fast" doesn't match mine. The number
> for SIDH (key exchange, when the thread was going off on a tangent
> about signatures) is ~200ms.
>
> A portable newhope (Ring-LWE) implementation[0] on my laptop can do one
> side
On Sat, 2 Apr 2016 18:48:24 -0400
Jesse V wrote:
> Again, I have very little understanding of post-quantum crypto and I'm
> just starting to understand ECC, but after looking over
> https://en.wikipedia.org/wiki/Supersingular_isogeny_key_exchange and
> skimming the SIDH paper, I'm rather impressed
I just want to note you only need an algorithm that protects against
2^80 quantum operations for short-term keys.
Regardless, I doubt anyone is going to be spending a billion dollars
to crack data sent over a single Tor connection.
___
tor-dev mailing li
On 02/03/2016 12:12 PM, Jeff Burdges wrote:
> I donno that you'll ever beat that 1kb key size with a post-quantum
> system. There is a lattice based signature scheme and an isogeny based
> scheme that'll both beat SPHINCS on signature sizes, but I think not so
> much on key size.
I just wanted t
On Thu, Mar 3, 2016 at 3:16 PM, Yawning Angel
wrote:
> On Thu, 3 Mar 2016 16:33:42 + (UTC)
> lukep wrote:
> > Hi,
> > I'm trying to understand the hybrid protocol that's described here.
> > The server generates the parallel secret PAR_SEC or P and then
> > computes C = ENCRYPT( P | B | Y, Q
On Thu, 3 Mar 2016 16:33:42 + (UTC)
lukep wrote:
> Hi,
> I'm trying to understand the hybrid protocol that's described here.
> The server generates the parallel secret PAR_SEC or P and then
> computes C = ENCRYPT( P | B | Y, QSPK);
> The client decrypts C to get P and then uses it combination
Zhenfei Zhang writes:
> 2.2.2 Handshake
>
> To perform the handshake, the client needs to know an identity key
digest
> for the server, and an ntor onion key (a curve25519 public key) for that
> server. Call the ntor onion key "B".
>
> The client generates a tempora
On Fri, 2016-01-01 at 11:14 +, Yawning Angel wrote:
> On Thu, 31 Dec 2015 20:51:43 +
> isis wrote:
> [snip]
> > I feel like there needs to be some new terminology here. It's
> > certainly not post-quantum secure, but "quantum-safe" doesn't seem
> > right either, because it's exactly the
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
previo
(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. And
> furthermore, we can also h
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
>
Wasn't there a transition period in migrating from RSA to ECC?
Maybe I'm just confused. Or you are confused. But I think it is best plan
for a five or ten year transition period.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproj
Hi,
s7r:
quantum computers don't exist...
Yet:
http://www.amarchenkova.com/about/
Wordlife,
Spencer
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1/3/2016 11:24 PM, Ryan Carboni wrote:
>
> Given the slow time it takes to roll things out, a timeline which
> begins with trusted directory keys include post-quantum crypto
> first, and which ends in enabling clients to use post-quantum
> crypt
>
> We had a GSOC project to produce "consensus diffs", so that clients could
> download the differences between each consensus each hour, rather than
> downloading a full consensus (~1.5MB).
>
> It showed some great results, but still needs a little work before we merge
> it.https://trac.torpro
On Sun, 3 Jan 2016 04:16:17 -0500
grarpamp wrote:
> http://safecurves.cr.yp.to/
>
> Just another link.
None of those algorithms will hold up to a quantum computer, and apart
from for TLS (where we use the NIST curves) we already use "safe"
Curve/Ed25519.
So I don't know why you're bringing it up
On Sat, Jan 2, 2016 at 10:22 PM, Yawning Angel wrote:
> In terms of prioritization, ensuring all existing traffic isn't
> subject to later decryption is far more important
I'd think so as you could adapt around other things, but
a traffic decrypt seems quite bad, especially given how
much is stor
On Sat, Jan 2, 2016 at 7:11 PM, Jesse V wrote:
> Here's a webpage, a paper, and software from djb:
> http://sphincs.cr.yp.to/ This is of course one example, there are other
> works on [typeof] cryptography, and I'm sure most of the authors
> like to provide a reference implementation of their idea
> On 3 Jan 2016, at 14:12, Jesse V wrote:
>
> On 01/02/2016 05:42 PM, Tim Wilson-Brown - teor wrote:
>> And if we can't use the reference implementation, we have some decent
>> programmers…
>> (On the other hand, if there's no reference implementation, then that
>> makes it hard to recommend tha
On Sat, 2 Jan 2016 17:18:56 -0800
Ryan Carboni wrote:
> And yet the NSA is moving to prime numbers.
So? In terms of prioritization, ensuring all existing traffic isn't
subject to later decryption is far more important that defending against
targeted active attacks that require hardware that doe
On 01/02/2016 05:42 PM, Tim Wilson-Brown - teor wrote:
> And if we can't use the reference implementation, we have some decent
> programmers…
> (On the other hand, if there's no reference implementation, then that
> makes it hard to recommend that particular crypto scheme.)
That sounds pretty clos
> On 3 Jan 2016, at 12:18, Ryan Carboni wrote:
>
> And yet the NSA is moving to prime numbers.
>
> A large public key isn't a very good reason to not adopt quantum-safe crypto,
> it just means that it requires having the Tor project to be able to scale to
> a larger degree. I suggest hash tab
> On 3 Jan 2016, at 11:11, Jesse V wrote:
>
> On 01/02/2016 01:49 PM, Flipchan wrote:
>> How would u add quantum-safe
>> crypto? I havent seen anyone puttin a pub lib that anyone can import
>
> Here's a webpage, a paper, and software from djb:
> http://sphincs.cr.yp.to/ This is of course one ex
And yet the NSA is moving to prime numbers.
A large public key isn't a very good reason to not adopt quantum-safe
crypto, it just means that it requires having the Tor project to be able to
scale to a larger degree. I suggest hash tables, a percentage of which are
pseudorandomly downloaded. Otherw
On 01/02/2016 01:49 PM, Flipchan wrote:
> How would u add quantum-safe
> crypto? I havent seen anyone puttin a pub lib that anyone can import
Here's a webpage, a paper, and software from djb:
http://sphincs.cr.yp.to/ This is of course one example, there are other
works on post-quantum cryptography
On 12/28/2015 11:34 PM, Zhenfei Zhang wrote:
1.2 Motivation: Disaster resilience
We are really trying to protect against the disastrous situation of one key
being entirely compromised. By introducing a second cryptographic
primitive,
namely, NTRUEncrypt, we ensure that the sys
On Fri, 1 Jan 2016 19:33:31 -0800
Ryan Carboni wrote:
> The first step should be replacing the long-term keys with
> quantum-safe crypto.
Wrong.
There are NO usable PQ signature primitives that are suitable for
deployment. Adding 1408+ bytes to every single microdescriptor is
not a realistic p
The first step should be replacing the long-term keys with quantum-safe
crypto.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hello,
On Thu, 31 Dec 2015 20:51:43 +
isis wrote:
[snip]
> I feel like there needs to be some new terminology here. It's
> certainly not post-quantum secure, but "quantum-safe" doesn't seem
> right either, because it's exactly the point at which the adversary
> gains appropriate quantum comp
On Thu, Dec 31, 2015 at 3:51 PM, isis wrote:
> Zhenfei Zhang transcribed 22K bytes:
[...]
>> In addition, this is a modular design that allows us to use any quantum-safe
>> cryptographic primitives. As a proof of concept, we instantiated the
>> protocol with NTRUEncrypt lattice-based crypto. We
Zhenfei Zhang transcribed 22K bytes:
> 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.
Hello Zhenfei,
We're al
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
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
47 matches
Mail list logo
