On Fri, 2016-04-22 at 11:10 +0000, Yawning Angel wrote: > On Fri, 22 Apr 2016 11:41:30 +0200 > Jeff Burdges <burdges@xxxxxxxxxx> 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 bad things happen. I'd assume that 'a' could be generated by both parties from a seed parameter declared by Alice? I haven't noticed it being secretly tweaked by Alice. If 'a' must be sent, then 'a' would double the key size from one side, no? In that case, one should consider if reversing the Alice and Bob roles of the client and server helped by either (a) adjusting the traffic flow to mask circuit building, or (b) allowing one to stash 'a' in the descriptor. I donno if there are any concerns like the client needing to influence 'a'. > > There is some chance SIDH might wind up being preferable for key > > exchanges with long term key material. > > Maybe. Some people have hinted at an improved version of SPHINCS256 > being in the works as well. Ain't clear how that'd work. There are homomorphic MAC like constructions, like accumulators, which might let you reuse your Merkle tree. I though these usually needed assumptions that Shor's algorithm nukes, like one is f(x,y) = x^7 + 3 y^7 mod N with N=pq secret, for example. I suppose Nyberg's accumulator scheme is post-quantum, but I though it's huge too. I'm not completely sure if just an accumulator helps anyways. Jeff
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev