• PUDN用户
    了解作者
  • Unix_Linux
    开发工具
  • 2.3MB
    文件大小
  • gz
    文件格式
  • 1
    收藏次数
  • 10 积分
    下载积分
  • 2205
    下载次数
  • 2009-11-15 03:30
    上传日期
The Onion Router 洋葱路由。具体不用解释了。
tor-0.2.1.20.tar.gz
  • tor-0.2.1.20
  • src
  • or
  • Makefile.am
    3.6KB
  • Makefile.in
    24.1KB
  • eventdns_tor.h
    516B
  • test_data.c
    9KB
  • policies.c
    42.4KB
  • routerlist.c
    184KB
  • rendcommon.c
    52.1KB
  • dnsserv.c
    10.3KB
  • hibernate.c
    29.9KB
  • router.c
    64.9KB
  • rendclient.c
    36.9KB
  • ntmain.c
    24.6KB
  • geoip.c
    21.8KB
  • onion.c
    12.8KB
  • test.c
    163.4KB
  • config.c
    184.4KB
  • or.h
    206.6KB
  • routerparse.c
    134.3KB
  • connection.c
    104.1KB
  • rephist.c
    75.3KB
  • relay.c
    68.8KB
  • circuitbuild.c
    109.8KB
  • cpuworker.c
    14.9KB
  • dirvote.c
    77.5KB
  • networkstatus.c
    69.9KB
  • control.c
    136.5KB
  • reasons.c
    10.8KB
  • buffers.c
    54.8KB
  • micro-revision.i
    3B
  • tor_main.c
    830B
  • dns.c
    56.5KB
  • command.c
    22.3KB
  • circuituse.c
    55.1KB
  • connection_or.c
    46.3KB
  • directory.c
    132.1KB
  • connection_edge.c
    105KB
  • main.c
    70.2KB
  • eventdns.h
    13.4KB
  • rendmid.c
    10.8KB
  • eventdns.c
    93.5KB
  • dirserv.c
    109.9KB
  • rendservice.c
    78.5KB
  • circuitlist.c
    40.1KB
  • win32
  • Makefile.am
    26B
  • Makefile.in
    8.5KB
  • orconfig.h
    6KB
  • tools
  • Makefile.am
    730B
  • Makefile.in
    15KB
  • tor-checkkey.c
    1.5KB
  • tor-gencert.c
    14.7KB
  • tor-resolve.c
    12.1KB
  • config
  • Makefile.am
    247B
  • Makefile.in
    10.7KB
  • torrc.sample.in
    7KB
  • geoip
    2.2MB
  • common
  • Makefile.am
    513B
  • aes.h
    850B
  • Makefile.in
    14KB
  • compat.h
    17.4KB
  • torgzip.c
    12.4KB
  • compat.c
    65.8KB
  • container.h
    27.7KB
  • strlcpy.c
    2.2KB
  • address.c
    39.4KB
  • tortls.c
    45KB
  • crypto.c
    63.4KB
  • memarea.c
    8.1KB
  • torint.h
    6.7KB
  • ht.h
    28.1KB
  • test.h
    9.7KB
  • torgzip.h
    1.8KB
  • mempool.h
    2.1KB
  • address.h
    7.1KB
  • util.c
    67.3KB
  • tortls.h
    3.2KB
  • crypto.h
    9.5KB
  • strlcat.c
    2.5KB
  • log.h
    7.5KB
  • OpenBSD_malloc_Linux.c
    44.9KB
  • aes.c
    43.9KB
  • util.h
    11.8KB
  • memarea.h
    850B
  • mempool.c
    20.2KB
  • container.c
    33.7KB
  • ciphers.inc
    4.8KB
  • log.c
    27KB
  • Makefile.am
    152B
  • Makefile.in
    14KB
  • doc
  • website
  • tor-doc-web.html.de
    6.4KB
  • tor-doc-relay.html.en
    15.1KB
  • tor-doc-server.html.es
    16.8KB
