[tor-dev] tor-dev Digest, Vol 90, Issue 32

[flipchan]

Regarding implementing Marionette.

It's a great project and a great way to use fte! Worked on a fork of it called layerprox a while ago , however, here is my question: Marionette has a dsl that you write "formats" in that generates traffic patterns, is the idea to randomly switch between these formats or use the same all the time ? Also is the formats automatically gonna be updated ?

Take care
/flipchan

Ps


I'm sorry for awnsering all emails in this thread (my email client is not the greatest)

Send tor-dev mailing list submissions to
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-dev digest..."
1. Re: Ready to Integrate/Review New Marionette Version into Tor
(John Helmsen)
2. Re: Ready to Integrate/Review New Marionette Version into Tor
(David Fifield)
3. Re: Ready to Integrate/Review New Marionette Version into Tor
(John Helmsen)
4. Re: Ready to Integrate/Review New Marionette Version into Tor
(David Fifield)
5. Re: Proposal 295: Using the ATL construction for relay
cryptography (solving the crypto-tagging attack) (Taylor Yu)
----------------------------------------------------------------------
Message: 1
Date: Tue, 24 Jul 2018 11:42:08 -0400
Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
Version into Tor
Content-Type: text/plain; charset="utf-8"
David,
Thank you, I have created the ticket as #26920.
https://trac.torproject.org/projects/tor/ticket/26920#ticket. Having
downloaded the git project, it seems that this work cannot be performed
on
a Mac, since it doesn't run 'runc'. Is that right?
Ben,
I am currently trying to create a virtual machine using Ubuntu 16.04
for
development. Unless I am mistaken, this work cannot be done on a Mac.
Please do the same, so that we can put this thing to bed.

We are in the process of writing the documentation for Marionette,

but

the

documentation on the web page should be sufficient for at least

getting

a full

evaluation started. We'd like to have the evaluation complete by

the

end of

next month, hopefully the middle of next month, and stand ready to

make

any and

all changes necessary.
A full set of documentation will also be written for designing your

own

protocols. This is in process.
Please let us know what you need.

The Tor Browser developers may have more specific requests, but I can
suggest some steps to get started.
Open a ticket at https://trac.torproject.org/ for discussion and to
track progress.
Type: project
Component: Applications/Tor Browser
Keywords: marionette

https://bugs.torproject.org/

10362
And then it would help if you port your build process to the Tor

Browser

https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking
First, just build
git clone https://git.torproject.org/
builders/tor-browser-build.git
cd tor-browser-build
git checkout tbb-8.0a9-build3
make testbuild # or, e.g., testbuild-linux-x86_64
Then you'll have to add a new project (consisting of a "build" and
"config" file) for Marionette and each of its dependencies. You can

copy

from existing projects as templates. Here is the meek project, for
https://gitweb.torproject.org/builders/tor-browser-build.
git/tree/projects/meek
https://gitweb.torproject.org/builders/tor-browser-build.
git/tree/projects/tor-browser/Bundle-Data/PTConfigs/bridge_prefs.js
rbm/rbm build gmp --target testbuild --target
torbrowser-linux-x86_64
rbm/rbm build marionette --target testbuild --target
torbrowser-linux-x86_64

--
John Helmsen
C: [phone]
-------------- next part --------------
An HTML attachment was scrubbed...
<http://lists.torproject.org/pipermail/tor-dev/attachments/20180724/f0735790/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 24 Jul 2018 09:46:50 -0700
Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
Version into Tor
Content-Type: text/plain; charset=utf-8

Thank you, I have created the ticket as

#26920. https://trac.torproject.org/

projects/tor/ticket/26920#ticket.  Having downloaded the git project,

it seems

that this work cannot be performed on a Mac, since it doesn't run

'runc'.  Is

that right?

