Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Zhenfei Zhang]

Thanks Yawning.

> Agreed.  I like the QSH design, though I still want to use FIPS 202
> (SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're
> changing things anyway, we may as well future proof here too".

Yes. Will put that in the request too. Sorry missed this comment in
previous email.

> Client side for Tor is somewhat deceptive because Hidden Services act
> as the client when connecting to the Rdv point, so we do care about
> performance there too.  I fully expect that the gains that we will get
> from separate work due to improved threading will pay for the CPU cost
> increases here, but I'll need to do some benchmarking to be certain.

Thanks. I didn't know that.

Cheers,
Zhenfei

On Mon, Jan 4, 2016 at 1:26 PM, Yawning Angel 
wrote:

> (Note: Snipping liberally for brevity)
>
> On Mon, 4 Jan 2016 11:56:54 -0500
> Zhenfei Zhang  wrote:
> > 2. On NTRU vs NTRU-Prime vs R-LWE and others.
> > The QSH is modular designed to suite any quantum-safe encryption
> > algorithm. So we can chose any one we want for trail. And
> > furthermore, we can also hybrid, say ECC, NTRU and R-LWE, to give a
> > bit more confidence in case one of the quantum-safe encryption
> > algorithm turns out to be not quantum safe, or broken.
>
> Hybridizing all 3 probably will get somewhat expensive (though not
> prohibitively so), nickm and I have branches to thread the client side
> circuit build crypto which will help mask the performance penalty of
> this proposal in general (not yet merged, shouldn't require changes to
> your branch).
>
> > That been said, we chose NTRU for several reasons. NTRU is more
> > mature than R-LWE from our point o view. NTRU has a full spec, a
> > reference implementation, and is standardized by several bodies;
> > while for R-LWE, since it enables many interesting cryptographic
> > primitives, such as FHE, there has been many different parameter
> > proposals, which leads to some kind of confusion as to which one
> > should reference to.
>
> At the current time, if I had to pick one, I'd use the newhope variant
> of Peikert's KEM scheme (And in fact was going to amend the proposal
> to specify that as the Ring-LWE primitive).
>
> The BCNS proposal has gotten slightly more scrutiny, but it's slower,
> has larger keys, and provides a lower security level than newhope.
>
> > We are happy to roll out any above encryption algorithm as you see
> > fit. But our proposal is mainly about the QSH approach. I think the
> > best option for now is to buildin a QSH for Tor, with a flexible
> > API that allows us to switch between algorithms when fit. And for now
> > use any quantum-safe encryption algorithm that is ready to be used.
> > After all, any QS encryption is better than nothing.
>
> Agreed.  I like the QSH design, though I still want to use FIPS 202
> (SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're
> changing things anyway, we may as well future proof here too".
>
> > 3. License
> > I am sorry I am not familiar with the license. But my general feeling
> > is that Security Innovation is willing to let Tor to use NTRU for
> > free. We just need to work out the suitable license to make this
> > happen.
>
> I'm glad to hear that.  My main concern here is that if, say Debian
> Legal thinks that the existing FOSS patent wavier is insufficient to
> allow NTRU to be included in Debian packages till 2017, this will
> significantly hamper the relay side uptake of the safer primitives due
> to the Debian monoculture on our relays.
>
> I can do the Ring-LWE work, since the QSH primitive is modular so that
> there will be options for people that have more stringent
> license/patent policies than we do.
>
> If I were to prioritize handshake selection, I would lean towards
> NTRU + Ring-LWE, over NTRU, over Ring-LWE based on what the
> peer supports.
>
> > > As I recall, the product form parameter sets are extra encumbered.
> > > Apart from key/ciphertext size and a minor performance
> > > differential, is there any reason to not use one of the X9.98
> > > parameter sets (Eg: EES613EP1)
> >
> > Yes we can use non-product form polynomials, if everyone agrees on it.
> > Non-product form polynomials will make key generation and decryption
> > a bit slower, but those cost are on the client side. It has no impact
> > on the load of server side.
>
> Client side for Tor is somewhat deceptive because Hidden Services act
> as the client when connecting to the Rdv point, so we do care about
> performance there too.  I fully expect that the gains that we will get
> from separate work due to improved threading will pay for the CPU cost
> increases here, but I'll need to do some benchmarking to be certain.
>
> > > * "For 128 bits quantum security, use NTRU_EESS743EP1." should be
> > >   "For 256 bits" (Section 2.3).
> >
> > NTRU_EESS743EP1 provides 256 classical security and 128 bits quantum
> > security. Please see
> > 

[tor-dev] Oops / Re: Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[n...@cock.li]

Blah, what I said was already suggested, but I hadn't received the
original mail when I'd replied
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[n...@cock.li]

Tim Wilson-Brown - teor:
> One consequence of this proposal is that relays that only exit to 443
> and 6667 will lose the Exit flag. But these relays do exit to an
> encrypted port, so this somewhat contradicts the goal of the
> proposal: "Exit flags can no longer be assigned to relays that exit
> only to unencrypted ports."
> 
> Why not make the rule: "at least one of 80/6667, and at least one of
> 443/5222".

Perhaps also a transitional period where exit-qualifying ports are
added, and months after that, 80/6667 are no longer qualifying?

> I am also concerned about the choice of XMMP "because the XMPP
> protocol is slowly gaining popularity within the communities on the
> internet". Shouldn't we focus on secure protocols that are widely
> used right now?
> 
> Alternately, we could add other widely used SSL ports in addition to
> XMMP, and perhaps increase the rule to "at least two SSL ports".

6697 is the most popular IRCS port, maybe it could replace 6667.
Should 993(IMAPS), 995(POP3S) or 465(SMTPS) be considered as well?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Tom van der Woerdt]

