July 2018 - cypherpunks-legacy

A.C. Swinburne
by cypherpunks＠algebra.com 06 Jul '18

06 Jul '18

META MAX FOR MEN AND WOMEN Yours Free for 30 Days The all natural sexual performance for men and women This special formula is specifically designed to " STIMULATE SEXUAL RESPONSE " and revive arousal powers. It is also intended to help overcome sexual roadblocks and allow you to gain the stimulating drive vital for proper sexual performance. And although it can be remarkably effective, Meta Max is an all -natural, safe formula. MOTHER NATURE'S WONDER pill...yours risk free!! To Claim Your 30 Day Trial Offer.. Go To: http://www.metamax4life.us?id=625 To Be Removed Go To Above Link And Click On Remove... META MAX FOR MEN AND WOMEN ours Free for 30 Days he all natural sexual performance for men and women

1 0

Re: [tahoe-dev] Idea for a Publish/Subscribe Message System, on Tahoe-LAFS
by Stuart W. Card 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 all -- Sorry to chime in late and initially without reference citations, but I wanted you all to be aware of some work we have been doing recently at Syracuse University and my company Critical Technologies Inc., using Tahoe-LAFS as a principal building block for a publish-subscribe-query distributed blackboard that will be the backbone of a framework for distributed sensing/computation/control. A unifying theme is use of capability based security throughout the stack, from the underlying microkernel-based hypervisor all the way up through the mobile agent based applications. We are working towards compliance with OMG Data Distribution Service (DDS) API specs, but initially have done only proof-of-concept work without regard for such specs. We are looking at plugging in Tahoe as an archival message store for OpenDDS, OpenSplice or RTI-DDS. I am limited in what I can say in public prior to obtaining specific permission from our funding sources, but as Tahoe is a community supported product that is central to our architecture, I believe I can discuss here those aspects directly related to Tahoe development. I will go out on a limb and say that I think the whole notion of mutable files is a mistake. We currently use them only for directories, and there only until such time as we develop a replacement based on our architecture. Instead of mutable files, we prefer revision control: once a message (file) is published, it is immutable for all time; but a new version can be published, as either a complete snapshot or a diff (respect to rsync), with suitable meta-data markups and pointers in directories (also to be immutable but version controlled). To provide notification of new publications (including revisions of old ones), we use the NACK Oriented Reliable Multicast (NORM) transport protocol, which is the _only_ IETF standards track reliable multicast protocol that offers both statistical reliability (erasure code FEC) and acknowledged delivery (ARQ), combining them in a Type II Hybrid ARQ/FEC (which can approach the Shannon limit despite dynamically varying channel error rates). Urgent short messages that do not require persistent archival can also be sent via NORM without the latencies and costs inherent to Tahoe. Long term, we also want to enable use of NORM as a multicast transport for Tahoe, in place of multiple unicast TCP connections. We have some notions about using URIs as capabilities, not only for Tahoe, but also for the microvisor and other subsystems. We want to define a syntax and semantics for extended capability URIs that can embed policies (including PKI based restrictions on who can exercise the capability, thus integrating Role Based Access Control with capabilities), and short "handle" URIs (that merely reference long URIs with their embedded information). We intend to develop capability middleware (including proxies subsuming the capability security notion of "membrane") that will enable programmers and admins who are not [yet] familiar with capability security to nonetheless utilize it with a minimum of unintended capability leaks. If any of you find any of the above interesting and want to discuss it, please e-mail me directly, as (unfortunately) I can't go into much more detail on the list (I must obtain specific approval of the text of each "public release of information" that I make). - -- Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 <Stu.Card(a)critical.com> www.critical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nWmAACgkQS7PQ0a2weL7ZGwCgnPaITAgigg3PRPUhkNrul3pB Ur8An1ALUNdzXv76XlO18wkVnUpcjWN+ =/iWs -----END PGP SIGNATURE----- _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://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

[gsc] Public Key Transaction Processor
by Andrew McMeikan 06 Jul '18

06 Jul '18

