- tor-dev - lists.torproject.org

is ECC patented? (was: Draft sketch document with ideas for future crypto ops)
by Zooko O'Whielacronx 02 Nov '11

02 Nov '11

A few pointers. On the happy "yay we can use it freely" side, we have: * RFC 6090 Pure gold! A catalog of ECC techniques which were published so long ago that they cannot still be under patent. It includes digital signatures and Diffie-Hellman. * DJB's page stating that certain patents don't apply to Curve25519 (which you mentioned): http://cr.yp.to/ecdh/patents.html * Jack Lloyd's statement that he avoided techniques newer than about 1990 in Botan: https://bugzilla.redhat.com/show_bug.cgi?id=615372#c19 On the sad "no we can't use it" side, we have: * Fedora's insistence on removing all elliptic curve cryptography from their Linux distribution and refusing to answer questions about why: https://bugzilla.redhat.com/show_bug.cgi?id=615372 Regards, Zooko

2 1

Re: [tor-dev] SHA-3 isn't looking so hot to me
by Watson Ladd 02 Nov '11

02 Nov '11

On Tue, Nov 1, 2011 at 4:40 PM, Marsh Ray <marsh(a)extendedsubset.com> wrote: > > On 11/01/2011 03:06 PM, Watson Ladd wrote: >> >> GCM is a Wegman-Carter authenticator with polynomial evaluation in >> GF2^128 as the universal hash and AES as the encryption. As NIST >> pointed out, neither of those papers had anything to say about the >> actual security of GCM: the security claims in the GCM paper are still >> valid. The Microsoft paper is simply irrelevant. 2^{n-k} looks scary, >> but messages are 2^k blocks long, where a block is 128 bits. And the >> GCM paper limited the length of messages to 2^36 bytes. The Joux paper >> was a threat to a misfeature: Theorem 1 still holds from the GCM paper >> (http://eprint.iacr.org/2004/193.pdf) Its just a matter of >> remembering that unique means unique, and that supporting variable >> length IVs by padding changes the meaning of the word unique. > > But those are exactly the kinds of details that get overlooked time and time > again. Whether or not you consider it a "real attack", a little bit of > controversy can help raise the important design constraints out of footnote > status. Definition of attack: something that breaks a security claim. Microsoft breaks a claim the GCM designers never made, Joux very cleverly breaks a part of the standard that their proof doesn't cover. The designers also didn't claim anything near the real security. (http://cr.yp.to/antiforgery/securitywcs-20050227.pdf is a tighter proof). True, NIST should put the claims front and center in the document, especially when they have such a nice form. But it is the responsibility of implementators of cryptography to exhaustively document what their security claims are. Hiding behind NIST won't save your data if you do something stupid. > >> I don't >> think stupidity by standards designers is a strike against what they >> are standardizing. > > :-) > > Everyone except fools and specialized cryptographers look to the recognized > experts to guide them. NIST's function is to provide expert, conservative > guidance on these topics, and they're pretty well regarded by engineers and > others who choose which standard to use. By following NIST, at the very > least it's not your fault if it turns out to be broken. NIST is standardizing cryptographic algorithms for government use. They make tradeoffs in their algorithms the same as any other user: speed vs. security. Blindly implementing standards is a way to fall into a trap. DES is a standard, Blowfish isn't as much. Which would you rather use? Furthermore, NIST didn't write the draft that the comments from Ferguson were about. As the response indicates GCM could be secure if you made the right parameter choices. Its not substantially different from RSA in that regard. Now, why the options, why q=2^128 instead of some prime? Because NIST wanted to support high speed encryption of fiber optic links in hardware, and Galois fields are easy in hardware. This is the story I get from the comments on the standard. If you are working in software, I would suggest something else. > > If, as you suggest, NIST can't get this unambiguously correct the first time > then in peoples' minds it naturally raises the question of the whole scheme > maybe being too complicated in practice. The standard is complicated But the problem is the picking the IV. I have no idea why NIST decided to use 96 bit IVs but fix the first 32 bits, so you are left with a 64 bit counter, then support longer ones through hashing, and then ultimately have to backtrack and support only 64 bit counters as nonces. But GCM is simple: it is polynomial evaluation, and encryption of the resulting value. The NSA has had these incidents before: ECMQV used to be in Suit B, before unknown key share attacks were published against it. The NIST P-256 was fast on 32 bit machines, but put a reflection right in the middle of a word on 64 bit machines. Etc, etc,. I'm sure there are many we never hear about. More fundamentally implementing a system such as Tor requires making choices about how standards are used and fit together. It is the rare (and wonderful!) standard that has no options. Making those choices requires knowledge of the security offered by the standard. It is never going to be possible to rely on guidance alone. Implementors who implement AES with giant tables are in for a surprise when they run on cloud machines. Hashing a password is pointless when that hash is a hash function: checking all 10 character passwords takes about a week on a nice graphics card. Understanding of cryptography is required even if standards exist. Nonces are required for protection against replay attacks. If nonces are unique, GCM is secure and pretty fast. Poly1305 is faster. HMAC does not have as high a margin of security proven, and when a hash function breaks so does HMAC. This is a good case for GCM or Poly1305 in Tor. Right now we have nothing: cells are encrypted with AES in counter mode only. In order to do something constructive I might go through Torspec and look at how things are used and what we rely on them for. This might give us a better idea of what the requirements are. > >> KDF!=turn a password into a bunch of bits. The KDF Tor uses is used to >> turn the result of a DH negotiation into keying material for several >> different algorithms. The KDF we need just needs to take some >> distribution to something random looking. We have enough randomness in >> the initial DH negotiation to not have to worry about slowing down >> brute force attacks. > > So you could almost use MD5(counter + DH material) for that :-) You can indeed. Or any stream cipher really. (Provided it doesn't do very bad things) > >> Where we use hashing to protect a password we >> should use scrypt or similar functions. > > I didn't know if passwords was a use case under discussion. PBKDFs has been > a hot topic lately and was just ranting in general. > > Thanks, > > - Marsh > Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin

1 0

future-proofing by combining ciphers (was: Draft sketch document with ideas for future crypto ops)
by Zooko O'Whielacronx 01 Nov '11

01 Nov '11

in reference to https://lists.torproject.org/pipermail/tor-dev/2011-November/002999.html We're doing a development effort and/or thought experiment in the Tahoe-LAFS project. This development effort and/or thought experiment is called "One Hundred Year Cryptography" [1]. The main result of the experiment so far is that you don't need to worry very much future-proofing your digital signatures, collision-resistant hashes, or MACs, but you *should* worry about future-proofing your Diffie-Hellmans and ciphers! Once you deploy a future version of Tor which no longer accepts old-style signatures, then it will no longer matter to your users if someone subsequently figures out how to forge old-style signatures (for example by using quantum computers). On the other hand, once you deploy a future version of Tor that uses a newer cipher, your users remain vulnerable to an attacker who later breaks the older cipher and reads their older plaintexts. Combining two ciphers as you suggested by XORing their output (and keying them independently—perhaps by deriving two subkeys from a master key using a strong KDF) seems to be a safe and efficient way to protect against this sort of threat and doesn't seem to impose too high of a burden of complexity. That's what we intend to do in Tahoe-LAFS. A Google Summer of Code student, Yu Xue, contributed some code to generate subkeys and XOR the streams, but we haven't yet integrated it into Tahoe-LAFS itself. (I intend to do that in the release cycle that just opened up, so within the next 4 or so months.) I haven't thought very much about future-proofing Diffie-Hellman operations. That sounds like it might be more complex. I *have* thought about how to combine two different digital signatures or public key encryption algorithms. Those don't seem too dauntingly complex, but like I said not so urgent. I'm leaning toward combining AES-256 with XSalsa20. Other interesting options include ChaCha (used in SHA-3 finalist Blake, and very similar to Salsa20) and Threefish (used in SHA-3 finalist Skein). Regards, Zooko [1] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography

1 0

Reminder: one month left for big features in 0.2.3.x
by Nick Mathewson 31 Oct '11

31 Oct '11

Hi, all! This is the final reminder about the December 1 deadline for getting large stuff merged into 0.2.3.x. See http://archives.seul.org/or/dev/Jul-2011/msg00030.html for the original announcment. It should answer many questions. December 1 is the deadline for getting large features and complicated bugfixes merged into 0.2.3.x. January 6 is the deadline for new features and marginal bugfixes. I am looking forward to being able to release 0.2.3.x on a faster-than-previous-Tor-releases schedule. Please plan accordingly! cheers, -- Nick

1 0

git-rw moved hosts - new ssh host key
by Sebastian Hahn 30 Oct '11

30 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey there people who have repositories hosted on tpo hardware, weasel migrated cupani to our shiny new VM server. Along with this came a change of ssh host key, so please be ready to modify your known_hosts file accordingly when you next push. The new ssh key fingerprint is: ssh-rsa e7:a0:63:15:a6:d3:41:e3:cf:92:6e:78:ea:cb:d7:ee After doing the migration, we took the opportunity to run a full git gc --aggressive on each repository, which should result in smaller clone sizes and generally faster clones. Take this as a reminder to occasionally optimize your local repositories too, your pushes will benefit and you can reclaim some lost space :) Sorry this went through without prior notice, I hope nobody's work was interrupted. Let me know if there is anything amiss, we don't expect any kind of issues tho. All the best Sebastian -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJOrbUZAAoJEKlsb90UDJYb77AIAIXIW5bkuXVfOB8DEYwh93vN ddIlxAea8QvrY8hebqHNYGC9a/GgHkgT3+fDGRLW1EsHgTb6YzpYT4Jhnrj1BKHu 37Kn1UzIyuS1X6X1CzFKJzoa6Z2Wej8lmpcOMk5m8GXE+MTMnYV/3kAZ+qsRgJOi GLO75HIFZc4FbD/wy2xAU6it3aBMPP1wszKK30wtU0oCldo20FDeltqaXt9GlWav jimBI+AcWBhgFr6hx7FKVLsLNlNkVEeH911E7qtDTF2lNzQAh7mHnzDU4sIZ6FhK wTNJOV3n/eCiyOp6amNmWC9mk+5RO0qjtNsdG+0aiPcmeKPzNNeIPiH1oQFVBWc= =rYix -----END PGP SIGNATURE-----

