July 2018 - cypherpunks-legacy

how to encrypt and integrity-check with only one key
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

Folks: I had an idea about how to use a single key to accomplish both encryption and integrity checking on an immutable file. I posted it to the tahoe-dev list [1], and David-Sarah Hopwood followed up with an interesting new crypto cap design [2]. Here is the basic crypto trick, which may be useful in other contexts than Tahoe-LAFS. Suppose you have some data and you want to control who gets to see it, and you also want anyone who sees it to be able to verify its integrity. So far, these requirements are familiar to cryptographers. The obvious answer is to encrypt the data and then to MAC (Message Authentication Code) the ciphertext. There would be one key for the encryption and one key for the MAC. However, this has the wrong semantics for our purposes -- anyone who is given the ability to check the integrity (by being given the MAC key) is also given the ability to create new texts which would verify. Likewise, whoever creates the initial MAC tag can also create other MAC tags which would cause others files to also verify. Instead, we want a single file that can pass the integrity check, and nobody -- not a reader who is able to verify integrity nor even the writer who initially created the file -- is able to make a different file which would also pass the integrity check. Therefore, we want the integrity check value to be the secure hash of the file itself. That's what we currently have in Tahoe-LAFS. The immutable file read cap is a concatenation of two values: the decryption key and the secure hash. The latter is solely for integrity-checking. Actually in Tahoe-LAFS, the integrity check value is not just a flat hash of the plaintext, but instead it is the hash of the roots of a pair of Merkle Trees, one for verifying the correctness of the shares and the other for verifying the correctness of the ciphertext (see [3]). Now, convergent encryption could do both jobs with one value! If you let the symmetric key be the secure hash of the plaintext, then the reader could use the symmetric key to decrypt, then verify that the key was the hash of the plaintext. However, you can't always use convergent encryption. Not only because of the security issues [4], and not only because it requires two passes over the file which prevents "on-line" processing, but also because you might need to generate the symmetric key and/or the integrity check value in a different way. For example, the Tahoe-LAFS integrity-check value isn't just a secure hash of the plaintext. It would be inefficient to generate the full Tahoe-LAFS integrity check value before beginning to encrypt, and we want to be able to give someone the integrity check value (in a verify cap) without thus giving them the decryption key (i.e. the read cap). So here is my idea to use a single value to accomplish both decryption and integrity checking even when you can't set the symmetric key to be the secure hash of the plaintext. You use the encryption key K1 to encrypt the plaintext to produce the ciphertext, and in the same pass you compute the integrity-check value V. Then you compute the secure hash of the combination of K1 and V, let's call the result R = H(K1, V). Then you encrypt K1 using R and store the encrypted K1_enc with the ciphertext. Now R is the real key -- the read cap. If someone gives you R, the ciphertext, and the encrypted K1_enc, then you first use R to decrypt K1, check that R = H (K1, V), then perform the decryption and integrity-checking of the ciphertext. Here is a diagram: [5] (also attached). David-Sarah Hopwood suggested the improvement that the integrity- check value "V" could be computed as an integrity check (i.e. a secure hash) on the K1_enc in addition to the file contents. Regards, Zooko [1] http://allmydata.org/pipermail/tahoe-dev/2009-September/002796.html [2] http://allmydata.org/pipermail/tahoe-dev/2009-September/002848.html [3] http://allmydata.org/~zooko/lafs.pdf [4] http://hacktahoe.org/drew_perttula.html [5] http://zooko.com/imm-short-readcap-simple-drawing.svg ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] OTR and deniability
by Ian Goldberg 06 Jul '18

06 Jul '18

[I'm not usually on this list, but was pointed to this thread. Warning that we now have two "iang"s on here. ;-) ] This is a common confusion about OTR. OTR aims to provide the same deniability as plaintext, while also providing the same authentication as, say, PGP. You want assurance that the other person is who he says he is, but at the same time, you don't want digital signatures on all of your messages which can be used by a third party (or even the person you were speaking to) later to prove what you said. You can't achieve *more* deniability than plaintext, of course. Just as plaintext chat logs might be trusted because you believe the chain-of-custody, so might OTR logs be. (If the OTR logs are the ciphertexts, of course, you'd also need to log the keys to get anything useful out, but even then, the point is that you could have used the toolkit to modify individual messages, or even forge the whole transcript.) In this case, of course, the plaintexts were logged, so OTR's properties don't even come into it. Here, anyone could simply edit the text file containing the logs. - Ian (the other "iang") _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[righter] Response to Suicide Bombings
by Sarah Thompson 06 Jul '18

