[tor-dev] Proposal 216 (ntor) redux

Nick Mathewson nickm at alum.mit.edu
Fri Dec 14 18:46:40 UTC 2012

On Thu, Dec 13, 2012 at 4:21 PM, Ian Goldberg <iang at cs.uwaterloo.ca> wrote:
> lines 30-32:
> #  Let a,A=KEYGEN() yield a new private-public keypair in G, where a is
> #  the secret key and A = EXP(g,a).  If additional checks are needed to
> #  insure a valid keypair, they should be performed.
> s/insure/ensure/


> Should those checks be specified?

My understanding is that whether more checking is needed at that point
is going to be dependent on the actual group. But if you can tell me
what sentences to add, I will add them.

>     In particular, you need to ensure
> that the low three bits of a are 0.  Ah, I see you say it down at line
> 52-53; perhaps it should be moved up here?  You also define g down at
> 51, but use it at 31.

It's defined in 27-28 : "Let's say we are using a generator g for this group."

>    In addition, are a,A,g in the above para meant to
> be numbers or strings?

Hm. I believe that you can't go wrong reading the document if you
assume that everywhere I talk about transmitting group elements, they
must be strings, but everywhere I talk about operating on them, they
must be group elements. Then again, that's hardly a good way to write

>  You'll likely need to specify the mapping
> between numbers and strings (it's just little-endian bytes, as it turns
> out).

Okay; my understanding is that the curve25519 specification
encompasses that encoding; I've tried to make that explicit, though.


More information about the tor-dev mailing list