July 2018 - cypherpunks-legacy

[gsc] iPhone Loom
by Patrick Chkoreff 06 Jul '18

06 Jul '18

News Update: https://loom.cc/?function=news 2008-01-27 Bill St. Clair has released his iPhone interface for Loom. https://billstclair.com/loom/ip.php Here's a blog entry for it: http://billstclair.com/blog/loom_iphone_client.html -- Patrick

1 0

[tahoe-lafs-weekly-news] TWN 25
by Patrick R McDonald 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ======================================================= Tahoe-LAFS Weekly News, issue number 25, April 07, 2012 ======================================================= 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: https://tahoe-lafs.org .. _View TWN on the web: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: https://tahoe-lafs.org/~marlowe/TWN25.html Announcements and News ====================== TWN Hits Issue #25 - ------------------ With much delay, TWN hits the 25 issue milestone. I had greatly hoped we would reach this milestone much earlier. Unfortunately though work and personal life sometimes got in the way. Even after 25 issues, working on TWN every Friday is one of my favorite activities. I would like to thank the development team at Tahoe-LAFS for giving me the opportunity to contribute this way. Thank you very much. Not one to sit still, present outage excluded, we are working on more ways for you to be able to get your TWN fix. Look for them to be coming in the near future. David-Sarah Named Release Manager for Next Release - -------------------------------------------------- David-Sarah |davidsarah| is the `release manager for Tahoe-LAFS' next release`_. They were previously the release manager for 1.7. Look for their announcement on whether it will a bugfix-oriented 1.9.2 or a shiny new 1.10.0. Among the many other decisions for them, will be whether to continue using darcs and git or finally cut over to git (`#1644`_). .. _`release manager for Tahoe-LAFS' next release`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007215.html .. _`#1644`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1644# Boulder Hackfest - ---------------- Zooko |zooko| `hosted a Tahoe-LAFS hackfest`_ in lovely Boulder, CO. Lots of work got done and I wish I could have attended. David-Sarah did a tremendous job in cleaning up the Trac tickets. This is very much appreciated. Andrew Miller |amiller| wrote a unit test for `#641`_ to make "tahoe backup" follow a limited number of symlinks. Peter Le Bek |lebek| did some work on the wiki and fixed `#1668`_. Brian |brian| fixed `#1689`_. John Dougherty posted his first review. Lastly, I started reviewing documentation patches and resumed work on TWN. And that was just the first day. Thanks to Zooko for sponsoring the event and thanks to all those who attended and contributed. .. _`hosted a Tahoe-LAFS hackfest`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007231.html .. _`#641`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/641 .. _`#1668`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1668 .. _`#1689`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1689 pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958 - ------------------------------------------------------------------ `pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958 was released`_. Aside from having one of the coolest version numbers in existance, pycryptop is "a python wrapper around a few algorithms from the Crypto++ and python-Ed25519 libraries." [`0`_]. Included in this release were the following fixes/features: * src/pycryptopp/_version.py: release pycryptopp-0.6.0 * add Ed25519 signatures (`#75`_) * add XSalsa20 cipher (`#40`_) * switch from darcs to git for revision control * pycryptopp version numbers now include a decimal encoding of b& * reorganize the source tree and the version number generation * aesmodule.cpp: validate size of IV and throw exception if it is not 16 (`#70`_) * fixed compile errors with gcc-4.7.0 (`#78`_) * fixed compile errors concerning "CryptoPP::g_nullNameValuePairs" (`#77`_) * suppress warnings from valgrind with new OpenSSL 1.0.1 on Fedora (`#82`_) * raise Python exception instead of uncaught C++ exception (resulting in abort) when deserializing malformed RSA keys (`#83`_) .. _`pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958 was released`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007119.html .. _`0`: https://pypi.python.org/pypi/pycryptopp .. _`#75`: https://tahoe-lafs.org/trac/pycryptopp/ticket/75 .. _`#40`: https://tahoe-lafs.org/trac/pycryptopp/ticket/40 .. _`#70`: https;//tahoe-lafs.org/trac/pycryptopp/ticket/70 .. _`#78`: https://tahoe-lafs.org/trac/pycryptopp/ticket/78 .. _`#77`: https://tahoe-lafs.org/trac/pycryptopp/ticket/77 .. _`#82`: https://tahoe-lafs.org/trac/pycryptopp/ticket/82 .. _`#83`: https://tahoe-lafs.org/trac/pycryptopp/ticket/83 Signed-Introducer Announcements - ------------------------------- As a result of the new pycryptopp, `signed-introducer code has landed`_ (`#466`_). For users, this means: * tahoe now depends upon the new pycryptopp: next time you update, you'll need to do 'setup.py build' so it will pick up 0.6.0 * the first time your node wakes up with the new code, it will create a NODEDIR/private/server.privkey file, containing the new Ed25519 private signing key. This is a binary file, not meant for copy/paste or human interaction. * server IDs are changing. The old (foolscap-based) IDs look like "rkybwv7hpuwpnyqhwjz43v727orr7fqd". Once everything is upgraded, the Welcome page will show new server IDs that look like "v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". (the old ones are a SHA1 hash of the tub's public SSL certificate, the new ones are an Ed25519 public verifying key) [`1`_] Even more exciting is what this means for the future. Signed-introducer announcements open the door to a good many things: * Introducer announcements are now extensible dictionaries, instead of fixed-size tuples. This allows servers to cleanly advertise new services, and include additional metadata like how much space they have available. This will be used by the upcoming Accounting work to advertise an alternate storage-server object from which per-account connections can be obtained. `#666`_ * Announcements are signed, which means the Introducer doesn't get to modify the metadata, reducing its authority a little bit. This gets us one step closer to having a distributed introduction mechanism (the signed announcements can simply be flooded, without worrying about what the other nodes might do to them in transit). `#68`_ * Server nodes are known by their Ed25519 public verifying key, rather than by their Foolscap SSL TubID. This enables secure non-SSL messaging (sign a request instead of sending unsigned requests over a validated-SSL connection), so we can switch from Foolscap to e.g. HTTP for share transport, which should make the Tahoe protocol easier to port to other languages (Foolscap offers more features than we really need, and its need to check the SSL certificate is an implementation hassle). `#510`_ * Clients can securely reference a server by its pubkey, which will be the basis for explicit "which servers am I willing to use" configuration. `#467`_, `#295`_ [`2`_] .. _`signed-introducer code has landed`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007109.html .. _`#466`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/466 .. _`1`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007109.html .. _`#666`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/666 .. _`#68`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68 .. _`#510`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510 .. _`#467`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/467 .. _`#295`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/295 .. _`2`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007109.html Quote of the Week ================= A good friend of mine had terrific statement regarding Tahoe-LAFS which I wanted to share with everyone. I think her words pretty nicely sum up what makes Tahoe-LAFS really special for the end user. "For cloud security - I trust @tahoelafs. There is no cloud provider in the world I trust but I do trust good crypto." - @catskillmarina - From the tahoe-dev Mailing List =============================== There is a good deal here I want to cover. However, I am still neck deep in emails. I will make sure to bring everyone up to speed on them next week. Thanks again for your patience. Patches Needing Review of the Week ================================== There is one (1) ticket still needing review for 1.9.2: * `#1115`_: add servers-of-happiness to reports (post-repair says 10 hosts have good shares but there only 4 hosts) There are four (4) tickets still needing review for 1.10: * `#1161`_: improve new-downloader logging * `#1579`_: Patch to Add "Move" Functionality to Web Interface problem) * `#443`_: set ETag on immutable directories, short-circuit on cache hit * `#1693`_: flogtool doesn't get automatically provided .. _`#1115`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1115 .. _`#1161`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1161 .. _`#1579`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1579 .. _`#443`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/443 .. _`#1566`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566 .. _`#1693`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1693 - ---- *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 .. |davidsarah| image:: davidsarah_bw.png :height: 35 :alt: davidsarah :target: http://tahoe-lafs.org/trac/tahoe-lafs/wikiAboutUs .. |amiller| image:: amiller_grey.png :height: 35 :alt: amiller .. |lebek| image:: lebek.jpg :height: 35 :alt: lebek -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPgEqIAAoJEAT4nRyi0elyoE0P/jaTefsyu4egrM4xx4UOblp0 9eXMXFWApRHID+KTmALkjLhPbDHtVFTr5P49X/7LiOCj2VCtpYACij9Hs5fSo71i x7fEQtJA6mzUEk4ieqLTZSfAyBF/0c+tIOTUdq4VoPVWnaytAASWQxAe6ZsJLGud 6E2KTTcWomBO/hXmJHoUGjKf2HQ2c2CqEQtc0pqhiPKmpNKSMYd/YHJthyJBcbhn DQ9kjcAbj6QuRtMx5UJzTHIE0DfygqfnmDRw0R/W0l15kYSfOnsJndzoiqW7Jutn wwO0ZgFkHpWo4DmyI9Kx7S0K2yEm6YdHNGKc1z1dEexhbu0DaF1y+V/Asd4llAwB eIs1Kj1nz2LlqDsLVNJUsr06BkP5Qisb93AgUD+woRB967EW15OfABXR10gxtbDh yVQvn3jcYEJOK4AAQmQoRZSYf7iNC8vsex/rKulkQetGvqFZcj2uPYoFRoz0Q0Lo IQCt8JtmSsA+cHKqqomipmQM0lH7cM5WOLkFzhYoHsOnJuQ2503PMLn74JMX0nek ZJLE8W3qG+dpQBDEfRPYUMJsqrkHAhElC0g6eC/L3ZVFKlIMryv3BFLlxU4WUWzs Kq/OcEO4bEm0z2uMnGgotL6MMu8zUPXcGQsYddUn6nXsuuXYh+26AEL5NeF6Sb5I YkmNkuXUo8K92ZqxKIwP =E4Th -----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