06 Jul '18

The following was originally sent to the Utah Gun Owners Alliance email list. Utah Gun Owners Alliance joins with all Utahns and all Americans in mourning the terrible tragedies that occurred yesterday. Our thoughts and prayers go out to the dead, the injured, and their families - and to our elected leaders who will be making some difficult decisions in the days and months ahead. While we feel obligated to point out that much of the carnage could have been prevented by armed citizens, law enforcement officers, or sky marshals, we also believe that there are no simplistic solutions to terrorism. Remember that ordinary ammunition is considered hazardous on an airplane because it will penetrate the hull and lead to depressurization. And firing a gun in an extremely cramped and crowded plane also risks injury to innocent passengers. More relevant is the fact that Americans have been indoctrinated to be good victims. We're told over and over again that we should never resist criminals, that we should passively submit to being robbed, raped, mugged, or hijacked. Women's centers teach women not to fight back, even though fighting back with a firearm is the most effective way to avoid injury. Employers require their employees to be disarmed, and to agree to whatever a criminal demands. Those of us who are willing to take responsibility for our own safety are shunned, persecuted, and generally made to feel like second class citizens who are not welcome in "civilized society". The reason that a few hijackers armed only with knives and box cutters were able to murder tens of thousands of innocent people is less a problem of physically disarmed passengers, and more a problem of psychologically disarmed passengers. Had the passengers been taught that fighting back is the honorable and appropriate response to thugs, things would likely have turned out differently. It now appears that this is exactly what happened on the flight that crashed in Pennsylvania - the passengers attempted to subdue the hijackers. They gave their lives, but prevented the deaths of countless others, and the possible destruction of Camp David, the White House or the Capitol. They upheld our proud tradition of American heroism. In a pinch, pocket knives, cell phones, pens, books, laptop computers, keys, etc. can all be used as weapons. All that's needed is the will and courage to fight back. We do not say this to dishonor the dead, who almost certainly had no idea of what the terrorists planned. We're sure that had they known, they would have willingly sacrificed their lives to save thousands of others. We will probably never know how many heroic people did exactly that. But we must resolve - right here, right now - that we will stop our idolatrous worship of safety above all else, and return to the values of individual responsibility, community responsibility, courage, and resistance to evil that made our nation great. In the days and months ahead, we expect to see unprecedented attacks on our G-d given rights - not just the right to keep and bear arms, but the rights of free speech, of assembly, of privacy, of travel, and of due process. We expect to see calls for more gun control, more Carnivore type surveillance of the internet, more wiretaps and surveillance of cell phone traffic, more warrantless searches and seizures, more face recognition technology, more fingerprinting, more restrictions on peaceful assembly, and increasing demands for some sort of high-tech method to track everything each and every person does. We must have the courage to oppose these attacks on our rights. We cannot preserve our freedom by destroying it. If we allow the acts of vicious criminals to turn the United States into a police state, they will have won, and we will lose everything. Nearly 250 years ago, Benjamin Franklin wrote: "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety". Yesterday, President Bush said: "America was targeted for attack because we're the brightest beacon for freedom and opportunity in the world. And no one will keep that light from shining." We pray he keeps his word. Not only must we not give up our essential liberty for false promises of safety, we must ensure that our nation remains that "brightest beacon for freedom". Utah Gun Owners Alliance suggests the following: Write to your Congressman, Senators, and state legislators and let them know that you are not willing to sacrifice your liberty for promises of safety, and that you expect them to protect and defend our Constitution and Bill of Rights. Also let them know that so long as our government protects our liberties, we will support them 100% in the difficult days ahead. Check your preparedness status. Do you have adequate food, water, medical supplies, lighting, batteries, radios, and self defense equipment should you need them? We're not trying to be alarmist here, but we think citizens have the obligation to be prepared to be useful and self sufficient in time of crisis, rather than becoming additional burdens on social services. Fly your flag! It's simple, free, shows your support for our country, and will encourage your neighbors to get into the patriotic spirit. If you're in good enough health to donate blood, please give the gift of life. Also consider donating to the religious and charitable organizations that are helping victims. The American Red Cross web site has a lot of information at www.redcross.org Don't stoop to hatred based on anyone's nationality, ethnicity or religion. Justice is the most noble of human endeavors. Bigotry is not. Don't let terrorists define our nation, and make sure that those who died did not die in vain! Pray for wisdom, courage, and strength for the injured, the families of victims, President Bush, our Congress, and all Americans. May G-d bless America, land of the FREE, home of the BRAVE. Copyright 2001 Sarah Thompson, M.D. <http://www.therighter.com> Subscribe to "The Righter", an intermittent column focusing on civil liberties and individual action. To subscribe please use the form at <http://www.therighter.com> Permission to distribute granted so long as no changes are made and this message is included. ************************************************************************** Subscribe to Freematt's Alerts: Pro-Individual Rights Issues Send a blank message to: freematt(a)coil.com with the words subscribe FA on the subject line. List is private and moderated (7-30 messages per week) Matthew Gaylor, (614) 313-5722 ICQ: 106212065 Archived at http://groups.yahoo.com/group/fa/ **************************************************************************