I've had this on my todo list for a while, finally wrote it down.

Honestly, it's a minor change, but something that imho needs to be done.

Torspec branch:
https://github.com/TvdW/torspec/commits/exit-flag-not-all-plaintext

Full text below, tldr first: replace [80,443,6667] with [80,443,5222]
for Exit flagging.

===

Filename: 264-exit-flag-not-all-plaintext.txt
Title: Stop giving Exit flags when only unencrypted traffic can exit
Author: Tom van der Woerdt
Created: 2016-01-05
Status: Open


1. Introduction

  Tor's Exit flags are assigned to relays that have an exit policy that
allows
  exiting to at least two out of three pre-defined ports: 80, 443 and 6667.

  Since 80 and 6667 (resp. http and irc) are generally used for unencrypted
  traffic, an attacker could construct an exit policy that relays only
  unencrypted data.

2. Changes

2.1. Exit flagging

  By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit
  flags can no longer be assigned to relays that exit only to unencrypted
  ports.

2.2. dir-spec.txt

  A change to dir-spec.txt will be needed to change port 6667 to 5222.

3. Migration

  This change only needs to be rolled out to directory authorities.
Since the
  flagging system is simple, no special migration is needed for this change,
  and it will take effect as soon as the deployment of the change has
reached
  a sufficient number of directory authorities.

4. Other considerations

  While it would have been ideal to drop the port 80 condition as well,
in the
  current state of the internet this is not likely to be a good idea. Too
  much websites still use unencrypted connections. However, this may be
worth
  reconsidering every few years.

  XMPP was chosen to replace IRC because nowadays unencrypted XMPP is rare,
  and because the XMPP protocol is slowly gaining popularity within the
  communities on the internet. Other popular ports have been considered,
such
  as 22 (SSH), 465 (SMTP), or 995 (POP3), but these are unlikely to be good
  candidates because of wide spread bruteforce attacks on these ports.

===


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

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Tim Wilson-Brown - teor]

> On 5 Jan 2016, at 11:29, Tom van der Woerdt  wrote:
> ...
> 2.1. Exit flagging
> 
>  By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit
>  flags can no longer be assigned to relays that exit only to unencrypted
>  ports.

One consequence of this proposal is that relays that only exit to 443 and 6667 
will lose the Exit flag.
But these relays do exit to an encrypted port, so this somewhat contradicts the 
goal of the proposal:
"Exit flags can no longer be assigned to relays that exit only to unencrypted 
ports."

Why not make the rule: "at least one of 80/6667, and at least one of 443/5222".

