Re: [cryptography] Which encryption chips are compromised?
On Thu, Dec 12, 2013 at 08:04:00AM -0800, Steve Weis wrote: The document is talking about FY2013. IVB already shipped in 2012. I'd guess it was fabricated for testing in 2009-2010 and designed for a few years prior. What enablement would be complete in 2013 for something that has been on the market a year and is already being phased out? A microcode update ? -jf ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Fri, Dec 13, 2013 at 2:32 AM, Jan-Frode Myklebust janfr...@tanso.net wrote: What enablement would be complete in 2013 for something that has been on the market a year and is already being phased out? A microcode update ? I think that compromising microcode update keys is a much more interesting and believable prospect than compromising RDRAND. I've seen surprisingly little research around microcode update security. This post by Ben Hawkes is pretty interesting: http://inertiawar.com/microcode/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
one last amusing note, Google has gone whole hog on SDN: http://www.networkcomputing.com/data-networking-management/inside-googles-software-defined-network/240154879 how amusing would it be if they implemented inter-DC IPsec keyed with RDRAND directly on compromised cores in one of these Highland Forest like SDN deployments? i can already see the updated napkin sketch now, and imagine the streaming swears pouring forth from the googlies once uncovered... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
Please stop this suicidal, treacherous discussion. You're undermining the global industry of weak crypto and comsec. That counts as economic terrorism in all the countries who abide arms control, export control, copyright, capitalism, heirarchical rule, suppression of dissent, lawful spying, breaking and entering black jobs, ubiquitous spying on each other and everybody else, in particular what NRO terms unobservable and unknown phenomena, and a lot of other secret stuff which can only be revealed by low-ranked knobheads sure to be burned at the stake by their cowardly protectors for the irresistable allure of IPO millions based on government contracts to keep this shit among us. Got that? This is a place to share fudging how it should work, and does now and then. You think this is bullshit, dontcha? Well, it aint. Why look at the rising use of Tor, PFS, TLS, those rat-infested private keyservers and millions of eaters of Symantec back-doored dookie-pie. You seen any US producers of comsec go under yet? No, and you wont, for they are locked into surefire global success when failure is built into their products. Screwing customers and citizens with faulty comsec, what's wrong with that, where you been, that's patriotic, and damn profitable. Sure, call for outraged dissent, fine, great, if that moves the ponzi, balloons those bitcoins. At 09:08 AM 12/12/2013, coderman wrote: i see your skepticism, and i raise you a retort! ;) also, this year by end of year, in 2013 you expect to: - Make gains in enabling decryption and Computer Network Exploitation (CNE) access to fourth generation/Long Term Evolution (4GL/LTE) networks by inserting vulnerabilities. - Complete enabling for [well recognized name] encryption chips used in Virtual Private Network and Web encryption devices. and last but not least, - Shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS. Ok, given those requirements. Who fits the bill? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Dec 12, 2013 6:08 AM, coderman coder...@gmail.com wrote: i see your skepticism, and i raise you a retort! ;) i even have a list of candidates you can experiment with to confirm Intel Ivy Bridge as best fit. [0] I think this is a weak guess. The document is talking about FY2013. IVB already shipped in 2012. I'd guess it was fabricated for testing in 2009-2010 and designed for a few years prior. What enablement would be complete in 2013 for something that has been on the market a year and is already being phased out? By 2013, Intel had already started shipping Haswell. They did launch new IVB E5v2 Xeon server processors this fall, but future CPUs will be Haswell and Broadwell. Intel already has the next, next generation Skylake with SGX fabricated for testing. I still think the document is talking about a dedicated crypto chip for VPN and SSL acceleration devices, just like it says. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Thu, Dec 12, 2013 at 7:08 AM, John Young j...@pipeline.com wrote: Please stop this suicidal, treacherous discussion. You're undermining the global industry of weak crypto and comsec. That counts as economic terrorism in all the countries who abide arms control, export control, copyright, capitalism, heirarchical rule, suppression of dissent, lawful spying, breaking and entering black jobs, ubiquitous spying on each other and everybody else, ... ... Sure, call for outraged dissent, fine, great, if that moves the ponzi, balloons those bitcoins. let it be known: in the event of my untimely demise under suspicious circumstances, i will my coins to JYA so he may bless my passing with grand oration and strong tale as he is so adept at providing. *grin* on a serious note, the useful steps are clear: 1. Intel releases raw access to noise samples 2. NIST defining and mandating a design that also supports raw sample access, (we could change subject here to discuss something pleasant like on-line checks and continuous checks,) 3. OS distributions include userspace entropy scavenging daemons (haveged, dakarand, etc) to complement properly vetted hardware entropy sources run in a conservative fashion. default is set safe, not fast. is that so much to ask? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Thu, Dec 12, 2013 at 8:04 AM, Steve Weis stevew...@gmail.com wrote: ... The document is talking about FY2013. IVB already shipped in 2012. I'd guess it was fabricated for testing in 2009-2010 and designed for a few years prior. What enablement would be complete in 2013 for something that has been on the market a year and is already being phased out? the bulk of 2012 was consume user hardware. the endpoint is a totally solved problem (read: trivial to exploit in many ways, all day, every day, per the docs) only server Ivy Bridge: Xeon E3 in mid-2012. the cores pushed in the SDN initiatives above came out not so many months ago... high capacity crypto aggregation points like this are an ideal target, with backdoor keying of VPN/SSL the ideal (passive) attack with their view of target's long haul fiber. By 2013, Intel had already started shipping Haswell. They did launch new IVB E5v2 Xeon server processors this fall, but future CPUs will be Haswell and Broadwell. Intel already has the next, next generation Skylake with SGX fabricated for testing. but not released, and enabling means tied into X-KEYSCORE, TRAFFICTHIEF, whatever else gets draped off UPSTREAM... I still think the document is talking about a dedicated crypto chip for VPN and SSL acceleration devices, just like it says. the backdoors for all the other vendor hardware happened in years prior. HSMs and crypto accelerator gear is not exactly a vibrant or competitive market. in fact, these companies never seem to die, just carry on with decent margins riding on incremental design upgrades until they're bought out by a larger/growing competitor. ;) of course, this could be because companies like Sun charge $9,999 for an HSM/accelerator that is at best a reasonable cost at $1,499... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Thu, Dec 12, 2013 at 8:42 AM, coderman coder...@gmail.com wrote: IVB already shipped in 2012... only server Ivy Bridge: Xeon E3 in mid-2012. this does bring up an interesting point: while it may be more efficient to use the same key for the DRBG output across all processor lines, it would be more secure to use a different key per line. this implies that each iteration of Sandy Bridge - Ivy Bridge - Haswell needs to be enabled by CCP, with Xeon E5 debut in 2013 as discussed. for Sandy Bridge, this would have shown in 2010? and unless in network equipment described simply as enabling decryption for Sandy Bridge used by $operating systems and $applications. sadly we'll have to wait a while to confirm this conjecture for Haswell. and we'll have to wait forever for more leaks apparently, as the continuing decline of details demonstrates... best regards, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Thu, 12 Dec 2013, coderman wrote: of course, this could be because companies like Sun charge $9,999 for an HSM/accelerator that is at best a reasonable cost at $1,499... If you mean the SCA 6000, those were $1600 at Sun. When Oracle bought them they just bumped it to $10k. On ebay you can see listings right now for $300-$750 for used ones, with the familiar traces of heated up plastic :) And yes, no one should use them as accelerator. They only have an HSM function at this point. And in practise, they've turned out to be a bit troubled with overheating and crashing linux drivers. Paul ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Thu, Dec 12, 2013 at 08:04:00AM -0800, Steve Weis wrote: On Dec 12, 2013 6:08 AM, coderman coder...@gmail.com wrote: i see your skepticism, and i raise you a retort! ;) i even have a list of candidates you can experiment with to confirm Intel Ivy Bridge as best fit. [0] I think this is a weak guess. In reply to Declan tweeting about this discussion (shame on you, Declan, if you're reading this and trying to take the discussion to the public), Kevin Poulsen points out https://twitter.com/kpoulsen/status/411226939547222016 that the Times' comment on this redaction appears to imply that the redacted text names two chips: http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0 Large Internet companies use dedicated hardware to scramble traffic before it is sent. In 2013, the agency planned to be able to decode traffic that was encoded by one of these two encryption chips, either by working with the manufacturers of the chips to insert back doors or by exploiting a security flaw in the chips' design. The document is talking about FY2013. IVB already shipped in 2012. I'd guess it was fabricated for testing in 2009-2010 and designed for a few years prior. What enablement would be complete in 2013 for something that has been on the market a year and is already being phased out? VPN gear lasts in the field for 2-5 years post roll-out. Design wins into large provider's hardware will often see the same chip being manufactured for 2-5 years after it ceases being available at retail. (ark.intel.com has an embedded option available? field to denote the chips they support this for.) Complete Enablement is jargon with a specific meaning. I'm not certain I understand it, but I *think* it means we have plaintext access on any targeted session. I don't think it means we can get plaintext for an arbitrary previously recorded session and I don't think it means we automatically get plaintext for every session we can hear. Suppose a NSA chip backdoor receives its triggering command by a specific sequence of TCP retransmits (dropped packets) and after being triggered, leaks the key by varying the timing or ordering of outbound packets. By my reading, this would count as complete enablement even though a session which was not triggered would not be eavesdroppable. To specifically respond to your point, Complete enablement is also time dependent. Productionizing a timing side channel attack could result in complete enablement only for new flows and would still be complete even though there was no enablement before the attack was available. By 2013, Intel had already started shipping Haswell. They did launch new IVB E5v2 Xeon server processors this fall, but future CPUs will be Haswell and Broadwell. Intel already has the next, next generation Skylake with SGX fabricated for testing. I still think the document is talking about a dedicated crypto chip for VPN and SSL acceleration devices, just like it says. Especially taking the NYT commentary into account, I'm even more convinced you're right. Intel and AMD is about the right length... -andy ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Thu, Dec 12, 2013 at 1:24 PM, Andy Isaacson a...@hexapodia.org wrote: ... In reply to Declan tweeting about this discussion (shame on you, Declan, if you're reading this and trying to take the discussion to the public), the worst kind of xpost of all? every day without RDRAW is another day of my life with provably less information theoretic meaning. ;) Kevin Poulsen points out https://twitter.com/kpoulsen/status/411226939547222016 that the Times' comment on this redaction appears to imply that the redacted text names two chips: http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0 Large Internet companies use dedicated hardware to scramble traffic before it is sent. In 2013, the agency planned to be able to decode traffic that was encoded by one of these two encryption chips, either by working with the manufacturers of the chips to insert back doors or by exploiting a security flaw in the chips' design. two chips or two families or two architectures or ... is this a game of twenty questions? can we do a reddit AMA for the leakers with their stash at the ready? Complete Enablement is jargon you know, if we had more documents providing context, Suppose a NSA chip backdoor receives its triggering command by a specific sequence of TCP retransmits (dropped packets) and after being triggered, leaks the key by varying the timing or ordering of outbound packets. By my reading, this would count as complete enablement even though a session which was not triggered would not be eavesdroppable. past experience tells us they like attacks universally effective, unidirectional, silent/random-looking (without secret knowledge), and don't mind expending custom hardware and algorithms to do it. Dual_EC_DRBG doesn't count - that was a jeezus, everyone asleep at the wheel. i bet we could get this approved! moment. triggering is active, observable (potentially), and usually re-playable. the only delivered payloads, ala EGOTISTICAL*/ERRONEOUS*, appear to be for confirmation pinging or identification, and memory resident forensic/exfiltration run locally on the host. even the slides you link to note the OPSEC concerns of adversarial actors (i think that's us on this list?) To specifically respond to your point, Complete enablement is also time dependent. Productionizing a timing side channel attack could result in complete enablement only for new flows and would still be complete even though there was no enablement before the attack was available. sure. note how this is also more complicated, with higher risk? if there was a better way i bet they'd choose it! Intel and AMD is about the right length... also, Intel and ARM, Apple and ARM, Apple and VIA, etc. you're not helping my pleading and cajoling for RDRAW sir. on a related note, if Intel were to decide to include RDRAW in next CPU line design, how long would it be to retail channels? 3yrs? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Tue, Dec 10, 2013 at 4:11 PM, d...@geer.org wrote: * (TS//SI//REL TO USA, FVEY) Complete enabling for [XX] encryption chips used in Virtual Private Network and Web encryption devices. [CCP_9]. For this to be an explicit line item in that document, it has to be special. unredacted: https://peertech.org/dist/nsa-cpp-goals-FY2013-unredact.png Intel Ivy Bridge ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Wed, Dec 11, 2013 at 6:28 PM, Steve Weis stevew...@gmail.com wrote: ... Ivy Bridge processors are general purpose x86 CPUs. It doesn't make sense to me to refer to it as an encryption chip for web encryption devices. used in Virtual Private Network == PPTP,IPsec,OpenVPN,etc. Web encryption devices == in my interpretation, this is any targeted hardware with the vulnerable chip. it could be a tablet, a desktop, and rack mount server... any of these platforms could speak VPN or Web crypto. TAO/SCS do like to get into the switches though ;) Do you know of products using IVB processors for SSL offloading or in VPN appliances? mostly cloud infrastructure, software defined data center, and the like: http://www.routeranalysis.com/the-vyatta-cloud-router-story/ http://www.routeranalysis.com/etsi-network-function-virtualization-working-group/ To me, the redacted document sounds like it's referring to a security processor used for SSL offloading. For example, something like a Cavium Nitrox (which I'm not implying is the subject of the document). back in the day, Sun got tired of the (relatively) slow performance and latency of crypto offloading via bus and simply threw it into the core. you were still offloading crypto, but within the CPU. also note that endpoint compromises sufficient to decrypt VPN or secure web traffic is already present in TAO/CNE's tasking. this effort [CCP_9] may focus on VPN concentrator / secure web proxy deployments specifically to handle the RDRAND lookup per their private starting counter. previous back doors have also used entropy leakage sufficient to bring a brute force attack into reasonable effort, while still denying third parties a class break of the entropy / keys used. this type of key space search is not done on the ground with portable CNE but instead back at SCS... on a related tangent, the lack of additional disclosures is quite frustrating. this entire conversation would be resolved in a glance if $the_snowden_gatekeepers were acting in the public interest. :/ best regards, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Wed, Dec 11, 2013 at 06:28:31PM -0800, Steve Weis wrote: On Wed, Dec 11, 2013 at 6:00 PM, coderman coder...@gmail.com wrote: unredacted: https://peertech.org/dist/nsa-cpp-goals-FY2013-unredact.png Intel Ivy Bridge Is this a guess because Intel Ivy Bridge fits into the redacted space or is there some other evidence? I believe it's just a guess based on fit. Ivy Bridge processors are general purpose x86 CPUs. It doesn't make sense to me to refer to it as an encryption chip for web encryption devices. Do you know of products using IVB processors for SSL offloading or in VPN appliances? Suppose I'm the manager writing this document, reporting the expected accomplishments of my group. We do cryptanalysis. If we're projecting success against FooBarCo chips' encryption sub-core, and everybody knows FooBarCo chips are used in both encryption and non-encryption products, it makes sense to cite the specific applications where FooBarCo chips are used. So for FooBarCo chips used in VPN and SSL makes sense, even if FooBarCo chips are not *solely* VPN and SSL. However, in for FooBarCo encryption chips used in VPN, the encryption seems to me to denote a special purpose chip, rather than a general purpose chip with an encryption sub-core. I've seen worse manglings of language in similar documents, though, so I would not put it past said middle manager to write for Intel Ivy Bridge encryption chips used in VPN and SSL, even though that's a bit of word salad to anyone who knows the technology. To me, the redacted document sounds like it's referring to a security processor used for SSL offloading. For example, something like a Cavium Nitrox (which I'm not implying is the subject of the document). Cavium Networks or Cavium Nitrox are approximately the right length to fit. Other vendors that might be interesting include F5, Barracuda, Riverbed, Cisco SCA 11000, Radware (an Israeli/American company), and everybody listed on http://en.wikipedia.org/wiki/SSL_Acceleration The document looks like Word and appears to be fully justified; anyone with that software want to match the fonts and try out various substitutions to see what fits best? Note that http://s3.documentcloud.org/documents/784159/sigintenabling-clean-1.pdf seems to have been digitally processed and redacted; the font baselines are perfectly aligned, to the sub-pixel antialiasing limit; while http://s3.documentcloud.org/documents/784280/sigint-enabling-project.pdf appears to have gone out to paper and then been scanned in on a non-flatbed scanner; there is significant vertical slew across the line of text in question. Since the source document appears to be the same for both, an enterprising DTP jockey could use -clean-1.pdf to tune the document settings precisely, and then use -project.pdf to search for better unredaction matches. -andy ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Wed, Dec 11, 2013 at 9:15 PM, Andy Isaacson a...@hexapodia.org wrote: ... Since the source document appears to be the same for both, an enterprising DTP jockey could use -clean-1.pdf to tune the document settings precisely, and then use -project.pdf to search for better unredaction matches. i remember seeing software to do this, but for the life of me cannot find it. anyone? my favorite redaction technique is still the Adobe white text on white background in PDF trick; combine with a filter for CONFIDENTIAL / PROPRIETARY and you've got a fire hose of informative flotsam...[0] best regards, 0. The Revenge of Distance: Vulnerability Analysis of Critical Information Infrastructure http://arxiv.org/abs/cond-mat/0310427 back when Sean Goreman's work and post 9/11 hysteria combined to drive critical infrastructure information into access controlled obscurity (not even FCC outage reports public!) i used this technique with custom deep web crawlers for court documents and other technical references. code doesn't care about color ;) thus fiber counts along specific rights of way allocated to named customers provided the specific capacity information needed to make useful models for measuring spatial implications of telecommunications infrastructure susceptibility to targeted attack. this was the first time i wrote code that actually scared/disturbed me :o ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Tue, Dec 10, 2013 at 4:11 PM, d...@geer.org wrote: ... For this to be an explicit line item in that document, it has to be special. The two classes of special that occur to me are (1) XX has a near monopoly (like Broadcom does in its sector) or (2) XX is uniquely vulnerable to blackmail (a merchant with an export control problem, say). you ask interesting questions Dan, and draw useful conclusions :) some items to note: - is this DUAL_EC_DRNG? don't think so. deadline is FY 2013. - is this DUAL_EC_DRNG? the market for closed source, proprietary crypto solutions is small (and growing smaller, :( - is this XSTORE? it's been a while. but never should have been used directly. see mtrngd with MSR bits set no whitening, max sample, max freq. into mix + conservative estimate before /dev/random write. But in related news: Engineers abandon encryption chips after Snowden leaks http://rt.com/usa/snowden-leak-rng-randomness-019/ some cryptographers and cypherpunks have become despondent or dejected or demoralized by these events. i see a larger picture: never before have so many been doing crypto less wrong! ;P best regards, cross post from cpunks list to save cert for https://peertech.org/ with sha256 C6:5E:C0:43:56:84:2E:11:A3:35:C8:AC:A9:70:96:7B:A5:2E:5B:77 from godaddy with their ident keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE i'm not going to replace cert until jan2014 unless ... it went bad from there. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
The Guardian version (greater redaction): http://s3.documentcloud.org/documents/784159/sigintenabling-clean-1.pdf NYTimes-ProPublica version (lesser redaction): http://s3.documentcloud.org/documents/784280/sigint-enabling-project.pdf [0] A related question is where were these slides posted on the Guardian and NYT sites? Which did which redaction? [1] https://twitter.com/ashk4n/status/37575818993312/photo/1 http://financialcryptography.com/mt/archives/001455.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On 10/11/13 16:31 PM, John Young wrote: The Guardian version (greater redaction): http://s3.documentcloud.org/documents/784159/sigintenabling-clean-1.pdf NYTimes-ProPublica version (lesser redaction): http://s3.documentcloud.org/documents/784280/sigint-enabling-project.pdf [0] A related question is where were these slides posted on the Guardian and NYT sites? Which did which redaction? [1] https://twitter.com/ashk4n/status/37575818993312/photo/1 http://financialcryptography.com/mt/archives/001455.html Nice! Lots more information, and evidence. Blog post updated... This appears to be the NYT commentary: http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0#briefing What I was surprised about with these detailed revelations was that there was almost no fuss. This stuff is the smoking gun for our industry. I must have been totally asleep to miss them... iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
The Gardian, NYT and ProPublica have disclosed their close coordination for Snowden releases. But AFAIK have not disclosed redaction coordination. There is a bit of evidence of PDF and publication coordination among The Guardian and the NYT-Propub via PDF properties and DocCloud file number: ProPub produced its PDF a few minutes before The Guardian but the Guardian was first to put it on DocCloud. Two types of PDF programs were used. Thus the redactions made by likely different means and therefore possibly different means might be used to lift the redactions. The imaging PDFs by the spies are more protective than the commercial versions, and produce much larger file sizes. and more blurred content. See those by ODNI as examples. Several programs claim to be able to lift PDF redactions. PitStop is one we have used successfully some time ago but not recently. http://www.enfocus.com/en/products/pitstop-pro Redax is used widely by the USG to redact. Our version of Redax does not lift the Sigint Enabling redactions on either version. http://www.appligent.com/desktop-software/redax/ Some may recall we lifted redactions on an NYT release of CIA overthrow of Mossedeq by accident when an old, slow machine momentarily delayed the black stripes. We froze the screen repeatedly to grab and reconstruct the underlying text. Adobe has since fixed that hole. But there are likely others due to the incessant attack on vainglorius Adobe. A source for hacking PDF passwords and maybe lifting redactions is Elcomsoft.com, a Russian firm infamous for its coder Dimitry Sklyrov indictment for copyright miscreancy. https://www.eff.org/cases/us-v-elcomsoft-sklyarov http://www.elcomsoft.com/ Lifting redactions would be a fine research project, kind of like Tempest revelations, so great are redactions deployed by govs and journalists these days to wield and flaunt joint complicity to tease and withhold until bribes and budget increases are paid. But results would have to be fast and undercover before the digital barn doors are closed and old-time paper incision is re-instituted. Same for eventual dust-binning of digital crypto in favor of, well, best not to fall for open source delusion again. At 11:25 AM 11/10/2013, you wrote: On 10/11/13 16:31 PM, John Young wrote: The Guardian version (greater redaction): http://s3.documentcloud.org/documents/784159/sigintenabling-clean-1.pdf NYTimes-ProPublica version (lesser redaction): http://s3.documentcloud.org/documents/784280/sigint-enabling-project.pdf [0] A related question is where were these slides posted on the Guardian and NYT sites? Which did which redaction? [1] https://twitter.com/ashk4n/status/37575818993312/photo/1 http://financialcryptography.com/mt/archives/001455.html Nice! Lots more information, and evidence. Blog post updated... This appears to be the NYT commentary: http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0#briefing What I was surprised about with these detailed revelations was that there was almost no fuss. This stuff is the smoking gun for our industry. I must have been totally asleep to miss them... iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