1 0

Tor 0.1.1.11-alpha is out
by Roger Dingledine 06 Jul '18

06 Jul '18

This is the eleventh development snapshot for the 0.1.1.x series. This release implements entry guard nodes: it automatically chooses a handful of entry nodes and sticks with them for all circuits. The logs about entry guards are still pretty chatty, but hopefully that will help us track down any problems. Please let us know whether it works for you. The release also reduces directory bandwidth overhead substantially, makes Tor servers with dynamic IP addresses useful again, and makes IRC and IM connections over Tor more reliable. Everybody who runs a hidden service should upgrade. http://tor.eff.org/download.html Changes in version 0.1.1.11-alpha - 2006-01-10 o Crashes in 0.1.1.x: - Include all the assert/crash fixes from 0.1.0.16. - If you start Tor and then quit very quickly, there were some races that tried to free things that weren't allocated yet. - Fix a rare memory stomp if you're running hidden services. - Fix segfault when specifying DirServer in config without nickname. - Fix a seg fault when you finish connecting to a server but at that moment you dump his server descriptor. - Extendcircuit and Attachstream controller commands would assert/crash if you don't give them enough arguments. - Fix an assert error when we're out of space in the connection_list and we try to post a hidden service descriptor (reported by weasel). - If you specify a relative torrc path and you set RunAsDaemon in your torrc, then it chdir()'s to the new directory. If you HUP, it tries to load the new torrc location, fails, and exits. The fix: no longer allow a relative path to torrc using -f. o Major features: - Implement "entry guards": automatically choose a handful of entry nodes and stick with them for all circuits. Only pick new guards when the ones you have are unsuitable, and if the old guards become suitable again, switch back. This will increase security dramatically against certain end-point attacks. The EntryNodes config option now provides some hints about which entry guards you want to use most; and StrictEntryNodes means to only use those. - New directory logic: download by descriptor digest, not by fingerprint. Caches try to download all listed digests from authorities; clients try to download "best" digests from caches. This avoids partitioning and isolating attacks better. - Make the "stable" router flag in network-status be the median of the uptimes of running valid servers, and make clients pay attention to the network-status flags. Thus the cutoff adapts to the stability of the network as a whole, making IRC, IM, etc connections more reliable. o Major fixes: - Tor servers with dynamic IP addresses were needing to wait 18 hours before they could start doing reachability testing using the new IP address and ports. This is because they were using the internal descriptor to learn what to test, yet they were only rebuilding the descriptor once they decided they were reachable. - Tor 0.1.1.9 and 0.1.1.10 had a serious bug that caused clients to download certain server descriptors, throw them away, and then fetch them again after 30 minutes. Now mirrors throw away these server descriptors so clients can't get them. - We were leaving duplicate connections to other ORs open for a week, rather than closing them once we detect a duplicate. This only really affected authdirservers, but it affected them a lot. - Spread the authdirservers' reachability testing over the entire testing interval, so we don't try to do 500 TLS's at once every 20 minutes. o Minor fixes: - If the network is down, and we try to connect to a conn because we have a circuit in mind, and we timeout (30 seconds) because the network never answers, we were expiring the circuit, but we weren't obsoleting the connection or telling the entry_guards functions. - Some Tor servers process billions of cells per day. These statistics need to be uint64_t's. - Check for integer overflows in more places, when adding elements to smartlists. This could possibly prevent a buffer overflow on malicious huge inputs. I don't see any, but I haven't looked carefully. - ReachableAddresses kept growing new "reject *:*" lines on every setconf/reload. - When you "setconf log" via the controller, it should remove all logs. We were automatically adding back in a "log notice stdout". - Newly bootstrapped Tor networks couldn't establish hidden service circuits until they had nodes with high uptime. Be more tolerant. - We were marking servers down when they could not answer every piece of the directory request we sent them. This was far too harsh. - Fix the torify (tsocks) config file to not use Tor for localhost connections. - Directory authorities now go to the proper authority when asking for a networkstatus, even when they want a compressed one. - Fix a harmless bug that was causing Tor servers to log "Got an end because of misc error, but we're not an AP. Closing." - Authorities were treating their own descriptor changes as cosmetic, meaning the descriptor available in the network-status and the descriptor that clients downloaded were different. - The OS X installer was adding a symlink for tor_resolve but the binary was called tor-resolve (reported by Thomas Hardly). - Workaround a problem with some http proxies where they refuse GET requests that specify "Content-Length: 0" (reported by Adrian). - Fix wrong log message when you add a "HiddenServiceNodes" config line without any HiddenServiceDir line (reported by Chris Thomas). o Minor features: - Write the TorVersion into the state file so we have a prayer of keeping forward and backward compatibility. - Revive the FascistFirewall config option rather than eliminating it: now it's a synonym for ReachableAddresses *:80,*:443. - Clients choose directory servers from the network status lists, not from their internal list of router descriptors. Now they can go to caches directly rather than needing to go to authorities to bootstrap. - Directory authorities ignore router descriptors that have only cosmetic differences: do this for 0.1.0.x servers now too. - Add a new flag to network-status indicating whether the server can answer v2 directory requests too. - Authdirs now stop whining so loudly about bad descriptors that they fetch from other dirservers. So when there's a log complaint, it's for sure from a freshly uploaded descriptor. - Reduce memory requirements in our structs by changing the order of fields. - There used to be two ways to specify your listening ports in a server descriptor: on the "router" line and with a separate "ports" line. Remove support for the "ports" line. - New config option "AuthDirRejectUnlisted" for auth dirservers as a panic button: if we get flooded with unusable servers we can revert to only listing servers in the approved-routers file. - Auth dir servers can now mark a fingerprint as "!reject" or "!invalid" in the approved-routers file (as its nickname), to refuse descriptors outright or include them but marked as invalid. - Servers store bandwidth history across restarts/crashes. - Add reasons to DESTROY and RELAY_TRUNCATED cells, so clients can get a better idea of why their circuits failed. Not used yet. - Directory mirrors now cache up to 16 unrecognized network-status docs. Now we can add new authdirservers and they'll be cached too. - When picking a random directory, prefer non-authorities if any are known. - New controller option "getinfo desc/all-recent" to fetch the latest server descriptor for every router that Tor knows about. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [cryptography] OTR and deniability
by Ian Goldberg 06 Jul '18

