- cypherpunks-legacy - lists.cpunks.org

[IP] Diebold easily hacked
by David Farber 05 Jul '18

05 Jul '18

Begin forwarded message:

1 0

Re: [tor-relays] Deploy relays using hidden exit IP's?
by Julian Yon 05 Jul '18

05 Jul '18

On Tue, 27 Nov 2012 01:58:40 +0000 (UTC) Sven Olaf Kamphuis <sven(a)cb3rob.net> wrote: > [Utopian fantasy] Meanwhile, back in the Real World, ancient protocols like SMTP dominate the Internet (oh look, you used it to post to this list) and people do what they have to in order to keep their services running. Perhaps you've never worked on a project large enough that network ops and development are handled by separate teams, but in such an environment a sysadmin who allowed the servers to fall over because they believed it was dev's responsibility would quickly find herself out of a job. Tor won't benefit from that person's career suicide. Whereas giving admins the power to implement an easy kill switch (by blocking the exits when they need to) makes Tor a much less attractive prospect for those who would abuse the network. If you can run your attack over Tor, knowing you can be blocked easily, or over some botnet, which would you choose? This means more bandwidth for the rest of us, and fewer abuse complaints for exit operators. I'd say that's a win. Of course, some organisations (I'm looking at Wikipedia) have a problem with Tor that is due to policy, not technology. Is their policy right? Of course not - the impressive level of vandalism that happens anyway proves that (although CluebotNG has an equally impressive catch rate, it has to be said). But unless you're the one paying for and running the infrastructure of that free-as-in-beer service, what right do you have to say b let them all go to hellb? Do you say the same about people who run relays whose exit policies don't allow your traffic? Do you curse at your neighbour whose unencrypted wireless network doesn't allow connections to your favourite porn site? Seriously, get some perspective. Nobody's going to listen if you're rude to/about them. They're more likely to just dig in their heels and erect another barrier. People do what they feel they must to protect what they (are being paid to) care about. Being open about where the exits are is one way of saying b look, we're all friendsb. Conversely, making a serious effort to circumvent their blocks by using unpublished exit addresses will simply create another game of Cat & Mouse, just like the one being played with bridge relays. Sites like Wikipedia, who have made at least some token efforts to come to a solution which works for Tor, will stop trying at all because it will no longer be possible to distinguish Tor exit traffic from other non-authenticated connections. As you can see I've made the effort to write in real sentences, use capital letters and avoid b zomgb. I won't do so a second time, because if I haven't convinced you by now I'm not going to. By all means continue daydreaming, just remember that's what it is. If you want your utopia to eventually exist, you have to start with reality. You can't just will it into existence. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012(a)jry.me> _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- 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: [tor] Softlayer finally kicks us from their data center
by grarpamp 05 Jul '18

05 Jul '18

> On the cost side, Cogent and Hurricane Electric both sell 100 meg in > the $400 to $500 range in top tier data centers. You can easily get > Gigabit for $1500 from them (unmetered). Didn't know Cogent had gone that low yet, thx. HE is more a provider of mixed services (colo/host/transit) than traditional pipe though. > But the DMCA notices go to the ARIN contact for the block. If you > just get service, you may not be set as the "owner" (according to > ARIN) of the block. Sure. I guess my mention of being an ISP should have said it was for purposes of going naturally alongside direct allocation. In a former life, I did send notices to upstream pipe as needed. ie: If there was an issue requiring it... traceroute, lookup and mail. So even an independant ISP, in their own room, buying circuit from L3/etc, could have a ticket lodged at L3. That was also the point about structuring. Companies layer and silo things as suits them. > I've been ignoring DMCA notices for 10 years As would many rightly do, laws of other countries don't apply. Business seeks to minimize cost, ignoring saves cost with minimal risk. > Really, though, there's only 86 days of IPv4 allocation left (see HE's > status page or gadget). The time for you to set up a company, get raw > bandwidth and speak BGP with your peers is likely come and gone. TOR > needs to think about IPv6. Yep, I left that part out of my prior note. That's a big problem as far as opening up shop as a new ISP. For this or any other purpose. Especially if you want to keep it private [held and funded] with organic growth... no time left for that. Save for givebacks and if IANA/etc brokers private swaps, direct v4 allocation simply won't exist, everything will be SWIP. The v6 net, current OS's, DNS are all ready. A fair number of popular apps, certainly opensource ones, do v6. So yes, Tor needs to become v6 capable. The v4 game may be played out. But given that true global v6 adoption vs NAT everywhere has what maybe a 50/50 chance?... early v6 ISP's could make a killing. Maybe we'll be among them :) Oh well, kindof off topic. Cheers. ----- 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: [tor] Softlayer finally kicks us from their data center
by grarpamp 05 Jul '18

05 Jul '18

> On the cost side, Cogent and Hurricane Electric both sell 100 meg in > the $400 to $500 range in top tier data centers. You can easily get > Gigabit for $1500 from them (unmetered). Didn't know Cogent had gone that low yet, thx. HE is more a provider of mixed services (colo/host/transit) than traditional pipe though. > But the DMCA notices go to the ARIN contact for the block. If you > just get service, you may not be set as the "owner" (according to > ARIN) of the block. Sure. I guess my mention of being an ISP should have said it was for purposes of going naturally alongside direct allocation. In a former life, I did send notices to upstream pipe as needed. ie: If there was an issue requiring it... traceroute, lookup and mail. So even an independant ISP, in their own room, buying circuit from L3/etc, could have a ticket lodged at L3. That was also the point about structuring. Companies layer and silo things as suits them. > I've been ignoring DMCA notices for 10 years As would many rightly do, laws of other countries don't apply. Business seeks to minimize cost, ignoring saves cost with minimal risk. > Really, though, there's only 86 days of IPv4 allocation left (see HE's > status page or gadget). The time for you to set up a company, get raw > bandwidth and speak BGP with your peers is likely come and gone. TOR > needs to think about IPv6. Yep, I left that part out of my prior note. That's a big problem as far as opening up shop as a new ISP. For this or any other purpose. Especially if you want to keep it private [held and funded] with organic growth... no time left for that. Save for givebacks and if IANA/etc brokers private swaps, direct v4 allocation simply won't exist, everything will be SWIP. The v6 net, current OS's, DNS are all ready. A fair number of popular apps, certainly opensource ones, do v6. So yes, Tor needs to become v6 capable. The v4 game may be played out. But given that true global v6 adoption vs NAT everywhere has what maybe a 50/50 chance?... early v6 ISP's could make a killing. Maybe we'll be among them :) Oh well, kindof off topic. Cheers. ----- 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] Is BitCoin a triple entry system?
by Sampo Syreeni 05 Jul '18