About seven years ago, I started coding on a program for digital payments using pgp keys as accounts. I still have not finished it, not because it is hard, I just don't program fast :) Over the last six months Trubanc has come together and no doubt will get lots of use as it does much of the magic I have been trying to implement only much more shiny. For those that reject the easy shiny way, my rough awkward gritty way is almost done as well. Along with requiring some technical knowledge and only for certain system configurations (Linux) a much more close to the crypto solution is coming soon. If you already have a gpg/pgp key, you already have an account! I am still slowly hammering away at code, but if you dont mind rough edges and would like to play let me know! I need testers! I have skipped my java version and just doing some simple scripts to do the work. As an overview, the fingerprint of each key is associated with a balance in a variety of commodities held at a vault. Transactions are performed by signing a transaction to transfer an amount to a different key. Very similar to trubanc, but done very simply, no client required if you stick to the format to use, or very simple inspectable script that generates transactions to be signed. Your private key never leaves your control. Very easy for multiple vaults to exist eliminating any centralised point to be raided. While not dependent on loom or other systems for asset backing, loom does seem ideally suited as an inter-vault settlement system. Once some testing is done a web and email server for transactions will be trialled and as many can set up their own as they please. I would very much like to email with someone who is interested in testing such a system. cya, Andrew...

1 0

Tor Browser Bundle for Gnu/Linux: a new hope
by Jacob Appelbaum 06 Jul '18

06 Jul '18

[I utterly fail at sending email after hacking for 18 hours.] Hi, I've been hacking on creating a Tor Browser Bundle for Gnu/Linux. It's starting to get off of the ground. After I ensure that it's stable, I'll move onto to making the Tor Browser Bundle for Mac OS X. Your feedback and testing is greatly appreciated! The current TBBL alpha includes Firefox, Openssl, zlib, Qt, Vidalia, Polipo, Tor and it's all wrapped up in a nice package. It's intended to be used on USB devices. It's designed to run on Debian Gnu/Linux systems and may also work on Ubuntu. This is a limitation of my build environment and if others want to help, we can make it work on many different Gnu/Linux systems. Here's the url where I've published current alpha builds of the TBBL: http://freehaven.net/~ioerror/tbb/index.html Download the bundle for your locale and verify it's signature: gpg --verify tor-browser-gnu-linux-1.2.4-alpha-de.tar.gz.asc gpg: Signature made Fri 28 Aug 2009 01:52:27 AM PDT using DSA key ID 9D0FACE4 gpg: Good signature from "Jacob Appelbaum <jacob(a)appelbaum.net>" If the signature verifies, unpack it: tar -xvzf tor-browser-gnu-linux-1.2.4-alpha-de.tar.gz This is very important: Ensure that you do not have Tor, Vidalia, Privoxy, Polipo or Firefox running. Run it: cd "Tor Browser_de/Tor\ Browser" ./"Start Tor Browser" If you'd like to follow along at home, you can build it from source like so: svn co https://tor-svn.freehaven.net/svn/torbrowser/trunk/ cd build-scripts time make -f Makefile.linux build-all-binaries time make -f Makefile.linux all-compressed-bundles If you're on a reasonable system, you should see some results in about an hour. You'll see all of the localized tar.gz files in ttbl-release/ if all goes well. Here's a list of known issues that I intend to tackle over the next day or so: openssl needs to be a shared library The google search box needs to be removed How shall we solve the tarball splitting? shar files? I should investigate the Qt warning We should use custom icon for ease of use If vidalia quits, take firefox and other stuff with it Investigate data leaks that happen outside of the TBB directory Best, Jacob ----- 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: [Geowanking] E911 // cellular trilateration accuracy
by Debi Jones 06 Jul '18

06 Jul '18

