uld remain open to schemes other than NewHope." That still doesn't make
> sense to me.
It was two separate statements really. Having flexibility on choice of
algorithm is a good idea. Some weird scheme which is based on NTRU has been
broken. If I had a point, it was "new
NTRU-like algorithms into ring-LWE like algorithms, and dismissing the former
since they are known to be weaker. I still think a flexible protocol rather
than all eggs in the NewHope basket is a Good Thing.
-- lukep
___
tor-dev mailing list
tor-dev@
X2. Personally I don't really care
about not having the security reduction for 'a' (there's still the proof in
the newhope paper for the rest of the key exchange).
The bandwidth can be halved for n=512 vice n=1024 - this is the JarJar of
NewHope - m
is easy to switch
> at a later point, and deploy it.
The important thing now is surely to get the protocol right so that we can
slot algorithms in or out (then pick one or two that we actually want to
integrate)
-- lukep
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
a - the values of t0,t1,t2,t3 must be
kept secret, so must also be timing-attack-resistant. Also the calculation
of t is incorrect as stated (copy-and-paste error; needs to be a function of
v1,v2,v3,t1,t2,t3 etc.)
If I ever get chance to play with the code I'd like to have a go a prod
> FWIW, the performance hasn't changed noticeably, unless there's
> something newer than 20160328.
I can now see you've got a new version in your github repository. Is this
standalone or have you tried incorporating it into tor source code yet?
Thanks
-- lukep
_
as settled down yet. There's also a
new paper on IACR called "How (not) to instantiate ring-LWE" which has some
ideas on how to choose the error distribution - this might mean that newhope
has to change again??
-- lukep
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
nput = E | P | QSPK | ID | PROTOID
So E is secret, P is generated by the server, QSPK ID and PROTOID are all
public. So IF ECC is broken and IF the server has been compromised (big
IF's!) then everything is known.
I guess my point is that the client isnt contributing any secret information
to the quantum-safe part of KEY_SEED. Is that OK?
-- lukep
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
