September 2017 - tor-dev - lists.torproject.org

Re: [tor-dev] Padding prop224 REND1 cells to blend them with legacy cells
by Ian Goldberg 20 Sep '17

20 Sep '17

Resending from a subscribed address. On Tue, Sep 19, 2017 at 05:44:46PM +0300, George Kadianakis wrote: > Hello Ian, (and other cryptographers on the list) > > here is a quick question which you might be able to answer super fast: > > Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 > spec suggests we pad the new cells so that they look similar in size to > the legacy ones. > > Here is how the legacy ones look like: > > RC Rendezvous cookie [20 octets] > g^y Diffie-Hellman [128 octets] > KH Handshake digest [20 octets] > > Here is how the prop224 ones look like: > > RENDEZVOUS_COOKIE [20 bytes] > HANDSHAKE_INFO [64 bytes] > > The suggestion is to pad the prop224 cells to 168 bytes using random data. > > Would that work? My main question is whether the g^y part of the legacy > cell has any distinguishers that could distinguish it from random data. > It's encoded using OpenSSL's BN_bn2bin() and it's a 1024 bit DH public > key. Are there any algebraic or openssl structure distinguishers we > should be worrying about, or is random data sufficient to mask it out? > > Thanks!!! :) Is your goal that someone who sees the *plaintext* of that cell won't be able to tell if it's a legacy RENDEZVOUS1 cell or a new one? If so, life is a bit complicated, since the g^y field will always be in the prime-order subgroup. (Note: I'm not actually 100% sure Tor uses a generator of the prime-order subgroup for g in this part of the spec. But it should have, and so hopefully did.) If HANDSHAKE_INFO || PADDING_64 (the latter being the first 64 bytes of the padding) is _not_ in the prime-order subgroup, the observer will be sure it's a prop224 cell. If it _is_, the observer can't tell. If that's undesirable, you could always insist that PADDING_64 be chosen such that HANDSHAKE_INFO || PADDING_64 _is_ in the prime-order subgroup. Raise it to the power of the prime order q to check; if the result is 1, you're good. You'll need to try on average (p-1)/q random values of PADDING_64 before you get a good one. (NOTE: *NOT* CONSTANT TIME.) If p = 2q+1, that's just 2, so not *terrible*, but 2 1024-bit modexps might still be annoying. If for some reason p is a DSA modululus or something bizarre like that, life is much more annoying. (I hope it's not.) This is all assuming p is of the form 2^1024 - (some number at most say 2^960), so that HANDSHAKE_INFO || PADDING_64 won't be larger than p itself, which would be another problem. To be sure, what are the g and p values used in this particular Diffie-Hellman?

2 2

Re: [tor-dev] tor-dev Digest, Vol 80, Issue 10
by flipchan 20 Sep '17

20 Sep '17

I emailed someone that runned an out of date version of tor yesterday and maybe it's more efficient to have an auto mailer to remind ppl to update On September 19, 2017 2:00:09 PM GMT+02:00, tor-dev-request(a)lists.torproject.org wrote: >Send tor-dev mailing list submissions to > tor-dev(a)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(a)lists.torproject.org > >You can reach the person managing the list at > tor-dev-owner(a)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: Auto-senescence and/or CW penalty for a less outdated tor > network? (nusenu) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 18 Sep 2017 17:30:00 +0000 >From: nusenu <nusenu-lists(a)riseup.net> >To: tor-dev(a)lists.torproject.org >Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less > outdated tor network? >Message-ID: <6aaa7727-7013-2ff8-3eb1-ac9b752b5981(a)riseup.net> >Content-Type: text/plain; charset="windows-1252" > >>> 1) Auto-senescence >>> ------------------- >> >> I think automatic timed shutdown can be unhelpful or dangerous: > >Yes it reduces the number of options once such a feature would be >implemented and deployed. > >> * what if we need it earlier due to a severe bug or mandatory >feature? > >This should not be an issue since that auto-shutdown only mandates an >upper limit but does not stop you from removing a relay before that >limit has been reached. > >> * what if it isn't needed, and the relay version is fine? > >Yes this can be an issue, but if you say "every relay that runs >versions >past its eol date" [1] is "not fine" then the auto-shutdown date can be >specified with a very high likelihood to a date that is past the eol >date because you have an estimate of how long you plan to support it >(3y >for LTS). > >I'm less concerned about auto-shutdown for tor clients since most tor >users might be using TBB with auto updates and it would help you having >to do things like prop266. > >[1] >https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… > >>> 2) consensus weight penalty for outdated relays >>> ----------------------------------------------- >> >> I can't see much point in this: if the relays are insecure, they >> should be eliminated. If not, they should be used. > >I'm happy with "insecure -> should be removed". >With "outdated" I meant "not running a recommended version" I'm not >sure >if that is the same as 'insecure'. > >A CW penalty would be a strong incentive for relay operators to keep >their relays up to date (to a recommended version). >This would likely reduce the number of relays running not-recommended >versions because currently the incentive is inverted (never >restart/update your tor instance - uptime!). >..but it would also affect testers running master. > > >>> 3) update tor dir auth code to reject old tor releases (not include >them >>> in consensus) >>> >------------------------------------------------------------------------- > >> In the past, we've excluded relay versions when they don't have a >> required feature. > >Does this step (excluding specific versions) require a code change or a >dir auth configuration change? (like it does for changing recommended >versions list) >If it does: Maybe it could be turned into a configurable option for dir >auths like recommended version. > >(3) will not stop old relays from contacting dir auths. > > >> We have a ticket to make a plan to kill off old client versions: >> https://trac.torproject.org/projects/tor/ticket/15940 >> But there's no equivalent ticket for relay versions. > > > >-- >https://mastodon.social/@nusenu >https://twitter.com/nusenu_ > >