06 Jul '18

[I'm not usually on this list, but was pointed to this thread. Warning that we now have two "iang"s on here. ;-) ] This is a common confusion about OTR. OTR aims to provide the same deniability as plaintext, while also providing the same authentication as, say, PGP. You want assurance that the other person is who he says he is, but at the same time, you don't want digital signatures on all of your messages which can be used by a third party (or even the person you were speaking to) later to prove what you said. You can't achieve *more* deniability than plaintext, of course. Just as plaintext chat logs might be trusted because you believe the chain-of-custody, so might OTR logs be. (If the OTR logs are the ciphertexts, of course, you'd also need to log the keys to get anything useful out, but even then, the point is that you could have used the toolkit to modify individual messages, or even forge the whole transcript.) In this case, of course, the plaintexts were logged, so OTR's properties don't even come into it. Here, anyone could simply edit the text file containing the logs. - Ian (the other "iang") _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [ZS] Re: RESfest 2012 [B] : Basic issues: The importance of resources to any vision of the future.
by Bryce Lynch 06 Jul '18

06 Jul '18

Necroposting, to be sure, but it's of relevance to Network 25: CouchDB (http://couchdb.org/) is a NoSQL database server which is capable of constructing massively distributed databases with very little effort. Everything is stored internally as JSON documents, and the server speaks HTTP(S) with a REST API, so you can manipulate it with a web browser (or even wget or curl, if you've a mind to). Applications are written in HTML with JavaScript and stored in the CouchDB database itself. To access them, you just plug the URL of the CouchDB server into your web browser and use it like any other website. It runs well on remarkably underpowered hardware I'm told. PouchDB (http://pouchdb.org/) is an extremely tiny implementation of much of the CouchDB API written in JavaScript and is designed to be embedded in web apps. When you access CouchDB apps that use PouchDB, PouchDB transparently proxies requests and caches output from the Couch database. Here's the nifty bit: If you go offline - your cellular reception tanks or you have to disconnect from the local wireless net, you can continue to interact with the web app in question as long as it's in your browser's cache because it has a snapshot of all of the relevant data inside of it. When you go back online, PouchDB synchs up with the CouchDB instance elsewhere... I have a subprocess researching this combination for Project Byzantium - I think we can implement the massively distributed microblog with it, among other things. For a truly distributed Network 25, we might want to consider researching and making use of whatever CouchDB socnet apps exist. -- The Doctor [412/724/301/703] [ZS (MED)] https://drwho.virtadpt.net/ "I am everywhere." -- -- Zero State mailing list: http://groups.google.com/group/DoctrineZero ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[tahoe-dev] Announcing Tahoe-LAFS v1.9.2
by David-Sarah Hopwood 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.9.2 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.9.2 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" b meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst The previous stable release of Tahoe-LAFS was v1.9.1, released on January 12, 2012. v1.9.2 is a bugfix release that primarily fixes regressions in mutable file support. See the NEWS file [1] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [2].) COMPATIBILITY This release is compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the seventeenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the foreseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [4] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.rst" [5] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.rst" [6]. HACKING AND COMMUNITY Please join us on the mailing list [7]. Patches are gratefully accepted -- the RoadMap page [8] shows the next improvements that we plan to make and CREDITS [9] lists the names of people who've contributed to the project. The Dev page [10] contains resources for hackers. SPONSORSHIP Atlas Networks has contributed several hosted servers for performance testing. Thank you to Atlas Networks [11] for their generous and public-spirited support. And a special thanks to Least Authority Enterprises [12], which employs several Tahoe-LAFS developers, for their continued support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that we feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [13]. ACKNOWLEDGEMENTS This is the eleventh release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. David-Sarah Hopwood on behalf of the Tahoe-LAFS team July 3, 2012 Rainhill, Merseyside, UK [1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst [2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst [3] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects [4] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL [5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst [6] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst [7] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [8] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap [9] https://tahoe-lafs.org/trac/tahoe-lafs/browser/CREDITS [10] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev [11] http://atlasnetworks.us/ [12] https://leastauthority.com/ [13] https://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Syndicated Dave and Declan... RSS
by Joseph Lorenzo Hall 06 Jul '18

