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

flipchan flipchan at riseup.net
Fri Jul 27 19:21:18 UTC 2018 

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)

On July 24, 2018 8:48:22 PM UTC, tor-dev-request at lists.torproject.org wrote:
>Send tor-dev mailing list submissions to
>	tor-dev at 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-request at lists.torproject.org
>
>You can reach the person managing the list at
>	tor-dev-owner at 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: 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
>From: John Helmsen <john.helmsen at redjack.com>
>To: John Helmsen <john.helmsen at redjack.com>,
>	tor-dev at lists.torproject.org, ahf at 0x90.dk, Ben Johnson
>	<benbjohnson at yahoo.com>
>Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
>	Version into Tor
>Message-ID:
>	<CAFtdMkhH+jDVLcQXp1X1Ot=5t_bVrs5oeCaLJp93On3-AUvj1w at mail.gmail.com>
>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.
>
>
>On Mon, Jul 23, 2018 at 10:05 PM, David Fifield <david at bamsoftware.com>
>wrote:
>
>> On Fri, Jul 20, 2018 at 04:12:21PM -0400, John Helmsen wrote:
>> > 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
>> The old ticket for FTE is a good reference:
>https://bugs.torproject.org/
>> 10362
>>
>> And then it would help if you port your build process to the Tor
>Browser
>> build system. General information:
>> 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
>> example:
>> https://gitweb.torproject.org/builders/tor-browser-build.
>> git/tree/projects/meek
>> You'll also need to add bridge lines to:
>> https://gitweb.torproject.org/builders/tor-browser-build.
>> git/tree/projects/tor-browser/Bundle-Data/PTConfigs/bridge_prefs.js
>> To build just one project, not an entire release, do e.g.:
>>         rbm/rbm build gmp --target testbuild --target
>> torbrowser-linux-x86_64
>>         rbm/rbm build marionette --target testbuild --target
>> torbrowser-linux-x86_64
>>
>
>
>
>-- 
>John Helmsen
>john.helmsen at redjack.com
>C: (240) 899-5676
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.torproject.org/pipermail/tor-dev/attachments/20180724/f0735790/attachment-0001.html>
>
>------------------------------
>
>Message: 2
>Date: Tue, 24 Jul 2018 09:46:50 -0700
>From: David Fifield <david at bamsoftware.com>
>To: John Helmsen <john.helmsen at redjack.com>
>Cc: tor-dev at lists.torproject.org, ahf at 0x90.dk, Ben Johnson
>	<benbjohnson at yahoo.com>
>Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
>	Version into Tor
>Message-ID: <20180724164650.fqxrc7fkwwusfjlb at bamsoftware.com>
>Content-Type: text/plain; charset=utf-8
>
>On Tue, Jul 24, 2018 at 11:42:08AM -0400, John Helmsen wrote:
>> 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
>From: John Helmsen <john.helmsen at redjack.com>
>To: John Helmsen <john.helmsen at redjack.com>,
>	tor-dev at lists.torproject.org, ahf at 0x90.dk, Ben Johnson
>	<benbjohnson at yahoo.com>
>Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
>	Version into Tor
>Message-ID:
>	<CAFtdMkiV+nzm_Qkc1s_ikSfmYF+9Mk3fgfdHyVYMADxo24GvZw at mail.gmail.com>
>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.
>
>On Tue, Jul 24, 2018 at 12:46 PM, David Fifield <david at bamsoftware.com>
>wrote:
>
>> On Tue, Jul 24, 2018 at 11:42:08AM -0400, John Helmsen wrote:
>> > 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
>john.helmsen at redjack.com
>C: (240) 899-5676
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.torproject.org/pipermail/tor-dev/attachments/20180724/ba3f0067/attachment-0001.html>
>
>------------------------------
>
>Message: 4
>Date: Tue, 24 Jul 2018 11:09:45 -0700
>From: David Fifield <david at bamsoftware.com>
>To: John Helmsen <john.helmsen at redjack.com>
>Cc: tor-dev at lists.torproject.org, ahf at 0x90.dk, Ben Johnson
>	<benbjohnson at yahoo.com>
>Subject: Re: [tor-dev] Ready to Integrate/Review New Marionette
>	Version into Tor
>Message-ID: <20180724180945.sdvhvf2jx3f5eu4f at bamsoftware.com>
>Content-Type: text/plain; charset=utf-8
>
>On Tue, Jul 24, 2018 at 01:57:36PM -0400, John Helmsen wrote:
>> 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
>From: Taylor Yu <catalyst at torproject.org>
>To: tor-dev at lists.torproject.org
>Subject: Re: [tor-dev] Proposal 295: Using the ATL construction for
>	relay cryptography (solving the crypto-tagging attack)
>Message-ID: <303b5243-fd81-fb4b-c63d-0c33fac49738 at torproject.org>
>Content-Type: text/plain; charset=utf-8
>
>On 07/20/2018 02:27 AM, teor wrote:
>
>> 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.)
>
>I'm going to tentatively propose some more consistent notation here:
>
>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.)
>
>-----
>
>single hop outbound (same direction as CREATE):
>
>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
>
>single hop inbound (same direction as CREATED):
>
>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
>
>receiving/decrypting a cell at the endpoint (e.g., exit):
>
>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
>
>sending/encrypting a cell from the endpoint:
>
>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.)
>> 
>> Please generalise the proposal so that:
>> * 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
>tor-dev at lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
>------------------------------
>
>End of tor-dev Digest, Vol 90, Issue 32
>***************************************

-- 
Take Care Sincerely flipchan layerprox dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180727/3d3fe30f/attachment-0001.html>

More information about the tor-dev mailing list