- cypherpunks - lists.cpunks.org

Charge for Pen Register Service? $600 per target per two months.
by Jim Bell 23 Sep '13

23 Sep '13

The url http://www.tdcaa.com/node/4813 includes the claim, "Additionally, telephone companies typically charge an average of $600 per target to conduct pens [registers]." (Didn't say for how long, but I suppose it's two months.) And, http://www.wired.com/threatlevel/2013/08/millions-paid-prism-compliance/ said, "For example, Cox Communications charges $2,500 for a pen register/trap-and-trace order for 60 days." Imagine how expensive it would be if the NSA got a bill for $600 per two months to conduct a 'pen register' (metadata) on your, and the same charge covering everyone else's, phone. I'd suggest to the phone co. that they charge that $600 per two months, then take $200 of that and give me the whizziest, unlimited-service around the world, the bestest service that I could possibly want, and make a $400 profit to boot! Myself, I'd be far more comfortable if my metadata was being sold to the NSA if my full cell-phone bill was paid-for by them! In fact, at those prices, I'd want a second phone, too! (Does this make me a sell-out?!?) Interesting guide to telecoms to comply with the law: http://www.kelleydrye.com/publications/client_advisories/0134/_res/id=Files… I wonder if anybody has implemented a 'metadata-killer': An app, perhaps, for a smartphone which accesses a 'telephone remailer': A (friendly) MITM (Man in the Middle) which can be called, and will automatically forward the call based on encrypted-number data, and maintain the connection to the target phone number. It would make collection of metadata much more difficult. Companies which do internet phone calls would be obvious candidates for that function. (Skype, Ooma, etc.) Jim Bell

2 1

Re: [cryptography] [Cryptography] What is Intel(R) Core™ vPro™ Technology Animation
by coderman 23 Sep '13

23 Sep '13

