- cypherpunks - lists.cpunks.org

[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

Re: [Cryptography] What is Intel® Core™ vPro™ Technology Animation
by d.nix 22 Sep '13

22 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/2013 2:23 PM, Jerry Leichter wrote: > On Sep 21, 2013, at 10:05 PM, d.nix wrote: >> 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… > >> The question isn't whether it's what it claims to be. It is that. But is it's *more* than it claims to be. > Yes, in my haste I neglected the "only" disclaimer bit; it is indeed a means by which the *rightful owner/administrator* might perform very useful tasks. The obvious crux of the biscuit is *who else* has access, and what can they do surreptitiously? If for example, the paper regarding manipulating the RNG circuit by alternate chip doping is valid, then an adversary with deep pockets and vast resources might well be able remotely target specific systems on demand. Possibly even air gapped ones if this function is controllable via a 3G signal as I have read elsewhere. Or perhaps just outright reroute and tap information prior to encryption, or subtly corrupt things in other ways such that processes fail or leak data. A universal on-demand STUXNET, if you will... Yes, idle unfounded speculation, I know... but still... these days the fear is that we're not paranoid enough. Hmmmm. Maybe time to pull my old 1996 SGI R10K and R4400 boxes out of storage. For a few *very* dedicated and air gapped tasks they might be a small measure of worthwhile trouble. Regards, DN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSP4OfAAoJEDMbeBxcUNAeVmUH/3MRSd/QkH9J/fY4iezSX/ME 2AbXaRSJmyLhZPW/c+moH0aUYAIPUQQ3JmVt0InZWM06jrR0pO/I9GxIM9IUWYM7 /6u/NLUcdiDtJx+BLcyUdtqSpYErkWQH9qoWxunDtUUj988xxTgia1Q+yN0h+ZOg 6PJtXB8+fTAGSoRCkhuokitB/XGbMFgAxtIyq2CMVSr3v0fOGCItvEq2wVzw8+h1 o0ps90OE3RLnel6u4YNm5EFRWoDiwN45+u/wGdXHJlSUZrncX1o6NsGvSC/0Pl94 7CYF7qpeltMMzpgPrp0IeWrls/G89FdOnjD97nzcCQ480RZAfpYCNXOIBURXq+I= =SUzc -----END PGP SIGNATURE-----

1 0

Re: [cryptography] Dual_EC_DRBG was cooked, but not AES?
by Eugen Leitl 22 Sep '13

22 Sep '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Sun, 22 Sep 2013 16:39:36 +0300 From: ianG <iang(a)iang.org> To: cryptography(a)randombit.net Subject: Re: [cryptography] Dual_EC_DRBG was cooked, but not AES? User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 22/09/13 16:05 PM, Ed Stone wrote: > Why has AES escaped general suspicion? Are we to believe that NIST tested, selected, endorsed and promulgated an algorithm that was immune to NSA's toolset, without NSA participation and approval? NSA involvement in DES is known, but we await cryptanalysis or Snowdenesque revelations before having skepticism about AES? NIST didn't really "test, select, endorse and promulgate" the AES algorithm, and neither did the NSA. The process was a competition for open cryptographers, not agencies. It was done this way because we strongly suspected DES interference. Some 30 algorithms were accepted in the first round, and subject to a year or so worth of scrutiny by the same submitting teams. This then led to a second round of 5 competitors and another long-ish period of aggressive scrutiny. The scrutiny was quite fierce because the reputations of the winners would be made, so the 5 teams did their darndest to undermine the competition. Many famous names were hoping for the prize. It is the case that NIST (and probably the NSA) selected Rijndael from the 5 finalists. But they did so on the basis of a lot of commentary, and all the critics was agreed that all 5 were secure [0]. So, claiming that the NSA perverted the AES competition faces a much higher burden. They would have had to have done these things: * pervert some of the early teams, * pervert the selection process to enable their stooges through, * and designed something that escaped the aggressive scrutiny of the losers. It's possible, but much harder to get away with. In contrast, with the DRBG adventure, NSA designed the process, and tacked it onto a more internal NIST standards process. Little or minimal scrutiny from outside, and little or minimal perversion of outsiders necessary in the standardisation phase (but that did come later). iang [0] At the time, myself and my team followed it, and we predicted that Rijndael would be the winner ... just by reading all the comments. Note we weren't serious cryptographers, but we provided the Java framework for the competition, so it was a _______________________________________________ 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