Forgot the link: http://www.sun.com/emrkt/innercircle/newsletter/0304cto.html
Ron
-----Original Message----- From: Ron Teitelbaum [mailto:Ron@USMedRec.com] Sent: Friday, November 24, 2006 2:25 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] ECC and/or NSA Suite B?
I'm not sure I understand this since SUN released ECC to the public domain. I'll get an opinion on it:
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Matthew S. Hamrick Sent: Friday, November 24, 2006 2:07 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] ECC and/or NSA Suite B?
Keep in mind, however, that products violate patent restrictions, not implementations. Otherwise OpenSSL would not be able to include IDEA, MDC2 or RC5.
With all the discussion of FIPS 140, I had assumed that most everyone on the list is working on government contracts. Otherwise, why bother with it?
The NSA negotiated a blanket US Federal Government deal for Certicom's patent portfolio for use in ECDSA, ECDH and ECMQV. So... if you're a federal government agency, you get to use these algorithms without having to pay Certicom anything extra. So... if part of what you're hoping to do is to create an ECC implementation that can be used by a federal agency, then you can do so without fear of the Certicom lawyers. Now... the moment the implementation gets used in a commercial product, then you've got issues.
On Nov 23, 2006, at 10:24 PM, Cerebus wrote:
Is anyone working on Suite B stuff?
Rijndael is there, but it probably should be subclassed as AES proper if only to lock down the blocksize to 128 bits and the keysize to the allowed 128 & 256 bits.
SHA256 is there, but it doesn't extent to cover the rest of the SHA2 family (SHA384 and SHA512). SHA384 is part of Suite B.
Is anyone working on ECDSA, ECDH & ECMQV? (Well, given that ECMQV is more heavily patent-encumbered in the US, I can understand if it's left by the wayside).
If not I might take a crack at a couple of pieces.
-- Tim _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Certicom also holds patents on a number of ECC things (like almost all of ECMQV and things like point compression). NSA has licensed Certicom's ECC patents en masse for anything done on US Gov't contract.
There's a patent letter on the SECG website:
Part of the problem right now is that ECC work is a bit divided, which has made standardization a bit of a pain.
-- Tim
On 11/24/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Forgot the link: http://www.sun.com/emrkt/innercircle/newsletter/0304cto.html
Ron
-----Original Message----- From: Ron Teitelbaum [mailto:Ron@USMedRec.com] Sent: Friday, November 24, 2006 2:25 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] ECC and/or NSA Suite B?
I'm not sure I understand this since SUN released ECC to the public domain. I'll get an opinion on it:
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Matthew S. Hamrick Sent: Friday, November 24, 2006 2:07 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] ECC and/or NSA Suite B?
Keep in mind, however, that products violate patent restrictions, not implementations. Otherwise OpenSSL would not be able to include IDEA, MDC2 or RC5.
With all the discussion of FIPS 140, I had assumed that most everyone on the list is working on government contracts. Otherwise, why bother with it?
The NSA negotiated a blanket US Federal Government deal for Certicom's patent portfolio for use in ECDSA, ECDH and ECMQV. So... if you're a federal government agency, you get to use these algorithms without having to pay Certicom anything extra. So... if part of what you're hoping to do is to create an ECC implementation that can be used by a federal agency, then you can do so without fear of the Certicom lawyers. Now... the moment the implementation gets used in a commercial product, then you've got issues.
On Nov 23, 2006, at 10:24 PM, Cerebus wrote:
Is anyone working on Suite B stuff?
Rijndael is there, but it probably should be subclassed as AES proper if only to lock down the blocksize to 128 bits and the keysize to the allowed 128 & 256 bits.
SHA256 is there, but it doesn't extent to cover the rest of the SHA2 family (SHA384 and SHA512). SHA384 is part of Suite B.
Is anyone working on ECDSA, ECDH & ECMQV? (Well, given that ECMQV is more heavily patent-encumbered in the US, I can understand if it's left by the wayside).
If not I might take a crack at a couple of pieces.
-- Tim _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
What has Sun contributed to OpenSSL? I guess my question is this: If there are version of ECC that are developed and patented by Sun that have been given to the OS communities, either directly or through the OpenSSL license then can we use their implementation?
I wouldn't want to post any code that is not open source in our library which would includes IDEA, MDC2 and RC5.
If we find that ECC is only available to government users then I suggest we do not include it in our repository, the risk would be too great.
What we need to understand is what ECC technology is currently Open Source and can we do our own implementation and distribute it.
Ron
-----Original Message----- From: Cerebus [mailto:cerebus2@gmail.com] Sent: Friday, November 24, 2006 2:36 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: RE: [Cryptography Team] ECC and/or NSA Suite B?
Certicom also holds patents on a number of ECC things (like almost all of ECMQV and things like point compression). NSA has licensed Certicom's ECC patents en masse for anything done on US Gov't contract.
There's a patent letter on the SECG website:
Part of the problem right now is that ECC work is a bit divided, which has made standardization a bit of a pain.
-- Tim
On 11/24/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Forgot the link: http://www.sun.com/emrkt/innercircle/newsletter/0304cto.html
Ron
-----Original Message----- From: Ron Teitelbaum [mailto:Ron@USMedRec.com] Sent: Friday, November 24, 2006 2:25 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] ECC and/or NSA Suite B?
I'm not sure I understand this since SUN released ECC to the public domain. I'll get an opinion on it:
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf
Of
Matthew S. Hamrick Sent: Friday, November 24, 2006 2:07 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] ECC and/or NSA Suite B?
Keep in mind, however, that products violate patent restrictions,
not
implementations. Otherwise OpenSSL would not be able to include
IDEA,
MDC2 or RC5.
With all the discussion of FIPS 140, I had assumed that most
everyone
on the list is working on government contracts. Otherwise, why
bother
with it?
The NSA negotiated a blanket US Federal Government deal for Certicom's patent portfolio for use in ECDSA, ECDH and ECMQV. So... if you're a federal government agency, you get to use these algorithms without having to pay Certicom anything extra. So... if part of what you're hoping to do is to create an ECC implementation that can be used by a federal agency, then you can do so without
fear
of the Certicom lawyers. Now... the moment the implementation gets used in a commercial product, then you've got issues.
On Nov 23, 2006, at 10:24 PM, Cerebus wrote:
Is anyone working on Suite B stuff?
Rijndael is there, but it probably should be subclassed as AES
proper
if only to lock down the blocksize to 128 bits and the keysize to
the
allowed 128 & 256 bits.
SHA256 is there, but it doesn't extent to cover the rest of the
SHA2
family (SHA384 and SHA512). SHA384 is part of Suite B.
Is anyone working on ECDSA, ECDH & ECMQV? (Well, given that ECMQV
is
more heavily patent-encumbered in the US, I can understand if it's left by the wayside).
If not I might take a crack at a couple of pieces.
-- Tim _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-
bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
This is interesting too: http://www.ietf.org/ietf/IPR/certicom-ipr-rfc-3446.pdf
This appears to be related to TLS.
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Ron Teitelbaum Sent: Friday, November 24, 2006 2:44 PM To: 'Cerebus'; 'Cryptography Team Development List' Subject: RE: RE: [Cryptography Team] ECC and/or NSA Suite B?
What has Sun contributed to OpenSSL? I guess my question is this: If there are version of ECC that are developed and patented by Sun that have been given to the OS communities, either directly or through the OpenSSL license then can we use their implementation?
I wouldn't want to post any code that is not open source in our library which would includes IDEA, MDC2 and RC5.
If we find that ECC is only available to government users then I suggest we do not include it in our repository, the risk would be too great.
What we need to understand is what ECC technology is currently Open Source and can we do our own implementation and distribute it.
Ron
-----Original Message----- From: Cerebus [mailto:cerebus2@gmail.com] Sent: Friday, November 24, 2006 2:36 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: RE: [Cryptography Team] ECC and/or NSA Suite B?
Certicom also holds patents on a number of ECC things (like almost all of ECMQV and things like point compression). NSA has licensed Certicom's ECC patents en masse for anything done on US Gov't contract.
There's a patent letter on the SECG website:
Part of the problem right now is that ECC work is a bit divided, which has made standardization a bit of a pain.
-- Tim
On 11/24/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Forgot the link: http://www.sun.com/emrkt/innercircle/newsletter/0304cto.html
Ron
-----Original Message----- From: Ron Teitelbaum [mailto:Ron@USMedRec.com] Sent: Friday, November 24, 2006 2:25 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] ECC and/or NSA Suite B?
I'm not sure I understand this since SUN released ECC to the public domain. I'll get an opinion on it:
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf
Of
Matthew S. Hamrick Sent: Friday, November 24, 2006 2:07 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] ECC and/or NSA Suite B?
Keep in mind, however, that products violate patent restrictions,
not
implementations. Otherwise OpenSSL would not be able to include
IDEA,
MDC2 or RC5.
With all the discussion of FIPS 140, I had assumed that most
everyone
on the list is working on government contracts. Otherwise, why
bother
with it?
The NSA negotiated a blanket US Federal Government deal for Certicom's patent portfolio for use in ECDSA, ECDH and ECMQV.
So...
if you're a federal government agency, you get to use these algorithms without having to pay Certicom anything extra. So... if part of what you're hoping to do is to create an ECC
implementation
that can be used by a federal agency, then you can do so without
fear
of the Certicom lawyers. Now... the moment the implementation gets used in a commercial product, then you've got issues.
On Nov 23, 2006, at 10:24 PM, Cerebus wrote:
Is anyone working on Suite B stuff?
Rijndael is there, but it probably should be subclassed as AES
proper
if only to lock down the blocksize to 128 bits and the keysize
to
the
allowed 128 & 256 bits.
SHA256 is there, but it doesn't extent to cover the rest of the
SHA2
family (SHA384 and SHA512). SHA384 is part of Suite B.
Is anyone working on ECDSA, ECDH & ECMQV? (Well, given that
ECMQV
is
more heavily patent-encumbered in the US, I can understand if
it's
left by the wayside).
If not I might take a crack at a couple of pieces.
-- Tim _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-
bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-
bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
On Nov 24, 2006, at 11:43 AM, Ron Teitelbaum wrote:
What has Sun contributed to OpenSSL? I guess my question is this: If there are version of ECC that are developed and patented by Sun that have been given to the OS communities, either directly or through the OpenSSL license then can we use their implementation?
Yes.
I wouldn't want to post any code that is not open source in our library which would includes IDEA, MDC2 and RC5.
Some people use SSL with RC5 and many banking applications rely on MDC2.
If we find that ECC is only available to government users then I suggest we do not include it in our repository, the risk would be too great.
Why?
What we need to understand is what ECC technology is currently Open Source and can we do our own implementation and distribute it.
ECC is not "Open Source." Open Source generally refers to copyrights, not patents. ECC and it's related technologies may be patented, but in general not copyrighted. An implementation of an ECC cryptosystem may be copyrighted, even if it is not patented. By using an open source license, the copyright holder of the implementation may describe rights under which third parties may copy the implementation.
So...
Even if someone has a copyrighted implementation, you may still be able to use it as part of OpenSSL, if that implementation has been licensed under the appropriate open source license. (look at Borzoi, for instance.) But... if even an open source implementation is put in a product and sold, this is a clear violation of patent. Things get a little murkier when you're including encumbered technology outside of a commercial product. However... if the patent holder issues a royalty-free, non-commercial license (as is the case for IDEA) then I would guess it's okay to produce and distribute an implementation, as long as you don't violate the terms of the non-commercial license. Since the Squeak community is not a commercial entity, I think there's a justification here...
In short... many patent-holders have explicitly granted third parties the right to a royalty-free non-commercial license. In these cases it might be useful to include this technology in the repository, but possibly make a default Squeak image without it. (As it's entirely possible that someone may include Squeak in a commercial product.) But the reason you would not want to include encumbered technology in a default squeak image is not because the Squeak community could get in trouble, but because it would require people who want to use Squeak commercially to understand (and possibly remove) code that implements the encumbered technology.
Ron
-----Original Message----- From: Cerebus [mailto:cerebus2@gmail.com] Sent: Friday, November 24, 2006 2:36 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: RE: [Cryptography Team] ECC and/or NSA Suite B?
Certicom also holds patents on a number of ECC things (like almost all of ECMQV and things like point compression). NSA has licensed Certicom's ECC patents en masse for anything done on US Gov't contract.
There's a patent letter on the SECG website:
Part of the problem right now is that ECC work is a bit divided, which has made standardization a bit of a pain.
-- Tim
On 11/24/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Forgot the link: http://www.sun.com/emrkt/innercircle/newsletter/0304cto.html
Ron
-----Original Message----- From: Ron Teitelbaum [mailto:Ron@USMedRec.com] Sent: Friday, November 24, 2006 2:25 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] ECC and/or NSA Suite B?
I'm not sure I understand this since SUN released ECC to the public domain. I'll get an opinion on it:
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf
Of
Matthew S. Hamrick Sent: Friday, November 24, 2006 2:07 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] ECC and/or NSA Suite B?
Keep in mind, however, that products violate patent restrictions,
not
implementations. Otherwise OpenSSL would not be able to include
IDEA,
MDC2 or RC5.
With all the discussion of FIPS 140, I had assumed that most
everyone
on the list is working on government contracts. Otherwise, why
bother
with it?
The NSA negotiated a blanket US Federal Government deal for Certicom's patent portfolio for use in ECDSA, ECDH and ECMQV. So... if you're a federal government agency, you get to use these algorithms without having to pay Certicom anything extra. So... if part of what you're hoping to do is to create an ECC implementation that can be used by a federal agency, then you can do so without
fear
of the Certicom lawyers. Now... the moment the implementation gets used in a commercial product, then you've got issues.
On Nov 23, 2006, at 10:24 PM, Cerebus wrote:
Is anyone working on Suite B stuff?
Rijndael is there, but it probably should be subclassed as AES
proper
if only to lock down the blocksize to 128 bits and the keysize to
the
allowed 128 & 256 bits.
SHA256 is there, but it doesn't extent to cover the rest of the
SHA2
family (SHA384 and SHA512). SHA384 is part of Suite B.
Is anyone working on ECDSA, ECDH & ECMQV? (Well, given that ECMQV
is
more heavily patent-encumbered in the US, I can understand if it's left by the wayside).
If not I might take a crack at a couple of pieces.
-- Tim _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-
bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Hi Matthew,
-----Original Message----- From: Matthew S. Hamrick Sent: Friday, November 24, 2006 3:25 PM
On Nov 24, 2006, at 11:43 AM, Ron Teitelbaum wrote:
What has Sun contributed to OpenSSL? I guess my question is this: If there are version of ECC that are developed and patented by Sun that have been given to the OS communities, either directly or through the OpenSSL license then can we use their implementation?
Yes.
I wouldn't want to post any code that is not open source in our library which would includes IDEA, MDC2 and RC5.
Some people use SSL with RC5 and many banking applications rely on MDC2.
If we find that ECC is only available to government users then I suggest we do not include it in our repository, the risk would be too great.
Why?
My concern right now is that we have no way of identifying what is OS and what is not. Given that we have no way of making it clear to those that are downloading and using it, I don't want to add something that can not be used in a commercial product without restriction. The risk as I see it is that someone will do it and then come back and say they relied on our advice or some such foolishness. For now unless we have a clear way to delineate what is truly open source and what is available for use but needs licensing from some other third party or must have some agreement already negotiated, I think we should only include truly open source software in our repository.
What we need to understand is what ECC technology is currently Open Source and can we do our own implementation and distribute it.
ECC is not "Open Source." Open Source generally refers to copyrights, not patents.
It appears to me on first glance, [I am not a lawyer and my first glance should not be taken as any sort of legal opinion], that full implementations of ECC have been done and donated to the Open Source Communities by Sun. It also appears that Certicom has made provisions for sharing some of their patents in order to encourage wide spread adoption. My concern is not the patents and/or copyrights but our ability to legally redistributed patented or copyrighted material for use by end users for commercial applications. [The fact that I state this desire does not imply that we certify that our code is usable in a commercial application, if you have legal questions regarding our code and the use of this code in a commercial application please contact a lawyer]
ECC and it's related technologies may be patented, but in general not copyrighted. An implementation of an ECC cryptosystem may be copyrighted, even if it is not patented. By using an open source license, the copyright holder of the implementation may describe rights under which third parties may copy the implementation.
So...
Even if someone has a copyrighted implementation, you may still be able to use it as part of OpenSSL, if that implementation has been licensed under the appropriate open source license. (look at Borzoi, for instance.) But... if even an open source implementation is put in a product and sold, this is a clear violation of patent. Things get a little murkier when you're including encumbered technology outside of a commercial product. However... if the patent holder issues a royalty-free, non-commercial license (as is the case for IDEA) then I would guess it's okay to produce and distribute an implementation, as long as you don't violate the terms of the non-commercial license. Since the Squeak community is not a commercial entity, I think there's a justification here...
Again for right now anything that we redistribute should have a clearly stated license and needs to be usable in a commercial product, before we include the code in our repository. [The fact that I state this desire does not imply that we certify that our code is usable in a commercial application, if you have legal questions regarding our code and the use of this code in a commercial application please contact a lawyer]
In short... many patent-holders have explicitly granted third parties the right to a royalty-free non-commercial license. In these cases it might be useful to include this technology in the repository, but possibly make a default Squeak image without it. (As it's entirely possible that someone may include Squeak in a commercial product.) But the reason you would not want to include encumbered technology in a default squeak image is not because the Squeak community could get in trouble, but because it would require people who want to use Squeak commercially to understand (and possibly remove) code that implements the encumbered technology.
Ron
-----Original Message----- From: Cerebus [mailto:cerebus2@gmail.com] Sent: Friday, November 24, 2006 2:36 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: RE: [Cryptography Team] ECC and/or NSA Suite B?
Certicom also holds patents on a number of ECC things (like almost all of ECMQV and things like point compression). NSA has licensed Certicom's ECC patents en masse for anything done on US Gov't contract.
There's a patent letter on the SECG website:
Part of the problem right now is that ECC work is a bit divided, which has made standardization a bit of a pain.
-- Tim
On 11/24/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Forgot the link: http://www.sun.com/emrkt/innercircle/newsletter/0304cto.html
Ron
-----Original Message----- From: Ron Teitelbaum [mailto:Ron@USMedRec.com] Sent: Friday, November 24, 2006 2:25 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] ECC and/or NSA Suite B?
I'm not sure I understand this since SUN released ECC to the public domain. I'll get an opinion on it:
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf
Of
Matthew S. Hamrick Sent: Friday, November 24, 2006 2:07 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] ECC and/or NSA Suite B?
Keep in mind, however, that products violate patent restrictions,
not
implementations. Otherwise OpenSSL would not be able to include
IDEA,
MDC2 or RC5.
With all the discussion of FIPS 140, I had assumed that most
everyone
on the list is working on government contracts. Otherwise, why
bother
with it?
The NSA negotiated a blanket US Federal Government deal for Certicom's patent portfolio for use in ECDSA, ECDH and ECMQV. So... if you're a federal government agency, you get to use these algorithms without having to pay Certicom anything extra. So... if part of what you're hoping to do is to create an ECC implementation that can be used by a federal agency, then you can do so without
fear
of the Certicom lawyers. Now... the moment the implementation gets used in a commercial product, then you've got issues.
On Nov 23, 2006, at 10:24 PM, Cerebus wrote:
> Is anyone working on Suite B stuff? > > Rijndael is there, but it probably should be subclassed as AES
proper
> if only to lock down the blocksize to 128 bits and the keysize to
the
> allowed 128 & 256 bits. > > SHA256 is there, but it doesn't extent to cover the rest of the
SHA2
> family (SHA384 and SHA512). SHA384 is part of Suite B. > > Is anyone working on ECDSA, ECDH & ECMQV? (Well, given that > ECMQV
is
> more heavily patent-encumbered in the US, I can understand if > it's > left by the wayside). > > If not I might take a crack at a couple of pieces. > > -- Tim > _______________________________________________ > Cryptography mailing list > Cryptography@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ > cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-
bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Great. Do you have a link that talks about what Sun released to the public domain?
On Nov 24, 2006, at 11:25 AM, Ron Teitelbaum wrote:
Forgot the link: http://www.sun.com/emrkt/innercircle/newsletter/0304cto.html
Ron
-----Original Message----- From: Ron Teitelbaum [mailto:Ron@USMedRec.com] Sent: Friday, November 24, 2006 2:25 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] ECC and/or NSA Suite B?
I'm not sure I understand this since SUN released ECC to the public domain. I'll get an opinion on it:
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Matthew S. Hamrick Sent: Friday, November 24, 2006 2:07 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] ECC and/or NSA Suite B?
Keep in mind, however, that products violate patent restrictions, not implementations. Otherwise OpenSSL would not be able to include IDEA, MDC2 or RC5.
With all the discussion of FIPS 140, I had assumed that most everyone on the list is working on government contracts. Otherwise, why bother with it?
The NSA negotiated a blanket US Federal Government deal for Certicom's patent portfolio for use in ECDSA, ECDH and ECMQV. So... if you're a federal government agency, you get to use these algorithms without having to pay Certicom anything extra. So... if part of what you're hoping to do is to create an ECC implementation that can be used by a federal agency, then you can do so without fear of the Certicom lawyers. Now... the moment the implementation gets used in a commercial product, then you've got issues.
On Nov 23, 2006, at 10:24 PM, Cerebus wrote:
Is anyone working on Suite B stuff?
Rijndael is there, but it probably should be subclassed as AES proper if only to lock down the blocksize to 128 bits and the keysize to the allowed 128 & 256 bits.
SHA256 is there, but it doesn't extent to cover the rest of the SHA2 family (SHA384 and SHA512). SHA384 is part of Suite B.
Is anyone working on ECDSA, ECDH & ECMQV? (Well, given that ECMQV is more heavily patent-encumbered in the US, I can understand if it's left by the wayside).
If not I might take a crack at a couple of pieces.
-- Tim _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
cryptography@lists.squeakfoundation.org
-
Cerebus -
Matthew S. Hamrick -
Ron Teitelbaum