diff options
Diffstat (limited to 'doc/spec/proposals/ideas/xxx-choosing-crypto-in-tor-protocol.txt')
| -rw-r--r-- | doc/spec/proposals/ideas/xxx-choosing-crypto-in-tor-protocol.txt | 138 |
1 files changed, 0 insertions, 138 deletions
diff --git a/doc/spec/proposals/ideas/xxx-choosing-crypto-in-tor-protocol.txt b/doc/spec/proposals/ideas/xxx-choosing-crypto-in-tor-protocol.txt deleted file mode 100644 index e8489570f7..0000000000 --- a/doc/spec/proposals/ideas/xxx-choosing-crypto-in-tor-protocol.txt +++ /dev/null @@ -1,138 +0,0 @@ -Filename: xxx-choosing-crypto-in-tor-protocol.txt -Title: Picking cryptographic standards in the Tor wire protocol -Author: Marian -Created: 2009-05-16 -Status: Draft - -Motivation: - - SHA-1 is horribly outdated and not suited for security critical - purposes. SHA-2, RIPEMD-160, Whirlpool and Tigerare good options - for a short-term replacement, but in the long run, we will - probably want to upgrade to the winner or a semi-finalist of the - SHA-3 competition. - - For a 2006 comparison of different hash algorithms, read: - http://www.sane.nl/sane2006/program/final-papers/R10.pdf - - Other reading about SHA-1: - http://www.schneier.com/blog/archives/2005/02/sha1_broken.html - http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html - http://www.schneier.com/paper-preimages.html - - Additionally, AES has been theoretically broken for years. While - the attack is still not efficient enough that the public sector - has been able to prove that it works, we should probably consider - the time between a theoretical attack and a practical attack as an - opportunity to figure out how to upgrade to a better algorithm, - such as Twofish. - - See: - http://schneier.com/crypto-gram-0209.html#1 - -Design: - - I suggest that nodes should publish in directories which - cryptographic standards, such as hash algorithms and ciphers, - they support. Clients communicating with nodes will then - pick whichever of those cryptographic standards they prefer - the most. In the case that the node does not publish which - cryptographic standards it supports, the client should assume - that the server supports the older standards, such as SHA-1 - and AES, until such time as we choose to desupport those - standards. - - Node to node communications could work similarly. However, in - case they both support a set of algorithms but have different - preferences, the disagreement would have to be resolved - somehow. Two possibilities include: - * the node requesting communications presents which - cryptographic standards it supports in the request. The - other node picks. - * both nodes send each other lists of what they support and - what version of Tor they are using. The newer node picks, - based on the assumption that the newer node has the most up - to date information about which hash algorithm is the best. - Of course, the node could lie about its version, but then - again, it could also maliciously choose only to support older - algorithms. - - Using this method, we could potentially add server side support - to hash algorithms and ciphers before we instruct clients to - begin preferring those hash algorithms and ciphers. In this way, - the clients could upgrade and the servers would already support - the newly preferred hash algorithms and ciphers, even if the - servers were still using older versions of Tor, so long as the - older versions of Tor were at least new enough to have server - side support. - - This would make quickly upgrading to new hash algorithms and - ciphers easier. This could be very useful when new attacks - are published. - - One concern is that client preferences could expose the client - to segmentation attacks. To mitigate this, we suggest hardcoding - preferences in the client, to prevent the client from choosing - to use a new hash algorithm or cipher that no one else is using - yet. While offering a preference might be useful in case a client - with an older version of Tor wants to start using the newer hash - algorithm or cipher that everyone else is using, if the client - cares enough, he or she can just upgrade Tor. - - We may also have to worry about nodes which, through laziness or - maliciousness, refuse to start supporting new hash algorithms or - ciphers. This must be balanced with the need to maintain - backward compatibility so the client will have a large selection - of nodes to pick from. Adding new hash algorithms and ciphers - long before we suggest nodes start using them can help mitigate - this. However, eventually, once sufficient nodes support new - standards, client side support for older standards should be - disabled, particularly if there are practical rather than merely - theoretical attacks. - - Server side support for older standards can be kept much longer - than client side support, since clients using older hashes and - ciphers are really only hurting theirselvse. - - If server side support for a hash algorithm or cipher is added - but never preferred before we decide we don't really want it, - support can be removed without having to worry about backward - compatibility. - -Security implications: - Improving cryptography will improve Tor's security. However, if - clients pick different cryptographic standards, they could be - partitioned based on their cryptographic preferences. We also - need to worry about nodes refusing to support new standards. - These issues are detailed above. - -Specification: - - Todo. Need better understanding of how Tor currently works or - help from someone who does. - -Compatibility: - - This idea is intended to allow easier upgrading of cryptographic - hash algorithms and ciphers while maintaining backwards - compatibility. However, at some point, backwards compatibility - with very old hashes and ciphers should be dropped for security - reasons. - -Implementation: - - Todo. - -Performance and scalability nodes: - - Better hashes and cipher are someimes a little more CPU intensive - than weaker ones. For instance, on most computers AES is a little - faster than Twofish. However, in that example, I consider Twofish's - additional security worth the tradeoff. - -Acknowledgements: - - Discussed this on IRC with a few people, mostly Nick Mathewson. - Nick was particularly helpful in explaining how Tor works, - explaining goals, and providing various links to Tor - specifications. |