1 0

Proposal 187: Reserve a cell type to allow client authorization
by Nick Mathewson 29 Oct '11

29 Oct '11

Filename: 187-allow-client-auth.txt Title: Reserve a cell type to allow client authorization Author: Nick Mathewson Created: 16-Oct-2011 Status: Open Target: 0.2.3.x Overview: Proposals 176 and 184 introduce a new "v3" handshake, coupled with a new version 3 link protocol. This is a good time to introduce other stuff we might need. One thing we might want is a scanning resistance feature for bridges. This proposal suggests a change we should make right away to enable us to deploy such a feature in future versions of Tor. Motivation: If an adversary has a suspected bridge address/port combination, the easiest way for them to confirm or disconfirm their suspicion is to connect to the address and see whether they can do a Tor handshake. The easiest way to fix this problem seems to be to give out bridge addresses along with some secret that clients should know, but which an adversary shouldn't be able to learn easily. The client should prove to the bridge that it's authorized to know about the bridge, before the bridge acts like a bridge. If the client doesn't show knowledge of the proper secret, the bridge should at like an HTTPS server or a bittorrent tracker or something. This proposal *does not* specify a way for clients to authorize themselves at bridges; rather, it specifies changes that we should make now in order to allow this kind of authorization in the future. Design: Currently, now that proposal 176 is implemented, if a server provides a certificate that indicates a v3 handshake, and the client understands how to do a V3 handshake, we specify that the client's first cell must be a VERSIONS cell. Instead, we make the following specification changes: We reserve a new variable-length cell type, "AUTHORIZE." We specify that any number of PADDING or VPADDING or AUTHORIZE cells may be sent by the client before it sends a VERSIONS cell. Servers that do not require client authorization MUST ignore such cells, except to include them when calculating the HMAC that will appear in the CLOG part of a client's AUTHENTICATE cell. We still specify that clients SHOULD send VERSIONS as their first cell; only in some future version of Tor will an AUTHORIZE cell be sent first. Discussion: This change allows future versions of the Tor client to know that some bridges need authorization, and to send them authentication before sending them anything recognizably Tor-like. The authorization cell needs to be received before the server can send any Tor cells, so we can't just patch it in after the VERSIONS cell exchange: the server's VERSIONS cell is unsendable until after the AUTHORIZE has been accepted. Note that to avoid scanning attacks, it's not sufficient to wait for a single cell, and then either handle it as authorization or reject the connection. Instead, we need to decide what kind of server we're impersonating, and respond once the client has provided *either* an authorization cell, *or* a recognizably valid or invalid command in the impersonated protocol. Alternative design: Just use pluggable transports Pluggable transports can do this too, but in general, we want to avoid designing the Tor protocol so that any particular desirable feature can only be done with a pluggable transport. That is, any feature that *every* bridge should want, should be doable in Tor proper. Also, as of 16 Oct 2011, pluggable transports aren't in general use. Past experience IMO suggests that we shouldn't offload architectural responsibilities to our chickens until they've hatched. Alternative design: Out-of-TLS authorization There are features (like port-knocking) designed to allow a client to show that it's authorized to use a bridge before the TLS handshake even happens. These are appropriate for bunches of applications, but they're trickier with an adversary who is MITMing the client. Alternative design: Just use padding. Arguably, we could only add the "VPADDING" cell type to the list of those allowed before VERSIONS cells, and say that any client authorization we specify later on will be sent as a VPADDING cell. But that design is kludgy: padding should be padding, not semantically significant. Besides, cell types are still fairly plentiful. Counterargument: specify it later We could, later on, say that if a client learns that a bridge needs authorization, it should send an AUTHORIZE cell. So long as a client never sends an AUTHORIZE to anything other than a bridge that needs authorization, it'll never violate the spec. But all things considered, it seems easier (just a few lines of spec and code) to let bridges eat unexpected authorization now than it does to have stuff fail later when clients think that a bridge needs authorization but it doesn't. Counterargument: it's too late! We've already got the prop176 branch merged and running on a few servers. But as of this writing, it isn't in any Tor version. Even if it *is* out in an alpha before we can get this proposal accepted and implemented, that's not a big disaster. In the worst case, where future clients don't know whom to send authorization to so they need to send it to _all_ v3 servers, they will at worst break their connections only to a couple of alpha versions which one hopes by then will be long-deprecated already.