1 0

Auto-senescence and/or CW penalty for a less outdated tor network?
by nusenu 18 Sep '17

18 Sep '17

Hi, tl;dr: ideas to reduce the cw fraction that outdated relays make up of the tor network This email can be somewhat summarized by these three polls: https://twitter.com/nusenu_/status/909356846900801536 https://twitter.com/nusenu_/status/909359701908971520 https://twitter.com/nusenu_/status/909361044988071936 This email was sparked by a recent thread on twitter. As of 2017-09-16 more than 27% CW fraction of the tor network (>2500 relays) run a version of tor that is not recommended by tor's directory authorities [2]. More than 8% CW fraction (>1100 relays) even run tor branches that reached end-of-life and are no longer maintained. So if we agree that 27% CW fraction is to much, we could aim at reducing that fraction within the tor network. Here are a few ideas. 1) Auto-senescence ------------------- Alfie John suggested [1]: > automatic shutdown after its version is too old as used in zcash (the tor snap from Chad Miller does auto-shutdown already today), Moritz replied: > Tor already has this mechanism in the form of recommended/required versions in consensus I looked into that [3] but this is about tor _protocols_ (not versions) and is probably better suitable for avoiding compatibility issues within the tor network as multiple protocols coexist but you can not use that to remove specific tor versions because many versions share the same protocol set [4]. [1] https://twitter.com/alfiedotwtf/status/906310842672603136 [2] https://consensus-health.torproject.org/#recommendedversions [3] https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-ve… [4] https://gist.github.com/nusenu/1302a04b26dac8e2ef838117f5f3fd2b So back to Alfie's suggestion. If tor should shutdown when 'too old' we have to know what 'too old' is. To come up with a timespan for 'too old' I looked into 61 currently used tor versions that are no longer recommended by dirauths. I measured the time between release date (as mentioned in the changelog) and the last consensus where the given version was listed as a recommended relay tor version [5], but these graphs show the "recommended" lifespan of releases before the new support policy [6] with shorter release cycles for "regular" releases has been introduced. [5] https://twitter.com/nusenu_/status/909355193434853376 [6] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… So instead of of using this historical data we could simply follow the support policy. regular release: Auto-shutdown 18 months (=9+grace period) after the branch became stable. LTS relase: Auto-shutdown 4 years (=3+grace period) after the branch became stable. Dates would be hardcoded and do not require relays to contact dirauths. So old relays will not but any load on dir auths and fallbackdirs everytime they start. Lets simulate these timespans for tor 0.2.4 and 0.2.5 (and lets assume they are LTS releases) - tor 0.2.4 relays - if they had such a logic - would shutdown on 2017-12-11 (eol date was 2017-08-01) - tor 0.2.5 relays whould shutdown on 2018-10-24 (eol date is 2018-05-01) (not mentioning 0.2.6/7 here) - tor 0.2.9 relays would shutdown on 2020-12-19 (eol date is 2020-01-01) You could add a torrc option to allow operators (and package maintainers) to opt-out of auto-shutdown. There is no doubt that any mechanism to disable old relays _automatically_ and by _default_ would shrink the tor network (compared to not having that), so having a good answer for "What is an acceptable CW fraction for outdated tor versions on the network?" would be important, but since the reasons for removing versions from the recommended list are very different the recommended datapoint might not be enough. 2) consensus weight penalty for outdated relays ----------------------------------------------- Instead of (or additionally to) telling relays to not upload descriptors (complete removal) you could _automatically_ reduce/cap their consensus weight on the dirauth side if they run - unsupported branches (harsher penalty) - run not-recommended tor releases over a long time (less harsh penalty) (The distinction between unsupported branches and not-recommended is currently not available as consensus information.) This approach makes the recommended version list a more critical consensus item and as you know this is not always managed ideally: - new releases not added to the list in a timely manner -> operators upgrading timely get warnings - old releases not removed timely or before deb.torproject.org provided new releases 3) update tor dir auth code to reject old tor releases (not include them in consensus) ------------------------------------------------------------------------- As soon as a tor directory operator updates to a new release the dirauth would no longer vote for specific tor versions (I guess this is the current mostly manual approach). Another important aspect is the practical reality in current package repositories, but I simply assume they will follow LTS releases and are fine with the 4 years (3+grace period) lifespan. regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