05 Jul '18

On 2011-06-13, Ian G wrote: > Double entry achieves the remarkable trick of separating out mishaps > from frauds. The problem with single entry (what people do when making > lists of numbers and adding them up) is that the person can leave off a > number, and no-one is the wiser [7]. I would tend to disagree here. It's not too difficult to defraud with double entry, either: just appear sloppy. Yes, I know, the system's value is usually painted as deriving from this primitive form of error correction, consistency checking and redundancy. But really I think it's more about something else -- equally trivial -- that took me a long time to figure out since the accounting literature doesn't much help you there. I think that something has to do with the asynchronous, multiple-input-multiple-output nature of how a firm operates, and people's highly limited ability to deal with more than one single thing or aspect of things at any one time. This dawned on me when I had to partake in a scheme used to manage a collective liqueur cabinet. It eventually evolved all by itself into a double entry system, which I went on to describe in http://boleforjoy.blogspot.com/2009/12/accounting-wonders.html . Thus, I think that we shouldn't be considering the trusted (distributed) third party in BitCoin on an equal footing with the innovation of double entry. Fundamentally I see them as performing separate roles, with the trusted verifier being the only one that has relevance wrt security. A better comparison in the world of accounting would be how receipts are kept, balanced cleared, different ledgers compared with each other by an independent accountant, or perhaps procedures where different people own different accounts and need to establish mutual trust upon a transaction before accepting it. > There is only one area where a signed receipt falls short of complete > evidence and that is when a digital piece of evidence can be lost. For > this reason, all three of Alice, Bob and Ivan keep hold of a copy. All > three combined have the incentive to preserve it; the three will police > each other. Well, there's also the point about Byzantine failure tolerance. At the very minimum it always takes three parties to guarantee that even a single malfunctioning party can be reliably voted down. That's why mirroring wouldn't be any good by itself, without the independent check from the underlying error correcting code. BitCoin goes with the general version, and tries to limit each party from having more than one vote (or too many votes) by imposing a computational challenge which is economically limiting "in the real world". -- Sampo Syreeni, aka decoy - decoy(a)iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 _______________________________________________ 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

