Cypherpunks Eternity Service Data-haven
---[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 12 of 17 -------------------------[ The Eternity Service --------[ Adam Back <> Information wants to be Free ====================================================================== Information wants to be free. Censorship sucks. Having your account yanked because some censorious idiot doesn't like you discussing hacking tips and tricks in USENET sucks. Being tortured to death by some totalitarian country's military police for speaking the truth about government corruption sucks even more. Have friends who have been hounded by the Feds, SPA software police, or system admins who believe in security by obscurity? Had nasty threats made by censorious system admins for helpfully drawing their attention to flaws in their systems security? Ever had a control freak try to get your web pages censored because they don't like its content, or simply because they get their kicks harassing people? Ever wanted to publish something on the 'Net but felt intimidated by censors? Do you consider that free speech is your right as guaranteed by the first amendment of the US constitution, and do you therefore also consider it your right to speak anonymously? There are lots of reasons to protect the ability to speak anonymously. Anonymous speech is required for truly free speech. Strongly anonymous free speech is the freest speech of all. If you're going to preserve your ability to speak anonymously, and protect your right to free speech you might as well do it properly... Want to do something to help free speech? Want to piss off the 'Net censors? Want to piss off censorious Governments? Read on... What is the Eternity Service? ====================================================================== The Eternity Service is a distributed data-haven, it takes a different approach to ensuring unpopular content can be published. Traditionally unpopular content has been surreptitiously exchanged via DCCs in IRC, or PGP encrypted email, or FSP, or in funny named directories via FTP or via agreed file names in incoming directories set drwx-wx-wx. Other kinds of unpopular content have been published on web pages for a short time until the censor gets to work and threatens the ISP, the publisher's employee, and the publisher with law suits. Sometimes these web pages get mirrored, if there is someone interested, and spoiling for a fight, or if the content is only censored by force of law in one jurisdiction. The Eternity Service deals with censorship more directly: it confronts the problem in a more general way with the aim that anyone should be able to publish anything anonymously in a convenient persistent, uncensorable data-haven. So in a nut-shell that is the design goal of the eternity service, to allow anyone to publish material which others would like to censor. For convenience the publishing medium addressed is the World Wide Web. Systems for publishing anonymously in USENET news and email already exist: cypherpunks type I and type II (mixmaster) remailers. Why the name `Eternity Service'? ====================================================================== There is a cryptographic paper by Ross Anderson called "The Eternity Service", which is where the idea for this implementation came from. I rather liked Ross's name for his conceptual service, and instead of thinking up some other name I just "borrowed" his name. Readers might find his paper interesting, it's on the web in htmlized form at: Ross's design is quite ambitious, so I simplified his design in developing the software included with this article. My implementation shares Ross's main design goal, which is to create a censorship-proof, long-term document store, but its design has been made much simpler and less ambitious initially to make it easier to implement. The main simplification is that I built the design on top of an existing hard-to-censor distributed distribution channel: `alt' USENET newsgroups. This design is described in the next sections. The motivation for providing a simplified version was to have something people could use practically, today. Another reason is that by releasing this design, and it's implementation, it allows you, the reader, to play with it, and to contribute to it, improve it in a piecewise fashion in the good tradition of free software on the 'Net. The design calls for many eternity servers to be in existence to make it hard to censor. At time of writing a mailing list exists for discussion on using and improving the eternity service. Instructions on how to subscribe the eternity mailing list are given at the bottom of this article. USENET and distributed systems ====================================================================== The Internet was built to survive nuclear attack. It would survive such an attack because it is a distributed system. Distributed systems are hard to break, and therefore, hard to censor. USENET, particularly the `alt` newsgroups offer the most amazing chaotic discussion areas. The articles which are posted often contain materials which would be considered illegal in many jurisdictions. And yet USENET lives, and `alt` USENET newsgroups thrive. Extremely well funded attackers have tried to remove individual `alt` USENET groups, and to censor posts in alt USENET groups. They have all failed. The reason that USENET is hard to attack is because it is a distributed system. The network of news feeds has some redundancy. USENET articles enter the news distribution network from anywhere in the network. If a censor in one country succeeds in persuading a news site to censor its feed and not carry particular alt groups, it doesn't affect the overall system that much. There are lots of other nodes carrying the groups, disgruntled users will switch ISPs, and disgruntled down-feed sites will switch feeds. The system routes *around* censorship. There are just so many USENET admins with individual opinions, and commercial interests in carrying groups users want to read, that USENET can not die. It occurred to me in trying to design a simplified eternity service, that it would be useful to borrow some of Usenet's indestructible nature. USENET is part of the landscape; it's here to stay. If we build a new distributed distribution system from scratch, to start with there won't be many nodes. The censor will have any easy time censoring a few nodes, he'll just go and harass each of them in turn. With USENET on the other hand, it has been around for so long, and is carried at so many sites that it would be a huge task for a censor to even have a significant affect on USENET. So, the design of my eternity server aims to allow operators to point the finger at USENET and say: "that's where the content is coming from, if you want to censor anything go attack USENET". My eternity server design is a service designed to blur the differences between USENET news and the Web. It provides an interface which makes a stream of encrypted USENET news articles look like WWW pages with a persistent URL. As the default disclaimer for eternity servers says: Note to censors: Eternity servers are specialized search engines for reading web documents from USENET news. The pages you request are actually USENET news posts which the server is searching for, reformatting and forwarding to you. The administrator of this server has no control over the content of USENET news, and will not be held responsible for any documents you instruct this server to forward for you. Eternity Server design ====================================================================== Once you accept the idea that it would be nice to borrow, or build upon some of USENET news's strength as a uncensorable distribution mechanism, the next issue is achieving this, technically. The main differences between USENET news articles and WWW pages is that USENET is transient, the articles expire in newsgroups, and that USENET articles have no persistent globally addressable locator. USENET is not as convenient as the Web; there are no hypertext links between articles, and there are no inline images. Eternity service articles are WWW pages specially formatted and posted to USENET news. The eternity server reads news and translates Web page requests into GROUP and ARTICLE commands to an NNTP news server (or file system accesses to a local news spool). (The default list of newsgroups to read consists of one group: alt.anonymous.messages). Web pages are often updated, as one of the interesting aspects of the WWW as a publishing medium is that it allows people to maintain up-to-date information. This maintains interest and keeps people coming back to an interesting site to see what else the author has collected, or what other related pages have been added. A sense of community can be built up with others submitting interesting links, corrections, and tips to the author. To provide the possibility of updating web pages with the eternity server, the eternity formatting convention allows submitted web pages to be signed with PGP. This ensures that no one else can replace your pages with other pages. Being able to replace your page with a blank page would allow a censor to temporarily censor you. (Only temporary because you could always replace the blank page with the real document again). With a PGP signature this is prevented... and the system becomes such that eternity virtual domains are very much first-come first-served. First-come first-served naming ====================================================================== Eternity URLs are all under the non-existent Top Level Domain (TLD) "eternity". (Other TLDs being .com, .org, .edu, .ai, etc) Eternity URLs are therefore of the form: http://*eternity/* Where * represents any string of characters. On the Internet domain names must be resolved to IP addresses via Domain Name Servers (DNS). The owner of the TLD you desire a domain name in charges you for registering a domain. Internic (who currently has a hotly contested monopoly on TLDs .com, .org, and .net), charge $100 for the first 2 years, and $50 for each year thereafter. Eternity domains don't exist in this sense. There is no root domain server for eternity. You don't need to buy eternity URLs from anyone. Nobody _can_ own an eternity URL in the normal sense. The first person to submit a document with a URL: http://bluebox.eternity/ gets it. If that person signed the submitted document with PGP, no one will be able to take over that URL. If that person signed the submitted page with PGP and threw away the key, it would be uncensorable for all time. They couldn't even remove the document themselves if they wanted to. Throwing away the key might be a good idea if the publisher isn't publishing anonymously and expects reprisals. The fact that one user has submitted a signed web page for http://bluebox.eternity/ doesn't stop BlackBeard from putting up his design at: http://bluebox.eternity/blackbeard/ That is to say ownership of any given URL, even the top level URL of a virtual domain, doesn't give any control over who could submit documents in that virtual domain. Of course you don't have to link to their pages. But those pages will show in a directory search of your virtual site. Directory searches ====================================================================== Submitted eternity news articles can set options controlling whether or not the document is listed in the index. The choice is either "exdirectory" (the default) or "directory". This is useful because if you created the URL for http://bluebox.eternity/, you might like to include some inline images, or diagrams, or a series of other pages hypertext linked from that page. So you would set option "directory" for the main page http://bluebox.eternity/, and set all the inline images and smaller pages linked from it to "exdirectory", as a convention to save the directory becoming cluttered up with junk. You can also use "exdirectory" if you don't want to generally advertise your page. Note this is not all that secure if you access your page via a public access eternity server, as the server operator could modify the server to record all exdirectory URLs. You can request a listing of all eternity pages at an eternity server by filling in the form with virtual URL containing a wild-card: http://* (Exdirectory documents will not be listed.) You can also include an option to give a small description (a maximum of 60 characters) which will be listed beside your virtual URL when someone does such a search. You can narrow the search to just list all root eternity documents with: http://*/ Which will find: http://eternity/ http://bluebox.eternity/ but not: http://test.eternity/example1/ You can also do: http://bluebox.eternity/* which will find: http://bluebox.eternity/ http://bluebox.eternity/blackbeard/ You can combine *s to find what you want. Advanced searches are possible: http://*box*.eternity/*blue* and so on. Eternity materials are likely to be targets for censors, and it is possible that they might try to censor the directory listing itself. Even the URL could suffer. (Did you know that Internic turned down some guy who wanted to register `'?) I'm sure someone creative could up with something to upset a censor in the 60 characters allocated for URL descriptions too. For these reasons the eternity server operator has the option to disable directory service. With this option disabled looking up URLs with wild-cards (*s) in them will get back a notice explaining that directory listings service has not been turned on at this server. Servers with directory service turned off make less useful servers, so it is hoped that most eternity server operators don't have to do this. However, an eternity server with directory service turned off still works normally for accessing known URLs, and you could maintain the directory listing yourself, or use a directory listing at another site. Formatting Eternity documents ====================================================================== Eternity documents submitted as USENET news articles are formatted with PGP. There are three of reasons to format messages in USENET to make them not immediately readable. 1) It prevents censors from working out which articles correspond to which eternity web pages. Depending on the options chosen this can degrade to just obfuscation. Obfuscation alone however can be useful as censors are often not particularly clue-full. 2) PGP includes compression, so the articles are much smaller. 3) If used with highest security options amongst a group of people who follow security guidelines it means that a censor will have no way to translate the articles back into WWW pages, or even of obtaining the URL. To demonstrate the formatting requirements for eternity page submissions, we'll work with an example page, http://bluebox.eternity/. You'll need an implementation of SHA1 for this. There is a C implementation, and also a perl implementation in the eternity server distribution. Some systems may already have /usr/local/bin/sha1. (Note: below "echo -n" is used -- on Suns the built-in echo doesn't handle the -n flag properly -- you'll have to use /usr/ucb/echo instead) 0) Generate a Nom de Plume If you are planning to sign your document, you probably won't want to sign it with your normal key, so you'll generate a new keypair for the purpose, this will be your pseudonym, or Nom de Plume for the purposes of publishing this document. The "-u fred" tells pgp to use that user id. See pgp documentation for how to generate keys (use pgp -kg). Once you've generated your key, extract it to a file with: % pgp -kxa fred fred where `fred` is your new user name. It will save the key as "fred.asc". We'll use this file below. 1) Sign the document We create a normal web page such as you might put on your home page. You can view the page with Netscape (or other browser) by opening it as a file URL: file:/home/fred/bluebox/index.html to check that it looks OK, and that any inline images line up correctly etc. You can use relative, site relative, and absolute URLs normally in eternity documents. You can also use absolute URLs pointing at other sites in the normal way. To submit index.html as http://bluebox.eternity/ we first use PGP to ASCII armor the document. If we want to sign it at the same time as ASCII armoring it, so that we can update it later, we can do: % pgp -sa index.html -u fred There is another option to encrypt as well as sign and armor, which will be discussed more below, to do this do: % pgp -csa index.html -u fred If we don't want to sign it, we do this instead: % pgp -a index.html In either case after this operation PGP will create file "index.asc" for us. Rename index.asc to something else, say "index" (Another legal combination would be to encrypt and not sign with -ca). 2) Set the options If you signed the document, you need to include the key. Insert the keyfile (fred.asc extracted in step 0 above) into the document "index". Order is not significant. Then the ASCII armored document (pgp munged html or gif file produced in stage 1), the keyfile "fred.asc", and the flags described below can be jumbled up in order. You now have several flags you can include to control how your URL will be cached, how it will be displayed in indexes etc. The flags are: URL: http://bluebox.eternity/ The flag URL: sets what the eternity virtual URL will be. It must have .eternity as the virtual TLD. Cache: yes Cache: encrypted Cache: no Cache settings, choose one of those. These cache settings override the used eternity server's settings if doing so will increase security. "yes" and "no" are obvious. "encrypted" means that the document will be cached but it will be encrypted in the cache in such a way that the URL is required to decrypt it. If the document is exdirectory this means that the server won't know the URL. Options: directory Options: exdirectory Choose one of those options. This flag controls whether the URL will be listed in the URL index. "directory" means it will be listed, "exdirectory" means it will not be listed. If you give neither option the document defaults to exdirectory. Description: Freds blue box page This is the description that will appear in directory listings. If the document is exdirectory there is no point giving a description. So the file "index" is likely to look something like this once you've finished editing it: URL: http://bluebox.eternity/ Cache: yes Options: directory Description: Freds blue box page -----BEGIN PGP PUBLIC KEY----- ... -----END PGP PUBLIC KEY----- -----BEGIN PGP MESSAGE----- ... -----BEGIN PGP MESSAGE----- Where ... indicates the rest of the ASCII armored key or message will be displayed. Some of these parts can be omitted as shown above. When you are submitting an web page update you can omit anything you're not trying to change. (That can be everything, so your updated document has nothing but the new message part). However this is not necessarily a good idea because it will not make sense to an eternity server that has not seen the first document, for example if your first document doesn't make it via USENET to one site. 3) Package the document "index" ready for posting You have a couple of choices here. Method A (most common): Either you can encrypt with PGP -c: % pgp -c -z"eternity" index Method B: Or you can encrypt with the SHA1 of the URL with 1 prefixed, % echo -n 1http://bluebox.eternity/ | sha1 dab1a32aba30b4e3a9594da143c33d2ba9b00a38 % pgp -c -z"dab1a32aba30b4e3a9594da143c33d2ba9b00a38" index Most normal eternity URLs which you're expecting to be indexed on the directory services of public access eternity servers should be encrypted with the first simpler method. There's not that much point encrypting with the second method unless your document is going to be exdirectory, because once the document gets in the URL everyone will know the URL anyway. It might take a censor a little longer to figure out. If you were planning to only access the document via private, or local eternity servers, you can reveal the URL only to those you wish to have access. However this might not be that secure because people may be able to guess your URL if it is something common as above. Method C: For this reason you have a third option, which is to encrypt at the same time as signing and ASCII armoring as described in step 1. You can combine that option with above method B (pgp -c with sha1 of 1<URL>) to conceal the URL. Or alternately you can expose the URL by using method 1 above (pgp -c -z"eternity"), but have the document encrypted in step 1. (This would allow you to have a directory entry, but the page not accessible without knowing the password chosen in step 1 when encrypting. The result of the last pgp -c operation for any of method A, B, or C will be file "index.asc". 4) Post the article anonymously The subject field of the article should always be the SHA1 hash of the URL: % echo -n http://bluebox.eternity/ | sha1 2e730bcd62dbc63aaedde56c06625abeeb38dd92 Now post the article to USENET news (by default eternity servers read only newsgroup alt.anonymous.messages with release 0.10). You can test your eternity submissions work by installing an eternity server on localhost. If you get stuck you could ask for assistance on the eternity mailing list (instructions on subscribing are at the bottom of this article). To post anonymously you'll need to post via anonymous remailers. Some remailers can post to USENET directly, for other remailers you have to post via a mail2news gateway. Instructions on using remailers, and windows and Unix clients to automate the process of using remailers can be found here: You can find a list of mail2news gateways here: People are already working on a nice easy to use CGI interface to eternity servers over on the eternity list while I'm typing, so perhaps when you read this you won't need to know the above information in such detail. Caching ====================================================================== With WWW technology, caching is often used to speed up accesses. There are a number of caches in effect with a typical web browsing session. The Netscape browser for instance has both a memory cache, and a disk cache, which are configurable in size. In addition Netscape can be set up to use a proxy cache, which is a special caching service. Users of a proxy cache send their web requests through it. The proxy cache checks each request to see if it has it in the cache, if it does, it can deliver it back if quickly. If it doesn't it will go and fetch whatever URL you are asking for and remember it for next time. A proxy cache would normally be used by a group of web users, perhaps a university campus, or an ISPs customers, or a companies employees. Caches traditionally have some protection from censors -- it's an automated process after all -- your average ISP hardly wants to be responsible for the contents of the disk on its proxy cache machine. For performance reasons the eternity server also has a cache. The cache behavior is configurable. The server operator can set his caching preferences when he installs the server by editing eternity.conf. Possible settings are "on", "off" and "encrypted". Setting cache to "off" is safest, then you have no eternity documents on your disk. The "encrypted" cache option means that cached documents are encrypted with PGP -c and the SHA1 hash of a 1 prepended to the URL. If the server also turns off directory service, and does no logging this provides reasonable deniability of knowledge of contents of documents in the cache. Even with directory service on, it provides cache set to "encrypted" provides protection in that the server operator will not know the URLs of exdirectory web pages. Further work ====================================================================== There are a few unimplemented features that could use some work. These features are being discussed on the eternity mailing list (see instructions for subscribing below). A first immediate problem is that the eternity server has no cache replacement policy. Your eternity cache will just keep growing. This is great for ensuring articles with caching turned on don't disappear due to expiring in the news spool, but as eternity grows more popular it will become impossible for each single eternity server to hold the full document store. The solution to this problem is quite complex, and is the subject of the next implementation effort on the mailing list. One interim solution is to use the USENET searching facilities of services which archive USENET such as and There are several tweaks that would have to be done to be able to use USENET archivers as sources of eternity documents. Two main problems have to be combated: 1) the archives make attempts not to archive 7-bit encoded binaries to save space, 2) you can't search by 40 character hex numbers to find subject fields. These are both easy to overcome, but the overall solution is not that attractive because the archivers will be a single point of failure. Censors will attack them, and they may be hostile to eternity servers due to our bypassing their 7-bit encoding filters and consuming space on their soon to be multiple TB raid file servers. A better solution is to build a distributed data store that allows eternity servers to exchange documents with each other in such a way that the eternity servers together form a virtual raid file-server where the documents are spread randomly and redundantly over the nodes. A simple starting point to allow this is to create a second long-term cache area, and to have a cache replacement policy for that area which selects a random document for discarding. This cache replacement policy will ensure that statistically some servers will have a given document. Next we have to design a scalable method of forwarding requests to other servers to ask for old USENET articles by URL hash (subject field). World-FS ====================================================================== Another approach to improving the eternity server is to actually use and develop the full set of techniques described in Ross Anderson's paper to build a distributed file system (DFS). I dub this direction `world-FS' because the aim is to build a worldwide distributed, redundant, uncensorable, and virtual file system. This file system would be designed to withstand a nuclear war, and to easily withstand the best efforts of one government to censor material in it. A world-FS done well could easily replace the current pattern of web page hosting. The world-FS would have different interfaces, or drivers, to allow it to be accessed as an NFS file system, or as a distributed web based eternity service. The eternity server described in this document would then be superseded, and become the HTTP driver interface for world-FS. An FTP, or NNTP (USENET news) interface could also be built for the world-FS, or for parts of it's directory tree. People discussing this so far have thought that you would need to include ability to pay for service with an anonymous payment system (or with multiple payment systems). The eternity mailing list is also for discussion of world-FS, as it all falls under the umbrella of Ross Anderson's concept of an `eternity service'. Comments and collaboration requested ====================================================================== Your contribution matters. Progress of the eternity service beyond this point relies on a collaborative effort. You can collaborate by doing any of the following and reporting back to the eternity mailing list how you got on (subscription instructions below): - submitting documents to the eternity document store - installing an public access eternity server in your account - or persuading your ISP to install one - or installing a private eternity server in your account - finding and reporting bugs to the mailing list - contributing code - contributing ideas for more efficient distributed request protocols Adam Back More information ====================================================================== Eternity mailing list send message "subscribe eternity" to The eternity mailing list is for eternity service users, eternity server operators, and eternity server developers to discuss issues to do with eternity. Issues include censorship attempts, operator liability, practical attacks on the security, and discussion of new protocols, and discussion amongst developers and users on the best way to design the next versions. Cypherpunks mailing list Cypherpunks write code. Cypherpunks are the people who bought you type I and type II remailers, remailer clients, plus many, many other crypto applications. Governments are scared of the implications of distributed systems and freedom to use cryptographic code. Cypherpunks are crypto-anarchists, and they shall inherit the earth. Information is power, and cypherpunks are applied cryptographers with attitude. They don't care if governments don't like their code, in fact they probably view it as a compliment. You'd be surprised at how many cryptographers, net journalists, cryptographic consultants, small ISP owners, and Netizens are crypto-anarchists at heart. Netizens never were very keen on government intrusions into the 'Net. Read Tim May's Cyphernomicon for a mega-faq on cypherpunks, and crypto-anarchy. See: To subscribe to cypherpunks: send message "subscribe cypherpunks" to or send message "subscribe cypherpunks" to or send message "subscribe cypherpunks" to (Some time ago there was an attempt to impose moderation on the cypherpunks list, and this is the reason for this rather curious situation of multiple mailing lists, it is designed to be more resilient to censorship -- if someone pulls the plug on one list -- the rest continue without glitch.) Cypherpunks is a high volume mailing list. There is no moderator, Software Please set a server up a public access eternity serve in your account. You can also operate your own eternity server for your own use -- this is the more secure way to browse eternity. If you have any kind of dial up or internet connected Unix system you can do this. You'll need a web account with cgi capability, access to perl5, and read access to an NNTP news server, or a local news spool. Cron access is useful but not essential. Current Public Access Eternity Servers Contacting the author or or PGP encrypted mail preferred, here's my key: Type Bits/KeyID Date User ID pub 2048/28B24551 1995/09/09 Adam Back <> (High Security) Key fingerprint = 01 8F 04 06 5C DD F3 33 D8 84 C4 63 85 BA 50 E8 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzBRMbMAAAEIANoe/ABNaJv6/ETtDzlih4P3znc63CMP4ViFWStxyeWWjxd2 L8WOsM0b1naV4YmeRrd34GUsnZFetItToVqsvT5tKcwJKHwEWeXEQMbCM3cbaAxB +MGSx9PoLRc4ZLz79q/hMQXybNKmw5Rk7NwsyLiejZR+jt2Eoy/BHeFMunxfXD8j 38927FZBxG3UgCbL75ImJhWVsn8IoDOJ5psTfJwRcAZlkxsrpDSx2OIb6G35+pwm mEv8O066wOij7eMTQ8VQ5+rbn2ql0Ubsz3qA2szP2KZYlmobjwj5M82dmLcPfG9C bExMBldd8poJyBCn0e04kAFiGBJJPnvKqCiyRVEABRG0LEFkYW0gQmFjayA8YWJh QGRjcy5leC5hYy51az4gKEhpZ2ggU2VjdXJpdHkpiQCVAgUQMli+7B98EdWB2LS9 AQFF0gQAjiAOPPCs7s0VCHoFI2IWMEcAeQInmnl2p+6rpsvIxjX1v3wBqqstgBu5 aCLY9Uns+iKjzcnt5DTj6NPhJ8EOlefwgHUssiBLTsw7tOvT9fQwcIXOE5ikGP7j RObTq3a2Vtz4/O/YgN0KQnWcqTDuadeP17cJ2bbaWJpZiGDyWGSJAJUDBRAyIN+r RlGJMStI9vUBAXJTA/4wzbGnP9X0luqRYcfj51bamX9WdTDG9A8AvKngTbMG87x2 jV6vUicIP9XMERSl6fgT35Q2BYSCKGlhH5gGYkC+IfkyMZFHvZMdATurb4MuRivW pv30gTVstoF61CN3JKF1N/j1Ez2LOfFWFW+miceowAPrKr3e3zHCRXyewv75BIkB FQMFEDBW0M+xVzBJFqEkZQEBBQEH/AnpNhKJh1IPmii7X7xxmccMKFnq5R2DAP4Z +OJQ/otoy6AXifI9Y5aDYnm7sbPZX9uBk93ubf4Zm/v9wOcOKL6hXcE4+tvGSQA+ rAPgph1+t96iDTSTGwf5ZKVp+LfJXBz63wZHDJ+JlSTDRl9YeSxeRZgAo2XJtI/h v7fazds4CK0jFwDSWUtQUd7my9znsJ92W0UONe6iltnFUvywUICNGyXxCHV4RDPv /wTmDKarzHm44OfdzXhI+oTQvY3lG51gU6TMjR6Q/bjy9YEYpTcDRvOpMmkJ4aud tCxG/w82OG6lKnFw8Hv46VcpQVPt2YZMbgjUJBIQi6FedDjeky6JAJUDBRAwUUqY Kci4nVVqSmcBAaFJA/wJ0vcYZm8V7gqlk+nDzjIDvGNP1IaQtBFaXE/imyQaqyKe oIsyzhCWCNnsCvu8Cq2ZwmD63wBKzs+63ZgzJ7h1hC4lYKUB1mCsF0UnrZNJ7rtW DVMa0aLlvxIia7qsmbhaZ6ibs5+juqn3CKUvjCJKyOpuS0Lmrem5EXk9Byu5/IkB FQMFEDBRSjc+e8qoKLJFUQEBWjEH/3yb3JYhsjoqZdEjA1xSZJcjyoTnPG0vUhaD oi6OhTByqYShLe14RU9rYDzpOGmdwpZ6GSwF4X0uBAH1lCGnsi6QQXrnsp1fBq/6 +TQy1nBs2FZyj/YTXQIKhhXIH700ed0Nqg4okwtovyUqX0xbqlA2Sv1N+XC6hKuc bl9XWOQbKi8OM8VEKeLnrY9Glzrxk9piVb+eCT1RJnLovWdfPL7WFOwSbOQ/I9aB jBKBHYMGdLihf7PYeb3Eg3B8Kt3IDfipPUFfXjqes94hpqQl/DGpWSpDHHFQ5cTB iQIB4twFzz4bI1HMVEayKboPliJl3dI9vY0SQJ58b6OFYJTB4Jc= =E4rO -----END PGP PUBLIC KEY BLOCK----- Here are SHA1 hashes of the eternity service distribution <++> hashes.asc -----BEGIN PGP SIGNED MESSAGE----- eb32d19e992e4663df29141cedf6ec0aa3f92af3 pgp/config.txt 7b1da1bd199b2dded10216a3d19e4b05bbb66c90 eternity.conf a44cec86d7d0f1cf1239f1c00bb21dc3476148b4 1f9f7860c8c2d5b376c8bffa7417ffe54b8b1429 newsgroups 926a9630fd214b756ecc18658d813017b288bf2c sha1/sha1.c 58989aa6f40b06136d078a96ad958b482756fe8f sha1/endian.c 2d46e74b805ee06d3960ff756a09407f0b3267fa sha1/sha1.h 21e7e596a715c6ed247f9444393df675d7447f23 sha1/endian.h 5f9c194f542960c8e7f9f6d81f84cd3b62dd4032 sha1/sha1file.c 4544f194e381a3b64150f3761900993d28c5f465 sha1/sha1test.c ea58eec253cdb4af6d3958d94cebfbe39988da44 sha1/timer.c 22a60ac9aa0242ad6ee00da8781500c5c1311837 sha1/timer.h 67d37d81d0064c2a0a1a369cba2cfc2f9d878803 sha1/types.h f7691ef67ac7a111082c6730b045ea2dc00dd903 sha1/compiling 01a7b85827ff35583bd11cecb7470c4917fdd0ea sha1/README efc53ecc93eb1105341f4e250ecf654a44a11394 sha1/Makefile 5375b154bd0724dc0c6ee6fac59bbc5c93a6a209 adam-key.asc 0b9849c2332e5d7aa7714adc67861465d99b34db mime.types b50a661ba69747c8969ebfb9c997eaf0f1b75893 README d498a12d0a795d3ae22bc059631293b0a0ab4cd1 ANNOUNCE ba8ccee1f86dc5872b5ce95c0e2e494924b927f8 configure 6f9bcf72be9f836f5201bc430cc764828fda68ba news/alt/anonymous/messages/1 ac26faf5df1e14eaefa6e0e05f5be2d2f1ee67db news/alt/anonymous/messages/2 75ead2fb83bf3fa2c701b70741097f4956fb9043 news/alt/anonymous/messages/3 4c892147c69fcfb60803587c5606427d1641d473 ecat fa3b13f3e8241936795d97f72fe647f0a4a26902 CHANGELOG 31cc2c663972f536922f3603625804a42b40c367 UTILS 08120e964cb8b61f2c95ac155a3f75ce8b27535b dcrypt 0fded38fd70c8626551e7bb21657cd960c2b8f67 sitegrab.dist 7121ab8cd3e54bc962524054c95316b28d8c76e4 dev/submit 56a1cb622bf8df7f863e8449a97ef8746a0d2469 dev/submit.html f1b6720b0861b1d79fbedcfa4cc694b1172c81a1 SITEGRAB 428d389aa228d9e96c678d4400179df1ab5db0a3 fred.asc 3ed6458862762fa993a900ec1b5dc8e2c739f61c eternity.gif 5ea784f32dc51d74ae98134adcd93126230d5a0f rsa.gif 2c62082f57ca8c0019f741d04f5f14133976bb15 cypherpunks.gif 3d7f09b91b04577dc4406eb9493753dc1e3ba7d2 datahaven.gif 8016173f3db9fccd0b787c9682e7b7bec1ada3b8 index.html.dist 108e0ef9d29387e3cf57b68614a4e8b2961c2d02 disclaimer.html 7ca4684965a7b4d51ad032f85c20480f0cd175fe eternity.cgi.dist 08b072350488abc3ac6337ce95d7cf881e1f547b directory.html.dist 769d9620c85de07a3ce6703a39b56eafdd3cad9d host.html 24f17a65a4a637d60c5cbaab485eda231adb62c6 dbmcat.dist 584d76031069f89fef3288cdbb6bed6e89ec7fd6 ecrypt.dist 122584c63267811628cc790ef898e9d651cdc728 LIST -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBM/L+RT57yqgoskVRAQHpdAgAjbGfqr4FaycrS/LOHq4TnAQIBoTYx+6k cG9DTnUMp/gQSXqwBzvSv1bmou/+nwvH/qC5UgXc7Ko98rT8+tAatfrZj3u1g36M a63oWtonLFJowOO8w1jBiPSpl44kT25hPYZ2qUscVC1qGzbSmutHhDyToY4y4i7L v2TARR4Jq3dJI67WT63dxr1/o+AnTtNZBTq5c9z5LzfQWVfP9HRaOgYXF6d4LrVZ 7NF3YKImEe5914L45CUW+OjJcsabGufFVj4waR0kNhdmA7ZQT3cxkg5Ygv6jhtcn q7Ys67hMAYU0TGrxvyogEy23FyzXC5wi1JY2NBYnE+AuJXObDGB85w== =Xfz4 -----END PGP SIGNATURE----- <--> [The source code for the server can be found here] ----[ EOF
Comments, html bugs to me (Adam Back) at <>