None
by Catherine Meadows 06 Jul '18

06 Jul '18

Paul: The IETF has been discussing setting up a working group for anonymous IPSec. They will have a BOF at the next IETF in DC in November. They're also setting up a mailing list you might be interested in if you haven't heard about it already. Information is below. At 10:08 PM -0700 9/6/04, Joe Touch wrote: >Hi, all, > >To follow-up on related presentations at both SAAG and TCPM, we've >created a mailing list for discussions of anonymous security. > >Further information on the list and how to join it, as well as >pointers to related resources can be found at: > > http://www.postel.org/anonsec > >The mailing list address is: anonsec(a)postel.org > >Joe > Cathy ----- End forwarded message ----- _______________________________________________ NymIP-res-group mailing list NymIP-res-group(a)nymip.org http://www.nymip.org/mailman/listinfo/nymip-res-group --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

potential new IETF WG on anonymous IPSec
by Paul Syverson 06 Jul '18

06 Jul '18

----- Forwarded message from Catherine Meadows <meadows(a)itd.nrl.navy.mil> -----

1 0

[tahoe-lafs-weekly-news] TWN 25
by Patrick R McDonald 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ======================================================= Tahoe-LAFS Weekly News, issue number 25, April 07, 2012 ======================================================= 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: https://tahoe-lafs.org .. _View TWN on the web: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: https://tahoe-lafs.org/~marlowe/TWN25.html Announcements and News ====================== TWN Hits Issue #25 - ------------------ With much delay, TWN hits the 25 issue milestone. I had greatly hoped we would reach this milestone much earlier. Unfortunately though work and personal life sometimes got in the way. Even after 25 issues, working on TWN every Friday is one of my favorite activities. I would like to thank the development team at Tahoe-LAFS for giving me the opportunity to contribute this way. Thank you very much. Not one to sit still, present outage excluded, we are working on more ways for you to be able to get your TWN fix. Look for them to be coming in the near future. David-Sarah Named Release Manager for Next Release - -------------------------------------------------- David-Sarah |davidsarah| is the `release manager for Tahoe-LAFS' next release`_. They were previously the release manager for 1.7. Look for their announcement on whether it will a bugfix-oriented 1.9.2 or a shiny new 1.10.0. Among the many other decisions for them, will be whether to continue using darcs and git or finally cut over to git (`#1644`_). .. _`release manager for Tahoe-LAFS' next release`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007215.html .. _`#1644`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1644# Boulder Hackfest - ---------------- Zooko |zooko| `hosted a Tahoe-LAFS hackfest`_ in lovely Boulder, CO. Lots of work got done and I wish I could have attended. David-Sarah did a tremendous job in cleaning up the Trac tickets. This is very much appreciated. Andrew Miller |amiller| wrote a unit test for `#641`_ to make "tahoe backup" follow a limited number of symlinks. Peter Le Bek |lebek| did some work on the wiki and fixed `#1668`_. Brian |brian| fixed `#1689`_. John Dougherty posted his first review. Lastly, I started reviewing documentation patches and resumed work on TWN. And that was just the first day. Thanks to Zooko for sponsoring the event and thanks to all those who attended and contributed. .. _`hosted a Tahoe-LAFS hackfest`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007231.html .. _`#641`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/641 .. _`#1668`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1668 .. _`#1689`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1689 pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958 - ------------------------------------------------------------------ `pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958 was released`_. Aside from having one of the coolest version numbers in existance, pycryptop is "a python wrapper around a few algorithms from the Crypto++ and python-Ed25519 libraries." [`0`_]. Included in this release were the following fixes/features: * src/pycryptopp/_version.py: release pycryptopp-0.6.0 * add Ed25519 signatures (`#75`_) * add XSalsa20 cipher (`#40`_) * switch from darcs to git for revision control * pycryptopp version numbers now include a decimal encoding of b& * reorganize the source tree and the version number generation * aesmodule.cpp: validate size of IV and throw exception if it is not 16 (`#70`_) * fixed compile errors with gcc-4.7.0 (`#78`_) * fixed compile errors concerning "CryptoPP::g_nullNameValuePairs" (`#77`_) * suppress warnings from valgrind with new OpenSSL 1.0.1 on Fedora (`#82`_) * raise Python exception instead of uncaught C++ exception (resulting in abort) when deserializing malformed RSA keys (`#83`_) .. _`pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958 was released`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007119.html .. _`0`: https://pypi.python.org/pypi/pycryptopp .. _`#75`: https://tahoe-lafs.org/trac/pycryptopp/ticket/75 .. _`#40`: https://tahoe-lafs.org/trac/pycryptopp/ticket/40 .. _`#70`: https;//tahoe-lafs.org/trac/pycryptopp/ticket/70 .. _`#78`: https://tahoe-lafs.org/trac/pycryptopp/ticket/78 .. _`#77`: https://tahoe-lafs.org/trac/pycryptopp/ticket/77 .. _`#82`: https://tahoe-lafs.org/trac/pycryptopp/ticket/82 .. _`#83`: https://tahoe-lafs.org/trac/pycryptopp/ticket/83 Signed-Introducer Announcements - ------------------------------- As a result of the new pycryptopp, `signed-introducer code has landed`_ (`#466`_). For users, this means: * tahoe now depends upon the new pycryptopp: next time you update, you'll need to do 'setup.py build' so it will pick up 0.6.0 * the first time your node wakes up with the new code, it will create a NODEDIR/private/server.privkey file, containing the new Ed25519 private signing key. This is a binary file, not meant for copy/paste or human interaction. * server IDs are changing. The old (foolscap-based) IDs look like "rkybwv7hpuwpnyqhwjz43v727orr7fqd". Once everything is upgraded, the Welcome page will show new server IDs that look like "v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". (the old ones are a SHA1 hash of the tub's public SSL certificate, the new ones are an Ed25519 public verifying key) [`1`_] Even more exciting is what this means for the future. Signed-introducer announcements open the door to a good many things: * Introducer announcements are now extensible dictionaries, instead of fixed-size tuples. This allows servers to cleanly advertise new services, and include additional metadata like how much space they have available. This will be used by the upcoming Accounting work to advertise an alternate storage-server object from which per-account connections can be obtained. `#666`_ * Announcements are signed, which means the Introducer doesn't get to modify the metadata, reducing its authority a little bit. This gets us one step closer to having a distributed introduction mechanism (the signed announcements can simply be flooded, without worrying about what the other nodes might do to them in transit). `#68`_ * Server nodes are known by their Ed25519 public verifying key, rather than by their Foolscap SSL TubID. This enables secure non-SSL messaging (sign a request instead of sending unsigned requests over a validated-SSL connection), so we can switch from Foolscap to e.g. HTTP for share transport, which should make the Tahoe protocol easier to port to other languages (Foolscap offers more features than we really need, and its need to check the SSL certificate is an implementation hassle). `#510`_ * Clients can securely reference a server by its pubkey, which will be the basis for explicit "which servers am I willing to use" configuration. `#467`_, `#295`_ [`2`_] .. _`signed-introducer code has landed`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007109.html .. _`#466`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/466 .. _`1`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007109.html .. _`#666`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/666 .. _`#68`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68 .. _`#510`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510 .. _`#467`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/467 .. _`#295`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/295 .. _`2`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007109.html Quote of the Week ================= A good friend of mine had terrific statement regarding Tahoe-LAFS which I wanted to share with everyone. I think her words pretty nicely sum up what makes Tahoe-LAFS really special for the end user. "For cloud security - I trust @tahoelafs. There is no cloud provider in the world I trust but I do trust good crypto." - @catskillmarina - From the tahoe-dev Mailing List =============================== There is a good deal here I want to cover. However, I am still neck deep in emails. I will make sure to bring everyone up to speed on them next week. Thanks again for your patience. Patches Needing Review of the Week ================================== There is one (1) ticket still needing review for 1.9.2: * `#1115`_: add servers-of-happiness to reports (post-repair says 10 hosts have good shares but there only 4 hosts) There are four (4) tickets still needing review for 1.10: * `#1161`_: improve new-downloader logging * `#1579`_: Patch to Add "Move" Functionality to Web Interface problem) * `#443`_: set ETag on immutable directories, short-circuit on cache hit * `#1693`_: flogtool doesn't get automatically provided .. _`#1115`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1115 .. _`#1161`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1161 .. _`#1579`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1579 .. _`#443`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/443 .. _`#1566`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566 .. _`#1693`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1693 - ---- *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 .. |davidsarah| image:: davidsarah_bw.png :height: 35 :alt: davidsarah :target: http://tahoe-lafs.org/trac/tahoe-lafs/wikiAboutUs .. |amiller| image:: amiller_grey.png :height: 35 :alt: amiller .. |lebek| image:: lebek.jpg :height: 35 :alt: lebek -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPgEqIAAoJEAT4nRyi0elyoE0P/jaTefsyu4egrM4xx4UOblp0 9eXMXFWApRHID+KTmALkjLhPbDHtVFTr5P49X/7LiOCj2VCtpYACij9Hs5fSo71i x7fEQtJA6mzUEk4ieqLTZSfAyBF/0c+tIOTUdq4VoPVWnaytAASWQxAe6ZsJLGud 6E2KTTcWomBO/hXmJHoUGjKf2HQ2c2CqEQtc0pqhiPKmpNKSMYd/YHJthyJBcbhn DQ9kjcAbj6QuRtMx5UJzTHIE0DfygqfnmDRw0R/W0l15kYSfOnsJndzoiqW7Jutn wwO0ZgFkHpWo4DmyI9Kx7S0K2yEm6YdHNGKc1z1dEexhbu0DaF1y+V/Asd4llAwB eIs1Kj1nz2LlqDsLVNJUsr06BkP5Qisb93AgUD+woRB967EW15OfABXR10gxtbDh yVQvn3jcYEJOK4AAQmQoRZSYf7iNC8vsex/rKulkQetGvqFZcj2uPYoFRoz0Q0Lo IQCt8JtmSsA+cHKqqomipmQM0lH7cM5WOLkFzhYoHsOnJuQ2503PMLn74JMX0nek ZJLE8W3qG+dpQBDEfRPYUMJsqrkHAhElC0g6eC/L3ZVFKlIMryv3BFLlxU4WUWzs Kq/OcEO4bEm0z2uMnGgotL6MMu8zUPXcGQsYddUn6nXsuuXYh+26AEL5NeF6Sb5I YkmNkuXUo8K92ZqxKIwP =E4Th -----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: cleversafe says: 3 Reasons Why Encryption is Overrated
by Jerry Leichter 06 Jul '18

