Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
On Fri, Nov 4, 2011 at 11:35 PM, Marsh Ray wrote: > On 11/04/2011 09:19 PM, Watson Ladd wrote: >> >> On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon wrote: >>> >>> What if the GET request can be anything innocuous (e.g. robots.txt, >>> index.html) and a valid document is sent back. But the headers include >>> an ETag derived in some way from the document content (or just the URL), >>> the shared secret and the bridge's TLS cert. If there's a MITM then the >>> client will compute a different ETag (due to the wrong cert) and can >>> close the connection. Otherwise it can immediately initiate the full >>> authorisation sequence. >> >> ETag is a great idea. We can then have bridges run their own web >> content or specify a page to serve up (with suitably redirected links) >> or forwards real requests to an actual webserver. This >> way every bridge can hide differently: serving tor.eff.org everywhere >> would be a dead giveaway. > > I love this line of thinking. But what if the MitM calls your bluff and > returns his own cookie, ETag header and a 302 Redirect to the same page? > What would the client do then? If the client did observe the redirect as a > browser would, he may be unable to try again for some time. Otherwise, it > would tend to confirm the status of the server as a Tor node. > > Seems like what we want is like TLS channel bindings to detect the MitM. > This is standardized. http://tools.ietf.org/html/rfc5056 > Microsoft IE+IIS implemented it, it thwarts their MitM tool: >> >> >> http://blogs.msdn.com/b/fiddler/archive/2010/10/15/fiddler-https-decryption-and-channel-binding-token-authentication-problems.aspx > > Tossing out an idea here: maybe this would work better backwards. > > What if the client were to choose any innocuous-looking URL to request > before initiating the handshake? Then he could bury an HMAC for a message > including that URL in the TLS client_hello.random. The HMAC key could > derived from the AUTHORIZE secret. I don't know enough aboutTLS to comment on this. But I do know Telex used a covert channel in TLS to good effect. Maybe we can do some kind of similar stunt. > > The client_random is supposed to contain a (generous) 28 random bytes > transmitted in the clear. AFAICT, it's mainly to prevent replay attacks and > is most important in special cases like session resumption and certs with > fixed DH parameters. The encrypted premaster secret adds significant > client-supplied entropy to the handshake too. Replacing some of the true > random bytes with an HMAC formed from a secret key should not reduce the > entropy (as perceived by the active attacker) too much I think. > > The message input to the HMAC should probably include the rest of the > client_random. > > The client could also include some unpredictable stuff in the request (e.g., > some meaningless cookies). This could prevent any net unpredictability loss > in the client_random, so even if an attacker knew the AUTHORIZE secret it > would not enable any additional attacks on the TLS handshake. > > I would like other people to double-check my reasoning on this obviously. > > - Marsh > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
On 11/04/2011 09:19 PM, Watson Ladd wrote: On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon wrote: What if the GET request can be anything innocuous (e.g. robots.txt, index.html) and a valid document is sent back. But the headers include an ETag derived in some way from the document content (or just the URL), the shared secret and the bridge's TLS cert. If there's a MITM then the client will compute a different ETag (due to the wrong cert) and can close the connection. Otherwise it can immediately initiate the full authorisation sequence. ETag is a great idea. We can then have bridges run their own web content or specify a page to serve up (with suitably redirected links) or forwards real requests to an actual webserver. This way every bridge can hide differently: serving tor.eff.org everywhere would be a dead giveaway. I love this line of thinking. But what if the MitM calls your bluff and returns his own cookie, ETag header and a 302 Redirect to the same page? What would the client do then? If the client did observe the redirect as a browser would, he may be unable to try again for some time. Otherwise, it would tend to confirm the status of the server as a Tor node. Seems like what we want is like TLS channel bindings to detect the MitM. This is standardized. http://tools.ietf.org/html/rfc5056 Microsoft IE+IIS implemented it, it thwarts their MitM tool: http://blogs.msdn.com/b/fiddler/archive/2010/10/15/fiddler-https-decryption-and-channel-binding-token-authentication-problems.aspx Tossing out an idea here: maybe this would work better backwards. What if the client were to choose any innocuous-looking URL to request before initiating the handshake? Then he could bury an HMAC for a message including that URL in the TLS client_hello.random. The HMAC key could derived from the AUTHORIZE secret. The client_random is supposed to contain a (generous) 28 random bytes transmitted in the clear. AFAICT, it's mainly to prevent replay attacks and is most important in special cases like session resumption and certs with fixed DH parameters. The encrypted premaster secret adds significant client-supplied entropy to the handshake too. Replacing some of the true random bytes with an HMAC formed from a secret key should not reduce the entropy (as perceived by the active attacker) too much I think. The message input to the HMAC should probably include the rest of the client_random. The client could also include some unpredictable stuff in the request (e.g., some meaningless cookies). This could prevent any net unpredictability loss in the client_random, so even if an attacker knew the AUTHORIZE secret it would not enable any additional attacks on the TLS handshake. I would like other people to double-check my reasoning on this obviously. - Marsh ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
Julian Yon writes: > On 04/11/11 21:37, Watson Ladd wrote: >> On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom wrote: >>> | Should the client send a string of the form "GET >>> | /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE >>> | cell, where "correct+horse+battery+staple" is a semi-plausible search >>> | phrase derived from the HMAC in some way? >> >> Seems to me at that point we are hosed anyway. If you see >> correct+horse+battery+staple >> and the response is garbled data, not an HTTP response, its probably >> something unusual. >> Bridge descriptors should include enough information for Tor to ensure >> that the TLS connection is safe. > > What if the GET request can be anything innocuous (e.g. robots.txt, > index.html) and a valid document is sent back. But the headers include > an ETag derived in some way from the document content (or just the URL), > the shared secret and the bridge's TLS cert. If there's a MITM then the > client will compute a different ETag (due to the wrong cert) and can > close the connection. Otherwise it can immediately initiate the full > authorisation sequence. > > (NB. I'm not a cryptographer; feel free to tell me where the flaw in my > logic lies) > > Julian There are some things in these HTTP solutions that make me nervous. In the "GET /?q=correct+horse+battery+staple\r\n\r\n" client-side case we will have to build HTTP header spoofing into the tor client, which is not fun since modern browsers send loads of HTTP headers in their first GET. In the Etags/Cookies/whatever server-side case we will probably have to build some sort of 'valid document'/'innocuous webpage' generator into the Tor bridge, which is also not fun. Fortunately, we might be able to reuse such a construction when Bridge Passwords fail: https://lists.torproject.org/pipermail/tor-dev/2011-October/002996.html Still, I would very much enjoy if we could find a way to authenticate the bridge using the shared secret without relying on HTTP covert channel wizardry. I've been thinking of having bridges that use Bridge Passwords, "tag" their SSL certificate, say the Serial Number, with their password, and have clients validate them before proceeding with AUTHORIZE cells. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon wrote: > On 04/11/11 21:37, Watson Ladd wrote: >> On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom wrote: >>> | Should the client send a string of the form "GET >>> | /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE >>> | cell, where "correct+horse+battery+staple" is a semi-plausible search >>> | phrase derived from the HMAC in some way? >> >> Seems to me at that point we are hosed anyway. If you see >> correct+horse+battery+staple >> and the response is garbled data, not an HTTP response, its probably >> something unusual. >> Bridge descriptors should include enough information for Tor to ensure >> that the TLS connection is safe. > > What if the GET request can be anything innocuous (e.g. robots.txt, > index.html) and a valid document is sent back. But the headers include > an ETag derived in some way from the document content (or just the URL), > the shared secret and the bridge's TLS cert. If there's a MITM then the > client will compute a different ETag (due to the wrong cert) and can > close the connection. Otherwise it can immediately initiate the full > authorisation sequence. > > (NB. I'm not a cryptographer; feel free to tell me where the flaw in my > logic lies) ETag is a great idea. We can then have bridges run their own web content or specify a page to serve up (with suitably redirected links) or forwards real requests to an actual webserver. This way every bridge can hide differently: serving tor.eff.org everywhere would be a dead giveaway. Sincerely, Watson Ladd ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
On 04/11/11 21:37, Watson Ladd wrote: > On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom wrote: >> | Should the client send a string of the form "GET >> | /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE >> | cell, where "correct+horse+battery+staple" is a semi-plausible search >> | phrase derived from the HMAC in some way? > > Seems to me at that point we are hosed anyway. If you see > correct+horse+battery+staple > and the response is garbled data, not an HTTP response, its probably > something unusual. > Bridge descriptors should include enough information for Tor to ensure > that the TLS connection is safe. What if the GET request can be anything innocuous (e.g. robots.txt, index.html) and a valid document is sent back. But the headers include an ETag derived in some way from the document content (or just the URL), the shared secret and the bridge's TLS cert. If there's a MITM then the client will compute a different ETag (due to the wrong cert) and can close the connection. Otherwise it can immediately initiate the full authorisation sequence. (NB. I'm not a cryptographer; feel free to tell me where the flaw in my logic lies) Julian -- 3072D/D2DE707D Julian Yon (2011 General Use) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SHA-3 isn't looking so hot to me
Here is the letter I wrote to the SHA-3 mailing list, followed by
replies from Jon Callas and John Kelsey.
---
From: Zooko O'Whielacronx
Folks:
You might be interested in this discussion on the tor-dev mailing list
about a new crypto protocol for Tor:
https://lists.torproject.org/pipermail/tor-dev/2011-November/date.html
One of the issues brought up by Tor developer Nick Mathewson was
whether to switch from SHA-1 to SHA-2 or instead wait for SHA-3. I
argued that SHA-2 is better than SHA-3 (at least for a few years).
I feel slightly traitorous saying it, because I've enjoyed reading
this mailing list for years, and many of the SHA-3 candidates are
beautiful constructions, and I want them to be widely studied and
used, but there you have it: I can't think of good arguments for the
Tor developers to jump to SHA-3. Perhaps you can!
Regards,
Zooko
---
---
From: Jon Callas
Why do you feel traitorous saying it? In my opinion it's the right
decision (and frankly, having read the notes, some of the others are
sub-optimal), and I'm a co-author of a finalist.
Engineering is the art of applying science within constraints. Those
constraints include but are not limited to the laws of physics,
budgets, schedules, performance, and so on. The worst decision is no
decision.
If you are unhappy with SHA-1 for security reasons, then your first
choice should be using SHA-256. Your second choice should be SHA-512,
possibly in one of the narrow-width constructions that NIST recently
published. Those are the best-understood secure hash functions we
have.
SHA-3 candidates, no matter which ones they are are each and all
slightly less well-understood than SHA-2, for all the obvious reasons.
If you are unhappy with the above assessment for *performance*
reasons, well, that's a different kettle of fish entirely. Further
discussion is needed, but it's easier to find a performance metric and
select along it than there is to find a security metric. It can be
done, obviously, but the debate is a lot more entertaining.
The hardest thing of all, of course, is to try to minimax the two
considerations, security and performance. That debate would be really
entertaining.
All of this, however, presupposes that Tor can't reserve an algorithm
identifier for SHA-3 and design things so SHA-256 is used now and
SHA-3 when it's finally available. And yes, that's easier said than
done, but heck, that's what engineering is, too.
Jon
---
---
From: John Kelsey
For whatever it's worth, if someone asked me the same question, I'd
give the same advice--go ahead and switch to SHA256 or SHA512, but
make sure you build algorithm identifiers and versioning into your
protocol, so that it's possible to change hash functions (and
everything else) when you need to.
SHA1 has a claimed collision attack (which looks like it should be
right, but has never been verified experimentally), and also has a
certain collision attack at 2^{80} work, so if you are worried about
collisions in your application, you should definitely switch, and I
think SHA2 is pretty much the only good choice right now. Similarly,
if you're in a position to change hash functions now, but it will be a
big pain to do it in two or three years, switching to SHA2 makes good
sense. On the other hand, if you're only using SHA1 with HMAC to do
MACing and key derivation and random number generation, there doesn't
appear to be any great urgency in switching over, as there are no
results I'm aware of that come anywhere close to really threatening
those applications. There's no reason to keep SHA1 around in those
applications if you don't need to, but there is also no enormous
urgency switching over to SHA2 or SHA3 for HMAC.
Finally, if you're only worried about preimage and second preimage
resistance, SHA1 still seems okay. But be careful assuming that you
don't care about collisions--there are a lot of weird and surprising
things you can do to hash functions if you can find intermediate
collisions. For example, if a single colliding message is no big
deal, but a billion messages with the same hash is a disaster for your
application, it turns out you care very much about the difficulty of
finding one collision at a time in your Merkle-Damgaard hash function.
It's much safer to just use hash functions whose cryptographic
strength and width makes collisions impractical to ever find--that is,
hash functions like SHA2 instead of SHA1.
--John
---
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom wrote: > On 2011-11-04, George Kadianakis wrote: >> >> Filename: 189-authorize-cell.txt >> Title: AUTHORIZE and AUTHORIZED cells >> Author: George Kadianakis >> Created: 04 Nov 2011 >> Status: Open >> >> 1. Overview >> >> Proposal 187 introduced the concept of the AUTHORIZE cell, a cell >> whose purpose is to make Tor bridges resistant to scanning attacks. >> >> This is achieved by having the bridge and the client share a secret >> out-of-band and then use AUTHORIZE cells to validate that the >> client indeed knows that secret before proceeding with the Tor >> protocol. >> >> This proposal specifies the format of the AUTHORIZE cell and also >> introduces the AUTHORIZED cell, a way for bridges to announce to >> clients that the authorization process is complete and successful. >> >> 2. Motivation >> >> AUTHORIZE cells should be able to perform a variety of >> authorization protocols based on a variety of shared secrets. This >> forces the AUTHORIZE cell to have a dynamic format based on the >> authorization method used. >> >> AUTHORIZED cells are used by bridges to signal the end of a >> successful bridge client authorization and the beginning of the >> actual link handshake. AUTHORIZED cells have no other use and for >> this reason their format is very simple. >> >> Both AUTHORIZE and AUTHORIZED cells are to be used under censorship >> conditions and they should look innocuous to any adversary capable >> of monitoring network traffic. > > I wrote the following in my reply to proposal 190, but it probably > belongs here instead: > > | An adversary who MITMs the TLS connection and receives a Tor AUTHORIZE > | cell will know that the client is trying to connect to a Tor bridge. > | > | Should the client send a string of the form "GET > | /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE > | cell, where "correct+horse+battery+staple" is a semi-plausible search > | phrase derived from the HMAC in some way? Seems to me at that point we are hosed anyway. If you see correct+horse+battery+staple and the response is garbled data, not an HTTP response, its probably something unusual. Bridge descriptors should include enough information for Tor to ensure that the TLS connection is safe. If we are protecting against passive scanning then we just need to make it look like a webserver. One good way of doing that: ask people who have webservers to run bridges, and have Tor simply pass any confused HTTP requests to the actual webserver. (These shouldn't be popular sites) Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
On 2011-11-04, George Kadianakis wrote: > > Filename: 189-authorize-cell.txt > Title: AUTHORIZE and AUTHORIZED cells > Author: George Kadianakis > Created: 04 Nov 2011 > Status: Open > > 1. Overview > >Proposal 187 introduced the concept of the AUTHORIZE cell, a cell >whose purpose is to make Tor bridges resistant to scanning attacks. > >This is achieved by having the bridge and the client share a secret >out-of-band and then use AUTHORIZE cells to validate that the >client indeed knows that secret before proceeding with the Tor >protocol. > >This proposal specifies the format of the AUTHORIZE cell and also >introduces the AUTHORIZED cell, a way for bridges to announce to >clients that the authorization process is complete and successful. > > 2. Motivation > >AUTHORIZE cells should be able to perform a variety of >authorization protocols based on a variety of shared secrets. This >forces the AUTHORIZE cell to have a dynamic format based on the >authorization method used. > >AUTHORIZED cells are used by bridges to signal the end of a >successful bridge client authorization and the beginning of the >actual link handshake. AUTHORIZED cells have no other use and for >this reason their format is very simple. > >Both AUTHORIZE and AUTHORIZED cells are to be used under censorship >conditions and they should look innocuous to any adversary capable >of monitoring network traffic. I wrote the following in my reply to proposal 190, but it probably belongs here instead: | An adversary who MITMs the TLS connection and receives a Tor AUTHORIZE | cell will know that the client is trying to connect to a Tor bridge. | | Should the client send a string of the form "GET | /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE | cell, where "correct+horse+battery+staple" is a semi-plausible search | phrase derived from the HMAC in some way? >As an attack example, an adversary could passively monitor the >traffic of a bridge host, looking at the packets directly after the >TLS handshake and trying to deduce from their packet size if they >are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and >AUTHORIZED cells are padded with a random amount of padding before >sending. What distribution should this 'random amount' be chosen from? > 3. Design > > 3.1. AUTHORIZE cell > >The AUTHORIZE cell is a variable-sized cell. > >The generic AUTHORIZE cell format is: > > AuthMethod [1 octet] > MethodFields [...] > PadLen [2 octets] > Padding ['PadLen' octets] > >where: > >'AuthMethod', is the authorization method to be used. > >'MethodFields', is dependent on the authorization Method used. It's >a meta-field hosting an arbitrary amount of fields. > >'PadLen', specifies the amount of padding in octets. > >'Padding', is 'PadLen' octets of random content. > > 3.2. AUTHORIZED cell format > >The AUTHORIZED cell is a variable-sized cell. > >The AUTHORIZED cell format is: > > 'AuthMethod' [1 octet] > 'PadLen' [2 octets] > 'Padding' ['PadLen' octets] > >where all fields have the same meaning as in section 3.1. > > 3.3. Cell parsing > >Implementations MUST ignore the contents of 'Padding'. > >Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where >the 'Padding' field is not 'PadLen' octets long. > >Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod' >they don't recognize. What does "reject" mean here? > 4. Discussion > > 4.1. Why not let the pluggable transports do the padding, like they > are supposed to do for the rest of the Tor protocol? > >The arguments of section "Alternative design: Just use pluggable >transports" of proposal 187, apply here as well: > >All bridges who use client authorization will also need camouflaged >AUTHORIZE/AUTHORIZED cell. What does "camouflaged" mean here? > 4.2. How should multiple round-trip authorization protocols be handled? s/multiple round/multiple-round/ # it's part of a phrase acting as an ad-something >Protocols that require multiple round-trips between the client and >the bridge should use AUTHORIZE cells for communication. .-1s/round-trips/round trips/ # it's part of a top-level noun phrase >The format of the AUTHORIZE cell is flexible enough to support >messages from the client to the bridge and the inverse. s/inverse/reverse/ When can an AUTHORIZE cell be sent, and by whom? Can a bridge which requires client authorization perform reachability and bandwidth self-tests? If so, how? >In the end of a successful multiple round-trip protocol, an >AUTHORIZED cell must be issued from the brid
Re: [tor-dev] Subject: Re: The consequences of key compromise (or the reasons for changing)
On Nov 4, 2011, at 12:14 AM, Markku-Juhani O. Saarinen wrote: > > From: Jon Callas > >> People should get off of 80-bit crypto as soon as is reasonably possible. >> This means RSA 1024, SHA-1, etc. NIST recommended doing this by the end of >> 2010, but are now holding their nose and saying that 2013 is the real new >> date. > > Absolutely agree. The 80-bit figure was apparently adopted by U.S. > Government some 25+ years ago (skipjack etc). Yeah, Skipjack is one of the others in the suite, but we civilians don't use it. We're pretty good at 128-bit crypto on the symmetric side. However, the other major thing to remember is that a block size of 64 bits also is an issue. There are birthday-bounds problems for objects of size around the size of a Blu-Ray disk. > >> This seems basically reasonable to me. No one has yet factored a 768-bit >> number, let alone a 1K one. > > 768-bit RSA was factored in 2009 and the authors of that paper > conjecture that 1024 bits would be factored "within a decade" and > recommend that 1024-bit RSA should be phased out within a couple of > years. http://eprint.iacr.org/2010/006.pdf > > I am certainly doing that with the stuff that I am maintaining. It was a special-form number, though. It wasn't a general-case one. I didn't go into details because we should all be getting off 1024. In many cases, jumping to 2K-bit keys works fine. In others, it doesn't. > >> SHA-1 actually looks safer today than it did in 2005. But still. Moving away >> is a Good Thing, so long as it doesn't make you do something stupid. > > Well, after the 2005 Wang-Yin-Yu paper which had a 2^69 attack, there > was a claimed 2^52 attack in 2009 which turned out to have a flawed cost > evaluation. There has also been talk of a 2^63 attack, but that > difference can be put down to attack implementation skill and detail. I'll repeat what I said after the 2^52 paper: 2^52 *whats*? It matters. 2^52 seconds is still a large number, and smaller than (but near to) 2^80 clock cycles. I've never gotten a good answer to that. But -- I was recommending "walk, do not run to the exit" in 2005. NIST wanted people off of it by 2010. My comment is at best a left-handed compliment. > > I was always doubtful whether or not those techniques could be expanded > to work against the SHA-2 algorithms. Me too, but there were people who were sure of it in 2004-2005. > > It is also funny that many people talk about SHA-2 as if was a single > algorithm; there are actually two quite distinct algorithms, one for > (now fading) 32-bit architectures (SHA-224,SHA-256) and one for 64-bit > algorithms (SHA-384,SHA-512,SHA-512/224,SHA-512/256). The variants of > these two algorithms only differ in the number of output bits and the IV > values and hence have a constant speed regardless of their digest size. > You can run "openssl speed sha" to see a real-world performance > comparison on a particular box. You are, of course, correct. I try to call out SHA-256 and SHA-512, but sometimes it's simpler to call them SHA-2, especially since NIST does. Jon ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 190: Password-based Bridge Client Authorization
On 2011-11-04, Robert Ransom wrote: > On 2011-11-04, George Kadianakis wrote: >>To avoid problems associated with the human condition, schemes >>based on public key cryptography and certificates can be used. A >>public and well tested protocol that can be used as the basis of a >>future authorization scheme is the SSH "publickey" authorization >>protocol. > > Secret keys for DSA (with a fixed group) and EC-based signature > schemes can be short enough to be fairly easy to transport. Secret > keys for RSA are a PITA to transport, unless you either (a) specify a > deterministic key-generation procedure, or (b) make the public key > available to all clients somehow, and provide enough information to > clients intended to access a bridge that the client can factor the > modulus efficiently. Um. On second thought, this is just freaking ridiculous (especially my paragraph). We don't want each client to have to generate a public-key authentication keypair and send its public key to the bridge in advance; that would be a nightmare to implement with our current bridge infrastructure. So the only sensible ways to use public-key authentication seems to be to give the same secret key to every authorized client (i.e. distribute it like a password) (see Telex), and then we might as well use a (shorter) shared-secret password (unless we need magic features of a specific cryptosystem like the ‘public-key steganography’ used in Telex). Robert Ransom ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 190: Password-based Bridge Client Authorization
On 2011-11-04, George Kadianakis wrote: > > Filename: 190-password-bridge-authorization.txt > Title: Password-based Bridge Client Authorization > Author: George Kadianakis > Created: 04 Nov 2011 > Status: Open > > 1. Overview > >Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells. >Their purpose is to make bridge relays scanning resistant against >censoring adversaries capable of probing hosts to observe whether >they speak the Tor protocol. > >This proposal specifies a bridge client authorization scheme based >on a shared password between the bridge user and bridge operator. > > 2. Motivation > >A proper bridge client authorization scheme should: > >- request information from a client that only an authorized bridge > client would know. - request information from a client that only an authorized client of the bridge would know. >- ensure that the shared secret sent by the bridge client during > the authorization can only be read and validated by the proper > bridge relay. The shared secret cannot be read by the bridge relay, only validated. (That's a feature.) >This is important since the v3 link handshake which > authenticates the bridge to the client is carried out *after* the > bridge client authorization, which means that when the AUTHORIZE > cell is sent, the client might be actually speaking to a Man In > The Middle. And the reason that the client might be speaking to a MITM attacker is that the client has no way to determine whether it should accept whatever link certificate chain it receives. Hmm. >The bridge client authorization scheme presented in this proposal >is based on a shared password and attempts to satisfy both of the >above requirements. > > 3. Design > >If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants >to become authorized using a shared secret based on a password. > >The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'. > > 3.1. Notation > >'||', denotes concatenation. > >'HMAC(k, m)', is the Hash-based Message Authentication Code of > message 'm' using 'k' as the secret key. > >'H(m)', is a cryptographic hash function applied on a message 'm'. > >'HASH_LEN', is the output size of the hash function 'H'. > > 3.2. Shared secret format > >A bridge client and a bridge relay willing to use this >authorization scheme, should have already exchanged out-of-band >(for example, during the bridge credentials exchange) a shared >password. > >In this case, the shared secret of this scheme becomes: > > shared_secret = H( H(bridge_identity_key) || ":" || password) > >where: > >'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's > public identity key. > >'":"', is the colon character (0x3a in UTF-8). > >'password', is the bridge password. At the time that the client needs to compute shared_secret from password (before it receives a CERT cell from the bridge for the first time), the client does not know the bridge's identity key. There is no reason to have shared_secret and password be different strings. > 3.3. Password-based authorization AUTHORIZE cell format > >In password-based authorization, the MethodFields field of the >AUTHORIZE cell becomes: > >'HMAC(shared_secret, tls_cert)' [HASH_LEN octets] > >where: > >'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS >certificate of the bridge relay, using the shared secret of section >3.2 as the secret key. Which TLS certificate, encoded in what way? (The bridge may send a CA-signed certificate and its issuer chain.) > 3.4. Password-based authorization notes > >Bridge implementations MUST reject clients who provide malformed >AUTHORIZE cells or HMAC values that do not verify the appropriate >TLS certificate. > >Bridge implementations SHOULD provide an easy way to create and >change the bridge shared secret. > > 3.5. Security arguments > >An adversary who does not know the 'shared_secret' of a bridge >cannot construct an HMAC that verifies its TLS certificate when >used with the correct 'shared_secret'. > >An adversary who attempts to MITM the TLS connection of a bridge >user to steal the 'shared_secret' will instead steal an HMAC value >created by the 'tls_cert' of the TLS certificate that the attacker >used to MITM the TLS connection. Replaying that 'shared_secret' >value to the actual bridge will fail to verify the correct >'tls_cert'. An adversary who MITMs the TLS connection and receives a Tor AUTHORIZE cell will know that the client is trying to connect to a Tor bridge. Should the client send a string of the form "GET /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE cell, where "correct+horse+battery+staple" is a s
[tor-dev] Proposal 190: Password-based Bridge Client Authorization
Filename: 190-password-bridge-authorization.txt Title: Password-based Bridge Client Authorization Author: George Kadianakis Created: 04 Nov 2011 Status: Open 1. Overview Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells. Their purpose is to make bridge relays scanning resistant against censoring adversaries capable of probing hosts to observe whether they speak the Tor protocol. This proposal specifies a bridge client authorization scheme based on a shared password between the bridge user and bridge operator. 2. Motivation A proper bridge client authorization scheme should: - request information from a client that only an authorized bridge client would know. - ensure that the shared secret sent by the bridge client during the authorization can only be read and validated by the proper bridge relay. This is important since the v3 link handshake which authenticates the bridge to the client is carried out *after* the bridge client authorization, which means that when the AUTHORIZE cell is sent, the client might be actually speaking to a Man In The Middle. The bridge client authorization scheme presented in this proposal is based on a shared password and attempts to satisfy both of the above requirements. 3. Design If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants to become authorized using a shared secret based on a password. The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'. 3.1. Notation '||', denotes concatenation. 'HMAC(k, m)', is the Hash-based Message Authentication Code of message 'm' using 'k' as the secret key. 'H(m)', is a cryptographic hash function applied on a message 'm'. 'HASH_LEN', is the output size of the hash function 'H'. 3.2. Shared secret format A bridge client and a bridge relay willing to use this authorization scheme, should have already exchanged out-of-band (for example, during the bridge credentials exchange) a shared password. In this case, the shared secret of this scheme becomes: shared_secret = H( H(bridge_identity_key) || ":" || password) where: 'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's public identity key. '":"', is the colon character (0x3a in UTF-8). 'password', is the bridge password. 3.3. Password-based authorization AUTHORIZE cell format In password-based authorization, the MethodFields field of the AUTHORIZE cell becomes: 'HMAC(shared_secret, tls_cert)' [HASH_LEN octets] where: 'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS certificate of the bridge relay, using the shared secret of section 3.2 as the secret key. 3.4. Password-based authorization notes Bridge implementations MUST reject clients who provide malformed AUTHORIZE cells or HMAC values that do not verify the appropriate TLS certificate. Bridge implementations SHOULD provide an easy way to create and change the bridge shared secret. 3.5. Security arguments An adversary who does not know the 'shared_secret' of a bridge cannot construct an HMAC that verifies its TLS certificate when used with the correct 'shared_secret'. An adversary who attempts to MITM the TLS connection of a bridge user to steal the 'shared_secret' will instead steal an HMAC value created by the 'tls_cert' of the TLS certificate that the attacker used to MITM the TLS connection. Replaying that 'shared_secret' value to the actual bridge will fail to verify the correct 'tls_cert'. The two above paragraphs resolve the requirements of the 'Motivation' section. Furthermore, an adversary who compromises a bridge, steals the shared secret and attempts to replay it to other bridges of the same bridge operator will fail since each shared secret has a digest of the bridge's identity key baked in it. The bridge's identity key digest also serves as a salt to counter rainbow table precomputation attacks. 4. Tor implementation The Tor implementation of the above scheme uses SHA256 as the hash function 'H'. SHA256 also makes HASH_LEN equal to 32. 5. Discussion 5.1. Do we need more authorization schemes? Probably yes. The centuries-old problem with passwords is that humans can't get their passwords right. To avoid problems associated with the human condition, schemes based on public key cryptography and certificates can be used. A public and well tested protocol that can be used as the basis of a future authorization scheme is the SSH "publickey" authorization protocol. 5.2. What should actually happen when a bridge rejects an AUTHORIZE cell? When a bridge detects a badly formed or malicious AUTHORIZE cell, it should assume that the other side is an adversary scanning for bridges. The bridge should then
[tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
Filename: 189-authorize-cell.txt Title: AUTHORIZE and AUTHORIZED cells Author: George Kadianakis Created: 04 Nov 2011 Status: Open 1. Overview Proposal 187 introduced the concept of the AUTHORIZE cell, a cell whose purpose is to make Tor bridges resistant to scanning attacks. This is achieved by having the bridge and the client share a secret out-of-band and then use AUTHORIZE cells to validate that the client indeed knows that secret before proceeding with the Tor protocol. This proposal specifies the format of the AUTHORIZE cell and also introduces the AUTHORIZED cell, a way for bridges to announce to clients that the authorization process is complete and successful. 2. Motivation AUTHORIZE cells should be able to perform a variety of authorization protocols based on a variety of shared secrets. This forces the AUTHORIZE cell to have a dynamic format based on the authorization method used. AUTHORIZED cells are used by bridges to signal the end of a successful bridge client authorization and the beginning of the actual link handshake. AUTHORIZED cells have no other use and for this reason their format is very simple. Both AUTHORIZE and AUTHORIZED cells are to be used under censorship conditions and they should look innocuous to any adversary capable of monitoring network traffic. As an attack example, an adversary could passively monitor the traffic of a bridge host, looking at the packets directly after the TLS handshake and trying to deduce from their packet size if they are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and AUTHORIZED cells are padded with a random amount of padding before sending. 3. Design 3.1. AUTHORIZE cell The AUTHORIZE cell is a variable-sized cell. The generic AUTHORIZE cell format is: AuthMethod [1 octet] MethodFields [...] PadLen [2 octets] Padding ['PadLen' octets] where: 'AuthMethod', is the authorization method to be used. 'MethodFields', is dependent on the authorization Method used. It's a meta-field hosting an arbitrary amount of fields. 'PadLen', specifies the amount of padding in octets. 'Padding', is 'PadLen' octets of random content. 3.2. AUTHORIZED cell format The AUTHORIZED cell is a variable-sized cell. The AUTHORIZED cell format is: 'AuthMethod' [1 octet] 'PadLen' [2 octets] 'Padding' ['PadLen' octets] where all fields have the same meaning as in section 3.1. 3.3. Cell parsing Implementations MUST ignore the contents of 'Padding'. Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where the 'Padding' field is not 'PadLen' octets long. Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod' they don't recognize. 4. Discussion 4.1. Why not let the pluggable transports do the padding, like they are supposed to do for the rest of the Tor protocol? The arguments of section "Alternative design: Just use pluggable transports" of proposal 187, apply here as well: All bridges who use client authorization will also need camouflaged AUTHORIZE/AUTHORIZED cell. 4.2. How should multiple round-trip authorization protocols be handled? Protocols that require multiple round-trips between the client and the bridge should use AUTHORIZE cells for communication. The format of the AUTHORIZE cell is flexible enough to support messages from the client to the bridge and the inverse. In the end of a successful multiple round-trip protocol, an AUTHORIZED cell must be issued from the bridge to the client. 4.3. AUTHORIZED seems useless. Why not use VPADDING instead? As noted in proposal 187, the Tor protocol uses VPADDING cells for padding; any other use of VPADDING makes the Tor protocol kludgy. In the future, and in the example case of a v3 handshake, a client can optimistically send a VERSIONS cell along with the final AUTHORIZE cell of an authorization protocol. That allows the bridge, in the case of successful authorization, to also process the VERSIONS cell and begin the v3 handshake promptly. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SHA-3 isn't looking so hot to me
Hi, Robert! Hi, Jon! As usual, please take me not as being "That fellow who is a pompous ass and says things that aren't true" but rather as "that fellow who knows that he is probably wrong about some stuff, and doesn't know a better way to find out what he's wrong about than getting corrected." IOW, this is what I think now, but if it's not reasonable, I want to thing something else. On Fri, Nov 4, 2011 at 9:01 AM, Robert Ransom wrote: > On 2011-11-03, Jon Callas wrote: >> Zooko forwarded a hash question over to the SHA-3 competition mailing list, >> and mentioned the discussion that has been going on here. He's going to >> forward over comments that I made and John Kelsey made. Nonetheless, I'd >> like to offer some comments on what I've read in a larger context. >> >> I don't see any discussions of requirements, goals, or anything like that. I >> see discussions of what hash function to use, ECC, symmetric modes, and so >> on, and yet no reasons why you would do anything. If you don't have >> requirements, you aren't going to get a good answer. Any of those proposed >> solutions needs to have an answer to the question "What is this trying to >> solve?" at the very least. The next question should be, "How does it solve >> it?" > > For ‘What is this trying to solve?’, see: > > * https://www.torproject.org/docs/documentation#DesignDoc > > * https://svn.torproject.org/svn/projects/design-paper/tor-design.html > > * https://svn.torproject.org/svn/projects/design-paper/challenges.pdf > > * https://blog.torproject.org/blog/one-cell-enough On this last point about cell-tagging attacks, see also https://lists.torproject.org/pipermail/tor-dev/2011-November/003024.html for my current thinking. > See also the tor-dev mailing-list threads started with these > documents: > > * > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-crypto-migration.txt > > * > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-crypto-requirements.txt Right; and keep in mind that the requirements themselves are also in a evolving draft status. I think that one of the main problems with the draft I circulated the other week is that it tried to start discussion on three questions: * Should we keep using our current primitive operations (SHA1, AES-CTR starting at IV 0, 1024-bit DH, 1024-bit RSA, OpenSSL PRNG) or switch to something else? * Regardless of what primitive operations we're using, should we keep using them in the same ways in our protocol, or are their protocol improvements we could reasonably make? (That's the main point of Section 6 for relay crypto, and of the Goldberg-Stebilia-Ustaoglu "ntor" design for circuit exension.) * Assuming that we pick any primitives and protocols other than the ones we currently have, how can we best migrate? It should probably have been predictable that the first one would have gotten all the attention. Still, I'm not going to call "bike shed" too loudly here, since it helps people get involved in design, *and* the end result is actually important. Let me try to motivate this and explain goals a bit better. We want to choose our crypto primitives and protocols for a few properties. Some of the more justifiable ones from an engineering perspective are: [Please treat the above as a draft and tentative set of goals, motivations, and requirements. If you think any of these are stupid and wrongheaded, or just unmotivated, please tell me so!] A) They should be strong enough that attacking the crypto primitives and protocols is not the best attack on Tor. (We have this property today, I believe, and will continue to have it so long as nobody in the research community comes up with a solution to the low-latency traffic correlation attack.) B) Further, crypto attacks should not be even _close_ to the best attacks on Tor. (Except for the cell tagging attack, I think we have this property today. With cell tagging, however, the attack is IMO only a little worse than the end-to-end timing-attacks that a smart attacker would be doing instead. Moreover,, to the extent that it's feasible, I'd like to reach a situation where every crypto- or protocol-based attack on Tor is (and remains!) many orders of magnitude more expensive than the traffic correlation attacks that the research community doesn't know how to solve. Ideally, I'd like every crypto- or protocol-based attack to be hideously expensive on an absolute scale, if not downright impossible.) C) We need good performance. Our original design goal was "commodity hardware should be able to saturate commodity bandwidth." Right now, though, some of the busier servers do seem to be getting CPU-bound. (If I'm remembering what I've seen from profiles, the time sink seems to be to some extent AES and SHA1, and in larger part exponentiation for RSA and DH. But I'd want to double-check that to be sure. See comments below on performance requirements.) We also need our cell-crypto prot
Re: [tor-dev] SHA-3 isn't looking so hot to me
On Fri, Nov 4, 2011 at 9:24 AM, Ian Goldberg wrote: > On Fri, Nov 04, 2011 at 01:01:09PM +, Robert Ransom wrote: >> I have also seen parameters for an Edwards curve equivalent to >> Curve25519; we will need the Edwards-curve parameters in order to >> implement point addition efficiently in constant time for our EC >> signature scheme. > > Hmm? curve25519 _is_ an Edwards curve (that's why it has that slightly > annoying non-prime order), and djb's implementation, at least, is > supposed to be constant-time. Dear all, curve25519 is rationally equivalent to ed25519. Point addition isn't defined for curve25519 because public keys do not encode sign, because they are only the x coordinate. This is to take advantage of the special form y^2=x^3+a_2x^2+x. Until recently this was the fastest point exponentiation available, at the cost of making addition impossible. ed25519 supports point addition, and point compression without patents. This is because Edwards curves have never been discussed in Certicom patents. ed25519 is also faster then curve25519, due to new algorithms. In the future DJB has indicated he will have curve25519 convert into Edwards form for calculation. But signing requires ed25519 be used because addition is not defined on packed curve25519 keys. P-256 sadly does not support point compression without infringing on patents. So keys will have to be 64 bytes long. Edwards curves always exist over closures. The problem is that they only exist when the order is divisible by 4. Twisted Edward curves have points of order 2. P-256 could only be put into Edwards form with extension fields, and extension fields are slow. If we go with curve25519 we should not implement it ourselves. DJB has written an implementation that is quite nice to use in the form of NaCL. Signing is implemented along with batch signature verification (not in NaCL yet, but written). NaCL is also a lot nicer to use then OpenSSL, and is very fast (and ensures it always goes the fastest). Sincerely, Watson Ladd > > - Ian > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The consequences of key compromise (or the reasons for changing)
On 11/04/2011 01:39 AM, Jon Callas wrote: It's certainly laudable to worry about TLAs with ASICs. They probably can't break 80-bit crypto yet, but that's why you need to get off of it now. On the other hand, no TLA worth their salt is buying ASICs to crack crypto. They are buying zero-day kernel 'sploits. That's how the Germans are beating Skype. Keep that in perspective. The half life of an ASIC is 18 months. Zero-days are much more effective and much cheaper. I think this does not follow. Just because they are buying 0-days doesn't mean that they are not also buying ASICs (or at least FPGAs). My guess is that there are some adversaries with more money for cybershenanigans than they know what to do with right now. - Marsh ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SHA-3 isn't looking so hot to me
On 11/04/2011 08:01 AM, Robert Ransom wrote: On 2011-11-03, Jon Callas wrote: However, the safe, sane thing to do is use SHA-256. SHA-256 sucks unnecessarily on 64-bit processors. Our fast relays are 64-bit. It may be worth mentioning the newly-standardized SHA-512/256 here. This is not a new function, it's "SHA-2". I.e., its SHA-512 with a unique IV and output truncated to 256 (or 224) bits. http://csrc.nist.gov/publications/drafts/fips180-4/FRN_Draft-FIPS180-4.pdf SHA-512 is based on 64 bit integer operations and seems to run a bit faster than SHA-256 on 64 bit processors. It looks quite competitive with even the SHA-3 candidates and no less conservative for security. Of course, whether or not it's better to be faster on 32-bit CPUs or 64-bit CPUs is another interesting discussion. Given the complex cache and bus organization on modern chips, my guess is that a design decision like CELL_LEN=512 is likely to have as much of an effect on overall throughput as a difference of a half-dozen clocks per byte in the hash function. - Marsh ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SHA-3 isn't looking so hot to me
On Fri, Nov 04, 2011 at 01:01:09PM +, Robert Ransom wrote: > I have also seen parameters for an Edwards curve equivalent to > Curve25519; we will need the Edwards-curve parameters in order to > implement point addition efficiently in constant time for our EC > signature scheme. Hmm? curve25519 _is_ an Edwards curve (that's why it has that slightly annoying non-prime order), and djb's implementation, at least, is supposed to be constant-time. - Ian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SHA-3 isn't looking so hot to me
On 2011-11-03, Jon Callas wrote: > Zooko forwarded a hash question over to the SHA-3 competition mailing list, > and mentioned the discussion that has been going on here. He's going to > forward over comments that I made and John Kelsey made. Nonetheless, I'd > like to offer some comments on what I've read in a larger context. > > I don't see any discussions of requirements, goals, or anything like that. I > see discussions of what hash function to use, ECC, symmetric modes, and so > on, and yet no reasons why you would do anything. If you don't have > requirements, you aren't going to get a good answer. Any of those proposed > solutions needs to have an answer to the question "What is this trying to > solve?" at the very least. The next question should be, "How does it solve > it?" For ‘What is this trying to solve?’, see: * https://www.torproject.org/docs/documentation#DesignDoc * https://svn.torproject.org/svn/projects/design-paper/tor-design.html * https://svn.torproject.org/svn/projects/design-paper/challenges.pdf * https://blog.torproject.org/blog/one-cell-enough See also the tor-dev mailing-list threads started with these documents: * https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-crypto-migration.txt * https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-crypto-requirements.txt But as you may have seen, the tor-dev Cryptographic Bikeshed Design Task Force has ignored that part because it's more fun to talk endlessly about the least important details. (Based on the rest of your message, I assume they didn't even tell you about that part before inviting you into the discussion.) > Protocols are almost never broken because of the crypto. That's not the > problem. Tor as a protocol and as a *service* has many things it needs to > worry about long before you should worry about the crypto. Don't lose sight > of the real issues. Trust me, they aren't the crypto. You need to stick to > well-understood ciphers. Do not be frightened by warts on a function. The > property of being well-understood means that it will have warts. > > Additionally, you should stick to well-recognized constructions, too. The > main reason is that warts and all, we know most about these things. The > alternatives frequently either have different warts, or have unknown warts > that will bite you in the ass when they're finally found. Moreover, Tor is > an important protocol, service, and system. If you use a weird-ass > construction, then a flaw in that will be publicized as a flaw in Tor. If > someone finds a non-important problem in AES or SHA256, you'll be shielded > by ubiquity. If you use the Whizzy2^n-1 whatever, then when a problem is > found in it, that will hit the press as "FLAW FOUND IN TOR! EVERYONE RUN FOR > THEIR LIVES!" and you'll be left defending it yourself. The crypto elders > will also cluck their tongues and say, "Yeah, they really should have used > what NIST documented in SP 800-." Lastly on that, Tor is no important > that you'll be a target. People *will* target Tor because a teenie, tiny, > unimportant break in Tor is a g > uaranteed paper acceptance in Usenix Security or Eurocrypt. Anonymity loves > crowds; so do cryptographers. Tor's use of well-recognized constructions hasn't stopped the recent wave of ‘semi-technical bullshit attacks’ and plagiarisms of old, not-particularly-effective attacks from winning the attention economy. (One of the claims in the latest anti-Tor publicity campaign is that using AES in CTR mode is a ‘bugdoor’, and that we knew that we should have used CBC mode instead. This is even after the news that use of block ciphers in CBC mode breaks SSL's security. Yes, people *lie* in order to get publicity for an alleged attack on Tor.) > Here are some specifics: > > * Hash functions. Zooko will forward my full response, the summary of which > is to use SHA-2 in whatever length or form. Should you not want to do that, > why? What are you after? Speed? How much speed? Again, I don't see what > you're trying to solve, but I'll recommend using Skein if you don't like > SHA-2. I'm a co-designer of it, for full disclosure. > > Skein is secure, fast (under 7 clocks per byte on x64, and at 15.5 on > armv7), and has lots of Swiss Army Knife features. You can use it as a KDF, > PRNG, and so on. It has a one-pass MAC that has a proof of security on it, > so it is a valuable alternative to HMAC. ZRTP is using Skein's MAC to speed > up VOIP encryption as an alternative to HMAC (more full disclosure, I'm a > co-author of ZRTP, too, but Phil Z had to talk me into it, and he had real > performance goals to meet). Skein sucks on 32-bit processors, and on AMD64 processors in 32-bit mode. All of our Windows packages are 32-bit. And I'm not a fan of using a cryptographic primitive with as many features as Skein has. Implementation complexity sucks, especially in crypto software. > However, the safe, sane thing to do is use SHA-2
[tor-dev] Subject: Re: The consequences of key compromise (or the reasons for changing)
From: Jon Callas > People should get off of 80-bit crypto as soon as is reasonably possible. > This means RSA 1024, SHA-1, etc. NIST recommended doing this by the end of > 2010, but are now holding their nose and saying that 2013 is the real new > date. Absolutely agree. The 80-bit figure was apparently adopted by U.S. Government some 25+ years ago (skipjack etc). > This seems basically reasonable to me. No one has yet factored a 768-bit > number, let alone a 1K one. 768-bit RSA was factored in 2009 and the authors of that paper conjecture that 1024 bits would be factored "within a decade" and recommend that 1024-bit RSA should be phased out within a couple of years. http://eprint.iacr.org/2010/006.pdf I am certainly doing that with the stuff that I am maintaining. > SHA-1 actually looks safer today than it did in 2005. But still. Moving away > is a Good Thing, so long as it doesn't make you do something stupid. Well, after the 2005 Wang-Yin-Yu paper which had a 2^69 attack, there was a claimed 2^52 attack in 2009 which turned out to have a flawed cost evaluation. There has also been talk of a 2^63 attack, but that difference can be put down to attack implementation skill and detail. I was always doubtful whether or not those techniques could be expanded to work against the SHA-2 algorithms. It is also funny that many people talk about SHA-2 as if was a single algorithm; there are actually two quite distinct algorithms, one for (now fading) 32-bit architectures (SHA-224,SHA-256) and one for 64-bit algorithms (SHA-384,SHA-512,SHA-512/224,SHA-512/256). The variants of these two algorithms only differ in the number of output bits and the IV values and hence have a constant speed regardless of their digest size. You can run "openssl speed sha" to see a real-world performance comparison on a particular box. Cheers, - markku Dr. Markku-Juhani O. Saarinen ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