[tahoe-lafs-weekly-news] TWN18
by Patrick R McDonald 05 Jul '18

05 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ========================================================== Tahoe-LAFS Weekly News, issue number 18, November 29, 2011 ========================================================== Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS_ is a secure, distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_. If you would like to view the "new and improved" TWN, complete with pictures; please take a `look`_. .. _Tahoe-LAFS: http://tahoe-lafs.org .. _View TWN on the web: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: http://tahoe-lafs.org/~marlowe/TWN18.html Announcements and News ====================== Newest Contributor - ------------------ `Marcus Wanner`_ |marcus| is the newest contributor to Tahoe-LAFS. He is contributing the `move button`_ to the web interface. You will see the move button next to the rename button in the directory view of the web interface. Marcus' contribution needs review at ticket number 1579_. Marcus runs a node for the `Virginia Tech Linux and Unix Users Group`_ (VTLUUG) |VTLUUG| `Tahoe-LAFS grid`_. Welcome to the team, Marcus. .. _`Marcus Wanner`: http://t.co/IiQt88vh .. _`move button`: https://github.com/marcuswanner/tahoe-lafs/commits/movebutton .. _1579: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1579 .. _`Virginia Tech Linux and Unix Users Group`: https://vtluug.org/wiki/Main_page .. _`Tahoe-LAFS grid`: https://vtluug.org/wiki/Tahoe-LAFS .. |marcus| image:: marcus.png :height: 35 :alt: Marcus Warner :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |VTLUUG| image:: VTLUUG.png :height: 35 :alt: VTLUUG :target: https://vtluug.org/wiki/Main_page 1.8.3 Being Backported - ---------------------- Ubuntu_ |ubuntu| has a ticket `to backport 1.8.3`_ for Lucid, Maverick and Natty. The backport will make available to users of Lucid, Maverick and Natty, within the library of Ubuntu-provided packages, the features that were added between their current version and 1.8.3. .. _Ubuntu: http://www.ubuntu.com .. _`to backport 1.8.3`: https://bugs.launchpad.net/lucid-backports/+bug/834361 .. _`Tahoe-LAFS Weekly News 14`: https://tahoe-lafs.org/~marlowe/TWN14.html .. |ubuntu| image:: ubuntu.png :height: 35 :alt: Ubuntu :target: http://www.ubuntu.com - From the tahoe-dev Mailing List =============================== Tahoe-LAFS Inspired Students' Thesis - ------------------------------------ Three students from Norwegian University of Science and Technology thanked Tahoe-LAFS in their thesis. "We would like to thank all contributors of code and documentation to the open source software Tahoe-LAFS, which has given us great inspiration and building blocks for our thesis.b [1_] It appears the students implemented a subset of Tahoe-LAFS, including mutable directories and separate read- and write- caps in Java and tested it on Android. They implement the server side portion in Python. .. _1: https://github.com/zerqent/cloud-storage-vault/blob/master/report/main.pdf?… LAE Sponsors pycryptopp Hacking - ------------------------------- Taking advantage of `Least Authority Enterprises`_ (LAE) |LAE| allowing employees to work on open source projects on Fridays, Zooko |zooko| announced a pycryptopp hackaday on Nov. 25. Below is a list of items on the hackaday todo list: 1. Review and merge Brian's patch to add Ed25519 signatures: `https://tahoe-lafs.org/trac/pycryptopp/ticket/75`_ 2. Review and merge Yu Xue's patches to add: a) XSalsa20: `https://tahoe-lafs.org/trac/pycryptopp/ticket/40`_ b) Python HMAC: `https://tahoe-lafs.org/trac/pycryptopp/ticket/41`_ c) Python HKDF: `https://tahoe-lafs.org/trac/pycryptopp/ticket/42`_ d) combined AESb XSalsa20: `https://tahoe-lafs.org/trac/pycryptopp/ticket/46`_, `https://tahoe-lafs.org/trac/pycryptopp/ticket/47`_ e) Comb4P: `https://tahoe-lafs.org/trac/pycryptopp/ticket/50`_ f) curve25519: `https://tahoe-lafs.org/trac/pycryptopp/ticket/71`_ 3. See if Billy Earney or someone else will volunteer to port pycryptopp to "both Python 2 and Python 3 compatibility": `https://tahoe-lafs.org/trac/pycryptopp/ticket/35`_ 4. Look at the buildbot issues, solicit new volunteers to run buildslaves on more platforms: `https://tahoe-lafs.org/buildbot-pycryptopp/`_ 5. Look into alleged miscompilation by Microsoft compiler, try to devise defensive strategy, push someone else (the Crypto++ project) to devise defensive strategy, or just close this ticket as "wontfix": `https://tahoe-lafs.org/trac/pycryptopp/ticket/65`_ 6. Fix a few small bugs, e.g.: `https://tahoe-lafs.org/trac/pycryptopp/ticket/70`_ 7. See if we can replace Twisted conch's use of pycrypto with pycryptopp: `http://twistedmatrix.com/trac/ticket/4633`_ .. _`Least Authority Enterprises`: http://leastauthority.com/ .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/75`: https://tahoe-lafs.org/trac/pycryptopp/ticket/75 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/40`: https://tahoe-lafs.org/trac/pycryptopp/ticket/40 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/41`: https://tahoe-lafs.org/trac/pycryptopp/ticket/41 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/42`: https://tahoe-lafs.org/trac/pycryptopp/ticket/42 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/46`: https://tahoe-lafs.org/trac/pycryptopp/ticket/46 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/47`: https://tahoe-lafs.org/trac/pycryptopp/ticket/47 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/50`: https://tahoe-lafs.org/trac/pycryptopp/ticket/50 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/71`: https://tahoe-lafs.org/trac/pycryptopp/ticket/71 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/35`: https://tahoe-lafs.org/trac/pycryptopp/ticket/35 .. _`https://tahoe-lafs.org/buildbot-pycryptopp/`: https://tahoe-lafs.org/buildbot-pycryptopp/ .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/65`: https://tahoe-lafs.org/trac/pycryptopp/ticket/65 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/70`: https://tahoe-lafs.org/trac/pycryptopp/ticket/70 .. _`http://twistedmatrix.com/trac/ticket/4633`: http://twistedmatrix.com/trac/ticket/4633 .. |LAE| image:: LAE.png :height: 35 :alt: Least Authority Enterprises :target: http://leastauthority.com Open Source Project of the Week =============================== The Open Source Project of the Week is backshift_. backshift is a backup tool with "convergent variable-length block deduplication", as well as compression and incremental updates. The tool written in Python and uses a GPLv3 license. Zooko `posted to the backshift group list`_ with the suggestion of combination of the frontend behavior of backshift with the backend storage of Tahoe-LAFS. .. _backshift: http://stromberg.dnsalias.org/~dstromberg/backshift/ .. _`posted to the backshift group list`: https://groups.google.com/group/backshift/browse_thread/thread/61edde867842… Patch Needing Review of the Week ================================ There are four (4) tickets still needing review for 1.10: * `#393`_: mutable: implement MDMF * `#1265`_: New Visualizer is insufficiently labelled/documented (plus layout problem) * `#1398`_: make docs/performance.rst more precise and accurate * `#1566`_: if a stored share has a corrupt header, other shares held by that server for the file should still be accessible to clients .. _`#393`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393 .. _`#1265`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265 .. _`#1398`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1398 .. _`#1566`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566 - ---- *The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS* *Software Foundation, President and Treasurer: Peter Secor* |peter| *. Scribes: Patrick "marlowe" McDonald* |marlowe| *, Zooko Wilcox-O'Hearn* *, Editor: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_ *. Send your news stories to* `marlowe(a)antagonism.org`_ *b submission deadline: Friday night.* .. _marlowe(a)antagonism.org: mailto:marlowe@antagonism.org .. |zooko| image:: zooko.png :height: 35 :alt: zooko :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |brian| image:: warner.png :height: 35 :alt: brian :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |peter| image:: psecor.jpg :height: 35 :alt: peter :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |marlowe| image:: marlowe-x75-bw.jpg :height: 35 :alt: marlowe :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs - -- - ---------------------------------------------------------------- | Patrick R. McDonald GPG Key: A2D1E972 | | https://www.antagonism.org/ <marlowe(a)antagonism.org> | | <mcdonald.patrick.r(a)gmail.com> | | <patrick(a)opensecurityfoundation.org> | - ---------------------------------------------------------------- | Malo periculosam libertatem quam quietum servitium | - ---------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO1X6vAAoJEAT4nRyi0elyhfkQAMy1xGlEWW8dkJ2JwDzqdLI3 yRAJ96SQAQI0GOxr3KrNqGbJnl8BWdwAqtY4nNNyclYLGUaW/YpSFpb/VaYDwmFm crCmP6ndowMWQzU1jc98Op6tsKrX1MDv+NSwR9yyFiYV7ik2Nufb+D9zf698dqef k0TskNPZkT7+N8L9S4swRayDcLMtXSQPtwOjA4T1kEm9Jc/pzH0Mw8snUIn3UfCp nPHErjDAcvTO3MP6kX25vLHLDVUEWkI66ZRrh+4eoVZchIdoXD/DJ0fsIIBpBb5B QcB6v+f42xj9vOyF7RBqkCQ+Hj7J/iJF79AHguAGu7lsVVm1ygev2rL7ncT7Ra8M ckQmkGe5iFmLkO+YkY/+OCfxOBANbtPzOtvgfrqI+iVchjgnX48kcPfSMOI8zIs7 u0u6zBJfxxlzvFy+Janta43Ge209hQYuEoh90r1LtFCvQ+kD2EhJzwCaQIcgPN8o qSTzKNOQgWWsO80/EL3TTBaS1YDtg5yUYXFuxA3gSKC2DmUJd2M4VLcTFCAqmFNQ VF/xnyfAs1D95pv7otYy2jwF2cXmYE2qNs5kjRSImcl9+H+KsLK5O+utKEEFg2tI zYRDSfNWL9PixhBNg/pp8EPGjcZD7oDtBu2Uc6O8yF9UytI3owbhUPaAxwe7woP7 K/VCCuBFWbhylhxUnF0Z =HV15 -----END PGP SIGNATURE----- _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- 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] Is BitCoin a triple entry system?
by Sampo Syreeni 05 Jul '18

