Re: Why does OpenSSL own all the prefixes in the world?
On Sep 9, 2014, at 1:03 PM, Ted Byers wrote: >> El 09/09/2014 20:39, "Larry Bugbee" escribió: >>> >>> In the FWIW column >>> >>> Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL >>> from Python (and other dynamic languages) and depend on the C naming >>> convention. Adding a "OSSL_" prefix is fine; mangling creates huge >>> problems. >>> > I use a number of such languages and it isn't all that hard to mix > them with C++ (in sme cases, I'd extend them using C++ code, for the > sake of performance). In the case of Python, for example, there is a > boost library designed specifically for that purpose. From my > perspective, that is not a big problem. Rather, it is just one of > countless things I routinely have to deal with: just the cost of > getting things done. Hi Ted, I would probably agree if I were building production systems. But because I build mostly prototypes, quick usually trumps having to deal with the complexity of C++. OpenSSL and LibTom get used a lot because they are C and super easy to call. When I want classes I build them in Python and call the appropriate OpenSSL functions. Life is much, much simpler when I can stick with Python, C, and Python's ctypes. Then again, if I were building a production app My best, Larry > Cheers > > Ted > > -- > R.E.(Ted) Byers, Ph.D.,Ed.D. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
In the FWIW column Please don't mangle names by forcing C++ namespaces.
Some us call OpenSSL from Python (and other dynamic languages) and depend on
the C naming convention. Adding a "OSSL_" prefix is fine; mangling creates
huge problems.
-- Sent fm iTouch via Boxer
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Iñaki Baz Castillo
> Sent: Tuesday, 09 September, 2014 12:44
> To: openssl-users@openssl.org
> Subject: Re: Why does OpenSSL own all the prefixes in the world?
>
> May be I was not clear, but what I mean is:
>
>
> - Let's suppose openssl/foo.h has a #include .
>
> - In myproject.h I add:
>
> namespace myproject {
> #include
> }
>
> - And then in myproject.cpp I write:
>
> p = (char*)malloc(sizeof(char) * 100);
>
>
> Would this produce the "malloc not found, may be you mean
> 'myproject::malloc'?" error?
>
> PS: Note that I do NOT include in myproject.*.
Yes, in this case I'd expect that error. You need to include stdlib.h outside
of any namespace before you include openssl/foo.h.
My advice would be to stick a bunch of include statements for all the standard
headers used by any openssl/*.h into a single .h file, and then include that at
the top of myproject.h and any other C++ header file that includes an OpenSSL
header.
So:
- Create openssl_c_hdrs.h which has:
#include
#include
#include
...
- Change myproject.h to have:
#include "openssl_c_hdrs.h"
namespace myproject {
#include
}
Again, I can't say for sure that will work, because I haven't tested it. But it
ought to work around this particular issue. The standard headers included by
openssl_c_hdrs.h will preempt their inclusion within the namespace by the
OpenSSL headers.
Of course, for C++ code you normally wouldn't include the C standard headers;
you'd use their C++ versions (, etc). But this sort of thing is a
special case.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
???H???7??m
)z{,???RǫJ?i??Lj)b????)z{,?? ??)z{,????h??^t???Ƨj??&??^??%??
Re: Increment certificate serial numbers randomly
On Apr 28, 2014, at 1:53 AM, Mat Arge wrote: > You'd still have incrementally growing serial numbers > (which is actually bad by itself) but from distinct ranges. ...or perhaps random within the range. smime.p7s Description: S/MIME cryptographic signature
Re: no OPENSSL_Applink in my DLL
I wish you good luck. I was unsuccessful. Be sure to ask why not. For more google applink.c+bugbee -- Sent fm iTouch via Boxer On April 2, 2014 at 11:45:44 AM PDT, Mohan Kumar wrote:Hi, I am writing a DLL plugin which works with a third party plugin. The DLL uses open ssl. I was able to successfully connect to a ssl server from a console application (.exe). But when I added the same code to my dll, it is not working. Discussions point that i should include "applink.c" in my code which has main function, but sadly DLL is all I got. Please point me to a soln. -- Thanks,Mohan
Re: Help: DecryptFinal error
Sent from iTouch
> On Mar 7, 2014, at 11:42 AM, "Li, David" wrote:
>
> Hi,
>
> I am new to openssl C APIs. So I wrote a simple test to encrypt and decrypt a
> 15 byte ASCII string using AES128. The encryption seems OK and the encrypted
> length is 16. But the decryption always failed at EVP_DecryptFinal_ex(). The
> error code is 0 and means padding error. I have been searching on the web but
> so far nothing worked. Can anyone here suggest how to debug this error?
>
> Thanks!
>
> [ Code fragment]
> =
> static int
> my_decrypt(char* data, int datalen, char *debuf, int *delen)
> {
>
> // data is holding the cipher text
> // debuf is to hold the decrypted plain text
> // datalen is 16
> //
>
> int rc;
>
>
> printf (" Data len to be decrypted %d\n", datalen); // 16
> if (!( rc = EVP_DecryptUpdate(&ctx, debuf, delen, data, datalen))) {
> printf (" Decryption error: %d\n", rc);
> return -1;
> }
> printf (" DecryptUpdate delen = %d \n", *delen); // 16
>
> printf (" Finalizing \n");
> if ((rc = EVP_DecryptFinal_ex(&ctx, debuf, &datalen)) == 0) {
> printf (" Finalization error: %d\n", rc); // This is the failure! rc = 0
> return -1;
> }
>
>
>
> David Li
>
It is not clear your encryption is valid, and as you suspect padding may be the
cause.
In cases such as this I recommend firing up another crypto lib to encrypt on
one and decrypt on the other, and visa versa. You should be able to close in
on the cause a lot faster than continually futzing with only the one lib.
Re: Help: DecryptFinal error
On Mar 8, 2014, at 11:23 AM, Larry Bugbee wrote: > On Mar 7, 2014, at 11:42 AM, "Li, David" wrote: > >> Hi, >> >> I am new to openssl C APIs. So I wrote a simple test to encrypt and decrypt >> a 15 byte ASCII string using AES128. The encryption seems OK and the >> encrypted length is 16. But the decryption always failed at >> EVP_DecryptFinal_ex(). The error code is 0 and means padding error. I have >> been searching on the web but so far nothing worked. Can anyone here suggest >> how to debug this error? >> >> Thanks! >> >> [ Code fragment] >> = [ snip ] > It is not clear your encryption is valid, and as you suspect padding may be > the cause. > > In cases such as this I recommend firing up another crypto lib to encrypt on > one and decrypt on the other, and visa versa. You should be able to close in > on the cause a lot faster than continually futzing with only the one lib. Besides, you can be better assured you have interoperability and not a case of two compensating errors.
Re: Private key generation
On May 14, 2011, at 11:54 AM, Zico wrote: > Do we "actually" need a third party to make our certificate? I mean, we can > generate self-certified certificates, right? So, will my production machine > not run if I don't use CAcert.org or GoDaddy or Verisign? It is a matter of trust. If your server is serving a very small group that will trust your self-signed cert, then fine. If however your server is to be visited by a large number of people most of which won't know you, they would likely feel better if your cert was obtained from a well-known and trustable 3rd party. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to define/change "Signature Algorithm"?
Is it possible to define other (SHA512, SHA256, etc) SignatureAlgorithms for use? Yes, if you use 0.9.9-dev. Take a look at ftp.openssl.org. (Cert sigs using 0.9.8 always used SHA-1 regardless of how I attempted to specify SHA-256 etc.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Openssl for Java application
So, I hope that I will get sufficient information from you on how to integrate OpenSSL into my Java application. You might find it a lot easier if you were to use Bouncy Castle. http://www.bouncycastle.org/
Re: own Certificate Authority: Renewal of CA cert
On Mar 24, 2008, at 9:28 AM, Andreas Grimmel wrote: I found this command somewhere in a forum: openssl x509 -in cacert-old.pem -days 1460 -out cacert-new.pem - signkey private/cakey.pem - in my understanding, this command takes the old cert, changes the validity to four more years (1460 days), and generates the new cert signed with the same old private/cakey.pem - somewhat logically. No, that command resigns the cert but all the identity and expiry info is identical. You will need to create a fresh CSR with the same identity info to get a new expiry. But: opposite to that, *I* would have used this command, as I did when creating the original (old) CA cert: openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem - means to just create a new cert using the same old private/ cakey.pem again. As I can see, the only difference would be that in the upper command, I probably don't have to enter the ASN1 DN credentials like CN/ST and so on again, since this would be taken from the old cert Am I correct here? No. The first command just resigns the cert. Its expiry remains unchanged. Use the second command and be sure to type exactly what was on the old cert. Confirm with a -text. Test.
ecparam keygen writes new key in the clear?
It seems if you use 'openssl ecparam -genkey' to create a key pair, you cannot secure the PEM file output. You have to follow with a second command 'openssl ec' to encrypt the private key with AES. ...but the first command has already written the key to disk. Is this an Oops or did I miss something? I tried chaining the two commands and was unsuccessful. Thanks, Larry __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ECC Self-Signed Certificate
I have noticed this as well. I believe it operates correctly in the 0.9.9 snapshot. Indeed, the change log indicates a fix. Thanks. At the moment I'm unable to get a good build with the 3/10 SNAP. ...a problem linking .dylib. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
ecparam keygen writes new key in the clear?
It seems if you use 'openssl ecparam -genkey' to create a key pair, you cannot secure the PEM file output. You have to follow with a second command 'openssl ec' to encrypt the private key with AES. ...but the first command has already written the key to disk. Is this an Oops or did I miss something? I tried chaining the two commands and was unsuccessful. Thanks, Larry __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: testing upgrade from 0.9.7e to 0.9.8g
I am supposed to help with a test plan to make sure our stuff works properly, but I'm not sure what to test. I imagine that it has to be backward compatible, since everyone using HTTPS has to be, but am not sure. Other than reading the NEWS page for changes, can anyone think of something I should do or something specific I should test? I'd focus on testing your application to be sure it does what you want it to do. I'd start by designing a series of tests designed to stress your application, and in turn, openssl. If that means setting up a duplicate, but test environment, I would. You can test openssl all day long and not see what you need to see, namely the functions you use doing what you want them to do. Larry __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ECC Self-Signed Certificate
I've signed and consumed ECC certs just fine. My only problem is that when I specify a hash algorithm like SHA-256, OpenSSL falls back to the default SHA-1 for self-signed certs only. On Feb 13, 2008, at 7:13 AM, Nabil Ghadiali wrote: Ahh ok. That means that even if the signature is valid, it will show up like that. Thanks, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Patterson Sent: Wednesday, February 13, 2008 10:07 AM To: openssl-users@openssl.org Subject: Re: ECC Self-Signed Certificate On Wednesday 13 February 2008 09:58:08 Nabil Ghadiali wrote: I saved the base64 encoded text in a file with an extension ".cer" and then double-clicked it. Microsoft recognizes it is a certificate and opens it up in a certificate viewer. Over here it says "The integrity of the certificate cannot be guaranteed. The certificate may be corrupted or may have been altered" Unless you are using Vista, Microsoft CAPI doesn't support ECC. Have fun. Patrick. Thanks, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni Sent: Wednesday, February 13, 2008 8:00 AM To: openssl-users@openssl.org Subject: Re: ECC Self-Signed Certificate On Wed, Feb 13, 2008 at 12:40:18AM -0500, Nabil Ghadiali wrote: Can someone help me with the command to generate a self-signed certificate using openssl? I have used the following steps and when I get a certificate and open up it says "the signature is invalid". Am I missing something? What does "open it up" mean? The self-signed EC cert you posted looks fine. $ openssl verify -CAfile foo.pem -purpose crlsign foo.pem foo.pem: OK $ openssl x509 -text -in foo.pem Certificate: Data: Version: 3 (0x2) Serial Number: d2:4e:d0:af:62:63:da:1b Signature Algorithm: ecdsa-with-SHA1 Issuer: C=US, ST=Some-State, O=Internet Widgits Pty Ltd Validity Not Before: Feb 13 05:37:39 2008 GMT Not After : Feb 12 05:37:39 2009 GMT Subject: C=US, ST=Some-State, O=Internet Widgits Pty Ltd Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:f3:26:32:97:d1:db:f9:e6:18:40:53:95:f7:67: f7:ab:52:25:96:aa:58:d2:8e:dc:6d:d3:a5:e5:5d: 11:95:e7:73:f9:b3:24:df:5e:4f:b1:5e:55:49:66: 3e:a4:39:3c:c5:a4:74:f0:a3:62:35:94:23:aa:e5: db:83:67:07:35 ASN1 OID: prime256v1 X509v3 extensions: X509v3 Subject Key Identifier: E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2 X509v3 Authority Key Identifier: keyid:E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2 DirName:/C=US/ST=Some-State/O=Internet Widgits Pty Ltd serial:D2:4E:D0:AF:62:63:DA:1B X509v3 Basic Constraints: CA:TRUE Signature Algorithm: ecdsa-with-SHA1 30:45:02:21:00:a7:58:a0:52:62:be:42:dd:53:83:6d:4c:c4: 4f:dd:96:24:56:f5:f8:6b:76:ec:3f:cf:fa:0b:41:8c:6c:4b: 85:02:20:24:00:ae:a7:fb:1b:37:cf:77:f6:3e:2e:47:22:ed: ba:21:0b:79:32:31:3a:07:2b:2f:32:0e:81:4f:8c:eb:b0 -BEGIN CERTIFICATE- MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX 0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr 4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7 GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw -END CERTIFICATE- -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@ope
Re: Compiling on a Mac
The source for incremental_send isn't in the book anywhere that I've seen. I'm using the first edition (June 2002). My code does call incremental_send, and the code I'm trying to compile is the example code provided in the book itself (in chapter 6 - see example 6-4). The book provides the code for incremental_encrypt as well as incremental_finish, so my assumption is that it is a method included in the bowels of the libraries provided. Are you saying that this is a method that I must construct myself? The book doesn't say that, so my assumption is that it is provided. I have run into books that claim to be good but the publisher leaves out critical stuff. Go to the publisher's site and look for errata and downloadable source files. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: About ECC patent and OpenSSL ECC code
Perhaps, and I'm not disagreeing, but for the most part, the crypto libraries have had ECC support for some time. I'm seeing vendors beginning to support ECC, and a couple of CAs discussing and preparing their CPs. Couple all this with the NIST/NSA Suite B recommendation to go there, it is only a matter of time. My personal guess is that before the end of this year we will see major implementations, first as an option. Most will be "vanilla" implementations staying away from the patented subtopics. In 2009-2010 I expect to see ECC in fairly common use, starting with in niche applications, the mainstream to follow. Our challenge as developers is to understand and be ready. My 2 cents. On Jan 10, 2008, at 4:36 PM, Rodney Thayer wrote: As far as I'm concerned, ECC isn't a legitimate public key algorithm for enterprise use at this time because you can't buy a cert from a CA listed in a major browser where the cert uses ECC. Also, those of use who went through the onerous and in the end counterproductive experience of licensing RSA can tell you that the "give me money or I'll sue you" business model got old after a while. I'm not a lawyer but I do have to give CTO-class advice and, assuming you've found a business case for ECC, I always recommend people do a build/buy/license/"let them threaten litigation we don't care" comparison before entering into not-obviously-useful patent licensing deals. So I recommending paying a lawyer to determine if you even care about some vendor's alleged patent portfolio. The fact ECC is in OpenSSL is cute. In the "oh, isn't that cool, they implement IDEA, RC-6, and ECC" kind of exotic crypto side-show kind of way. It's not part of "openssl, the open source TLS/SSL implementation you can use in the real world" any more than any other non-IE/Firefox-supported TLS ciphersuite combination would be. I'd be more impressed with the NSA/Certicom deal if I could find any public evidence there's any PKI anywhere using ECC for a US .gov. As it is this just ends up looking like another exotic military purchase not related to the enterprise world. Show me an HSPD-12 spec that tells me I have to use ECC ;-) Larry Bugbee wrote: There is no substitute for legal counsel, but Tom had a summary that you might be interested in... http://libtom.org/pages/toorcon8_ecc_tstdenis.pdf See slides 24-27. Larry On Jan 10, 2008, at 2:25 PM, Anilkumar Bollineni wrote: Thanks a lot for the responses. Bill, I agree with you that the use of ECC is really matters here, the area where Certicom holds ECC patents. One of our application with respect to ECC that are planning to use ECDSA (Elliptic Curve DSA) signature based certificate generation/verification, signature generation/verification. Meanwhile I talked to one of the sales guy from Certicom, and he is saying that one of certicom patents is related to ECDSA and he said if I want to do ECDSA from OpenSSL, then I need to get license.I am not sure whether that information is correct or not. The OpenSSL does not say anyword about the EC/ECDSA usage and its patents information in Certicom. The only thing I got about that is that Sun has donated the EC code to OpenSSL. If OpenSSL users are really violating the Certicom patents then if users need to be aware of that, then it is better that OpenSSL tell some information about it in the release notes. Or May be that OpenSSL EC implementation does not violate any certicom patents and that's why OpenSSL is not mentioning? Could somebody has any insight in it? Thanks again. Best Regards, Anil Bill Colvin <[EMAIL PROTECTED]> wrote: I would characterize the Certicom patents as falling into 3 main categories: 1) patents relating to the use of ECC in very specific application circumstances This represents the bulk of Certicom patents. For these patents you will have to do your own research as they are dependent on you application and have nothing to do with OpenSSL. 2) patents that improve the performance of the underlying mathematics For these patents, it would be difficult to say if the developers who implemented the underlying math algorithms happened to implement a patented Certicom technique. However, unless they were actually using the patent docs during implementation, I doubt that this would be the case. 3) patents on ECC techniques Now these are the ones you can find in the implementation of OpenSSL. There are two main ones here – point compression and MQV. Point compression reduces the size of an ECC public key, but ECC keys are much smaller than RSA keys even without it, so this one can be avoided. MQV is a key exchange technique. It also can be avoided by using ECDH. NSA licensed 26 Certicom patents (which includes MQV and point
Re: ECC Usage - using OpenSSL as the server and/or client
And if you be a Python user, M2Crypto exposes ECC and the rest of OpenSSL to your program. On Jan 10, 2008, at 8:54 PM, Victor Duchovni wrote: On Thu, Jan 10, 2008 at 10:25:00PM -0500, Victor Duchovni wrote: Does 'openssl s_server' support this? Are there public ECC TLS implementations this is known to interoperate with? OpenSSL s_server is a test tool, not an application. In 0.9.9 snapshot builds, s_server support ECDSA, just point your cert and key files at an ECDSA cert and private key. I have not checked whether it has a command-line option to select an EECDH curve, but this is not important. The command-line option is "-named_curve", and if no curve is specified "prime256v1" is used by default unless the "-no_ecdhe" option is supplied (in which case any name curve is also ignored). So, for what its worth, s_server and s_client fully support EECDH and ECDSA. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: About ECC patent and OpenSSL ECC code
There is no substitute for legal counsel, but Tom had a summary that you might be interested in... http://libtom.org/pages/toorcon8_ecc_tstdenis.pdf See slides 24-27. Larry On Jan 10, 2008, at 2:25 PM, Anilkumar Bollineni wrote: Thanks a lot for the responses. Bill, I agree with you that the use of ECC is really matters here, the area where Certicom holds ECC patents. One of our application with respect to ECC that are planning to use ECDSA (Elliptic Curve DSA) signature based certificate generation/verification, signature generation/verification. Meanwhile I talked to one of the sales guy from Certicom, and he is saying that one of certicom patents is related to ECDSA and he said if I want to do ECDSA from OpenSSL, then I need to get license.I am not sure whether that information is correct or not. The OpenSSL does not say anyword about the EC/ECDSA usage and its patents information in Certicom. The only thing I got about that is that Sun has donated the EC code to OpenSSL. If OpenSSL users are really violating the Certicom patents then if users need to be aware of that, then it is better that OpenSSL tell some information about it in the release notes. Or May be that OpenSSL EC implementation does not violate any certicom patents and that's why OpenSSL is not mentioning? Could somebody has any insight in it? Thanks again. Best Regards, Anil Bill Colvin <[EMAIL PROTECTED]> wrote: I would characterize the Certicom patents as falling into 3 main categories: 1) patents relating to the use of ECC in very specific application circumstances This represents the bulk of Certicom patents. For these patents you will have to do your own research as they are dependent on you application and have nothing to do with OpenSSL. 2) patents that improve the performance of the underlying mathematics For these patents, it would be difficult to say if the developers who implemented the underlying math algorithms happened to implement a patented Certicom technique. However, unless they were actually using the patent docs during implementation, I doubt that this would be the case. 3) patents on ECC techniques Now these are the ones you can find in the implementation of OpenSSL. There are two main ones here – point compression and MQV. Point compression reduces the size of an ECC public key, but ECC keys are much smaller than RSA keys even without it, so this one can be avoided. MQV is a key exchange technique. It also can be avoided by using ECDH. NSA licensed 26 Certicom patents (which includes MQV and point compression) for use in government applications with prime modulus curves greater than 255. This is a good Q&A on the details of this license http://www.certicom.ca/download/aid-501/FAQ-The%20NSA%20ECC%20License%20Agreement.pdf NSA did not license all of Certicom’s patents, only a subset for use in a limited “field of use”. Bill From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Anilkumar Bollineni Sent: January 10, 2008 2:12 PM To: openssl-users@openssl.org Subject: About ECC patent and OpenSSL ECC code Hi there, I have a question on OpenSSL ECC (Elliptic Curve Cryptography) code. I saw that Sun systems has donated the the ECCcode to OpenSSL. Also I saw that Certicom has held 130 patents in ECC area and finally NSA has licensed that code. Suppose if I download the code from the OpenSSL and try to develop a product using the OpenSSL ECC code, does it violate any patent issue with certicom? Can anybody share any experience or information about this? Thanks for support. -Anil Never miss a thing. Make Yahoo your homepage.
