[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote:
eikovi@xxxxxxxxxxx transcribed 0.6K bytes:
> isis wrote:
> > eikovi@xxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



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