Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
Typos:
used as input to the SHAKE-256 extendable output function (XOF), as decribed
deScribed
In the case for relays possessing Ed25519 identity keys (c.f. Tor proposal ... descriptor (c.f. Tor proposal #264) advertises support for the "Relay" ... (c.f. Tor proposal #249). ... We introduce a new sub-protocol number, "Relay=3", (c.f. Tor proposal #264
confer, cf., it's a single flying word
public keys already being in included within the "ntor-onion-key" entry.
s/in included/included/
poly_getnoise() first generates 4096 Bytes of uniformly random data. This can
s/Bytes/bytes/
mode). The output of the PRG is considered an array of 2048 16-bit integers ... Note further that the output of this function is secret; the PRG (and the
PRnG was used previously
pseudocode description of a very naive inplace transformation of an input ... [0]; a pseudocode description of a very naive inplace transformation of an
s/inplace/in-place/g
eikovi@sigaint.org transcribed 1.1K bytes:
Typos:
Thanks! Fixed: https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=draft/newhope&... -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
isis wrote:
eikovi@sigaint.org transcribed 1.1K bytes:
Typos:
Thanks! Fixed:
https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=draft/newhope&...
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
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&...
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&... -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
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&...
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&...
-- ♥Ⓐ 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
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&...
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&...
-- ♥Ⓐ 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
participants (3)
-
eikovi＠sigaint.org -
isis -
Zhenfei Zhang