内容介绍
$Id$ Tor directory protocol, version 3 0. Scope and preliminaries This directory protocol is used by Tor version 0.2.0.x-alpha and later. See dir-spec-v1.txt for information on the protocol used up to the 0.1.0.x series, and dir-spec-v2.txt for information on the protocol used by the 0.1.1.x and 0.1.2.x series. Caches and authorities must still support older versions of the directory protocols, until the versions of Tor that require them are finally out of commission. See Section XXXX on backward compatibility. This document merges and supersedes the following proposals: 101 Voting on the Tor Directory System 103 Splitting identity key from regularly used signing key 104 Long and Short Router Descriptors AS OF 14 JUNE 2007, THIS SPECIFICATION HAS NOT YET BEEN COMPLETELY IMPLEMENTED, OR COMPLETELY COMPLETED. XXX when to download certificates. XXX timeline XXX fill in XXXXs 0.1. History The earliest versions of Onion Routing shipped with a list of known routers and their keys. When the set of routers changed, users needed to fetch a new list. The Version 1 Directory protocol -------------------------------- Early versions of Tor (0.0.2) introduced "Directory authorities": servers that served signed "directory" documents containing a list of signed "router descriptors", along with short summary of the status of each router. Thus, clients could get up-to-date information on the state of the network automatically, and be certain that the list they were getting was attested by a trusted directory authority. Later versions (0.0.8) added directory caches, which download directories from the authorities and serve them to clients. Non-caches fetch from the caches in preference to fetching from the authorities, thus distributing bandwidth requirements. Also added during the version 1 directory protocol were "router status" documents: short documents that listed only the up/down status of the routers on the network, rather than a complete list of all the descriptors. Clients and caches would fetch these documents far more frequently than they would fetch full directories. The Version 2 Directory Protocol -------------------------------- During the Tor 0.1.1.x series, Tor revised its handling of directory documents in order to address two major problems: * Directories had grown quite large (over 1MB), and most directory downloads consisted mainly of router descriptors that clients already had. * Every directory authority was a trust bottleneck: if a single directory authority lied, it could make clients believe for a time an arbitrarily distorted view of the Tor network. (Clients trusted the most recent signed document they downloaded.) Thus, adding more authorities would make the system less secure, not more. To address these, we extended the directory protocol so that authorities now published signed "network status" documents. Each network status listed, for every router in the network: a hash of its identity key, a hash of its most recent descriptor, and a summary of what the authority believed about its status. Clients would download the authorities' network status documents in turn, and believe statements about routers iff they were attested to by more than half of the authorities. Instead of downloading all router descriptors at once, clients downloaded only the descriptors that they did not have. Descriptors were indexed by their digests, in order to prevent malicious caches from giving different versions of a router descriptor to different clients. Routers began working harder to upload new descriptors only when their contents were substantially changed. 0.2. Goals of the version 3 protocol Version 3 of the Tor directory protocol tries to solve the following issues: * A great deal of bandwidth used to transmit router descriptors was used by two fields that are not actually used by Tor routers (namely read-history and write-history). We save about 60% by moving them into a separate document that most clients do not fetch or use. * It was possible under certain perverse circumstances for clients to download an unusual set of network status documents, thus partitioning themselves from clients who have a more recent and/or typical set of documents. Even under the best of circumstances, clients were sensitive to the ages of the network status documents they downloaded. Therefore, instead of having the clients correlate multiple network status documents, we have the authorities collectively vote on a single consensus network status document. * The most sensitive data in the entire network (the identity keys of the directory authorities) needed to be stored unencrypted so that the authorities can sign network-status documents on the fly. Now, the authorities' identity keys are stored offline, and used to certify medium-term signing keys that can be rotated. 0.3. Some Remaining questions Things we could solve on a v3 timeframe: The SHA-1 hash is showing its age. We should do something about our dependency on it. We could probably future-proof ourselves here in this revision, at least so far as documents from the authorities are concerned. Too many things about the authorities are hardcoded by IP. Perhaps we should start accepting longer identity keys for routers too. Things to solve eventually: Requiring every client to know about every router won't scale forever. Requiring every directory cache to know every router won't scale forever. 1. Outline There is a small set (say, around 5-10) of semi-trusted directory authorities. A default list of authorities is shipped with the Tor software. Users can change this list, but are encouraged not to do so, in order to avoid partitioning attacks. Every authority has a very-secret, long-term "Authority Identity Key". This is stored encrypted and/or offline, and is used to sign "key certificate" documents. Every key certificate contains a medium-term (3-12 months) "authority signing key", that is used by the authority to sign other directory information. (Note that the authority identity key is distinct from the router identity key that the authority uses in its role as an ordinary router.) Routers periodically upload signed "routers descriptors" to the directory authorities describing their keys, capabilities, and other information. Routers may also upload signed "extra info documents" containing information that is not required for the Tor protocol. Directory authorities serve router descriptors indexed by router identity, or by hash of the descriptor. Routers may act as directory caches to reduce load on the directory authorities. They announce this in their descriptors. Periodically, each directory authority generates a view of the current descriptors and status for known routers. They send a signed summary of this view (a "status vote") to the other authorities. The authorities compute the result of this vote, and sign a "consensus status" document containing the result of the vote. Directory caches download, cache, and re-serve consensus documents. Clients, directory caches, and directory authorities all use consensus documents to find out when their list of routers is out-of-date. (Directory authorities also use vote statuses.) If it is, they download any missing router descriptors. Clients download missing descriptors from caches; caches and authorities download from authorities. Descripto
评论
    相关推荐
    • NS2example.rar
      在ns2下实现无线传感器网络仿真,多个节点进行网络活动
    • IPMessage.zip
      局域网内聊天和文件传送工具飞鸽传书 传送文件时可以选择一个目录,速度非常快
    • some-ns2-trace-awk.rar
      ns2中的trace分析脚本,用于网络仿真,吞吐量,延时,抖动率的分析
    • WiMAX_Protocol_Code.rar
      This documentation is based on the following versions:- pre-release of the wimax model developed by NIST (file patch-wimax-prerelease-092206)- ns-2.29 此程序是NS2下用C、C++编写的,主要对Wimax 802.16d和802.16e的MAC层协议的仿真,压缩文件内部有详细的说明。 由于NS2运行在Linux下而且是对网络的模拟,因此把它归在Linux/网络类中
    • linux-socket-program.rar
      全套Socket简单编程实例,很适合于初学网络编程者!
    • WSN-node-location-demo2.rar
      无线传感器网络模拟整个流程演示视频demo
    • ns-cbrp.tar.gz
      CBRP协议(移动adhoc中基于分簇的路由协议)ns2下的源码
    • sscom32.rar
      这是一个串口调试功能的工具,可以回显烧入的驱动程序
    • rtsp.rar
      linux\UNIX下跑的一套服务端程序,支持RTSP、RTCP、RTP等各种协议,对做音视频传输挺有参考意义