Why doesn't Sun release the crypto module of the OpenSPARC?

zooko zooko at zooko.com
Fri Jun 27 15:19:04 EDT 2008

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.



[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 majordomo at metzdowd.com

More information about the cryptography mailing list