3 2

Fwd: [guardian-dev] Orbot-1.0.6-Tor-0.2.3.6-alpha-RC2
by Nathan Freitas 29 Oct '11

29 Oct '11

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Nathan of Guardian <nathan(a)guardianproject.info> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Major update to Orbot is now available for testing on Android devices: https://github.com/guardianproject/Orbot/Orbot-1.0.6-Tor-0.2.3.6-alpha-RC2.… (sig: https://github.com/downloads/guardianproject/Orbot/Orbot-1.0.6-Tor-0.2.3.6-…) This includes work from GSathya of GSoC, as well as the new "make your phone a Tor Wifi hotspot" feature. code, commits, whatnot is here now: https://gitweb.torproject.org/orbot.git +n -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk6rpcgACgkQ0qzSA7N0y9IJaQD/avI5IVCV4+Zy9yaz/XbVGDrO ZFIcUVe27zWSa8c8X3cA/j05eJhwnoGAIPLsIQ0jaywd+HcqKQmSI8FHfRgLqgus =ToXu -----END PGP SIGNATURE----- _____________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

1 0

Survey on Tor Trac usage and how you manage your tasks
by Karsten Loesing 25 Oct '11

25 Oct '11

Hi everyone! At the last annual dev meeting in Waterloo we had a very productive discussion about managing the various channels of Tor communication: https://trac.torproject.org/projects/tor/wiki/org/meetings/2011TorAnnualDev… Related to that discussion, we should talk about how we use Tor's Trac system, or more generally how we manage our Tor tasks. We use Trac as issue tracker, wiki, and for project management. But it seems that everyone uses Trac slightly different and has their own expectations how other people use it. This can slow us down. In addition to that, some people may not know how Trac can solve their problems. Knowing how others use Trac might help them manage their tasks more quickly. Let's conduct a survey! The survey below consists of two parts: The first part focuses on Trac's features and whether you're using them or not. The second part is about managing your tasks in general, either with or without Trac. If you are a Tor developer or volunteer or think you have some input on the topic, please fill out this survey until Sunday, August 28, 2011 and send it either to this list or to me. I'll try to summarize what was said and send the survey results to this list, hopefully before the end of the month. Thanks! Karsten 1 Using Trac features 1.1 Which of the reports (stored ticket queries) do you use most often? 1.2 What are typical custom queries that you run? 1.3 How do you use milestones and roadmaps? 1.4 Are you subscribed to tor-bugs and/or tor-wiki-changes, and how do you use the mails sent to these lists? 1.5 Which wiki pages do you read/edit most often? 1.6 How do you search for wiki pages? 1.7 What are typical search terms that you use when using the search features? 1.8 Do you use keywords and the tags page, and if so, what are keywords that you typically use? 1.9 How relevant are the following ticket fields for you? 1.9.1 Reported by 1.9.2 Owned by 1.9.3 Priority 1.9.4 Milestone 1.9.5 Component 1.9.6 Version 1.9.7 Keywords 1.9.8 Cc 1.9.9 Parent ID 1.9.10 Points 1.9.11 Actual Points 1.10 How relevant are the following ticket statuses for you? 1.10.1 accepted 1.10.2 assigned 1.10.3 closed 1.10.4 needs_information 1.10.5 needs_review 1.10.6 new 1.10.7 reopened 1.11 What other features do you use in Trac? 1.12 What features are you missing in Trac? 1.13 What features would you want our Trac not to offer anymore, because they're making things only more confusing for you (and for people who are new to Tor)? 2 Solving typical software development tasks Note that the questions below don't just focus on Trac, but on any tools or communication media you use for solving a task. 2.1 How do you decide what to work on, both when fixing bugs or when implementing new features? 2.2 How do you keep track of what things you're supposed to do for sponsors and for when? 2.3 How do you memorize new ideas to work on when they come up? 2.4 How do you coordinate working together with someone on something? 2.5 How do you learn who you could work together with on something? 2.6 What other software development tasks do you have that may be supported by Trac or a Trac-like system?