06 Jul '18

>3. Cleversafe should really tone down the Fear Uncertainty and >Doubt about today's encryption being mincemeat for tomorrow's >cryptanalysts. It might turn out to be true, but if so it will be >due to cryptanalytic innovations more than due to Moore's Law. And >it might not turn out like that -- perhaps AES-256 will remain safe >for centuries. Also, Cleversafe's product is not more secure than >any other product against this threat. Since people do keep bringing up Moore's Law in an attempt to justify larger keys our systems "stronger than cryptography," it's worth keeping in mind that we are approaching fairly deep physical limits. I wrote about this on this list quite a while back. If current physical theories are even approximately correct, there are limits to how many "bit flips" (which would encompass all possible binary operations) can occur in a fixed volume of space-time. You can turn this into a limit based solely on time through the finite speed of light: A computation that starts at some point and runs for n years can't involve a volume of space more than n light years in radius. (This is grossly optimistic - if you want the results to come back to the point where you entered the problem, the limit is n/2 light years, which has 1/8 the spacial volume). I made a very approximate guess at how many bit-flips you could get in a time-space volume of a 100 light- year sphere; the answer came out somewhere between 2^128 and 2^256, though much closer to the former. So physical limits prevent you from doing a brute force scan - in fact, you can't even enumerate all possible keys - in 100 years for key lengths somewhere not much more than 128 bits. It's rather remarkable that such fundamental limits on computation exist at all, but physics over the last 100 years - and especially over the last couple of decades - has increasingly shown us that the world is neither continuous nor infinite; it has solid finite limits on almost everything. Even more remarkable is that we've pretty much reached some of those limits. For any recently designed cryptosystem, brute force is simply out of the question, and will remains so forever (unless we are very much mistaken about physics). Moore's Law as a justification for using "something more" makes no sense. As you point out, the story for advances in cryptographic theory is much more complex and impossible to predict. That cryptographic advances would render the "safer" AES-256 at risk while AES-128 remains secure (for now) is something no one could have predicted, though in retrospect some of the concerns about the key scheduling may have been right. All the protocols and standards out there calling for AES-256 - it's obviously "better" than AES-128 because after all 256 is *twice as large* as 128! - were just a bunch of nonsense. And, perhaps, dangerous nonsense. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- 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

