- cypherpunks - lists.cpunks.org

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

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

22 Sep '13

----- Forwarded message from Ed Stone <temp(a)synernet.com> ----- Date: Sun, 22 Sep 2013 09:05:06 -0400 From: Ed Stone <temp(a)synernet.com> To: cryptography(a)randombit.net Subject: [cryptography] Dual_EC_DRBG was cooked, but not AES? X-Mailer: Apple Mail (2.1508) The Snowden revelations describe several methods by which NSA committed kleptography, caused compliance by hardware makers and influenced standards. 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? "On 17 March 1975, the proposed DES was published in the Federal Register. Public comments were requested, and in the following year two open workshops were held to discuss the proposed standard. There was some criticism from various parties, including from public-key cryptography pioneers Martin Hellman and Whitfield Diffie,[2] citing a shortened key length and the mysterious "S-boxes" as evidence of improper interference from the NSA. The suspicion was that the algorithm had been covertly weakened by the intelligence agency so that they — but no-one else — could easily read encrypted messages.[3] Alan Konheim (one of the designers of DES) commented, "We sent the S-boxes off to Washington. They came back and were all different."[4] The United States Senate Select Committee on Intelligence reviewed the NSA's actions to determine whether there had been any improper involvement. In the unclassified summary of their findings, published in 1978, the Committee wrote: In the development of DES, NSA convinced IBM that a reduced key size was sufficient; indirectly assisted in the development of the S-box structures; and certified that the final DES algorithm was, to the best of their knowledge, free from any statistical or mathematical weakness.[5] However, it also found that NSA did not tamper with the design of the algorithm in any way. IBM invented and designed the algorithm, made all pertinent decisions regarding it, and concurred that the agreed upon key size was more than adequate for all commercial applications for which the DES was intended.[6]" Source: https://en.wikipedia.org/wiki/Data_Encryption_Standard "On September 10 2013, The New York Times wrote that "internal memos leaked by a former N.S.A. contractor, Edward Snowden, suggest that the N.S.A. generated one of the random number generators used in a 2006 N.I.S.T. standard — called the Dual EC DRBG standard — which contains a backdoor for the NSA." On September 10 2013, The NIST director released a statement, saying that "NIST would not deliberately weaken a cryptographic standard."" Source: https://en.wikipedia.org/wiki/Dual_EC_DRBG "A major American computer security company has told thousands of customers to stop using an encryption system that relies on a mathematical formula developed by the National Security Agency (NSA). RSA, the security arm of the storage company EMC, sent an email to customers telling them that the default random number generator in a toolkit for developers used a weak formula, and they should switch to one of the other formulas in the product. The abrupt warning is the latest fallout from the huge intelligence disclosures by the whistleblower Edward Snowden about the extent of surveillance and the debasement of encryption by the NSA. Last week, the New York Times reported that Snowden's cache of documents from his time working for an NSA contractor showed that the agency used its public participation in the process for setting voluntary cryptography standards, run by the government's National Institute of Standards (NIST) and Technology, to push for a formula it knew it could break. Soon after that revelation, the NIST began advising against the use of one of its cryptographic standards and, having accepted the NSA proposal in 2006 as one of four systems acceptable for government use, said it would reconsider that inclusion in the wake of questions about its security." Source: http://www.theguardian.com/world/2013/sep/21/rsa-emc-warning-encryption-sys… _______________________________________________ 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

Re: [cryptography] [Cryptography] RSA equivalent key length/strength
by Eugen Leitl 22 Sep '13

22 Sep '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Sun, 22 Sep 2013 15:32:42 +0300 From: ianG <iang(a)iang.org> To: cryptography(a)randombit.net Subject: Re: [cryptography] [Cryptography] RSA equivalent key length/strength User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 19/09/13 00:23 AM, Lucky Green wrote: > According to published reports that I saw, NSA/DoD pays $250M (per > year?) to backdoor cryptographic implementations. I have knowledge of > only one such effort. That effort involved DoD/NSA paying $10M to a > leading cryptographic library provider to both implement and set as > the default the obviously backdoored Dual_EC_DRBG as the default RNG. So, boom. Once the finger is pointed so directly, this came tumbling down within a day or two. http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-ou… http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrb… One mystery is left for me. Why so much? It clearly doesn't cost that much money to implement the DRBG, or if it did, I would have done it for $5m, honest injun! Nor would it cost that to test it nor to deploy it on mass. Documentation, etc. What are we to conclude was the reason for such a high cost? Conscience sedative? Internal payoffs? > This was $10M wasted. While this vendor may have had a dominating > position in the market place before certain patents expired, by the > time DoD/NSA paid the $10M, few customers used that vendor's > cryptographic libraries. Another theory - take a fool's money? And, what happens to RSA now? If this is business-as-usual, does this mean that when the Feds show up to my door with 'a proposal' that I should see the mutual interest in sharing my customer's data with them by means ecliptic & exotic? Take the 30 pieces of silver (adj. for 2000 years of inflation), and be happy they're also keeping my struggling business in the black? Or grey? Or, is it the new Crypto AG? Is RSA the new byword for sellout? Does RSA go out of business? An Arthur Anderson event? In which case I have no choice. I have a reason to preserve the privacy of my customers, and tell the NSA I'm not interested in their cyanide pill patriotism. iang _______________________________________________ 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