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?"
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-9999."
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.
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).
However, the safe, sane thing to do is use SHA-256.
* ECC. I don't see a reason why you're looking at it; my remark isn't code for
thinking it's a bad idea, it means I don't see *reasons*, and yeah, yeah, I
keep harping on that.
ECC can be faster than RSA. But sometimes it isn't. I have seen RSA 1280
running at 10x the speed of P-256. Note that P-256 has the security properties
of RSA 3072, so it's not comparing apples to apples. But I'll bet that Tor
could run for the next five years on RSA 1280 or RSA 1536, and punt the problem
into the future. It is my gut feel that if you migrate to 256 bit ECC from RSA
1024, you will see a performance drop. Nonetheless, you need to move from RSA
1024 to *something*. I am just noting that from a performance standpoint,
you're not at the place where ECC is clearly better yet. Yet.
Now on the other hand, ECC is the wave of the future and why not bite the
bullet now? The patent issues are still thorny and that's another reason to
punt the decision into the future. The major ECC patents started expiring this
last summer, and if you delay the decision for three to five years, it'll be
pretty much a non-issue. On the other, other hand, I don't think the Tor
project has a lot to worry about. It is unlikely that RIM/Certicom will come
after Tor. Heck, they are as likely to donate a license to the project as
anything else. The IP issues shouldn't be much of a concern, but if they are --
wait. I see no requirements that say why you need ECC, and as I've said, you
might find that ECC is slower than RSA 1280 or 1536.
Should you go to ECC, use P-256; do not use some variant of 25519. You want to
be in a crowd. You want to use something that lots of smart people have looked
at. That means P-256. For *any* counter argument, please supply the requirement
or goal that makes P-256 the inferior choice, preferably with a metric. Absent
such, P-256 is your baby.
* Stream ciphers. For a stream cipher, you should be doing at AES-CTR. Really.
Stop worrying about the warts. There are hardware implementations with AES-NI,
or attached hardware that don't have problems. ArmV8 has AES in hardware along
with SHA256, which another reason to stick to the well-understood. AES-NI on an
x64 processor runs at under 1 clock per byte. That's all goodness.
If, for some reason, you really, really want to go off on a limb, then look
seriously at counter mode with either Twofish or Serpent, as they're likely the
next best-understood algorithms there are. However, there's not a lot of glory
in breaking them, so they haven't seen nearly as much work. Ditto for any
eStream cipher. If you must be trendy, then heck, please look at Threefish,
which runs twice as fast as AES and is inherently tweakable (note again, that
I'm a co-designer). But really, just use AES-CTR.
GCM is an alternative, but I'd use CTR and an HMAC, myself, especially since
you don't seem to have performance goals that are driving it. As others have
noted, it's really tetchy to use correctly, and there are limits on the
security it gives you. There is a 128-bit hardware multiply in the same Intel
processors that have AES-NI to speed it up, but I'd stick to the tried-and-true
HMAC, absent reasons with metrics.
Whatever you do, please do not do something as gosh-darned daft as XOR two
keystreams together. The crypto is not the problem, and every time someone
tries to do something like that to strengthen the crypto it all ends up with
someone's eye out.
* Random number generators. You're bikeshedding. Any of those are great things
to do, and there's no reason why continuing with what you've been doing (yeah,
throw in more entropy sources, it never hurts) is wrong or suboptimal.
Whatever. Do what you want, but I think you have bigger fish to fry.
* Fingerprints. Also a reasonable discussion of what color the shed should be.
My sole comment is that the gods punish hubris, and coding your hash function
into two bits is hubris. One of the major lessons of the obsessive
bit-conservation that PGP did is that you write more code and make more bugs
saving those bits than the bits were worth. If you use something smaller than a
byte, you will regret it.
* Other comments. In the relay crypto comments, there was something about
counter "in a less scary mode" -- just use what they describe in NIST
SP800-whatever.
Okay, that's it for me.
Regards,
Jon
_______________________________________________
tor-dev mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