15 35

Re: [tor-dev] tor-dev Digest, Vol 9, Issue 8
by Rob Jansen 15 Oct '11

15 Oct '11

On 10/14/2011 08:00 AM, tor-dev-request(a)lists.torproject.org wrote: > On Tue, Sep 27, 2011 at 4:20 PM, Rob Jansen<rob.g.jansen(a)nrl.navy.mil> wrote: >> > If you have the need to run Tor experiments, or are just interested in the >> > Software, please try it out. We would love any feedback or comments or >> > suggestions if you have them! > i've got more, but first off: > > - why secondary dependencies not in git and not opt-in? > e.g. downloading > http://shadow.cs.umn.edu/downloads/shadow-resources.tar.gz - if you > run fully offline build systems this default behavior breaks builds. > True, this is a good point. My original reason is that I thought the latency data we collected from PlanetLab was too large to put in git. Since then, my experience with git and its way of handling changes leads me to believe this isn't an issue after all. Also, it is unclear to me that resources should be versioned the same way that source code is. > - what about hw acceleration in performance estimates? > e.g. openssl dynamic engines in virtual CPU processing. > We incorporate CPU delays into Shadow by giving it a CDF distribution of real measurements of application and CPU throughput, and "delaying" the processing of events based on this distribution. You can model HW accel by skewing the distribution, or better yet creating a new one based on real measurements of an accelerated OpenSSL/Tor. > - is there a shadow-dev in addition to shadow-support?:) > Not yet. Since you asked, it will be up in a few days:) > >> > We are continuously working on improving the simulator, including more >> > efficient use of multiple CPU cores and a command-line interface to help >> > with installing Shadow and some of its dependencies. > https://github.com/shadow/shadow-cli also handy. > > thanks! Thanks for the comments, feel free to share your others. Rob