I am also concerned about the choice of XMMP "because the XMPP protocol is 
slowly gaining popularity within the
 communities on the internet".
Shouldn't we focus on secure protocols that are widely used right now?

Alternately, we could add other widely used SSL ports in addition to XMMP, and 
perhaps increase the rule to "at least two SSL ports".

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Go version in Gitian descriptors

[sycamoreone]

isis:
> Tim Wilson-Brown - teor transcribed 12K bytes:
>>
>> Note the go bootstrap process has changed now that go is entirely written in 
>> go:
>>
>> The new build process for Go 1.x (x ≥ 5) will be:
>>
>>  • Build cmd/dist with Go 1.4.
>>  • Using dist, build Go 1.x compiler toolchain with Go 1.4.
>>  • Using dist, rebuild Go 1.x compiler toolchain with itself.
>>  • Using dist, build Go 1.x cmd/go (as go_bootstrap) with Go 1.x 
>> compiler toolchain.
>>  • Using go_bootstrap, build the remaining Go 1.x standard library and 
>> commands.
>>
>> https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit?pref=2=1
>>
>> Tim Wilson-Brown (teor)
> 
> I've not tried it yet, but it's my understanding that gccgo can still be used
> to compile go-1.5:
> 
> https://github.com/golang/go/issues/10092
> 
> So another route might be to modify our build of GCC to include gccgo, then
> use that to bootstrap the official Go compiler.

I never tried using gccgo to bootstrap as using go_1.4 is rather easy in
practice using the official tooling:

  # 1. Build a go1.4 using GCC.

  git clone https://github.com/golang/go.git
  cp -r go go_bootstrap
  ( cd go_bootstrap; git checkout origin/release-branch.go1.4 )
  ( cd go_bootstrap/src/ && ./all.bash )

  # 2. Now build a go1.5 using the go1,4

  export GOROOT_BOOTSTRAP=$PWD/go_bootstrap
  ( cd go && git checkout origin/release-branch.go1.5 )
  ( cd go/src/ && ./all.bash )

  # 3. And now do
  echo "PATH=$PATH:$PWD/go/bin" >> .profile

Cheers!

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

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Zhenfei Zhang]

Hi all,

Thanks for all the comments. Sorry I wasn't able to reply immediately.
Please allow
me to summarize the comments. I see mainly the following questions.

1. Quantum-safe authentication.
As Yawning has pointed out,

> I personally don't think that any of the PQ signature schemes are usable
> for us right now, because the smallest key size for an algorithm that
> isn't known to be broken is ~1 KiB (SPHINCS256), and we probably can't
> afford to bloat our descriptors/micro-descriptors that much.

This is also the reason we wanted to roll out QSH first and add the
quantum-safe
signature schemes later. We have several good candidate for quantum-safe
encryption algorithms. But for signatures, they are not mature imho.