The most lethal phone is one that hits your head with enough force to crack your skull. The precision of cellid is location specific as it depends on cell size. It depends on the arrangement and distance between the towers being used to locate you. Think geometry. The longer the sides of a triangle the greater the area. That fellow might have been a GSM expert but clearly he wasn't an LBS or CDMA expert. One major benefit for current CDMA networks using cellid is that the base stations operate synchronously. They emit code sequences at exactly the same time, so there's no need for after collection synchronization as is the case for GSM. ...Debi > > <http://tech.cybernetnews.com/2006/03/26/this-may-help-your-firefox-memory-le ak/> > On 4/10/06, roger(a)sylvanascent.com <roger(a)sylvanascent.com> wrote: > > I think this is a great question. I talked to a gentleman from South > Africa > last year at Where 2 who claimed to be a GSM expert. He said that GSM can > locate you within something like 3 meters with no GPS support just using > the towers, and that this was built into the GSM spec. He spoke of a case > in South Africa where they located some sort of criminal using the GSM > records. > > He said that CDMA on the other hand, cannot locate so precisely. > > So, to me, A-GPS was designed to make CDMA users locatable to the same > degree as GSM. > > As an aside, does anyone know which type of cell phones are more lethal? > > Roger > > Original Message: > ----------------- > From: Ian | Urban Mapping ian(a)urbanmapping.com > Date: Mon, 10 Apr 2006 01:42:23 -0400 > To: geowanking(a)lists.burri.to > Subject: [Geowanking] E911 // cellular trilateration accuracy > > > At the risk of asking (another) obvious question, I continue my naC/ve > streak > on this listservb& > > > > I've heard very different reports of how accurate cellphone tracking > isbthe > FAA mandates something like 50% of calls must be traceable to within a > range > of 30m but I've heard some mobile pros say they've heard of it getting as > good as several feet. Obviously this varies depending on geography (urban, > rural, topography), but does anybody have any idea how the US wireless > carriers stack up? And how does this compare to phones with GPS? > > > > > > Ian White :: Urban Mapping LLC :: <mailto:ian@urbanmapping.com> > ian(a)urbanmapping.com > > 120 West 45th Street 20th Floor :: New York NY 10036 > > Tel.212.242.8267 :: Fax.866.385.8266 :: www.urbanmapping.com > > > > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > > _______________________________________________ > Geowanking mailing list > Geowanking(a)lists.burri.to > http://lists.burri.to/mailman/listinfo/geowanking > _______________________________________________ Geowanking mailing list Geowanking(a)lists.burri.to http://lists.burri.to/mailman/listinfo/geowanking ----- 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

[gsc] Public Key Transaction Processor
by Andrew McMeikan 06 Jul '18

06 Jul '18

About seven years ago, I started coding on a program for digital payments using pgp keys as accounts. I still have not finished it, not because it is hard, I just don't program fast :) Over the last six months Trubanc has come together and no doubt will get lots of use as it does much of the magic I have been trying to implement only much more shiny. For those that reject the easy shiny way, my rough awkward gritty way is almost done as well. Along with requiring some technical knowledge and only for certain system configurations (Linux) a much more close to the crypto solution is coming soon. If you already have a gpg/pgp key, you already have an account! I am still slowly hammering away at code, but if you dont mind rough edges and would like to play let me know! I need testers! I have skipped my java version and just doing some simple scripts to do the work. As an overview, the fingerprint of each key is associated with a balance in a variety of commodities held at a vault. Transactions are performed by signing a transaction to transfer an amount to a different key. Very similar to trubanc, but done very simply, no client required if you stick to the format to use, or very simple inspectable script that generates transactions to be signed. Your private key never leaves your control. Very easy for multiple vaults to exist eliminating any centralised point to be raided. While not dependent on loom or other systems for asset backing, loom does seem ideally suited as an inter-vault settlement system. Once some testing is done a web and email server for transactions will be trialled and as many can set up their own as they please. I would very much like to email with someone who is interested in testing such a system. cya, Andrew...

1 0

Tor Browser Bundle for Gnu/Linux: a new hope
by Jacob Appelbaum 06 Jul '18

06 Jul '18