PQ crypto updates
by bancfc＠openmailbox.org 18 Sep '17

18 Sep '17

If I understand correctly, DJB describes how NTRU-Prime is more robust against certain attack classes that Ring-LWE is more prone to: https://twitter.com/hashbreaker/status/880086983057526784 *** About two months later DJB releases a streamlined version of NTRU-Prime that is faster, safer and uses less resources than the latest version of New Hope while (wait for it...) completely eliminating decryption failures !: https://twitter.com/hashbreaker/status/898048057849380864 https://twitter.com/hashbreaker/status/898048506681860096 https://twitter.com/hashbreaker/status/898048760009420801 https://twitter.com/hashbreaker/status/898391210456489984 *** Boom headshot! AEZ is dead in the water post quantum: Paper name: Quantum Key-Recovery on full AEZ https://eprint.iacr.org/2017/767.pdf

5 8

Dir auths using 2x bandwidth in last week
by Roger Dingledine 18 Sep '17

18 Sep '17

https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.torproject.org/#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97… https://atlas.torproject.org/#details/BD6A829255CB08E66FBE7D3748363586E46B3… https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968… https://atlas.torproject.org/#details/7EA6EAD6FD83083C538F44038BBFA077587DD… all show a big increase in sent bytes starting at the end of July. It isn't growth in Tor users, since those have stayed relatively flat in the last two weeks. And the new rate seems to be the new normal -- it's showing no signs of going back to the old rate. I would assume it's outgoing directory stuff, since that's most of what dir auths do. Any guesses? --Roger

3 6

[release] CollecTor 1.3.0, metrics-lib 2.1.0, Onionoo 4.1-1.5.0
by iwakeh 15 Sep '17

15 Sep '17

Hi there! three new releases are available: https://dist.torproject.org/collector/1.3.0/ https://dist.torproject.org/metrics-lib/2.1.0/ https://dist.torproject.org/onionoo/4.1-1.5.0/ These releases upgrade all projects to use Java 8. A few issues and improvements come along and can be found in the change-logs [0], [1], [2]. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [1] https://gitweb.torproject.org/metrics-lib.git/tree/CHANGELOG.md?h=metrics-l… [2] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.1-1… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Proposal 280: Privacy-Preseving Statistics with Privcount in Tor
by Nick Mathewson 13 Sep '17

13 Sep '17