1 1

Running Real Tor Code Over Simulated Networks
by Rob Jansen 14 Oct '11

14 Oct '11

Hello, For the unaware, we have been working on the design and development of Shadow, a simulator capable of running real binaries over a simulated network, and a plug-in that runs real Tor. Shadow can simulate roughly 1000 Tor nodes in 10 GB of RAM and is easy to setup and use (no root required). You can generate realistic Tor topologies using a consensus, and test changes implemented in Tor extremely quickly. Earlier this year, I had an idea for a new algorithm on Sunday, thought about how it might work and discussed it with Nick [Hopper - my adviser] on Monday, implemented it in Tor and tested it on Tuesday and Wednesday, started running experiments and had results by Friday. Honestly. That fast. If you have the need to run Tor experiments, or are just interested in the Software, please try it out. We would love any feedback or comments or suggestions if you have them! We are continuously working on improving the simulator, including more efficient use of multiple CPU cores and a command-line interface to help with installing Shadow and some of its dependencies. (Because really, who wants to install dependencies?) More details on Shadow's design can be found in our technical report: http://www-users.cs.umn.edu/~jansen/papers/shadow-umntr11-020.pdf A release version that is somewhat stable is available on the Shadow webpage: http://shadow.cs.umn.edu/ Our code is public at https://github.com/shadow Best regards, Rob -- Rob G. Jansen U.S. Naval Research Laboratory rob.g.jansen(a)nrl.navy.mil 202.767.2389

2 1