Torpark v.1.5.0.3 pre-release
by Arrakistor 06 Jul '18

06 Jul '18

Howdy all, New version of Torpark available. Here is the english demo without NoScript. I'll have the rest of the packages built a little later. Let me know if you find any bugs. Also, if anyone has win95 or win98 running, I would be interested to find out how it turns out. Changes: - Using Tor v0.1.1.18 - Tor log file is written to the temp directory while Torpark is running. - all plugins now write to the executable temp direcory instead of the local directory. Directory is deleted when Torpark exits. - ExecDos.dll garbage bug fixed - NoScript WILL be added for this next version, as javascript sites have been quietly loading disallowed flash plugins, compromising security. - Torpark is again, smaller and faster. New splash as well. Download here: http://omega.uta.edu/~sxt6146/torpark_1.5.0.3_demo.exe Regards, Steve Topletz ----- 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: cleversafe says: 3 Reasons Why Encryption is Overrated
by Jerry Leichter 06 Jul '18

06 Jul '18

>3. Cleversafe should really tone down the Fear Uncertainty and >Doubt about today's encryption being mincemeat for tomorrow's >cryptanalysts. It might turn out to be true, but if so it will be >due to cryptanalytic innovations more than due to Moore's Law. And >it might not turn out like that -- perhaps AES-256 will remain safe >for centuries. Also, Cleversafe's product is not more secure than >any other product against this threat. Since people do keep bringing up Moore's Law in an attempt to justify larger keys our systems "stronger than cryptography," it's worth keeping in mind that we are approaching fairly deep physical limits. I wrote about this on this list quite a while back. If current physical theories are even approximately correct, there are limits to how many "bit flips" (which would encompass all possible binary operations) can occur in a fixed volume of space-time. You can turn this into a limit based solely on time through the finite speed of light: A computation that starts at some point and runs for n years can't involve a volume of space more than n light years in radius. (This is grossly optimistic - if you want the results to come back to the point where you entered the problem, the limit is n/2 light years, which has 1/8 the spacial volume). I made a very approximate guess at how many bit-flips you could get in a time-space volume of a 100 light- year sphere; the answer came out somewhere between 2^128 and 2^256, though much closer to the former. So physical limits prevent you from doing a brute force scan - in fact, you can't even enumerate all possible keys - in 100 years for key lengths somewhere not much more than 128 bits. It's rather remarkable that such fundamental limits on computation exist at all, but physics over the last 100 years - and especially over the last couple of decades - has increasingly shown us that the world is neither continuous nor infinite; it has solid finite limits on almost everything. Even more remarkable is that we've pretty much reached some of those limits. For any recently designed cryptosystem, brute force is simply out of the question, and will remains so forever (unless we are very much mistaken about physics). Moore's Law as a justification for using "something more" makes no sense. As you point out, the story for advances in cryptographic theory is much more complex and impossible to predict. That cryptographic advances would render the "safer" AES-256 at risk while AES-128 remains secure (for now) is something no one could have predicted, though in retrospect some of the concerns about the key scheduling may have been right. All the protocols and standards out there calling for AES-256 - it's obviously "better" than AES-128 because after all 256 is *twice as large* as 128! - were just a bunch of nonsense. And, perhaps, dangerous nonsense. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- 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

