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 <[email protected]
> 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 <[email protected]> wrote:
>
>> [email protected] transcribed 0.6K bytes:
>> > isis wrote:
>> > > [email protected] 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
>> [email protected]
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>>
>
_______________________________________________
tor-dev mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Reply via email to