05 Jul '18

On 2011-06-13, Ian G wrote: > Double entry achieves the remarkable trick of separating out mishaps > from frauds. The problem with single entry (what people do when making > lists of numbers and adding them up) is that the person can leave off a > number, and no-one is the wiser [7]. I would tend to disagree here. It's not too difficult to defraud with double entry, either: just appear sloppy. Yes, I know, the system's value is usually painted as deriving from this primitive form of error correction, consistency checking and redundancy. But really I think it's more about something else -- equally trivial -- that took me a long time to figure out since the accounting literature doesn't much help you there. I think that something has to do with the asynchronous, multiple-input-multiple-output nature of how a firm operates, and people's highly limited ability to deal with more than one single thing or aspect of things at any one time. This dawned on me when I had to partake in a scheme used to manage a collective liqueur cabinet. It eventually evolved all by itself into a double entry system, which I went on to describe in http://boleforjoy.blogspot.com/2009/12/accounting-wonders.html . Thus, I think that we shouldn't be considering the trusted (distributed) third party in BitCoin on an equal footing with the innovation of double entry. Fundamentally I see them as performing separate roles, with the trusted verifier being the only one that has relevance wrt security. A better comparison in the world of accounting would be how receipts are kept, balanced cleared, different ledgers compared with each other by an independent accountant, or perhaps procedures where different people own different accounts and need to establish mutual trust upon a transaction before accepting it. > There is only one area where a signed receipt falls short of complete > evidence and that is when a digital piece of evidence can be lost. For > this reason, all three of Alice, Bob and Ivan keep hold of a copy. All > three combined have the incentive to preserve it; the three will police > each other. Well, there's also the point about Byzantine failure tolerance. At the very minimum it always takes three parties to guarantee that even a single malfunctioning party can be reliably voted down. That's why mirroring wouldn't be any good by itself, without the independent check from the underlying error correcting code. BitCoin goes with the general version, and tries to limit each party from having more than one vote (or too many votes) by imposing a computational challenge which is economically limiting "in the real world". -- Sampo Syreeni, aka decoy - decoy(a)iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 _______________________________________________ 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