Another reason that we did not include authentication is due to the attack
model.
As I have mentioned (but probably didn't explain very clearly) in previous
email, we
are facing two types of attackers. Attacker type I, passive attacker at
present, who
cannot break classical authentication nor encryption, record the data
anyway, and
decrypt it when quantum computer become available in future. Attack type
II, active
attacker who tries to attack the authentication while the communication is
taking
place. This attack will be possible in future when quantum computer
arrives. But for
now, they will not be successful.

As we believe that there does not exist a general purpose quantum computer
at
present (and maybe several years away), we have time to deal with attacker
type II.
But the attacker type I is the real threat at the present day. Our proposal
is to address
this threat.

2. On NTRU vs NTRU-Prime vs R-LWE and others.
The QSH is modular designed to suite any quantum-safe encryption algorithm.
So we
can chose any one we want for trail. And furthermore, we can also hybrid,
say ECC,
NTRU and R-LWE, to give a bit more confidence in case one of the
quantum-safe encryption
algorithm turns out to be not quantum safe, or broken.

That been said, we chose NTRU for several reasons. NTRU is more mature than
R-LWE
from our point o view. NTRU has a full spec, a reference implementation,
and is standardized
by several bodies; while for R-LWE, since it enables many interesting
cryptographic primitives,
such as FHE, there has been many different parameter proposals, which leads
to some kind
of confusion as to which one should reference to.

> However, if we were to go the route of using NTRU, we'd likely want to
instead
> use Dan Bernstein's NTRU Prime parameters, in order to eliminate some of
the
> inherent algebraic structure of the ideal lattice which might possibly be
> exploited. [0] [1]

As for NTRU-Prime, I am not aware there is a specific instantiation of this
parameter sets, nor
any paper that considers the security of a specific parameter set. Also,
this NTRU-Prime would
require some extensive scrutiny before we can use it.

We are happy to roll out any above encryption algorithm as you see fit. But
our proposal is mainly
about the QSH approach. I think the best option for now is to buildin a QSH
for Tor, with a flexible
API that allows us to switch between algorithms when fit. And for now use
any quantum-safe
encryption algorithm that is ready to be used. After all, any QS encryption
is better than nothing.

3. License
I am sorry I am not familiar with the license. But my general feeling is
that Security Innovation is
willing to let Tor to use NTRU for free. We just need to work out the
suitable license to make this
happen.

4. Misc.
> Post-quantum forward-secrecy is what I've been using to describe this
> property.

We will use this terminology. Thanks.

> As I recall, the product form parameter sets are extra encumbered.
> Apart from key/ciphertext size and a minor performance differential, is
> there any reason to not use one of the X9.98 parameter sets (Eg:
> EES613EP1)

Yes we can use non-product form polynomials, if everyone agrees on it.
Non-product form polynomials will make key generation and decryption
a bit slower, but those cost are on the client side. It has no impact on
the
load of server side.


> * "For 128 bits quantum security, use NTRU_EESS743EP1." should be
>   "For 256 bits" (Section 2.3).

NTRU_EESS743EP1 provides 256 classical security and 128 bits quantum
security. Please see
https://eprint.iacr.org/2015/708.pdf
for arguments of those security levels.

> I'm a little confused about what exactly is meant by "disaster
resilience" here.

We will remove "disaster resilience".

Those are most comments I saw. Sorry if I missed some of your comments.
Please let me know
if you have questions that I failed to answer.

Happy new year to everyone.

Cheers,
Zhenfei


On Sun, Jan 3, 2016 at 8:32 PM, Ryan Carboni  wrote:

> Wasn't there a transition period in migrating from RSA to ECC?
>
> Maybe I'm just confused. Or you are confused. But I think it is best plan
> for a five or ten year transition period.
>
> ___
> tor-dev 

Re: [tor-dev] tor-dev Digest, Vol 60, Issue 2

[Zhenfei Zhang]

Hi Flipchan,

There are reference implementation of quantum-safe cryptographic
algorithms, such
as NTRU encryption algorithm (in libntruencrypt):
https://github.com/NTRUOpenSourceProject/NTRUEncrypt
and BLISS signature algorithm,
http://bliss.di.ens.fr/

Those are independent softwares. But for what I understand, common crypto
libraries,
such as crypto in openssl, libgcrypt, crypto++, do not have quantum-safe
crypto, except
wolfssl that supports NTRU.
https://github.com/wolfSSL/wolfssl

We also have libgcrypt with NTRU supports,
https://github.com/wwhyte-si/libgcrypt-ntru
but it is not an official release.

Cheers,
Zhenfei


On Sat, Jan 2, 2016 at 5:49 PM, Flipchan  wrote:

> How would u add quantum-safe
> crypto? I havent seen anyone puttin a pub lib that anyone can import
>
> tor-dev-requ...@lists.torproject.org skrev: (2 januari 2016 13:00:02 CET)
>>
>> Send tor-dev mailing list submissions to
>>  tor-dev@lists.torproject.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>> or, via email, send a message with subject or body 'help' to
>>  tor-dev-requ...@lists.torproject.org
>>
>> You can reach the person managing the list at
>>  tor-dev-ow...@lists.torproject.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of tor-dev digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: Quantum-safe Hybrid handshake for Tor (Ryan Carboni)
>>2. Re: Quantum-safe Hybrid handshake for Tor (Yawning Angel)
>>
>>
>> --
>>
>>
>> Message: 1
>> Date: Fri, 1 Jan 2016 19:33:31 -0800
>> From: Ryan Carboni 
>> To: tor-dev@lists.torproject.org
>> Subject: Re: [tor-dev] Quantum-safe Hybrid handshake for Tor
>> Message-ID:
>>  

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Yawning Angel]

