Sorry, my bad. Please ignore my previous email. I just noticed that here A is
not the public polynomial \hat{a} in the R-LWE setting, but the concatenation
of a seed that generates \hat{a}, and client's side of secret \hat{b} = \hat{a} s+e

Zhenfei

On Mon, May 9, 2016 at 2:04 PM, Zhenfei Zhang <zzhang@securityinnovation.com> wrote:
Hi all,

If I understand it properly, in the proposal the client need to send the whole
matrix A during the first initiation message. I draw this conclusion from the
datagram:

 | a, A         := NEWHOPE_KEYGEN(SEED)                                                 |
 | CLIENT_HDATA := ID || Z || X || A                                                    |
 |                                                                                      |
 |               --- CLIENT_HDATA --->  


May I ask why? Is it because the keypair generation is modularized, and
hence a and A are connected from a protocol point of view? However, in the
original construction of new hope, or other R-LWE based schemes, a and A
are sampled independently, giving out the seed of A will not leak information
on a. So how about the following:

 | A            := NEWHOPE_PK_KEYGEN(SEED1)                                             |
 | a := NEWHOPE_SK_KEYGEN(SEED2) |
 | CLIENT_HDATA := ID || Z || X || SEED1 | | | | --- CLIENT_HDATA --->


This will save significant data for the first transmission: over 1 KB of A
compared to 32 bits of SEED1. The server will be able to recover A from
NEWHOPE_PK_KEYGEN which will be a public function.


Cheers,
Zhenfei


On Mon, May 9, 2016 at 12:07 PM, isis <isis@torproject.org> wrote:
eikovi@sigaint.org transcribed 0.6K bytes:
> isis wrote:
> > eikovi@sigaint.org transcribed 1.1K bytes:
> >> Typos:
> >
> > Thanks!  Fixed:
> >
> > https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=draft/newhope&id=5c115905
>
> You skipped 2:
>
> -  public keys already being in included within the "ntor-onion-key" entry.
> +  public keys already being included within the "ntor-onion-key" entry.
>
> -  [0]; a pseudocode description of a very naive inplace transformation of an
> +  [0]; a pseudocode description of a very naive in-place transformation of an

Oops!  Thanks again.  Peter fixed those in this commit:
https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=draft/newhope&id=28181cc7

--
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev