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