(Note: Snipping liberally for brevity)

On Mon, 4 Jan 2016 11:56:54 -0500
Zhenfei Zhang  wrote:
> 2. On NTRU vs NTRU-Prime vs R-LWE and others.
> The QSH is modular designed to suite any quantum-safe encryption
> algorithm. So we can chose any one we want for trail. And
> furthermore, we can also hybrid, say ECC, NTRU and R-LWE, to give a
> bit more confidence in case one of the quantum-safe encryption
> algorithm turns out to be not quantum safe, or broken.

Hybridizing all 3 probably will get somewhat expensive (though not
prohibitively so), nickm and I have branches to thread the client side
circuit build crypto which will help mask the performance penalty of
this proposal in general (not yet merged, shouldn't require changes to
your branch).

> That been said, we chose NTRU for several reasons. NTRU is more
> mature than R-LWE from our point o view. NTRU has a full spec, a
> reference implementation, and is standardized by several bodies;
> while for R-LWE, since it enables many interesting cryptographic
> primitives, such as FHE, there has been many different parameter
> proposals, which leads to some kind of confusion as to which one
> should reference to.

At the current time, if I had to pick one, I'd use the newhope variant
of Peikert's KEM scheme (And in fact was going to amend the proposal
to specify that as the Ring-LWE primitive).

The BCNS proposal has gotten slightly more scrutiny, but it's slower,
has larger keys, and provides a lower security level than newhope.

> We are happy to roll out any above encryption algorithm as you see
> fit. But our proposal is mainly about the QSH approach. I think the
> best option for now is to buildin a QSH for Tor, with a flexible
> API that allows us to switch between algorithms when fit. And for now
> use any quantum-safe encryption algorithm that is ready to be used.
> After all, any QS encryption is better than nothing.

Agreed.  I like the QSH design, though I still want to use FIPS 202
(SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're
changing things anyway, we may as well future proof here too".

> 3. License
> I am sorry I am not familiar with the license. But my general feeling
> is that Security Innovation is willing to let Tor to use NTRU for
> free. We just need to work out the suitable license to make this
> happen.

I'm glad to hear that.  My main concern here is that if, say Debian
Legal thinks that the existing FOSS patent wavier is insufficient to
allow NTRU to be included in Debian packages till 2017, this will
significantly hamper the relay side uptake of the safer primitives due
to the Debian monoculture on our relays.

I can do the Ring-LWE work, since the QSH primitive is modular so that
there will be options for people that have more stringent
license/patent policies than we do.

If I were to prioritize handshake selection, I would lean towards
NTRU + Ring-LWE, over NTRU, over Ring-LWE based on what the
peer supports.

> > As I recall, the product form parameter sets are extra encumbered.
> > Apart from key/ciphertext size and a minor performance
> > differential, is there any reason to not use one of the X9.98
> > parameter sets (Eg: EES613EP1)  
> 
> Yes we can use non-product form polynomials, if everyone agrees on it.
> Non-product form polynomials will make key generation and decryption
> a bit slower, but those cost are on the client side. It has no impact
> on the load of server side.

Client side for Tor is somewhat deceptive because Hidden Services act
as the client when connecting to the Rdv point, so we do care about
performance there too.  I fully expect that the gains that we will get
from separate work due to improved threading will pay for the CPU cost
increases here, but I'll need to do some benchmarking to be certain.

> > * "For 128 bits quantum security, use NTRU_EESS743EP1." should be
> >   "For 256 bits" (Section 2.3).  
> 
> NTRU_EESS743EP1 provides 256 classical security and 128 bits quantum
> security. Please see
> https://eprint.iacr.org/2015/708.pdf
> for arguments of those security levels.

Ah gotcha, I haven't seen that paper and I was going off the initial
estimates, thanks for the clarification.

Regards,

-- 
Yawning Angel


pgpP9Y2gM0JOm.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev