Re: [tor-dev] txtorcon versioning

2017-04-12 Thread meejah 
Damian Johnson  writes:

> In the above you say "The onion service APIs *will* change" but also
> "At one point, I thought of breaking a few now-regrettable
> APIs. However, I will not do this." - are you changing APIs or not?

> If you are then Calendar Versioning will make it tricker for your
> users to figure out when you're doing so.

The programming guide and docstrings mention which onion APIs are
experimental; those will change.

The previously-released TCPHiddenServiceEndpoint and
EphemeralHiddenService APIs will maintain backwards compatiblity. The
names for the new things use "onion" (e.g. .create_onion_service)

Basically the idea is similar to (inspired by?) what Twisted itself
provides: if your code doesn't currently cause txtorcon to emit
warnings, then you can upgrade. Currently there are no warnings, so
everyone can upgrade.

cheers,

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

Re: [tor-dev] txtorcon versioning

2017-04-12 Thread Damian Johnson 
Hi meejah. This sounds like a good move since txtorcon makes so many
small incremental releases. I like symantic versioning for stem [1],
but I've only made six releases thus far. Not nineteen. :P

Symantic versioning provides a clear way of indicating what upgrades
are safely backwards compatible and which aren't. In the above you say
"The onion service APIs *will* change" but also "At one point, I
thought of breaking a few now-regrettable APIs. However, I will not do
this." - are you changing APIs or not?

If you are then Calendar Versioning will make it tricker for your
users to figure out when you're doing so.

[1] https://stem.torproject.org/change_log.html#versioning

On Wed, Apr 12, 2017 at 1:25 PM, meejah  wrote:
>
> I will soon release the next version of txtorcon with a ton of cool new
> features. This will be called 0.19.0. More details:
>
>http://timaq4ygg2iegci7.onion/releases.html
>
> Going forward, versioning will switch to a "CalVer.org" variant. At one
> point, I thought of breaking a few now-regrettable APIs.
>
> However, I will not do this.
>
> The next version after 0.19.0 will be 17.x.y
> Changes in any existing APIs will be done by first introducing the new
> thing, deprecating the old thing and eventually removing the old
> thing. The new documentation's "programming guide" includes some notes
> on API stability. I have not to date broken/changed any existing
> API. Also at this point nothing is deprecated (but there are "preferred"
> APIs).
>
> The onion services APIs *will* change for the 17.x release.
>
> New code should follow the recommendations in the programming
> guide. Existing code will continue to work for the forseeable future.
>
> thanks,
> meejah
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] txtorcon versioning

2017-04-12 Thread meejah 

I will soon release the next version of txtorcon with a ton of cool new
features. This will be called 0.19.0. More details: 

   http://timaq4ygg2iegci7.onion/releases.html

Going forward, versioning will switch to a "CalVer.org" variant. At one
point, I thought of breaking a few now-regrettable APIs.

However, I will not do this.

The next version after 0.19.0 will be 17.x.y
Changes in any existing APIs will be done by first introducing the new
thing, deprecating the old thing and eventually removing the old
thing. The new documentation's "programming guide" includes some notes
on API stability. I have not to date broken/changed any existing
API. Also at this point nothing is deprecated (but there are "preferred"
APIs).

The onion services APIs *will* change for the 17.x release.

New code should follow the recommendations in the programming
guide. Existing code will continue to work for the forseeable future.

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

Re: [tor-dev] Interest in collaborating on a standard Ed25519 key blinding scheme?

2017-04-12 Thread Oleg Andreev 
> From: George Kadianakis
> Date: Wed, Apr 12, 2017 at 7:57 AM
> 
> An update:
> 
> After lots of discussions in the Amsterdam Tor meeting, the following
> approach was suggested for cleansing keys of their torsion components
> that is more friendly towards hierarchical key-derivation schemes:
> https://moderncrypto.org/mail-archive/curves/2017/000866.html
> 
> However, my current intuition is to just not do this for hidden service
> ed25519 blinded keys. Those keys are only used for signing descriptors
> which should be safe to do, and we don't plan to use them for D-H any
> time soon. If we or some crazy app EVER decides to use those ephemeral
> keys for key exchange, we would need to use a special DH function that
> kills the tensor component of keys before using them, as suggested by
> Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html
> 
> Please let me know if you think this is not a good idea!