Right, the README says "To build Tor Browser, you need a Linux
distribution that has support for runc (such as Debian jessie, Ubuntu
16.04, Fedora 20, etc ...)."
The tag I suggested, tbb-8.0a9-build3, is the tag of the most recent
alpha release (I think). I haven't tried building it myself--if it
doesn't work, you may just need to try a different tag. One of the Tor
Browser devs could suggest an alternative if it doesn't work on the
first try.
------------------------------
Message: 3
Date: Tue, 24 Jul 2018 13:57:36 -0400
Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
Version into Tor
Content-Type: text/plain; charset="utf-8"
Okay, I have generated a VM using VirtualBox of Ubuntu version 16.
I've
had to restart the build process a couple of times, since the hard
drive
was 10GB, then 20GB. Now I am using a 50GB box, so it may work this
time.
Should we create the branch using the -b command? ('git checkout -b
tbb-8.0a9-build3'?) Otherwise, it complains about being headless.

Thank you, I have created the ticket as #26920. https://trac.

torproject.org/

projects/tor/ticket/26920#ticket. Having downloaded the git

project,

it seems

that this work cannot be performed on a Mac, since it doesn't run

'runc'. Is

that right?

Right, the README says "To build Tor Browser, you need a Linux
distribution that has support for runc (such as Debian jessie, Ubuntu
16.04, Fedora 20, etc ...)."
The tag I suggested, tbb-8.0a9-build3, is the tag of the most recent
alpha release (I think). I haven't tried building it myself--if it
doesn't work, you may just need to try a different tag. One of the

Tor

Browser devs could suggest an alternative if it doesn't work on the
first try.

--
John Helmsen
C: [phone]
-------------- next part --------------
An HTML attachment was scrubbed...
<http://lists.torproject.org/pipermail/tor-dev/attachments/20180724/ba3f0067/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 24 Jul 2018 11:09:45 -0700
Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
Version into Tor
Content-Type: text/plain; charset=utf-8

Okay, I have generated a VM using VirtualBox of Ubuntu version 16. 

I've had to

restart the build process a couple of times, since the hard drive was

10GB,

then 20GB.  Now I am using a 50GB box, so it may work this time.
Should we create the branch using the -b command? ('git checkout -b
tbb-8.0a9-build3'?) Otherwise, it complains about being headless.

It doesn't matter, just for the sake of doing a testbuild and priming
the cache of dependencies (you'll notice the git_clones directory get
filled in among others). But yes, you'll want a branch for integration,
something like
git checkout -b marionette-integration tbb-8.0a9-build3
------------------------------
Message: 5
Date: Tue, 24 Jul 2018 15:48:15 -0500
Subject: Re: [tor-dev] Proposal 295: Using the ATL construction for
relay cryptography (solving the crypto-tagging attack)
Content-Type: text/plain; charset=utf-8

A few of us discussed this proposal in the #tor-dev IRC earlier this

week.
Hi teor, and thanks for writing this summary! I generally agree with
what you've written.

We’re confused by 3.1 and 3.2, which seem to be duplicate sections

using

different notation.

On further reflection, I think sections 3.1 and 3.2 describe two
different revisions of the proposal. 3.1 seems to not include the
previous tweak (T' in 3.2.2) in computing a new tweak, while 3.2.2
does.
It seems like if we adapt 3.1 to incorporate some chaining of the
tweak, the scheme will be IND-CPA. (This is because the ciphertext
that
the endpoint receives will no longer be solely a function of the
plaintext and the key.)
C ciphertext
M plaintext message
S encrypted nonce
N CTR mode nonce
T nonce tweak
T' saved nonce tweak
U pre-nonce tweak
U' saved pre-nonce tweak
keys
kf, kb CTR mode key
hf, hb GHASH key
cf, cb nonce-encryption key
gf, gb pre-nonce GHASH key
bf, bb pre-nonce encryption key
(I'm happy to hear feedback on alternative designators.)
-----
input C||S
1. T = H_hf(T'||C) -- generate tweak T by hashing saved previous tweak
T' and ciphertext C
2. N = T ^ D_cf(S ^ T) -- decrypt encrypted nonce S using AES and tweak
T
3. M = C ^ CTR_kf(N) -- decrypt ciphertext C using CTR and nonce N
4. T' = T -- save tweak for next cell
5. output M||N
input M||N
1. C = M ^ CTR_kb(N) -- encrypt message M using CTR and nonce N
2. T = H_hb(T'||C) -- generate tweak T by hashing saved previous tweak
T' and ciphertext C
3. S = T ^ E_cb(N ^ T) -- encrypt nonce N using AES and tweak T
4. T' = T -- save tweak for next cell
5. output C||S
input C||S
1. decrypt as above to obtain M and N
2. U = H_gf(U'||M) -- generate tweak U by hashing saved previous tweak
U' and plaintext M
3. V = U ^ D_bf(N ^ U) -- decrypt nonce N with AES and pre-nonce tweak
U
for verification
4. U' = U -- save pre-nonce tweak for next cell
5. if V == 0, cell is authentic
input M
1. U = H_gb(U'||M) -- generate tweak U by hashing saved previous tweak
U' and plaintext M
2. N = U ^ E_bb(0 ^ U) -- generate nonce N by encrypting all-zeroes
block using AES and pre-nonce tweak U
3. U' = U
4. encrypt as above using M and N
-----
Open question: what do we initialize the saved tweaks T', U' to? Is it
safe to use an all-zeroes block?

Generalising to Different Numbers of Hops
The proposal assumes that all circuits are 3-hop circuits, but Tor

typically

builds 1, 3, 4, and 5-hop circuits. Also, Tor currently generates the

same

number of keys for each hop. There’s no way it can just generate

kf_M, kf_E,

kb_M, and kb_E for the final hop, because sometimes the final hop

changes.

(Due to circuit cannibalisation, or failed intro extension.)
* all references to “3-hop circuit” are changed to "N-hop circuit".
* all references to kf_1,2,3, kb_1,2,3, k_fM, k_fE, k_bM and k_bE;
are changed to kf_N, kb_N, kfM_N, kfE_N, kbM_N and kbE_N.

Judging by the cited paper, the subkeys k1, k2, k3 are all used in the
same hop. Given that we already use digits for hop numbers, we should
choose some alphabetic subkey designators.
(In the paper: k1 = CTR key; k2 = GHASH key for computing tweak; k3 =
AES key for encrypting nonce.)

Do we really need 6 keys per hop?
It’s ok if we do, let’s make sure there are no redundant keys.

It looks like ten keys per hop. Every ordinary relay hop needs the
endpoint authentication keys kf_M, kf_E, kb_M, kb_E to handle
EXTEND/EXTENDED cells at least.
I'm not sure yet which of these are actually required to be independent
to achieve the desired security properties.
Best regards,
-Taylor
------------------------------
Subject: Digest Footer
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
------------------------------
End of tor-dev Digest, Vol 90, Issue 32
***************************************