Hi! Tim helped me write this this draft last week, and I shared it with the PrivCount authors. I've already gotten some good comments from Aaron, which I'll repost in a followup message, with his permission. ================================ Filename: 280-privcount-in-tor.txt Title: Privacy-Preseving Statistics with Privcount in Tor Author: Nick Mathewson, Tim Wilson-Brown Created: 02-Aug-2017 Status: Draft 0. Acknowledgments Tariq Elahi, George Danezis, and Ian Goldberg designed and implemented the PrivEx blinding scheme. Rob Jansen and Aaron Johnson extended PrivEx's differential privacy guarantees to multiple counters in PrivCount: https://github.com/privcount/privcount/blob/master/README.markdown#research… Rob Jansen and Tim Wilson-Brown wrote the majority of the experimental PrivCount code, based on the PrivEx secret-sharing variant. This implementation includes contributions from the PrivEx authors, and others: https://github.com/privcount/privcount/blob/master/CONTRIBUTORS.markdown 1. Introduction and scope PrivCount is a privacy-preserving way to collect aggregate statistics about the Tor network without exposing the statistics from any single Tor relay. This document describes the behavior of the in-Tor portion of the PrivCount system. It DOES NOT describe the counter configurations, or any other parts of the system. (These will be covered in separate proposals.) 2. PrivCount overview Here follows an oversimplified summary of PrivCount, with enough information to explain the Tor side of things. The actual operation of the non-Tor components is trickier than described below. All values in the scheme below are 64-bit unsigned integers; addition and subtraction are modulo 2^64. In PrivCount, a Data Collector (in this case a Tor relay) shares numeric data with N different Tally Reporters. (A Tally Reporter performs the summing and unblinding roles of the Tally Server and Share Keeper from experimental PrivCount.) All N Tally Reporters together can reconstruct the original data, but no (N-1)-sized subset of the Tally Reporters can learn anything about the data. (In reality, the Tally Reporters don't reconstruct the original data at all! Instead, they will reconstruct a _sum_ of the original data across all participating relays.) To share data, for each value X to be shared, the relay generates random values B_1 though B_n, and shares each B_i secretly with a single Tally Reporter. The relay then publishes Y = X + SUM(B_i) + Z, where Z is a noise value taken at random from a gaussian distribution. The Tally Reporters can reconstruct X+Z by securely computing SUM(B_i) across all contributing Data Collectors. (Tally Reporters MUST NOT share individual B_i values: that would expose the underlying relay totals.) In order to prevent bogus data from corrupting the tally, the Tor relays and the Tally Reporters perform multiple "instances" of this algorithm, randomly sampling in each relays. The relay sends multiple Y values for each measurement, built with different sets of B_i. These "instances" are numbered in order from 1 to R. So that the system will still produce results in the event of a single Tally Reporter failure, these instances are distributed across multiple subsets of Tally Reporters. Below we describe a data format for this. 3. The document format This document format builds on the line-based directory format used for other tor documents, described in Tor's dir-spec.txt. Using this format, we describe two kinds of documents here: a "counters" document that publishes all the Y values, and a "blinding" document that describes the B_i values. But see "An optimized alternative" below. The "counters" document has these elements: "privctr-dump-format" SP VERSION SP SigningKey [At start, exactly once] Describes the version of the dump format, and provides an ed25519 signing key to identify the relay. The signing key is encoded in base64 with padding stripped. VERSION is "alpha" now, but should be "1" once this document is finalized. [[[TODO: Do we need a counter version as well? Noise is distributed across a particular set of counters, to provide differential privacy guarantees for those counters. Reducing noise requires a break in the collection. Adding counters is ok if the noise on each counter monotonically increases. (Removing counters always reduces noise.) We also need to work out how to handle instances with mixed Tor versions, where some Data Collectors report different counters to other Data Collectors. (The blinding works if we substitute zeroes for missing counters on Tally Reporters. But we also need to add noise in this case.) -teor ]]] "starting-at" SP IsoTime [Exactly once] The start of the time period when the statistics here were collected. "ending-at" SP IsoTime [Exactly once] The end of the time period when the statistics here were collected. "num-instances" SP Number [Exactly once] The number of "instances" that the relay used (see above.) "tally-reporter" SP Identifier SP Key SP InstanceNumbers [At least twice] The curve25519 public key of each Tally Reporter that the relay believes in. (If the list does not match the list of participating tally reporters, they won't be able to find the relay's values correctly.) The identifiers are non-space, non-nul character sequences. The Key values are encoded in base64 with padding stripped; they must be unique within each counters document. The InstanceNumbers are comma-separated lists of decimal integers from 0 to (num-instances - 1), in ascending order. Keyword ":" SP Int SP Int SP Int ... [Any number of times] The Y values for a single measurement. There are num-instances such Y values for each measurement. They are 64-bit unsigned integers, expressed in decimal. The "Keyword" denotes which measurement is being shared. Keyword MAY be any sequence of characters other than colon, nul, space, and newline, though implementators SHOULD avoid getting too creative here. Keywords MUST be unique within a single document. Tally Reporters MUST handle unrecognized keywords. Keywords MAY appear in any order. It is safe to send the blinded totals for each instance to every Tally Reporter. To unblind the totals, a Tally Reporter needs: * a blinding document from each relay in the instance, and * the per-counter blinding sums from the other Tally Reporters in their instance. [[[TODO: But is it safer to create a per-instance counters document? -- teor]]] The semantics of individual measurements are not specified here. "signature" SP Signature [At end, exactly once] The Ed25519 signature of all the fields in the document, from the first byte, up to but not including the "signature" keyword here. The signature is encoded in base64 with padding stripped. The "blinding" document has these elements: "privctr-secret-offsets" SP VERSION SP SigningKey [At start, exactly once.] The VERSION and SigningKey parameters are the same as for "privctr-dump-format". "instances" SP Numbers [Exactly once] The instances that this Tally Reporter handles. They are given as comma-separated decimal integers, as in the "tally-reporter" entry in the counters document. They MUST match the instances listed in the counters document. [[[TODO: this is redundant. Specify the constraint instead? --teor]]] "num-counters" SP Number [Exactly once] The number of counters that the relay used in its counters document. This MUST be equal to the number of keywords in the counters document. [[[TODO: this is redundant. Specify the constraint instead? --teor]]] "tally-reporter-pubkey" SP Key [Exactly once] The curve25519 public key of the tally reporter who is intended to receive an decrypt this document. The key is base64-encoded with padding stripped. "count-document-digest" SP "sha3" Digest NL "-----BEGIN ENCRYPTED DATA-----" NL Data "-----END ENCRYPTED DATA-----" NL [Exactly once] The SHA3-256 digest of the count document corresponding to this blinding document. The digest is base64-encoded with padding stripped. The data encodes the blinding values (See "The Blinding Values") below, and is encrypted to the tally reporter's public key using the hybrid encryption algorithm described below. "signature" SP Signature [At end, exactly once] The Ed25519 signature of all the fields in the document, from the first byte, up to but not including the "signature" keyword here. The signature is encoded in base64 with padding stripped. 4. The Blinding Values The "Data" field of the blinding documents above, when decrypted, yields a sequence of 64-bit binary values, encoded in network (big-endian) order. There are C * R such values, where C is the number of keywords in the count document, and R is the number of instances that the Tally Reporter participates in. The client generates all of these values uniformly at random. For each keyword in the count document, in the order specified by the count document, the decrypted data holds R*8 bytes for the specified instance of that keyword's blinded counter. For example: if the count document lists the keywords "b", "x", "g", and "a" (in that order), and lists instances "0", and "2", then the decrypted data will hold the blinding values in this order: b, instance 0 b, instance 2 x, instance 0 x, instance 2 g, instance 0 g, instance 2 a, instance 0 a, instance 2 4. Implementation Notes A relay should, when starting a new round, generate all the blinding values and noise values in advance. The relay should then use these values to compute Y_0 = SUM(B_i) + Z for each instance of each counter. Having done this, the relay MUST encrypt the blinding values to the public key of each tally reporter, and wipe them from memory. 5. The hybrid encryption algorithm We use a hybrid encryption scheme above, where items can be encrypted to a public key. We instantiate it as follows, using curve25519 public keys. To encrypt a plaintext M to a public key PK1 1. the sender generates a new ephemeral keypair sk2, PK2. 2. The sender computes the shared diffie hellman secret SEED = (sk2 * PK1). 3. The sender derives 64 bytes of key material as SHAKE256(TEXT | SEED)[...64] where "TEXT" is "Expand curve25519 for privcount encryption". The first 32 bytes of this is an aes key K1; the second 32 bytes are a mac key K2. 4. The sender computes a ciphertext C as AES256_CTR(K1, M) 5. The sender computes a MAC as SHA3_256([00 00 00 00 00 00 00 20] | K2 | C) 6. The hybrid-encrypted text is PK2 | MAC | C. 6. An optimized alternative As an alternative, the sequences of blinding values is NOT transmitted to the tally reporters. Instead the client generates a single ephemeral keypair sk_c, PK_c, and places the public key in its counts document. It does this each time a new round begins. For each tally reporter with public key PK_i, the client then does the handshake sk_c * PK_i to compute SEED_i. The client then generates the blinding values for that tally reporter as SHAKE256(SEED_i)[...R*C*8]. After initializing the counters to Y_0, the client can discard the blinding values and sk_c. Later, the tally reporters can reconstruct the blinding values as SHAKE256(sk_i * PK_c)[...] This alternative allows the client to transmit only a single public key, when previously it would need to transmit a complete set of blinding factors for each tally reporter. Further, the alternative does away with the need for blinding documents altogether. It is, however, more sensitive to any defects in SHAKE256 than the design above. Like the rest of this design, it would need rethinking if we want to expand this scheme to work with anonymous data collectors, such as Tor clients.