[I utterly fail at sending email after hacking for 18 hours.] Hi, I've been hacking on creating a Tor Browser Bundle for Gnu/Linux. It's starting to get off of the ground. After I ensure that it's stable, I'll move onto to making the Tor Browser Bundle for Mac OS X. Your feedback and testing is greatly appreciated! The current TBBL alpha includes Firefox, Openssl, zlib, Qt, Vidalia, Polipo, Tor and it's all wrapped up in a nice package. It's intended to be used on USB devices. It's designed to run on Debian Gnu/Linux systems and may also work on Ubuntu. This is a limitation of my build environment and if others want to help, we can make it work on many different Gnu/Linux systems. Here's the url where I've published current alpha builds of the TBBL: http://freehaven.net/~ioerror/tbb/index.html Download the bundle for your locale and verify it's signature: gpg --verify tor-browser-gnu-linux-1.2.4-alpha-de.tar.gz.asc gpg: Signature made Fri 28 Aug 2009 01:52:27 AM PDT using DSA key ID 9D0FACE4 gpg: Good signature from "Jacob Appelbaum <jacob(a)appelbaum.net>" If the signature verifies, unpack it: tar -xvzf tor-browser-gnu-linux-1.2.4-alpha-de.tar.gz This is very important: Ensure that you do not have Tor, Vidalia, Privoxy, Polipo or Firefox running. Run it: cd "Tor Browser_de/Tor\ Browser" ./"Start Tor Browser" If you'd like to follow along at home, you can build it from source like so: svn co https://tor-svn.freehaven.net/svn/torbrowser/trunk/ cd build-scripts time make -f Makefile.linux build-all-binaries time make -f Makefile.linux all-compressed-bundles If you're on a reasonable system, you should see some results in about an hour. You'll see all of the localized tar.gz files in ttbl-release/ if all goes well. Here's a list of known issues that I intend to tackle over the next day or so: openssl needs to be a shared library The google search box needs to be removed How shall we solve the tarball splitting? shar files? I should investigate the Qt warning We should use custom icon for ease of use If vidalia quits, take firefox and other stuff with it Investigate data leaks that happen outside of the TBB directory Best, Jacob ----- 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: [tahoe-dev] Idea for a Publish/Subscribe Message System, on Tahoe-LAFS
by Stuart W. Card 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 all -- Sorry to chime in late and initially without reference citations, but I wanted you all to be aware of some work we have been doing recently at Syracuse University and my company Critical Technologies Inc., using Tahoe-LAFS as a principal building block for a publish-subscribe-query distributed blackboard that will be the backbone of a framework for distributed sensing/computation/control. A unifying theme is use of capability based security throughout the stack, from the underlying microkernel-based hypervisor all the way up through the mobile agent based applications. We are working towards compliance with OMG Data Distribution Service (DDS) API specs, but initially have done only proof-of-concept work without regard for such specs. We are looking at plugging in Tahoe as an archival message store for OpenDDS, OpenSplice or RTI-DDS. I am limited in what I can say in public prior to obtaining specific permission from our funding sources, but as Tahoe is a community supported product that is central to our architecture, I believe I can discuss here those aspects directly related to Tahoe development. I will go out on a limb and say that I think the whole notion of mutable files is a mistake. We currently use them only for directories, and there only until such time as we develop a replacement based on our architecture. Instead of mutable files, we prefer revision control: once a message (file) is published, it is immutable for all time; but a new version can be published, as either a complete snapshot or a diff (respect to rsync), with suitable meta-data markups and pointers in directories (also to be immutable but version controlled). To provide notification of new publications (including revisions of old ones), we use the NACK Oriented Reliable Multicast (NORM) transport protocol, which is the _only_ IETF standards track reliable multicast protocol that offers both statistical reliability (erasure code FEC) and acknowledged delivery (ARQ), combining them in a Type II Hybrid ARQ/FEC (which can approach the Shannon limit despite dynamically varying channel error rates). Urgent short messages that do not require persistent archival can also be sent via NORM without the latencies and costs inherent to Tahoe. Long term, we also want to enable use of NORM as a multicast transport for Tahoe, in place of multiple unicast TCP connections. We have some notions about using URIs as capabilities, not only for Tahoe, but also for the microvisor and other subsystems. We want to define a syntax and semantics for extended capability URIs that can embed policies (including PKI based restrictions on who can exercise the capability, thus integrating Role Based Access Control with capabilities), and short "handle" URIs (that merely reference long URIs with their embedded information). We intend to develop capability middleware (including proxies subsuming the capability security notion of "membrane") that will enable programmers and admins who are not [yet] familiar with capability security to nonetheless utilize it with a minimum of unintended capability leaks. If any of you find any of the above interesting and want to discuss it, please e-mail me directly, as (unfortunately) I can't go into much more detail on the list (I must obtain specific approval of the text of each "public release of information" that I make). - -- Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 <Stu.Card(a)critical.com> www.critical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nWmAACgkQS7PQ0a2weL7ZGwCgnPaITAgigg3PRPUhkNrul3pB Ur8An1ALUNdzXv76XlO18wkVnUpcjWN+ =/iWs -----END PGP SIGNATURE----- _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://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

