[tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope

Zhenfei Zhang zzhang at securityinnovation.com
Mon May 9 18:16:34 UTC 2016


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 at 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 at torproject.org> wrote:
>
>> eikovi at sigaint.org transcribed 0.6K bytes:
>> > isis wrote:
>> > > eikovi at 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 at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160509/7ac174d3/attachment-0001.html>


More information about the tor-dev mailing list