Thanks for the update, George.

TL;DR: your scheme seems to be just fine for signatures, and even 
torsion-safety issues are not huge issues IMHO. For wide applicability
reasons, I am trying to make our scheme ChainKD [1] to fit as many 
use cases as possible and therefore very interested in Tor's 
requirements and rationale regarding Tor's key blinding proposal.

L;R:

After studying the situation with key derivation schemes for Ed25519, 
my impression is that the central issue is not even safety, but 
compatibility with existing Ed25519 implementations. People who have 
to integrate a key derivation scheme in their protocol are often not 
the same people who write the underlying primitives such as scalar 
multiplication.

This means, that it's safer to be conservative and keep the derivation
scheme as compatible with EdDSA as possible so that assumptions that 
implementors may take by just reading the EdDSA spec without knowing
about key derivation schemes, do not cause compatibility problems.

Since it's not a trivial task to even learn the landscape of problems
around Ed25519 compatibility- and safety-wise, it'd help if we can
figure all of that once, implement and reuse the result w/o having
to go through this again and again. Hence, our interest in standardizing
the scheme that satisfies as many requirements as possible.


https://xkcd.com/927/


Following the feedback in BIP32-Ed25519 paper [2], I've updated our
ChainKD [1] scheme to make it safely "compatible" with DH use cases 
(among those is asymmetric encryption such as ECIES). 

In the Design Rationale section [3] I try to describe the issues with
low/high bits and torsion-safe representative and why we choose
to keep those bits as defined in Curve25519 instead of "torsion-safe
representative" and why we use BIP32-style blinding-by-addition instead
of blinding-by-multiplication.

One piece of feedback affecting our proposal is missing, though:
I'd like to ask Tor developers what is the rationale and requirements 
for their key blinding proposal. Specifically, why do you choose to
blind via multiplication instead of addition:

s' = b*s; P' = b*P (Tor's proposal)

vs

s' = s + b; P' = P + b*G   (BIP32, ChainKD)


(G -- base point, 
 P -- pubkey, 
 s -- secret scalar, P = s*G,
 b -- blinding scalar)

I know of a few reasons to use addition over multiplication
(e.g. performance and bit-compatibility with EdDSA), 
but would love to learn if that hurts some protocols.


PS. I've just joined the list and replying to a forwarded message. 
I apologize if I break the thread.


[1] ChainKD, revised: 
https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications/chainkd.md
[2] BIP32-Ed25519: https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA
[3] ChainKD rationale: 
https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications/chainkd.md#design-rationale
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Interest in collaborating on a standard Ed25519 key blinding scheme?

2017-04-12 Thread George Kadianakis 
Tony Arcieri  writes:

> I'm trying to gauge interest on the IRTF's CFRG mailing list regarding
> collaborating on a draft for a standard Ed25519 hierarchical derivation /
> key blinding scheme:
>
> https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA
>
> The post makes several mentions of Tor's work in the space in regard to the
> next-generation hidden services design.
>
> I think it'd be great if Tor were to collaborate on the design of such a
> scheme and adopt it for the new hidden services design. I see a lot of
> convergent evolution in this space and think it would be great if there
> were a single standard everyone could implement.
>
> Even if you don't, I think there are some ideas from similar schemes Tor
> should fold back into its own design, particularly in regard to how certain
> bits of the private scalar are "clamped". Some discussion of that here:
>
> https://moderncrypto.org/mail-archive/curves/2017/000862.html
>
> tl;dr: clamp the third highest bit of the root scalar to zero (in addition
> to the bits normally clamped in the non-canonical Ed25519 private scalar),
> and use 224-bit child scalars.
>

An update:

After lots of discussions in the Amsterdam Tor meeting, the following
approach was suggested for cleansing keys of their torsion components
that is more friendly towards hierarchical key-derivation schemes:
https://moderncrypto.org/mail-archive/curves/2017/000866.html

However, my current intuition is to just not do this for hidden service
ed25519 blinded keys. Those keys are only used for signing descriptors
which should be safe to do, and we don't plan to use them for D-H any
time soon. If we or some crazy app EVER decides to use those ephemeral
keys for key exchange, we would need to use a special DH function that
kills the tensor component of keys before using them, as suggested by
Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html

Please let me know if you think this is not a good idea!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Action items wrt prop224 onion address encoding (was Re: Proposition: Applying an AONT to Prop224 addresses?)

2017-04-12 Thread George Kadianakis 
Michael Rogers  writes:

> On 11/04/17 11:45, George Kadianakis wrote:
>> We basically add the canonical onion address in the inner encrypted
>> layer of the descriptor, and expect the client to verify it. I made this
>> feature optional in case we ever decide it was a bad idea.
>
> Is the version number also included in the blinded key derivation? I
> haven't been keeping up with prop224 developments, so apologies if
> that's already been settled, but in your previous email it sounded like
> it was one of the suggestions but not one of the action items.
>

That's a fine question, and it made me think deeper about our options.

I think both of the following suggestions from my previous email aim to
protect from the same attacks:
a) Include version number in blinded key derivation formula
b) Include canonical onion address in descriptor