Re: [Geowanking] E911 // cellular trilateration accuracy
by Debi Jones 06 Jul '18

06 Jul '18

The most lethal phone is one that hits your head with enough force to crack your skull. The precision of cellid is location specific as it depends on cell size. It depends on the arrangement and distance between the towers being used to locate you. Think geometry. The longer the sides of a triangle the greater the area. That fellow might have been a GSM expert but clearly he wasn't an LBS or CDMA expert. One major benefit for current CDMA networks using cellid is that the base stations operate synchronously. They emit code sequences at exactly the same time, so there's no need for after collection synchronization as is the case for GSM. ...Debi > > <http://tech.cybernetnews.com/2006/03/26/this-may-help-your-firefox-memory-le ak/> > On 4/10/06, roger(a)sylvanascent.com <roger(a)sylvanascent.com> wrote: > > I think this is a great question. I talked to a gentleman from South > Africa > last year at Where 2 who claimed to be a GSM expert. He said that GSM can > locate you within something like 3 meters with no GPS support just using > the towers, and that this was built into the GSM spec. He spoke of a case > in South Africa where they located some sort of criminal using the GSM > records. > > He said that CDMA on the other hand, cannot locate so precisely. > > So, to me, A-GPS was designed to make CDMA users locatable to the same > degree as GSM. > > As an aside, does anyone know which type of cell phones are more lethal? > > Roger > > Original Message: > ----------------- > From: Ian | Urban Mapping ian(a)urbanmapping.com > Date: Mon, 10 Apr 2006 01:42:23 -0400 > To: geowanking(a)lists.burri.to > Subject: [Geowanking] E911 // cellular trilateration accuracy > > > At the risk of asking (another) obvious question, I continue my naC/ve > streak > on this listservb& > > > > I've heard very different reports of how accurate cellphone tracking > isbthe > FAA mandates something like 50% of calls must be traceable to within a > range > of 30m but I've heard some mobile pros say they've heard of it getting as > good as several feet. Obviously this varies depending on geography (urban, > rural, topography), but does anybody have any idea how the US wireless > carriers stack up? And how does this compare to phones with GPS? > > > > > > Ian White :: Urban Mapping LLC :: <mailto:ian@urbanmapping.com> > ian(a)urbanmapping.com > > 120 West 45th Street 20th Floor :: New York NY 10036 > > Tel.212.242.8267 :: Fax.866.385.8266 :: www.urbanmapping.com > > > > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > > _______________________________________________ > Geowanking mailing list > Geowanking(a)lists.burri.to > http://lists.burri.to/mailman/listinfo/geowanking > _______________________________________________ Geowanking mailing list Geowanking(a)lists.burri.to http://lists.burri.to/mailman/listinfo/geowanking ----- 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: GPS attack vector
by Tom Morris 06 Jul '18

06 Jul '18

This could also be a big show stopper for cellular and radio networks. Many use a 10.0000000 MHz timebase distributed from a GPS disciplined local oscillator for precise time and frequency synchronization. Without this tight frequency stabilization from a GPS receiver, major drama will occur on the "borders" between simulcasting repeater coverage areas, cell sites, etc. Can anyone say Spaghetti mess? Owwwww my brain hurts. Tom Morris, KG4CYX Chairman, South Florida Tropical Hamboree Mad Scientist, Miami Children's Museum This message sent from a mobile device. Silly typos provided free of charge. On Jan 16, 2013 8:08 PM, "Jay Ashworth" <jra(a)baylink.com> wrote: > Do you use GPS to provide any mission critical services (like time of day) > in your network? > > Have you already see this? (I hadn't) > > > http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-… > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra(a)baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > ----- 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