On Sun, Sep 22, 2013 at 9:21 PM, Jeffrey Walton <noloader(a)gmail.com> wrote: > ... > Painting with a broad brush, part of the solution is a remote > administration board that can''t be removed. Cf, Fujitsu LOM (Lights > Out Management), HP ILO (Integrated Lights Out) HP RILO (Remote > Integrated Lights Out), Compaq RIB (Remote Insight Board), and Dell > DRAC (Dell Remote Access Card). > > As for who has access, that depends on the quality of the > implementations. > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4784. as an attacker, these are my favorite systems, second only to continuous integration servers. remote access subsystems are hard to upgrade, poorly maintained, and provide exceptional access to hosts and systems. (and in fact, abusing a DRAC to get to the CI to then get keys to the kingdom, is a standard approach once you've got a pivot in network) i cannot count the number of times i've seen insecure configurations deployed, either self signed certs, common passwords, insecure ACLs, or all of the above. i can count the number of times i've seen a properly configured RA system with legit PKI and password management: ZERO! the traditional enterprise network is a soft gooey core with a fig leaf perimeter defense. sad realities...

1 0

[tor-talk] Tor mini-hackathon at GNU 30th Anniversary Celebration on 28-29 Sep
by Eugen Leitl 23 Sep '13

23 Sep '13

----- Forwarded message from Nick Mathewson <nickm(a)freehaven.net> ----- Date: Fri, 20 Sep 2013 21:00:35 -0400 From: Nick Mathewson <nickm(a)freehaven.net> To: "tor-talk(a)lists.torproject.org" <tor-talk(a)lists.torproject.org> Subject: [tor-talk] Tor mini-hackathon at GNU 30th Anniversary Celebration on 28-29 Sep Reply-To: tor-talk(a)lists.torproject.org Hi, all! Tor will be one of several fine software projects featured in the featured in the GNU 30th Anniversary Celebration and Hackathon next weekend at MIT. If you like to program, and you're interested in helping with Tor, sign up on the webpage (https://gnu.org/gnu30/celebration) and come on by! I'll be there myself, hoping to spend my time coding and getting people excited about hacking on Tor. Other Tor people in the greater Boston area may come by as well-I hope we can get at least two or three. I don't currently expect to have all of our sub-projects represented, but we'll try to put you in contact with the right people if you want to hack on something else. I'll try to have a list of fun suggested projects for people to work on ahead of the event, ideally on a wiki somewhere. peace, -- Nick Mathewson -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1

[tor-talk] Future changes to the legal code, in Russia.
by Eugen Leitl 23 Sep '13

23 Sep '13

----- Forwarded message from Nasuno <nasuno(a)riseup.net> ----- Date: Sun, 22 Sep 2013 16:51:25 -0700 From: Nasuno <nasuno(a)riseup.net> To: tor-talk(a)lists.torproject.org Subject: [tor-talk] Future changes to the legal code, in Russia. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 Reply-To: tor-talk(a)lists.torproject.org Thought this might be of interest. hxxp://rt.com/politics/russia-tor-anonymizer-ban-571/ a couple of snipets The head of the Federal Security Service (FSB) has personally ordered preparations for laws that would block the Tor anonymity network from the entire Russian sector of the Internet, a Russian newspaper reported. & The agency, however, informed the activists about possible future changes to the legal code. -- Subscribed to post this as I saw nowhere else appropriate on the website to relay this to anyone. Probably old news anyhow. Peace. Nasuno -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] Deleting data on a flash?
by Eugen Leitl 23 Sep '13

23 Sep '13

----- Forwarded message from Moritz <moritz(a)headstrong.de> ----- Date: Mon, 23 Sep 2013 10:26:42 +0200 From: Moritz <moritz(a)headstrong.de> To: cryptography(a)randombit.net Subject: Re: [cryptography] Deleting data on a flash? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130827 Icedove/17.0.8 On 09/23/2013 10:02 AM, ianG wrote: >> The issue is that it's pretty much impossible to delete data securely >> from a flash device. > Why is that? The flash memory controller hides the real storage cells from you and spreads writes across all cells equally for wear-leveling. You cannot directly access the cells. Some SSDs have a secure erase option, but you never know if it is properly implemented, and you can only use it to wipe the complete drive. https://www.schneier.com/blog/archives/2011/03/erasing_data_fr.html [...] Our results lead to three conclusions: First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs. --Mo _______________________________________________ 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[Cryptography] RSA recommends against use of its own products.
by Eugen Leitl 23 Sep '13

23 Sep '13

----- Forwarded message from Ray Dillinger <bear(a)sonic.net> ----- Date: Fri, 20 Sep 2013 11:08:00 -0700 From: Ray Dillinger <bear(a)sonic.net> To: cryptography(a)metzdowd.com Subject: [Cryptography] RSA recommends against use of its own products. User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130828 Icedove/17.0.8 More fuel for the fire... http://rt.com/usa/nsa-weak-cryptography-rsa-110/ RSA today declared its own BSAFE toolkit and all versions of its Data Protection Manager insecure, recommending that all customers immediately discontinue use of these products. The issue is apparently the Random Number Generator that these products use, the rather amusingly named "Dual Elliptic Curve Deterministic Random Bit Generator." *1 And according to more of the Snowden Files released to (or by) the New York Times last week, that pseudorandom generator is deliberately flawed in order to allow it to be sod... um, excuse me, I should have said, to permit backdoor penetration. RSA was truly between a rock and a hard place here as I see it. With the deliberate weakness now made public, they took a terrific blow to their business. But failure to follow up with a recommendation against their own products, no matter how much additional financial pain that action entails, would have destroyed all trust in their company and prospects for future business. As best I can tell, they have lost $Millions at least due to the tampering of their products, and American security and software companies taken as a whole are in the process of losing $Billions to foreign competitors for the same reasons. I wonder, would a class action suit seeking compensation for this wholesale sabotage be within the jurisdiction of the FISA court? Bear *1 "Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin." -- John Von Neumann _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Cryptographic mailto: URI
by Eugen Leitl 23 Sep '13

23 Sep '13

----- Forwarded message from Phillip Hallam-Baker <hallam(a)gmail.com> ----- Date: Fri, 20 Sep 2013 08:55:48 -0400 From: Phillip Hallam-Baker <hallam(a)gmail.com> To: Dirk-Willem van Gulik <dirkx(a)webweaving.org> Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] Cryptographic mailto: URI On Fri, Sep 20, 2013 at 4:36 AM, Dirk-Willem van Gulik <dirkx(a)webweaving.org > wrote: > > Op 19 sep. 2013, om 19:15 heeft Phillip Hallam-Baker <hallam(a)gmail.com> > het volgende geschreven: > > > Let us say I want to send an email to alice(a)example.com securely. > ... > > ppid:alice@example.com:example.net: > Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM > ... > > example.net is a server which will resolve the reference by means of a > simple HTTP query using the pattern http://<host>/.well-known/ppid/<hash> > > "Syd...NWM" is the Base64 hash of OID-SHA256 + SHA256(X) > .. > > So to use this as a mechanism for ghetto key distribution receivers > would add the URI into their account. Or let their PKI discovery agent do > it for them. > > We've been experimenting with much the same. With two twists. Basic > principle is the same. > > We use: > > - <namespace>:<id> > > as to keep it short. ID is currently a <sha1>; namespace is a 2-3 char > identifier. We then construct with this a 'hardcoded' zone name: > > <namespace>.fqdn-in-some-tld. > > which is to have a (signed) entry for in DNS: > > <id>.<ns>.<namespace>.fqdn-in-some-tld. > > which is in fact a first-come, first-served secure dynamic dns updatable > zone containing the public key. > > Which once created allows only updating to those (still) having the > private key of the public key that signed the initial claim of that <id>. > Interesting, though I suspect this is attempting to meet different trust requirements than I am. A couple of days ago I spoke with someone well known here who has seen the Snowden files. His take was that when the NSA has a choice of doing A or B it always does both. I think we need to adopt the same approach but in a way that lets all the various approaches work together. It should not be necessary for me to install five plug ins into Thunderbird to support five different flavors of researchy trust infrastructure. A better approach is to have one plug-in, or better native support for a connector to a Web Service that can then perform all the researchy trust infrastructure navigation on my behalf. The Web service can be shared between users and when there is a new researchy trust infrastructure proposed, all that is necessary to add it into the mix is to extend the Web Service and everyone using it can try out the new scheme and see if it is practical. This approach does introduce the risk that the web service might be compromised. Particularly if the client is unable to perform at least some degree of local validation on the keys. But the long term expectation would be that support for trust infrastructures that prove to be stable, widely used, and effective will eventually migrate into the client. At this point the experimental research question should be 'is this trust infrastructure practical'. We can get a very good idea of the security properties of the system by looking at how people use it and doing math. -- Website: http://hallambaker.com/ _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Jim Bell's fiber-optic patent application.
by Jim Bell 23 Sep '13