06 Jul '18

Hi Declan, Dave (for IP, if you wish), Being one of the many of your pesky readers that spends a good deal of time in a news aggregator and likes syndicated news (RSS, ATOM, etc.), I've bugged you both before about setting up something with RSS. (Declan finally caved and is using some sort of blog software with RSS and ATOM feeds: http://www.politechbot.com/ ) As for building a feed of Dave's IP list, I finally had to take matters into my own hands and hire a mercenary. I got Carlo Zottmann to build an RSS feed for Dave's Interesting People List... here's the RSS feed: http://bootleg-rss.g-blog.net/ d.interesting_people_org_archives_interesting-people.php A special feature that Carlo included was the ability to add '?date=YYYYMM' (ex: 200407) to the end of the script to access the archive for a previous month. When no date is given, the script defaults to the current month. Further, Carlo will scrape any site that you wished had syndication for $2 (If you like the IP syndication and would like to make a donation to Carlo's efforts, let me know): http://bootleg-rss.g-blog.net/journal/2004/07/announcement-accepting- feed-requests.html (via Boing Boing originally) I also asked him to syndicate the Drudge Report for fun (which appeared to be a major pain in the ass considering it seems to be hand-edited): http://bootleg-rss.g-blog.net/d.drudgereport_com.php Joe ------------------------------------------------------------------------ Joseph Lorenzo Hall, SIMS PhD Student; UC Berkeley. [web:<http://pobox.com/~joehall/>, blog:<http://pobox.com/~joehall/nqb>] ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[IP] Syndicated Dave and Declan... RSS
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[Freedombox-discuss] Tahoe-LAFS is not a filesystem
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: I'm a developer on the Tahoe-LAFS project (https://tahoe-lafs.org ) and I would be happy to see it used in Freedombox. The projects have many goals in common. I'm also the founder of a startup that sells Tahoe-LAFS ciphertext storage service: https://leastauthority.com . I'm just writing this brief note to try to explain something -- Tahoe, the Least-Authority File System fits better for file sharing, streaming or network-attached-storage than it does for a normal, local filesystem. It should probably be moved from here, where it is currently listed next to MooseFS: http://wiki.debian.org/FreedomBox/ExampleProjects#Filesystems To here: http://wiki.debian.org/FreedomBox/ExampleProjects#File_sharing or maybe here or here or here: http://wiki.debian.org/FreedomBox/ExampleProjects#Streaming http://wiki.debian.org/FreedomBox/ExampleProjects#Network_Attached_Storage Where it can be listed next to things like ownCloud, SparkleShare, BitTorrent, Tin Can Jukebox, etc. The confusion is that Tahoe-LAFS *is* a file system, in a couple of senses. It has arbitrarily nestable directories and files (unlike a lot of newfangled storage systems), and it has an SFTP server, which means you can point sshfs at it and have a reasonably good access to it directly in your kernel VFS. You could also use PyFilesystem to integrate it into your local filesystem. *But*, while the compatibility and correctness of Tahoe-LAFS and its SFTP server are pretty good, its performance characteristics as a distributed, secure, fault-tolerant storage system are sometimes a bad match for the expectations of user-space programs that access their storage through the POSIX filesystem API. Some things work fine -- it depends on your specific use case, but some access patterns that are normal and efficient on a local filesystem like ext4 are painfully slow or even infeasible on Tahoe-LAFS. For example, opening a file for append, appending a few bytes, and then closing it again, and then doing this over and over 10,000 times, will take about O(N) time and O(N) space on ext4 (about 10,000 disk operations and about 10,000 units of storage on disk), but take about O(N**2) time and O(N**2) space on Tahoe-LAFS (about 100,000,000 network operations and about 100,000,000 units of storage on the backend), which means the program that does something like that will never finish and might use up a lot of your secure cloud storage space. Everybody wants to use Tahoe-LAFS through FUSE as though it were a local filesystem, but nobody actually uses Tahoe-LAFS through FUSE, to my knowledge. All the people who actually Tahoe-LAFS end up using it less like it is a "filesystem" like ext4 and more like it is an "application" for backing up, sharing, or hosting files. (N.B. the tahoe-lafs developers actively try to support whatever it is that our users demand, and so we continue to support and improve its behavior when it is treated as though it were a local filesystem, even though I don't exactly recommend it.) Regards, Zooko _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0