[tahoe-lafs-weekly-news] TWN18
by Patrick R McDonald 05 Jul '18

05 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ========================================================== Tahoe-LAFS Weekly News, issue number 18, November 29, 2011 ========================================================== Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS_ is a secure, distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_. If you would like to view the "new and improved" TWN, complete with pictures; please take a `look`_. .. _Tahoe-LAFS: http://tahoe-lafs.org .. _View TWN on the web: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: http://tahoe-lafs.org/~marlowe/TWN18.html Announcements and News ====================== Newest Contributor - ------------------ `Marcus Wanner`_ |marcus| is the newest contributor to Tahoe-LAFS. He is contributing the `move button`_ to the web interface. You will see the move button next to the rename button in the directory view of the web interface. Marcus' contribution needs review at ticket number 1579_. Marcus runs a node for the `Virginia Tech Linux and Unix Users Group`_ (VTLUUG) |VTLUUG| `Tahoe-LAFS grid`_. Welcome to the team, Marcus. .. _`Marcus Wanner`: http://t.co/IiQt88vh .. _`move button`: https://github.com/marcuswanner/tahoe-lafs/commits/movebutton .. _1579: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1579 .. _`Virginia Tech Linux and Unix Users Group`: https://vtluug.org/wiki/Main_page .. _`Tahoe-LAFS grid`: https://vtluug.org/wiki/Tahoe-LAFS .. |marcus| image:: marcus.png :height: 35 :alt: Marcus Warner :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |VTLUUG| image:: VTLUUG.png :height: 35 :alt: VTLUUG :target: https://vtluug.org/wiki/Main_page 1.8.3 Being Backported - ---------------------- Ubuntu_ |ubuntu| has a ticket `to backport 1.8.3`_ for Lucid, Maverick and Natty. The backport will make available to users of Lucid, Maverick and Natty, within the library of Ubuntu-provided packages, the features that were added between their current version and 1.8.3. .. _Ubuntu: http://www.ubuntu.com .. _`to backport 1.8.3`: https://bugs.launchpad.net/lucid-backports/+bug/834361 .. _`Tahoe-LAFS Weekly News 14`: https://tahoe-lafs.org/~marlowe/TWN14.html .. |ubuntu| image:: ubuntu.png :height: 35 :alt: Ubuntu :target: http://www.ubuntu.com - From the tahoe-dev Mailing List =============================== Tahoe-LAFS Inspired Students' Thesis - ------------------------------------ Three students from Norwegian University of Science and Technology thanked Tahoe-LAFS in their thesis. "We would like to thank all contributors of code and documentation to the open source software Tahoe-LAFS, which has given us great inspiration and building blocks for our thesis.b [1_] It appears the students implemented a subset of Tahoe-LAFS, including mutable directories and separate read- and write- caps in Java and tested it on Android. They implement the server side portion in Python. .. _1: https://github.com/zerqent/cloud-storage-vault/blob/master/report/main.pdf?… LAE Sponsors pycryptopp Hacking - ------------------------------- Taking advantage of `Least Authority Enterprises`_ (LAE) |LAE| allowing employees to work on open source projects on Fridays, Zooko |zooko| announced a pycryptopp hackaday on Nov. 25. Below is a list of items on the hackaday todo list: 1. Review and merge Brian's patch to add Ed25519 signatures: `https://tahoe-lafs.org/trac/pycryptopp/ticket/75`_ 2. Review and merge Yu Xue's patches to add: a) XSalsa20: `https://tahoe-lafs.org/trac/pycryptopp/ticket/40`_ b) Python HMAC: `https://tahoe-lafs.org/trac/pycryptopp/ticket/41`_ c) Python HKDF: `https://tahoe-lafs.org/trac/pycryptopp/ticket/42`_ d) combined AESb XSalsa20: `https://tahoe-lafs.org/trac/pycryptopp/ticket/46`_, `https://tahoe-lafs.org/trac/pycryptopp/ticket/47`_ e) Comb4P: `https://tahoe-lafs.org/trac/pycryptopp/ticket/50`_ f) curve25519: `https://tahoe-lafs.org/trac/pycryptopp/ticket/71`_ 3. See if Billy Earney or someone else will volunteer to port pycryptopp to "both Python 2 and Python 3 compatibility": `https://tahoe-lafs.org/trac/pycryptopp/ticket/35`_ 4. Look at the buildbot issues, solicit new volunteers to run buildslaves on more platforms: `https://tahoe-lafs.org/buildbot-pycryptopp/`_ 5. Look into alleged miscompilation by Microsoft compiler, try to devise defensive strategy, push someone else (the Crypto++ project) to devise defensive strategy, or just close this ticket as "wontfix": `https://tahoe-lafs.org/trac/pycryptopp/ticket/65`_ 6. Fix a few small bugs, e.g.: `https://tahoe-lafs.org/trac/pycryptopp/ticket/70`_ 7. See if we can replace Twisted conch's use of pycrypto with pycryptopp: `http://twistedmatrix.com/trac/ticket/4633`_ .. _`Least Authority Enterprises`: http://leastauthority.com/ .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/75`: https://tahoe-lafs.org/trac/pycryptopp/ticket/75 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/40`: https://tahoe-lafs.org/trac/pycryptopp/ticket/40 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/41`: https://tahoe-lafs.org/trac/pycryptopp/ticket/41 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/42`: https://tahoe-lafs.org/trac/pycryptopp/ticket/42 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/46`: https://tahoe-lafs.org/trac/pycryptopp/ticket/46 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/47`: https://tahoe-lafs.org/trac/pycryptopp/ticket/47 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/50`: https://tahoe-lafs.org/trac/pycryptopp/ticket/50 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/71`: https://tahoe-lafs.org/trac/pycryptopp/ticket/71 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/35`: https://tahoe-lafs.org/trac/pycryptopp/ticket/35 .. _`https://tahoe-lafs.org/buildbot-pycryptopp/`: https://tahoe-lafs.org/buildbot-pycryptopp/ .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/65`: https://tahoe-lafs.org/trac/pycryptopp/ticket/65 .. _`https://tahoe-lafs.org/trac/pycryptopp/ticket/70`: https://tahoe-lafs.org/trac/pycryptopp/ticket/70 .. _`http://twistedmatrix.com/trac/ticket/4633`: http://twistedmatrix.com/trac/ticket/4633 .. |LAE| image:: LAE.png :height: 35 :alt: Least Authority Enterprises :target: http://leastauthority.com Open Source Project of the Week =============================== The Open Source Project of the Week is backshift_. backshift is a backup tool with "convergent variable-length block deduplication", as well as compression and incremental updates. The tool written in Python and uses a GPLv3 license. Zooko `posted to the backshift group list`_ with the suggestion of combination of the frontend behavior of backshift with the backend storage of Tahoe-LAFS. .. _backshift: http://stromberg.dnsalias.org/~dstromberg/backshift/ .. _`posted to the backshift group list`: https://groups.google.com/group/backshift/browse_thread/thread/61edde867842… Patch Needing Review of the Week ================================ There are four (4) tickets still needing review for 1.10: * `#393`_: mutable: implement MDMF * `#1265`_: New Visualizer is insufficiently labelled/documented (plus layout problem) * `#1398`_: make docs/performance.rst more precise and accurate * `#1566`_: if a stored share has a corrupt header, other shares held by that server for the file should still be accessible to clients .. _`#393`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393 .. _`#1265`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265 .. _`#1398`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1398 .. _`#1566`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566 - ---- *The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS* *Software Foundation, President and Treasurer: Peter Secor* |peter| *. Scribes: Patrick "marlowe" McDonald* |marlowe| *, Zooko Wilcox-O'Hearn* *, Editor: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_ *. Send your news stories to* `marlowe(a)antagonism.org`_ *b submission deadline: Friday night.* .. _marlowe(a)antagonism.org: mailto:marlowe@antagonism.org .. |zooko| image:: zooko.png :height: 35 :alt: zooko :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |brian| image:: warner.png :height: 35 :alt: brian :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |peter| image:: psecor.jpg :height: 35 :alt: peter :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |marlowe| image:: marlowe-x75-bw.jpg :height: 35 :alt: marlowe :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs - -- - ---------------------------------------------------------------- | Patrick R. McDonald GPG Key: A2D1E972 | | https://www.antagonism.org/ <marlowe(a)antagonism.org> | | <mcdonald.patrick.r(a)gmail.com> | | <patrick(a)opensecurityfoundation.org> | - ---------------------------------------------------------------- | Malo periculosam libertatem quam quietum servitium | - ---------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO1X6vAAoJEAT4nRyi0elyhfkQAMy1xGlEWW8dkJ2JwDzqdLI3 yRAJ96SQAQI0GOxr3KrNqGbJnl8BWdwAqtY4nNNyclYLGUaW/YpSFpb/VaYDwmFm crCmP6ndowMWQzU1jc98Op6tsKrX1MDv+NSwR9yyFiYV7ik2Nufb+D9zf698dqef k0TskNPZkT7+N8L9S4swRayDcLMtXSQPtwOjA4T1kEm9Jc/pzH0Mw8snUIn3UfCp nPHErjDAcvTO3MP6kX25vLHLDVUEWkI66ZRrh+4eoVZchIdoXD/DJ0fsIIBpBb5B QcB6v+f42xj9vOyF7RBqkCQ+Hj7J/iJF79AHguAGu7lsVVm1ygev2rL7ncT7Ra8M ckQmkGe5iFmLkO+YkY/+OCfxOBANbtPzOtvgfrqI+iVchjgnX48kcPfSMOI8zIs7 u0u6zBJfxxlzvFy+Janta43Ge209hQYuEoh90r1LtFCvQ+kD2EhJzwCaQIcgPN8o qSTzKNOQgWWsO80/EL3TTBaS1YDtg5yUYXFuxA3gSKC2DmUJd2M4VLcTFCAqmFNQ VF/xnyfAs1D95pv7otYy2jwF2cXmYE2qNs5kjRSImcl9+H+KsLK5O+utKEEFg2tI zYRDSfNWL9PixhBNg/pp8EPGjcZD7oDtBu2Uc6O8yF9UytI3owbhUPaAxwe7woP7 K/VCCuBFWbhylhxUnF0Z =HV15 -----END PGP SIGNATURE----- _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- 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] Tahoe, The Least Authority File System, Thursday Night Hack Meet
by Josh Wilcox 05 Jul '18