23 Sep '13

To the list members of Cypherpunks: I, Jim Bell (yes, THAT Jim Bell) have just (re-) subscribed to the Cypherpunks list. (Pardon me if I don't immediately attempt to relate the numerous reason(s) for my unfortunate 15-year absence.) Of some relevance to the list is the recent publication (by the US Patent and Trademark Office, USPTO) of my fiber-optic patent application. See http://www.freepatentsonline.com/WO2013101261A1.html . No, the patent hasn't been granted yet. A brief description of the invention follows: A silica optical fiber in which the core and inner-cladding are made from silica in which the silicon-atom content is modified from the usual 92.23% (atom/atom) Si-28 content, 4.67% Si-29, and 3.2% Si-30. A few of the possible advantage are, increase of the velocity-factor of the fiber to over 90% of 'c' (as opposed to the 68% of 'c' of existing fibers); a reduction in optical loss by a factor of 10-20 compared to existing fiber's 0.19 db/km; a factor of 10-20 reduction in 'optical dispersion' compared to existing fibers; an optical bandwidth increase to about 1000-1800 nanometers wavelength. There is actually the prospect of some crypto-relevance here. There is the Bell's theorem (not me, but John Stewart Bell's) theorem to the EPR (Einstein Podolsky Rosen) paradox. See the Wikipedia article "Bell's Theorem. This led to experimentation where a single 'entangled photon' was sent down two optical fibers in opposite directions. Eventually (30 or so kilometers apart, I believe) these photons were detected. See http://www.cleoconference.org/library/images/cleo/PDF/2009/09-plenary-aspec… . My understanding is that the distance limitations of these experiments are determined primarily by the loss of the optical fiber. If so, then a reduction by a factor of 10-20 in optical loss will result in an increase of a corresponding factor of 10-20 increase in the maximum practical distance of these kinds of quantum-entanglement experiments. Presumably, this will lead eventually to the same degrees of increases in maximum distances over which quantum encryption could operate. Jim Bell

7 15

What is Intel® Core™ vPro™ Technology Animation
by d.nix 23 Sep '13

23 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hah hah hah. Uh, reading between the lines, color me *skeptical* that this is really what it claims to be, given the current understanding of things... http://www.intel.com/content/www/us/en/enterprise-security/what-is-vpro-tec… - --- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSPlBtAAoJEDMbeBxcUNAe5RIH/iIG/149Nbaho+v8ni2lMr2T CD0VRErhdcYbqedBgHvP6cCTtErS9u2EeeVKA2yOHtZJg4FXgTWGsxGGA8vTkUYK 6NhK+HJqt7g4s0x+xSdE2nAmD0ib/94PubSOqgG1suyziqai2iRLoi9XkMaNQuX0 rIdnq6ieVA2aXCB+zK1mYWrn4ugoF9xsijlkoYm2kYkUA0a1/HlyVx880mKj2BGz b0aJNZeL3+EDubZ2tcsc93azeREethJesqBRDjAuY8StHWEaxFjqtlqqLGZbowUE hRbxOQ9vsrhy/9W4CCN3TIwT1RSh+5NjJ6JSq8GNkcPzYeZjsYSLmcHBKiGNbJE= =xwfm -----END PGP SIGNATURE-----

2 1

Re: [8] code observatory
by brian carroll 22 Sep '13

22 Sep '13

are you the fuckhead who BSOD my computer and took it down after my first cypherpunks post? (if you are you better watch out- you're in trouble...) On Sun, Sep 22, 2013 at 5:39 PM, Andy Isaacson <adi(a)hexapodia.org> wrote: > On Sat, Sep 21, 2013 at 07:08:58PM -0500, brian carroll wrote: > > --- continued... --- > > Do you really believe that the 55,000 words you've posted to the list > over the last two weeks, with exactly one reply, is considered a > valuable contribution by other list members? > > -andy >

3 2