Re: Why doesn't Sun release the crypto module of the OpenSPARC?
On Fri, Jun 27, 2008 at 12:19:04PM -0700, zooko wrote: > and probably other commodity products). Likewise newfangled ciphers like > Salsa20 and EnRUPT will be considered by me to be faster than AES (because > they are faster in software) rather than slower (because AES might be built > into the commodity hardware). The calculus on AES may change in the nearish future: Intel is adding AES instructions in upcoming processors, and AMD is adding another set of instructions in SSE5 to assist AES implementations. AMD claims a 5x speedup for AES using SSE5 versus plain x86-64 instructions [2], I have not yet seen performance estimates for the Intel instructions. -Jack [1]: http://softwarecommunity.intel.com/articles/eng/3788.htm [2]: http://www.ddj.com/hpc-high-performance-computing/201803067 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC?
On Jun 26, 2008, at 6:55 PM, David G. Koontz wrote: [Moderator's note: this seems to be much more about the open source wars and such than about crypto and security. I'm not going to forward replies on this topic that don't specifically address security issues -- those who were not interested in the original thread may want to skip this message, too. --Perry] The high-order bit here is that the reason Sun has not open sourced the crypto module of the Sparc T2 along with all the other modules is the US government's export restrictions and their extra-legal implicit threats. I've received another e-mail from a Sun employee stating that crypto export restrictions are the issue and that Sun management feels that it is too risky to defy the government's pressure because the government has the power to do billions of dollars in damage to the company by temporarily suspending their export licences for their whole suite of products. My conclusions are: 1. We didn't exactly win the free-crypto struggle after all (see Ian Grigg's and Sameer Parekh's comments [1, 2]), and 2. I'm going to keep designing my security systems to be optimized for software crypto and not to rely on hardware acceleration. In particular, that means that I can continue to consider the Tiger hash (faster in software but not available in commodity hardware) to be faster than the SHA-256 hash (slower in software but available in hardware in the Sparc T2 and probably other commodity products). Likewise newfangled ciphers like Salsa20 and EnRUPT will be considered by me to be faster than AES (because they are faster in software) rather than slower (because AES might be built into the commodity hardware). Note that it would also be a reasonable stance to rely on hardware implementations of crypto even though there are not commodity open source hardware implementations. The beginning of this thread was the question of how to weigh the threat of hardware backdoors, and what countermeasures we can use to gain assurance that we're not vulnerable to hardware backdoors. I'm not saying that having the source code for your hardware is either necessary or sufficient to protect yourself from that threat, but it might help, and I currently think it is a better strategy to design around the assumptions of software crypto. Regards, Zooko [1] https://financialcryptography.com/mt/archives/001064.html [2] http://www.creativedestruction.com/archives/000937.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC?
[Moderator's note: this seems to be much more about the open source wars and such than about crypto and security. I'm not going to forward replies on this topic that don't specifically address security issues -- those who were not interested in the original thread may want to skip this message, too. --Perry] David G. Koontz wrote: > zooko wrote: >> On Jun 12, 2008, at 4:35 PM, David G. Koontz wrote: >> >>> There's the aspect of competition. >>> I've also wondered if a reason they didn't release it is because they >>> bought >>> the 'IP' from someone. >> Those are good guesses, David, and I guessed similar things myself and >> inquired of various Sun folks if this was the "real" reason. Nobody >> could give me any definite answer, however, until Sridhar Vajapey wrote: >> >> "US export control regulations prevent Sun from opensourcing the crypto >> portion of N2.". > > > You've got to admit, that the work load for implementation is quite a bit > higher without the PCI-E, 10GE MACs, and crypto, for a piece of competitive > silicon. All the sudden you don't have that 'Server On a Chip' that Sun > sells. > > The net result is still that you can't compete directly with Sun, but you > can still expand the range of applications for Sun processors, and oh by the > way, Sun's silicon works perfectly well in any new markets. It still walks > like a duck. > > For the record I don't begrudge Sun captive markets, it supports a fairly > decent 64 bit architecture and isn't Intel. What they have released isn't > what they sell. They're demonstrably Rice Christian open source advocates. > > http://en.wikipedia.org/wiki/Rice_Christian > On June 5th, Sun released more of the T2 RTL source, in this case for the NIU (Network Interface Unit) which includes the 10G Ethernet interfaces. This was presented by the fellow responsible on several blogs and announcement on opensparc.net. http://blogs.sun.com/dv/entry/10g_ethernet_design_open_sourced http://blogs.sun.com/dwaynelee/entry/latest_opensparc_t1_and_t2 http://www.opensparc.net/2008-06/durgam-vahia-10g-ethernet-design-open-sourced.html http://www.opensparc.net/opensparc-t2/version-1.1-released.html announcement in which: OpenSPARC T2 System-on-chip (SoC) micro-architecture document has a new chapter on NIU. The document now is also divided in two volumes to reduce the size of the each book. This new System-on-chip (SoC) micro-architecture documents are not in evidence for download, the SoC document available is from December 2007 (without the NIU). One could note that lack of open release of documentation on the NIU would not be a major impediment to a Sun partner with a close working relationship (and access to the UltraSPARC T2 full documentation). One could likewise view it to be detrimental to an independent effort. The reasoning for why I labeled Sun as faint hearted open source advocates can be summed up by how well they fit into the open source community. http://www.groklaw.net/article.php?story=20080626160554713 Pamela Jone's Groklaw article entitled 'A Sun Update on the NetApp Litigation', 26 June 2008: Brendan Scott of Open Source Law was interviewed recently and he made this point: Open source is about community. You need to understand the community to operate effectively in it and this means changing your own behaviour. For example, if you start a new job and there is a cake morning on Monday, then you are going to have to find a cake shop or hone your baking skills if you want to be part of the team. Popping out for group coffee on a Friday like you did at your last employer won't work. That is why it's important to connect with people who are already members of the community and know their way around it - people from the Monday set, not the Friday set. In other words, you have to fit in. Releasing code is not all there is to it. Ethics, fairness, honesty -- it's the FOSS culture, and it's the value add. Any company that tries to play by the old rules undercuts that advantage. http://www.computerworld.com.au/index.php/id;1993045790;pp;1;fp;16;fpid;1 (Brenden Scott interview) Mike Dillon, Sun's General Counsel comments on the NetApp v. Sun litigation over ZFS and on his blog http://blogs.sun.com/dillon/entry/netapp_draft firmly declares Sun as a FOSS player. >From what we see with Sun's opensparc.net effort, their part of the Friday coffee crowd and not part of the Monday effort. The difference between getting by as an open source advocate while continuing your proprietary behaviors, versus really changing and pro actively supporting open source. Sun has lots of irons in the fire for open source, but as far as I know the opensparc effort is furthest along the path as far as using GPL licenses, favoring the CDDL for various other efforts, particularly historically. Sun is still hedging their open source efforts to the point of the appearance of maintaining a proprietary ad
Re: Why doesn't Sun release the crypto module of the OpenSPARC?
"David G. Koontz" <[EMAIL PROTECTED]> writes:
>zooko wrote:
>> "US export control regulations prevent Sun from opensourcing the crypto
>> portion of N2.".
>
>You've got to admit, that the work load for implementation is quite a bit
>higher without the PCI-E, 10GE MACs, and crypto, for a piece of competitive
>silicon. All the sudden you don't have that 'Server On a Chip' that Sun
>sells.
That's a thought I'd had as well, using the Dank Defence ("these nasty people
are holding a gun to our head and forcing us to do this even though we don't
want to") is the easy way out when your real reason is "we don't want to
release this because it's giving too much away to potential competitors".
>The net result is still that you can't compete directly with Sun, but you can
>still expand the range of applications for Sun processors, and oh by the way,
>Sun's silicon works perfectly well in any new markets. It still walks like a
>duck.
Yup.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC?
zooko wrote: > On Jun 12, 2008, at 4:35 PM, David G. Koontz wrote: > >> There's the aspect of competition. > >> I've also wondered if a reason they didn't release it is because they >> bought >> the 'IP' from someone. > > Those are good guesses, David, and I guessed similar things myself and > inquired of various Sun folks if this was the "real" reason. Nobody > could give me any definite answer, however, until Sridhar Vajapey wrote: > > "US export control regulations prevent Sun from opensourcing the crypto > portion of N2.". You've got to admit, that the work load for implementation is quite a bit higher without the PCI-E, 10GE MACs, and crypto, for a piece of competitive silicon. All the sudden you don't have that 'Server On a Chip' that Sun sells. The net result is still that you can't compete directly with Sun, but you can still expand the range of applications for Sun processors, and oh by the way, Sun's silicon works perfectly well in any new markets. It still walks like a duck. For the record I don't begrudge Sun captive markets, it supports a fairly decent 64 bit architecture and isn't Intel. What they have released isn't what they sell. They're demonstrably Rice Christian open source advocates. http://en.wikipedia.org/wiki/Rice_Christian - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC?
On Jun 12, 2008, at 4:35 PM, David G. Koontz wrote: There's the aspect of competition. I've also wondered if a reason they didn't release it is because they bought the 'IP' from someone. Those are good guesses, David, and I guessed similar things myself and inquired of various Sun folks if this was the "real" reason. Nobody could give me any definite answer, however, until Sridhar Vajapey wrote: "US export control regulations prevent Sun from opensourcing the crypto portion of N2.". This is consistent with other public statements such as the comment that originally set me wondering about this in this press piece: "When the UltraSPARC T2 specifications are released Tuesday, Mehta said the company plans on releasing most of the source code, including the designs for the logic gate circuitry and the test suites. The one part of the source code that Sun can not release are the algorithms approved by the National Security Agency as part of the chip's cryptographic accelerations units." http://www.eweek.com/c/a/Linux-and-Open-Source/Sun-Brings-Niagara-2- Chip-to-Open-Source/ Also, I've been watching Sun carefully for a couple of years now, and the top leadership is really fanatical about open source. It would be inconsistent with their current pattern of behavior to withhold a component from GPL release for reason of competitive advantage. My best guess remains that NSA or some such shadowy agency bamboozled them into thinking that it would be illegal to release it, or threatened them with unfortunate coincidences if they went ahead, or persuaded them that GPL'ing it would aid terrorists and cause the needless deaths of innocents. Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC? Competition?
Lawerence Spracklen's Blog: http://blogs.sun.com/sprack/entry/detailed_t2_crypto_info Detailed T2 crypto info Very detailed info on the UltraSPARC T2 cryptographic accelerators can be found here on the OpenSPARC website (the pertinent info can be found in chapter-21 of the doc) Posted on: Sep 11, 2007 With a rebuttal that the Ch 21 in the document found there contained the PCI Express Interface Unit: Unfortunately, it looks like the accelerator details have been removed :-( The SPU is not technically part of OpenSPARC Posted by Lawrence Spracklen on November 05, 2007 at 11:39 AM PST # There's the aspect of competition. The on core crypto gives one heck of a competitive edge for networking applications, and performance figures found on Dr. Spracklen's site show that the crypto stream processors across the CMT can keep up with the 10G Ethernet ports. I can't see them giving a potential competitor everything needed to compete directly. It'd be reminiscent of IBM and Amdahl clones, captive markets and margins for hardware threatened as easily as National's memory boards. I'm sure Sun is wiley enough to have some key patents, too. A case of encouraging help to enlarge the ecosystem, but not empowering direct competition. They don't mind if you develop more markets, after all Sun can play there, too. I've also wondered if a reason they didn't release it is because they bought the 'IP' from someone. There are other instances - parts of the System on a Chip. In the OpenSPARC T2 System on a Chip Micro Architecture pdf there is a disclaimer on page 3: Note ? OpenSPARC T2 currently does not include PCI-Express and 10Gigabit Ethernet design implementation due to current legal restrictions. Equivalent models may be available in the subsequent releases of OpenSPARC T2. If the real reason is competition, it's always nice to have a good excuse, too. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC? Crypto export restrictions
Richard Salz wrote: I would expect hardware designs to be treated more like hardware than software. That's an interesting observation, raising the issue of what is "speech" vs hardware. When I looked into this issue, I found the "Common Criteria" certification methodology as evidence that "speech" covers everything from the most high level abstract design description to the most concrete representation of the hardware that you would look at, e.g. for security certification assurance that electronic gates are properly positioned by the Computer-Aided-Design tools. Hence, any information is "speech", and if it's in the public domain, I would expect an export control exception would apply. Only the actual silicon, and non human-readable dies for the silicon, would be hardware. Otherwise, I see no legal base to locate a cut-off point between "speech" and hardware in the process of design refinements leading to the actual processor. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC? Crypto export restrictions
If only to make sure that there's no confusion about where I stand: I agree with you completely John. I am not surprised that the feds or Sun see it otherwise. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC? Crypto export restrictions
> I would expect hardware designs to be treated more like hardware than > software. A hardware "design" is not hardware. Only a naive parsing of the words would treat it so. A software design is not treated like software; you are free to write about how ATM machine crypto is designed, even if you can't export ATM machine crypto software without a license (because it's proprietary and not mass-market). A hardware design is a lot like software. It's human written and human readable, it's trivial to reproduce, it's compiled automatically into something that can execute, and if you write it into hardware, then it does something. The court case that EFF won against the export controls was won on those grounds: the government can't suppress the publication of human-written and human-readable text, on the grounds that somebody somewhere might put it into a machine that does things the government doesn't like. Sun may be chicken on the point, and the government did a sneaky trick to technically avoid having a Ninth Circuit precedent set on the topic, but a similar precedent was set by Peter Junger's case in another circuit. I think Sun would be well within its rights to ship VHDL or Verilog source code that implements crypto under an open source license. And I'd be happy to point them at good lawyers who'd be happy to be paid to render a more definitive opinion. John Gilmore - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC? Crypto export restrictions
I would expect hardware designs to be treated more like hardware than software. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