Both (a) and (b) above aim to protect against scenarios where an
attacker (without private keys) takes a legitimate onion address, tweaks
its metadata bits (version/whatever), and creates a
different-but-equivalent onion address that has the exact same behavior
as the original one (points to the same 25519 key, same descriptor,
etc.). See Alec's and Ian's emails for a demonstration of how this can
be exploited:
https://lists.torproject.org/pipermail/tor-dev/2017-April/012160.html
https://lists.torproject.org/pipermail/tor-dev/2017-April/012159.html

I'm pretty sure that both (a) and (b) defend against Alec's and Ian's
attack since:

- With (a), the different-but-equivalent onion address would produce a
  different blinded key from the original onion address. The attacker
  would not be able to forge a signature for the descriptor since they
  don't know the private part of the new blinded key, so the descriptor
  would not be accepted by the HSDir or the client.

- With (b), the different-but-equivalent onion address would work, but
  when the client fetches the descriptor, the client would verify the
  new "canonical-onion-addr" field, notice that they reached this onion
  service from another address, and reject the descriptor. It's like we
  are including an SSL CN field in our HS descriptors.

I considered (b) easier to understand and reason about, and it also
seems to protect against a wider variety of descriptor replay attacks,
and that's why I suggested we go with (b).

My main fear with (b) is that in the future we might come up with a new
load-balancing scheme of sorts that would get screwed by the
"canonical-onion-addr" field. It does not seem to pose a problem with
onionbalance or stealth-auth kind of schemes, so all is good so far.
Please let me know if you can think of a scenario where (b) is a bad idea.

> If the version number is included in the descriptor but not in the
> blinded key derivation, can a service publish descriptors for multiple
> protocol versions? Would there be a conflict if the HS directories store
> the descriptors under the same blinded key?
>

Yes it's possible to publish descs for multiple protocol versions, since
we use a different URL for each version. Quoting from spec:

   Hidden service descriptors conforming to this specification are uploaded
   with an HTTP POST request to the URL /tor/hs//publish relative to
   the hidden service directory's root, and downloaded with an HTTP GET
   request for the URL /tor/hs// where  is a base64 encoding of
   the hidden service's blinded public key and  is the protocol
   version which is "3" in this case.

Also the HSDirs store the descriptors using both the publickey and the
version as indices, so this should not be a problem.

---

Thanks for all the feedback people.

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