Torpark v.1.5.0.3 pre-release
by Arrakistor 06 Jul '18

06 Jul '18

Howdy all, New version of Torpark available. Here is the english demo without NoScript. I'll have the rest of the packages built a little later. Let me know if you find any bugs. Also, if anyone has win95 or win98 running, I would be interested to find out how it turns out. Changes: - Using Tor v0.1.1.18 - Tor log file is written to the temp directory while Torpark is running. - all plugins now write to the executable temp direcory instead of the local directory. Directory is deleted when Torpark exits. - ExecDos.dll garbage bug fixed - NoScript WILL be added for this next version, as javascript sites have been quietly loading disallowed flash plugins, compromising security. - Torpark is again, smaller and faster. New splash as well. Download here: http://omega.uta.edu/~sxt6146/torpark_1.5.0.3_demo.exe Regards, Steve Topletz ----- 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: Copyright infringement notice
by Anne P. Mitchell, Esq. 06 Jul '18

06 Jul '18

> > > The 6 strikes system doesn't kick in til Jan 2013 AFAIK. My understanding was that it started kicking in last month, but in any event, for whomever sent the original poster the complaint, it's clearly in effect now. > > Does the legal letter make any kind of demand? Usually the sender (aka copyright troll - a technical term) will be looking for personal info to associate with the IP in order to institute a shakedown of some nature. IANAL but I believe one can wait for a subpoena, and even then it's not open and closed. Actually under the "copyright alert" scheme, the ISPs specifically are *not* to give up personal information, they are simply to take the IP address being reported as downloading copyrighted material, and determine *internally* who the user is, and then send the user the copyright alert, *without* sharing with the accuser who the user is. And yes, in order to share user information forward-facing, one not only can - but one *should* - insist on a subpoena, as that will protect you from breach and invasion of privacy allegations by your own users (assuming your TOS, as it should, says something like "we will not share your private information *unless* required to by law" (and, IAAL :-) ). Anne Anne P. Mitchell, Esq CEO/President Institute for Social Internet Public Policy http://www.ISIPP.com Member, Cal. Bar Cyberspace Law Committee How do you get legitimate email through in a spam-filtered world? SuretyMail! Helping businesses get their email delivered to the inbox since 1998 http://www.isipp.com/SuretyMail Author, "They're Your Kids Too: The Single Father's Guide to Defending Your Fatherhood in a Broken Family Law System" http://www.amazon.com/Theyre-Your-Kids-Too-Fatherhood/dp/061551443X ----- 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