3 4

Proposal 282: Remove "Named" and "Unnamed" handling from consensus voting
by Nick Mathewson 12 Sep '17

12 Sep '17

Filename: 282-remove-named-from-consensus.txt Title: Remove "Named" and "Unnamed" handling from consensus voting Author: Nick Mathewson Created: 12-Sep-2017 Status: Open Target: 0.3.3.x 1. Summary Authorities no longer vote for the "Named" and "Unnamed" flags, and we have begun to remove the client code that supports them. (See proposal 235). The next logical step is to remove the special handling from these flags from the consensus voting algorithm. We specify this here. 2. Proposal We add a new consensus method, here represented as M, to be allocated when this proposal's implementation is merged. We specify that the Named and Unnamed flags are only handled specially when the negotiated consensus method is earlier than M. If the negotiated method is M or later, then the Named and Unnamed flags are handled as if any they were any other consensus flags.

1 0

Help us build Tails 3.2~alpha1 build reproducibly
by anonym 08 Sep '17

08 Sep '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tails and Tor contributors, dear Reproducible Builds community, We have sent out a first call [1] for testing to build Tails 3.1 reproducibly and we have received some build reports. Thank you very much for your help! We have since then tried to fix most of the identified issues [2] in Tails 3.2~alpha1, and thus we'd kindly like to ask you to try to build the new ISO image again, or even for the first time. Please don't hesitate to contact us if you get stuck at some point in the process, for example by connecting to our chatroom [3]! You can also send us email to tails-dev at boum.org (public) or tails at boum.org (private). Note that Tails 3.2~alpha1 is *not* recommended for real usage, since it has not gone through *any* QA. Please use Tails 3.1 instead until Tails 3.2 is released! # How? For your convenience all instructions needed to attempt to reproduce Tails 3.2~alpha1 are included hereafter. However all commands are adapted for Debian Stretch (and Buster/Sid), so your results may vary if you run another Linux distribution. Our full build instructions [4] might help if you are having problems. ## Setup the build environment Building Tails requires the KVM virtual machine hypervisor to be available, a minimum of 1 GiB of free RAM and a maximum of 20 GB of free storage. ### Install dependencies sudo apt-get install \ git \ rake \ libvirt-daemon-system \ dnsmasq-base \ ebtables \ qemu-system-x86 \ qemu-utils \ vagrant \ vagrant-libvirt \ vmdebootstrap && \ sudo systemctl restart libvirtd ### If building as a non-root user (Skip this section if you intend to build Tails as the root user!) Make sure that the user that is supposed to initiate the build is part of the relevant groups: for group in kvm libvirt libvirt-qemu; do sudo adduser $user $group; done Then run `newgrp` (or just reboot) to apply the new group memberships to the session. ## Build Tails 3.2~alpha1 git clone https://git-tails.immerda.ch/tails cd tails git checkout 3.2~alpha1 git submodule update --init rake build # Send us feedback! No matter how your build attempt turned out we are interested in you sending us feedback. For that we'll first need some information of the system you used -- please run these commands in the exact same terminal session that you ran `rake build` in (e.g. run them right after `rake build`)! sudo apt install apt-show-versions || : ( for f in /etc/issue /proc/cpuinfo do echo "--- File: ${f} ---" cat "${f}" echo done for c in free locale env 'uname -a' '/usr/sbin/libvirtd --version' \ 'qemu-system-x86_64 --version' 'vagrant --version' do echo "--- Command: ${c} ---" eval "${c}" echo done if which apt-show-versions >/dev/null then echo '--- APT package versions ---' apt-show-versions qemu:amd64 linux-image-amd64:amd64 vagrant \ libvirt0:amd64 fi ) | bzip2 > system-info.txt.bz2 Please have a look at the generated file with bzless system-info.txt.bz2 to make sure it doesn't contain any sensitive information you do not want to leak in case you send this file to us or make it public! Next, please follow the instructions below that match your situation! ## If the build failed. Please open a ticket on our bug tracker [5] with "Category" set to "Build system" and `system-info.txt.bz2` attached (note that this makes this file public). ## If the build succeeded ... Please compute the SHA-512 checksum of the resulting ISO image: sha512sum tails-amd64-3.2~alpha1.iso and compare it to: 1c928336264fc44821562f2fffbda4da97dcdc38072fce58f55b749fde04ac60055273cfc021b6c57120c5d276980859ffa3a5b0bd0f9c98851f34b682a09b02 tails-amd64-3.2~alpha1.iso Bonus points if you verify the signed (with: [8]) message containing the checksum below (note that manually inserted line-wraps marked with "`\`"). If you run Tails, the verification is very easy! :) [9] - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 $ sha512sum tails-amd64-3.2~alpha1.iso 1c928336264fc44821562f2fffbda4da97dcdc38072fce58f55b749f \ de04ac60055273cfc021b6c57120c5d276980859ffa3a5b0bd0f9c98 \ 851f34b682a09b02 tails-amd64-3.2~alpha1.iso - -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEuiwiL0SsAO2YmTiTmP7GvHUqPbYFAlmxqwAPHHRhaWxzQGJv dW0ub3JnAAoJEJj+xrx1Kj22RgAP/0auINj6Y5svR7DfeRF8HxPdnd2Rw/8VIiaM isN3eQoAmNGUtEe50b9VXY+UidCdWtApbZbyZPKFz9ITJOxp0XeSGS8K2+Y0PZIx NSIEYCx2LEWlzY96ivH2B4pboeq2TIzj/VkPLISYGc80CYRT32OzMRkDDcQn+3+Y 2dkGVf1HPvreZ7c7cUfozay4TNPhKrn2p5IZp1jHgpiq8aAYIv5jcubR//lm1W3S Ol/IpTQrxzCShJHzsCh1l6/7zLSx5Dv8ITTEIHTj2OTCsZdAcFnznB4byaHVfVQ0 jSogb+b2J6skNhlsHtX2Jo9xK6Ni9NKsCzYYQ2KgWufC93Cvpmh5J164CqkI/DEd ixe/KbFURP9sTzEL38ExS2DVbMvFvYTmmBmWzvU3USMo0nWfaErye2RIs4yB2pM6 wbsgy1g93tQ49YUU0eKFcoUQLnQpKJmZVsLacdkGpLTn7pL9uHR3AcUnRT27CSzb anzpyLVTllyApU+Suu3f5rJibx9ysmLu8gHp5/Osd54qzSBR9JVrhMTkgJmZnit4 67wuSWJDQgvhMKxRz+zB/z4biORIfyblviR4rv1ZbAfX/ChP25CWUxG9Tgk1Esp0 LMzroJyQNfmy++6GrGuHJ3miRsKwO66ot84GSc5/pN1cJHKYiNa4HQhfb+VZBXbk HoXLV3eR =Hhyr - -----END PGP SIGNATURE----- ### ... and the checksums match (i.e. reproduction succeeded). Congrats for successfully reproducing Tails 3.2~alpha1! Please send an email to tails-dev at boum.org (public) or tails at boum.org (private) with the subject "Reproduction of Tails 3.2~alpha1 successful" and attach `system-info.txt.bz2` to it. ### ... and the checksums differ (i.e. reproduction failed). Now you are in a great position to help Tails improve its reproducibility! Please install `diffoscope` [7] version 83 or higher. If you run Debian Stretch, that is: echo 'deb http://ftp.debian.org/debian stretch-backports main' \ | sudo tee /etc/apt/sources.list.d/stretch-backports.list && \ sudo apt update && \ sudo apt -o APT::Install-Suggests="true" \ -o APT::Install-Recommends="true" \ install diffoscope -t stretch-backports Then download the official Tails 3.2~alpha1 ISO image [6] and compare it to yours: diffoscope \ --text diffoscope.txt \ --html diffoscope.html \ --max-report-size 262144000 \ --max-diff-block-lines 10000 \ --max-diff-input-lines 10000000 \ path/to/official/tails-amd64-3.2~alpha1.iso \ path/to/your/tails-amd64-3.2~alpha1.iso && \ bzip2 diffoscope.* Please send an email to tails-dev at boum.org (public) or tails at boum.org (private) with the subject "Reproduction of Tails 3.2~alpha1 failed" and attach `system-info.txt.bz2` to it. We also want you attach one (the smallest!) of `diffoscope.txt.bz2` and `diffoscope.html.bz2` to the email, but if they are "big" (say >100 KiB) then please don't bomb our mail inboxes! Instead upload the file to some web-based file-sharing service (we recommend RiseUp [10]) and include the link(s) in the email. Thank you very much for your interest and help! Cheers! The Tails project [1] https://mailman.boum.org/pipermail/tails-dev/2017-August/011591.html [2] https://labs.riseup.net/code/issues/13624 https://mailman.boum.org/pipermail/tails-dev/2017-March/011297.html [3] https://tails.boum.org/support/#talk [4] https://tails.boum.org/contribute/build [5] https://labs.riseup.net/code/projects/tails/issues/new [6] http://dl.amnesia.boum.org/tails/alpha/tails-amd64-3.2~alpha1/ https://mirrors.wikimedia.org/tails/alpha/tails-amd64-3.2~alpha1/ https://mirrors.kernel.org/tails/alpha/tails-amd64-3.2~alpha1/ [7] https://diffoscope.org/ [8] https://tails.boum.org/tails-signing.key [9] https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/decrypt_verify/ [10] https://share.riseup.net/ -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEUrafEKOweFrQWvtHHYTM8BDMW8cFAlmxuZIACgkQHYTM8BDM W8fBag/+PlnYIFIfxf4KbPh97Tm9hrNlC6bJp5uTC+6WebBamVsEDekQXnXRzEtF wN4btdFG7MJuLHocSqeiV7gX33A07+KaugqCjQ4NJcVkZ6L9HPK6a1bjn9909EWw l/Cfn0NxaSkfGLhOsk2wFOm2BHU890But+j3bOPOU61JNMVUpwiHUbN2DS1xDK2X ZKE0dlOP3O4TC7kee7rRy6PFUVQx0eQkVW+1qrcusEeHEkc/Z6YzuLmNBdcHJ96m /OfkEi4ygY6l9j0B8z4O/vqPkyeU5VWQWwhhnETvJiSDqs5WNLDuttHOsumP0r29 sluAmicjNoM48mWJHwiyLYnEt5SfFHXOqHXPP1k5YzTOMLRfv/F2eH4Zoq/eI8TM sJy2MO+MgShH8SAOe1vJMBlV9Jqs6t85eToQt+39RFCCn4geyEYlynrk2Ka2hE3n ycn2Qa79nbNK8NJve+1rPZTiJq3lgYyXTYyb8chefKyWm1IsAdY8grS0UIYP44Po KAApudKD75DuCf6qczkOChVeAOcABu63RmAJLnJTYnEwGf7JLJ+KHrCdq0FQQS8s /PulDSSDZo9bhLAHx9tO2T6p2snJfZSf9/dmvM5H+kOlMwzY8GciCgN6wlluwlnU 5WMfAMYT5mhuKIH/WIU5BXlKuUj1MuOi0c64q2MQM2GByJ6SOa8= =6m+4 -----END PGP SIGNATURE-----

1 3