05 Jul '18

The Tahoe Least Authority File System is a peer-to-peer system that stores data redundantly with agents who cannot read the data contents. These agents are granted close to the *minimum* authority necessary to support requests about the data. This design is motivated by the "Principle of Least Authority". https://en.wikipedia.org/wiki/Principle_of_least_authority This Thursday (2012-12-06) at 19:00 PST, members of the Tahoe community will have a physical meetup at "The Big Noisebridge Table". We'll project a basic state diagram (https://en.wikipedia.org/wiki/State_diagram) depicting the behaviour of the distributed "Lease Database" that the "storage server" agents in the Tahoe network use to manage the encrypted data that they store. During our meeting we'll add correct and useful content to the diagram. An overview of the design, including the basic state diagram, can be found here: https://github.com/davidsarah/tahoe-lafs/blob/1819-cloud-merge/docs/propose… For a general introduction to Tahoe check this out: https://tahoe-lafs.org Gimme the code!! To understand the behavior of the "lease data base" we'll be inspecting this code (you might want to look at this before Thursday!): https://github.com/davidsarah/tahoe-lafs/tree/master/src/allmydata/ storage/leasedb.py storage/account.py storage/accountant.py storage/accounting_crawler.py storage/server.py (less important) No punch... no pie... just a group building a better Information Super Highway (a series of tubes in The Cyber)! -- Za <--> X8 A question: "What can I buy with bitcoin?" A better question: "What can I sell _for_ bitcoin?" "I want people to see the truth... regardless of who they are... because without information, you cannot make informed decisions as a public" *-- Bradley Manning* <http://allmydata.org> _______________________________________________ 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

[btns] Document Action: 'Problem and Applicability Statement for Better Than Nothing Security (BTNS)' to Informational RFC
by The IESG 05 Jul '18

05 Jul '18

The IESG has approved the following document: - 'Problem and Applicability Statement for Better Than Nothing Security (BTNS) ' <draft-ietf-btns-prob-and-applic-07.txt> as an Informational RFC This document is the product of the Better-Than-Nothing Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-07.txt Technical Summary The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec security mechanisms without authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate. Working Group Summary This document is a product of the Better Than Nothing Security (BTNS) working group. Document Quality This document was reviewed by Sam Hartman for the IESG. Personnel The Document Shepherd for this document is Julien Laganier (BTNS co-chair) and the Responsible Area Director is Tim Polk. _______________________________________________ btns mailing list btns(a)ietf.org https://www.ietf.org/mailman/listinfo/btns ----- 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