- cypherpunks-legacy - lists.cpunks.org

[Politech] License plate scanning: Balancing privacy with public safety, efficiency [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

Previous Politech message: http://www.politechbot.com/2006/08/01/indianapolis-police-test/ -------- Original Message -------- Subject: indianapolis police test camera-scanner that reads license plates Date: Wed, 9 Aug 2006 11:13:28 -0700 (PDT) From: Andrew Blumberg <blumberg(a)math.Stanford.EDU> To: declan(a)well.com References: <Pine.LNX.4.64.0608021133170.5718(a)math.uchicago.edu> hi declan, because of the necessity of having such devices for congestion pricing, not to mention their use in automatic traffic enforcement (e.g. catching stoplight violations), it seems likely that in a decade there will be ubiquitous monitoring of license plates in most metropolitan areas. this is really bad, from the perspective of "driver privacy" --- it means that it is easy for the state to track the motion of individual drivers, which could be the basis for obvious and disturbing abuses. on the other hand, as you point out there are compelling reasons to want such ubiquitous tracking --- congestion pricing is a good thing, and there are public safety benefits. some collaborators and i wrote a few papers on how to balance these concerns --- we designed a system which allows the state to catch traffic violators, without sacrificing driver privacy. similarly, one can do congestion pricing in a similarly privacy-preserving way. the solution involves monitoring devices on every corner, reading from transponders (like EZ-pass) in each car. but by using crytographic protocols (relying heavily on digital signatures and zero-knowledge interactions), the state can catch "bad guys" without compelling law-abiding citizens to give up their privacy. if you're interested, our papers on the subject are available at http://math.stanford.edu/~blumberg/driving.pdf and http://math.stanford.edu/~blumberg/congestion.pdf. regards, andrew _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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: [roy@rant-central.com: Re: [jwales@wikia.com: Re:
by Jimmy Wales 06 Jul '18

06 Jul '18

Eugen Leitl wrote: >>What is it that we don't get? > > That Tor is working as designed, and that the problem with bad actors using its > cloak is a problem with the actors themselves. "Finally, we note that exit abuse must not be dismissed as a peripheral issue: when a system's public image suffers, it can reduce the number and diversity of that system's users, and thereby reduce the anonymity of the system itself." I'm pleased to report that the original design documents rightly agree with me that the it is in the interest of the longterm success of the Tor project that an attitude of throwing up our hands in defeat is not enough. > Those people are not sticking their heads in the sand. They're correctly noting > that nothing is broken except the bad actors. That *is* sticking their heads in the sand. Yes, we can lay moral blame on the bad actors. That's fine. Let's all stop typing for a minute or two and just _hate_ them for it. Ok, now we all feel better. :-) But now we're back to the question: how can Tor be improved to deal with this very serious and important problem? What are the steps that might be taken, however imperfect, to reduce the amount of abuse coming from Tor nodes? --Jimbo ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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

[p2p-hackers] f2f for purposes other than privacy
by zooko＠zooko.com 06 Jul '18

06 Jul '18

Ian Clarke wrote: > > We (Freenet) have > been concerned about the fact that Freenet was harvestable for several > years now. Around spring this year I made the observation that if > human relationships form a small world network, it should be possible > to assign locations to people such that we form a Kleinberg-style > small world network, and thus we could make the network routable. > Oskar Sandberg then suggested a way to do this, and we set about > validating the concept using simulations. I would love to learn more. Is there a white-paper or design document beyond these slides from DefCon [1]? > Are you aware of any current or proposed f2f > networks for which concealment of user activity is not a goal? Well, I think of the links between two friends in f2f to be not solely communication channels but also to have other meaning. For example, if friends transmit music files to one another, then in addition to any privacy properties that the network may have, it also serves as a decentralized, attack-resistant recommendation engine for music. Honestly, this area of research is ripe for exploration, but I can give you at least a couple of examples. Doceur set it up with a claimed general negative result in "The Sybil Attack" in 2002 [2]. But his general negative result isn't quite true, as disproven by e.g. Advogato, 2000 [3, 4, 5]. Recently George Danezis, Chris Lesniewski-Laas, M. Frans Kaashoek, and Ross Anderson smashed these two ideas together and mixed in some DHT routing: [6]. [6] is an excellent paper, which proposes a concrete DHT design and which really nails the fact that the introduction graph or "bootstrap graph" contains information which can defeat the allegedly undefeatable Sybil Attack. [6] references some related work which looks interesting, but I haven't followed those links yet myself. I guess [6] is somewhat relevant to the Freenet v0.7 design. So, uh, anyway, this shows that there is interest in the notion of using friendship networks for purposes other than privacy, namely attack resistance of DHT routing and attack resistance of metadata [7 (self-citation)]. I think there's a lot more value to be mined from this concept, and I'm really glad that it has finally gotten the attention of some p2p researchers. Oh, and here's another perspective on this idea -- a post I wrote to my blog a few years ago suggesting that all sorts of DHT innovations which were intended to improve network performance could be applied to attack resistance: "trust is just another topology" [8]. Regards, Zooko [1] http://freenetproject.org/papers/vegas1_dc.pdf [2] http://citeseer.ist.psu.edu/douceur02sybil.html [3] http://www.advogato.org/trust-metric.html [4] http://www.levien.com/thesis/compact.pdf [5] http://www.levien.com/free/tmetric-HOWTO.html [6] http://pdos.csail.mit.edu/cgi-bin/pubs-date.cgi?match=Sybil-resistant+DHT+r… ting [7] http://conferences.oreillynet.com/cs/p2p2001/view/e_sess/1200 [8] http://www.zooko.com/log-2003-01.html#d2003-01-23-trust_is_just_another_top… ogy _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- 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

[Politech] License plate scanning: Balancing privacy with public safety, efficiency [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

Previous Politech message: http://www.politechbot.com/2006/08/01/indianapolis-police-test/ -------- Original Message -------- Subject: indianapolis police test camera-scanner that reads license plates Date: Wed, 9 Aug 2006 11:13:28 -0700 (PDT) From: Andrew Blumberg <blumberg(a)math.Stanford.EDU> To: declan(a)well.com References: <Pine.LNX.4.64.0608021133170.5718(a)math.uchicago.edu> hi declan, because of the necessity of having such devices for congestion pricing, not to mention their use in automatic traffic enforcement (e.g. catching stoplight violations), it seems likely that in a decade there will be ubiquitous monitoring of license plates in most metropolitan areas. this is really bad, from the perspective of "driver privacy" --- it means that it is easy for the state to track the motion of individual drivers, which could be the basis for obvious and disturbing abuses. on the other hand, as you point out there are compelling reasons to want such ubiquitous tracking --- congestion pricing is a good thing, and there are public safety benefits. some collaborators and i wrote a few papers on how to balance these concerns --- we designed a system which allows the state to catch traffic violators, without sacrificing driver privacy. similarly, one can do congestion pricing in a similarly privacy-preserving way. the solution involves monitoring devices on every corner, reading from transponders (like EZ-pass) in each car. but by using crytographic protocols (relying heavily on digital signatures and zero-knowledge interactions), the state can catch "bad guys" without compelling law-abiding citizens to give up their privacy. if you're interested, our papers on the subject are available at http://math.stanford.edu/~blumberg/driving.pdf and http://math.stanford.edu/~blumberg/congestion.pdf. regards, andrew _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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: [liberationtech] Forbes recommends tools for journalists
by Steve Weis 06 Jul '18

06 Jul '18

Just to go further down the tech tangent... There are SSD drives with full-disk encryption, such as the Intel 520 series. Here's a paper "Reliably Erasing Data From Flash-Based Solid State Drives" from Usenix 2011 that analyzes disk sanitation on several SSD drives. Their conclusion was that built in encryption and sanitization functions were most effective, but were not always implemented correctly: http://static.usenix.org/events/fast11/tech/full_papers/Wei.pdf Regarding storage for disk-encryption keys, PCs with TPMs can seal keys such that they can only be unsealed if the machine is booted to a verifiable state. Then you can leave the sealed key on the disk, which is how Bitlocker works. Keep in mind that TPMs can be compromised by physical attacks. They aren't going to protect you from a moderately-funded forensics effort. But if you're getting information security advice from a Forbes blog, that will be the least of your worries. On Mon, Dec 17, 2012 at 1:42 PM, Michael Rogers <michael(a)briarproject.org>wrote: > I'm not aware of any suitable storage on current smartphones or > personal computers, so we may need to ask device manufacturers to add > (simple, inexpensive) hardware to their devices to support secure > deletion. > -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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] TWN17
by Patrick R McDonald 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ========================================================== Tahoe-LAFS Weekly News, issue number 17, November 22, 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/TWN17.html Announcements and News ====================== 1.9 Released - ------------ With all the spooky things which came out during Halloween, we also saw the `release of 1.9.0`_. 1.9.0 offers a new mutable-file format, MDMF_ (more efficient for large files), a `file-blacklisting`_ feature, and a new "`drop-upload`_" feature. A big thanks goes to Brian Warner |brian|, release manager, and the `rest of development team`_ for such a fantastic release. .. _`release of 1.9.0`: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-October/006810.html .. _MDMF: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/specifications/mu… .. _`file-blacklisting`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1425 .. _`drop-upload`: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/drop-up… .. _`rest of development team`: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/CREDITS?rev=5356 New Server - ---------- In the dark of many a night, the Tahoe-LAFS ninjas `migrated`_ tahoe-lafs.org to a brand new server. You should noticed improved speed and responsiveness from our new server. I would thank the ninjas, but I can't seem to find them. Sneaky ninjas :) .. _migrated: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-October/006759.html Tahoe-LAFS Summit - ----------------- Tahoe-LAFS held its `second Tahoe-LAFS Summit`_ from November 7 through 11. The Summit was a huge success. Below is some of the agenda items covered during the Summit: * Review: Tahoe-LAFS v1.9 release, LAE_ |LAE| product launch * Brian explained how his `#466`_ `signed-introducer code`_ works, committed to a public-key signature scheme * decided upon a safe "web control panel" scheme * explained how Brian's `#666`_ `Accounting code`_ works * discussed how accounting, `#467`_ static-server-selection, and Invitations should interact, so Brian knows what to build going forward * discussed Performance Improvements, HTTP-only Storage Protocols, New Encoding Formats (Rainhill_!) * Thursday items: explained LAE's s3-backend branch, designed race-free Accounting leasedb-crawler * Friday items: explained Rainhill We have a report of the activities for each day: * `Day 1`_ * `Day 2`_ * `Day 3`_ * `Day 4`_ Lastly, we would like to thank `Mozilla`_ |mozilla| for their wonderful hospitality and those folks who made the video streams possible. As someone who couldn't make it, I really appreciate the latter. .. _`second Tahoe-LAFS Summit`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit .. _LAE: http://leastauthority.com .. |LAE| image:: LAE.png :height: 35 :alt: Least Authority Enterprises :target: http://leastauthority.com .. _`#466`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/466 .. _`signed-introducer code`: https://github.com/warner/tahoe-lafs/tree/466-ed25519 .. _`#666`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/666 .. _`Accounting code`: https://github.com/warner/tahoe-lafs/tree/accounting .. _`#467`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/467 .. _Rainhill: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/NewCaps/Rainhill .. _`Day 1`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day1 .. _`Day 2`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day2 .. _`Day 3`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day3 .. _`Day 4`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day4 .. _`Mozilla`: http://www.mozilla.com .. |mozilla| image:: Mozilla_logo-35x35.svg :height: 35 :alt: Mozilla :target: http://www.mozilla.com - From the tahoe-dev Mailing List =============================== Visualizer - ---------- Brian Warner landed a new verison of the immutable-file download visualizer, replacing the early version in 1.9.0 with one that zooms and pans faster. The visualizer is useful for studying the progress and significant events in an immutable-file download. This can aid you and developers determine any possible issues with a download. .. _visualizer: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-November/006812.html Buildslaves Need Update - ----------------------- With the migration to the new server, buildslave operators `need to update`_ their buildslaves to point to the new server. .. _`need to update`: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-November/006816.html FreedomBox Posting - ------------------ Zooko |zooko| posted a `fantastic description`_ of Tahoe-LAFS to the `FreedomBox discuss list`_. He covered ways in which Tahoe-LAFS resembles a filesystem, arbitrarily nestable directories and files and a built in SFTP server. However, its performance characteristics fail to match the expectations of user-space programs that access their storage through the POSIX filesystem API. I believe the following sums it up best, "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." [1_] .. _`fantastic description`: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-November/0… .. _`FreedomBox discuss list`: http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss .. _1: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-November/0… Patch Needing Review of the Week ================================ There are six (6) 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 * `#1557`_: apply coding tools to misc/ directories other than misc/build_helpers * `#1566`_: if a stored share has a corrupt header, other shares held by that server for the file should still be accessible to clients * `#1568`_: S3 backend: [storage]readonly is documented but ignored .. _`#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 .. _`#1557`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1557 .. _`#1566`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566 .. _`#1568`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1568 - ---- *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) iQIcBAEBCAAGBQJOy5oxAAoJEAT4nRyi0elyojkP/0KUZAsshxsMe5LKIWKf63x0 cnlvX8rApAlZJIFB09fS9YD0Nd++w77EkwWF/PRz2/RhX69UpwmySR7E6eS180h9 AXVnGm9FyvmzSor3VcbhOC9Aj4hl9qJNxNu/UrIQHXo1+SeJDx7cj6KlPjEHwNzN WLAPjikUMXDgmvk5Wgb44oPUWG7slw4Rqv17pigtfdctoAcMqAOStu9SxSy0W8dR xbaCufejyQ7vaC8dQ7f/bsRPNSmbKIVzWMdEfLIxwRv6oxc+1b/sQCweSQy0jKxJ rfQRhsZByTc2BddSWxrgZWHJxu5e9Q0yCIzzbExjEqyMKKdZs8FpOcvr3miP5sAh QNirRw3GYcR7VByDVuTDVBSrvjSj5Xo8C6zp3q9inHuxuS1u+Q8Xm6jN299NJ8cW HyZ/7V6ycbeFZDmDEgKMEOnPvDDEGdlDYHc6gNGr9R/F7lDNUOI82AXCPN+oXBMk 35jzPql/YVod2NI8tmPjOHc5Z+HBCm2ohwh6NY/bTDAgfjEwXxTHAxZCTQoAWjIh 9hhz0iFpD2CGdcUI6jNWLiWninbh/IwFKmKHVjeO9x5orKcKhZjfpAjN57JAX30m y7He0B+aY1/7bZDLoLe6yRl26uxFl6vNJg4ius2goDvlCbAUFVtVqiM9To84TzWg x6GHnJfukpI8tKT7oM4u =0r7c -----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] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
by Peter Gutmann 06 Jul '18

06 Jul '18

Adam Back <adam(a)cypherspace.org> writes: >a public MitM proxy? Or a corporate LAN. Private organisation. >That intermediate CA needs publishing, and the CA that issued it. I was asked not to reveal details and I won't, but in any case I don't know whether it would achieve much. For the case of a public CA doing it, you'd see that CA X is involved, but since it's quite likely that CAs A...W and Y...Z are also at the party, all it'd do is focus people's ire on one entity. Also, if this is being done by a private organisation for DPI to secure their corporate LAN then they're probably quite within their rights to do it. I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. >It breaks a clear expectation of security and privacy the user, even very >sophisitcated user, has about privacy of their communications. Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that in whatever way they want. >1. private label sub-CA (where the holder has signed an agreement not to >issue certs for domains they do not own - I know its policy only, there is no >crypto enforced mechanism, but thats the same bar as the main CAs themselves). For the cases where I've been involved I wasn't aware of there being anything like this in the agreements (actually there probably was something somewhere, I didn't look through all the paperwork). I still have at least some of the documentation stored somewhere (NB: Not under NDA and with the agreement of the parties involved, it was an interesting case study on how these things work), if I ever manage to dig it up I'll see what the conditions were. In any case though it was honour-system security, if you really wanted to do bad things there weren't any controls that I could see to stop you. >3. public provider SSL MitM - if your ISP, wifi hotspot, 3g data prov, is >doing this to you, paid or free, thats illegal IMO. Heads should roll up the >CA tree. I think this is where we differ in our outlook. This (and yeah, I'd still like to see the certs for one of these from a public location :-) is business as usual for commercial PKI. Remember the link to the SonicWall docs I posted a few days ago, http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI-SSL_Feature_Mod… It's an advertised feature of the hardware (not just from SonicWall, other vendors do it too), d'you think people are going to buy that and then not make use of it? So you just build your defences around the fact that it's broken and then you won't run into problems. Oh, another place where this happens is WAP gateways, where they MITM everything so they can rewrite the content to save bandwidth and make things work on mobile devices. So, is that bad, or good, or both, or neither? >I guess in corporate LANs and that itself employees should be aware of that. I think employees just need to be aware that a corporate LAN is owned by your employer, and run for their benefit, not yours. If you want to do $non_work_related_whatever, do it from your home system. Peter. _______________________________________________ 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] TWN17
by Patrick R McDonald 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ========================================================== Tahoe-LAFS Weekly News, issue number 17, November 22, 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/TWN17.html Announcements and News ====================== 1.9 Released - ------------ With all the spooky things which came out during Halloween, we also saw the `release of 1.9.0`_. 1.9.0 offers a new mutable-file format, MDMF_ (more efficient for large files), a `file-blacklisting`_ feature, and a new "`drop-upload`_" feature. A big thanks goes to Brian Warner |brian|, release manager, and the `rest of development team`_ for such a fantastic release. .. _`release of 1.9.0`: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-October/006810.html .. _MDMF: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/specifications/mu… .. _`file-blacklisting`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1425 .. _`drop-upload`: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/drop-up… .. _`rest of development team`: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/CREDITS?rev=5356 New Server - ---------- In the dark of many a night, the Tahoe-LAFS ninjas `migrated`_ tahoe-lafs.org to a brand new server. You should noticed improved speed and responsiveness from our new server. I would thank the ninjas, but I can't seem to find them. Sneaky ninjas :) .. _migrated: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-October/006759.html Tahoe-LAFS Summit - ----------------- Tahoe-LAFS held its `second Tahoe-LAFS Summit`_ from November 7 through 11. The Summit was a huge success. Below is some of the agenda items covered during the Summit: * Review: Tahoe-LAFS v1.9 release, LAE_ |LAE| product launch * Brian explained how his `#466`_ `signed-introducer code`_ works, committed to a public-key signature scheme * decided upon a safe "web control panel" scheme * explained how Brian's `#666`_ `Accounting code`_ works * discussed how accounting, `#467`_ static-server-selection, and Invitations should interact, so Brian knows what to build going forward * discussed Performance Improvements, HTTP-only Storage Protocols, New Encoding Formats (Rainhill_!) * Thursday items: explained LAE's s3-backend branch, designed race-free Accounting leasedb-crawler * Friday items: explained Rainhill We have a report of the activities for each day: * `Day 1`_ * `Day 2`_ * `Day 3`_ * `Day 4`_ Lastly, we would like to thank `Mozilla`_ |mozilla| for their wonderful hospitality and those folks who made the video streams possible. As someone who couldn't make it, I really appreciate the latter. .. _`second Tahoe-LAFS Summit`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit .. _LAE: http://leastauthority.com .. |LAE| image:: LAE.png :height: 35 :alt: Least Authority Enterprises :target: http://leastauthority.com .. _`#466`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/466 .. _`signed-introducer code`: https://github.com/warner/tahoe-lafs/tree/466-ed25519 .. _`#666`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/666 .. _`Accounting code`: https://github.com/warner/tahoe-lafs/tree/accounting .. _`#467`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/467 .. _Rainhill: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/NewCaps/Rainhill .. _`Day 1`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day1 .. _`Day 2`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day2 .. _`Day 3`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day3 .. _`Day 4`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day4 .. _`Mozilla`: http://www.mozilla.com .. |mozilla| image:: Mozilla_logo-35x35.svg :height: 35 :alt: Mozilla :target: http://www.mozilla.com - From the tahoe-dev Mailing List =============================== Visualizer - ---------- Brian Warner landed a new verison of the immutable-file download visualizer, replacing the early version in 1.9.0 with one that zooms and pans faster. The visualizer is useful for studying the progress and significant events in an immutable-file download. This can aid you and developers determine any possible issues with a download. .. _visualizer: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-November/006812.html Buildslaves Need Update - ----------------------- With the migration to the new server, buildslave operators `need to update`_ their buildslaves to point to the new server. .. _`need to update`: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-November/006816.html FreedomBox Posting - ------------------ Zooko |zooko| posted a `fantastic description`_ of Tahoe-LAFS to the `FreedomBox discuss list`_. He covered ways in which Tahoe-LAFS resembles a filesystem, arbitrarily nestable directories and files and a built in SFTP server. However, its performance characteristics fail to match the expectations of user-space programs that access their storage through the POSIX filesystem API. I believe the following sums it up best, "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." [1_] .. _`fantastic description`: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-November/0… .. _`FreedomBox discuss list`: http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss .. _1: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-November/0… Patch Needing Review of the Week ================================ There are six (6) 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 * `#1557`_: apply coding tools to misc/ directories other than misc/build_helpers * `#1566`_: if a stored share has a corrupt header, other shares held by that server for the file should still be accessible to clients * `#1568`_: S3 backend: [storage]readonly is documented but ignored .. _`#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 .. _`#1557`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1557 .. _`#1566`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566 .. _`#1568`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1568 - ---- *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) iQIcBAEBCAAGBQJOy5oxAAoJEAT4nRyi0elyojkP/0KUZAsshxsMe5LKIWKf63x0 cnlvX8rApAlZJIFB09fS9YD0Nd++w77EkwWF/PRz2/RhX69UpwmySR7E6eS180h9 AXVnGm9FyvmzSor3VcbhOC9Aj4hl9qJNxNu/UrIQHXo1+SeJDx7cj6KlPjEHwNzN WLAPjikUMXDgmvk5Wgb44oPUWG7slw4Rqv17pigtfdctoAcMqAOStu9SxSy0W8dR xbaCufejyQ7vaC8dQ7f/bsRPNSmbKIVzWMdEfLIxwRv6oxc+1b/sQCweSQy0jKxJ rfQRhsZByTc2BddSWxrgZWHJxu5e9Q0yCIzzbExjEqyMKKdZs8FpOcvr3miP5sAh QNirRw3GYcR7VByDVuTDVBSrvjSj5Xo8C6zp3q9inHuxuS1u+Q8Xm6jN299NJ8cW HyZ/7V6ycbeFZDmDEgKMEOnPvDDEGdlDYHc6gNGr9R/F7lDNUOI82AXCPN+oXBMk 35jzPql/YVod2NI8tmPjOHc5Z+HBCm2ohwh6NY/bTDAgfjEwXxTHAxZCTQoAWjIh 9hhz0iFpD2CGdcUI6jNWLiWninbh/IwFKmKHVjeO9x5orKcKhZjfpAjN57JAX30m y7He0B+aY1/7bZDLoLe6yRl26uxFl6vNJg4ius2goDvlCbAUFVtVqiM9To84TzWg x6GHnJfukpI8tKT7oM4u =0r7c -----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] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
by Peter Gutmann 06 Jul '18

06 Jul '18

Adam Back <adam(a)cypherspace.org> writes: >a public MitM proxy? Or a corporate LAN. Private organisation. >That intermediate CA needs publishing, and the CA that issued it. I was asked not to reveal details and I won't, but in any case I don't know whether it would achieve much. For the case of a public CA doing it, you'd see that CA X is involved, but since it's quite likely that CAs A...W and Y...Z are also at the party, all it'd do is focus people's ire on one entity. Also, if this is being done by a private organisation for DPI to secure their corporate LAN then they're probably quite within their rights to do it. I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. >It breaks a clear expectation of security and privacy the user, even very >sophisitcated user, has about privacy of their communications. Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that in whatever way they want. >1. private label sub-CA (where the holder has signed an agreement not to >issue certs for domains they do not own - I know its policy only, there is no >crypto enforced mechanism, but thats the same bar as the main CAs themselves). For the cases where I've been involved I wasn't aware of there being anything like this in the agreements (actually there probably was something somewhere, I didn't look through all the paperwork). I still have at least some of the documentation stored somewhere (NB: Not under NDA and with the agreement of the parties involved, it was an interesting case study on how these things work), if I ever manage to dig it up I'll see what the conditions were. In any case though it was honour-system security, if you really wanted to do bad things there weren't any controls that I could see to stop you. >3. public provider SSL MitM - if your ISP, wifi hotspot, 3g data prov, is >doing this to you, paid or free, thats illegal IMO. Heads should roll up the >CA tree. I think this is where we differ in our outlook. This (and yeah, I'd still like to see the certs for one of these from a public location :-) is business as usual for commercial PKI. Remember the link to the SonicWall docs I posted a few days ago, http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI-SSL_Feature_Mod… It's an advertised feature of the hardware (not just from SonicWall, other vendors do it too), d'you think people are going to buy that and then not make use of it? So you just build your defences around the fact that it's broken and then you won't run into problems. Oh, another place where this happens is WAP gateways, where they MITM everything so they can rewrite the content to save bandwidth and make things work on mobile devices. So, is that bad, or good, or both, or neither? >I guess in corporate LANs and that itself employees should be aware of that. I think employees just need to be aware that a corporate LAN is owned by your employer, and run for their benefit, not yours. If you want to do $non_work_related_whatever, do it from your home system. Peter. _______________________________________________ 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

None
by Gil Hamilton 06 Jul '18

06 Jul '18

> Mark, don't worry, the real programmers among us aren't afraid to > compete (actually, right now, there's plenty of work for everyone > who is competent so there's little need for real competetition). > Fortunately, these losers are unlikely to be successful in their > organizational and lobbying efforts. Thanks. I hope so... Free access to the US market has already enabled me to switch from $100 / month to $500 / month while in Romania, and to $3,500 / month here in Atlanta. [Yeah, I'm still far from Bill Gates, but it's still 35 times more than I made two years ago <g>] Mark

1 0