[no subject]
Hi Richard, Thanks for taking a look at this. [guest - Thu Oct 6 11:55:10 2005]: > This stops our engine working with the openssl application (as it > registers a lock debugging callback) and Apache 2.x (and other apps > too no doubt) That's because those applications don't set up callbacks for the dynamic locks. The correct thing to do is to talk with the application authors and tell them that there are new requirements to make engines work. Unfortunately we do not have relationships with all of the application developers for the applications that our customers use, so this is not possible. We shall certainly apply pressure in this direction where we can. On that note, is there a plan to update the apps/openssl application to not use the static lock callback for lock debugging? > or is there something else that we could do instead to allow our > engine to work with static locks? It seems that the dynamic locks > are rarely used. Yes, it's true, they are rarely use... currently. However, I really would encourage people to use them more, as they are a bit more flexible than the static locks. Ideally, OpenSSL should probably move to dynamic locks entirely, which would make maintainance quite a bit easier. The dynamic locks are clearly a much better solution and removing them from openssl will force all applications to move , which would be a good thing in the long run. Is there a plan to do this for any specific future release? Why is it that the static locks have not been removed completely for 0.9.8? If it is to keep some backward compatibility with older apps, or ones that see no reason to change, would it not be preferable if the whole of openssl was compatible in this way, including the engines? It seems a bit unfair on the end users who need hardware support for openssl to keep the interface, so the apps don't realise that they need to change, but to remove the engine support from these apps. I appreciate that the hack for our static lock was not pleasant, but it is no less pleasant than all the other static locks. Are you sure we can't persuade you to put it back in until all static locks are removed? By the way, do you have an nCipher HSM for interop testing? Thanks again -john -- John Hartley nCipher Ltd http://www.ncipher.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL under Win95/98 & Linux
I got the first problem on windows NT, but not on Linux. I suppose the tty is hanging on, because I managed to compile an independant client API that works fine. At 12:11 PM 2/17/99 +0100, [EMAIL PROTECTED] wrote: >I noticed this problem when I used SSLeay 0.9.0b, and I still have the >same problem with OpenSSL 0.9.1c under Win98... > >There are some things I cannot do with the ssleay.exe app: > - use s_client to connect to a web server and ask for the / page. The > negociation goes well, but I can't type anything, and when I stop the > s_client with Ctrl-C, a Windows dialog box raises about an invalid > operation (the message is in French), and everything I typed goes to > the prompt. > > - use s_server and s_client on the same machine. The negociation itself > doesn't work: > > Client side: (ssleay s_client -connect localhost:4433 -state) > CONNECTED(0030) > SSL_connect:before SSL initialization > SSL_connect:SSLv2/v3 write client hello A > SSL3 alert read:fatal:handshake failure > SSL_connect:error in SSLv2/v3 read server hello A > 4291104221:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 >alert handshake failure:.\ssl\s23_clnt.c:446: > __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
AES, counter mode, etc.
When I looked at the AES API, it looked like there was no way to specify a block size independently of the key size. Is that intentional? Additionally, with respect to counter mode, it might be best to implement external to the EVP proper interface, just like HMAC. There are a few issues I see that make counter mode a bit different from other modes: 1) You should be able to insert your own function for choosing a stream of counters. They don't have to be simple incrementing counters. 2) Counter mode can be used in a random-access manner. For example, if you encrypt a file with counter mode, you can then access the blocks of that file independently, as long as you know the counter value. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
Sorry to be a couple of weeks behind on the discussion. Too much going on. On Fri, Feb 15, 2002 at 04:41:10PM -0600, Stephen Sprunk wrote: > > The current state is EAY legacy. His idea was that one should be able > > to pick out any of the algorithm directories and create a separate > > library for them (the old libdes is actually exactly the same as > > crypto/des/). > > First of all, do we still think that's necessary, given the wide > acceptance of OpenSSL and libcrypto? I think it's a good idea to make algorithms easy to cut out. I very often run into people who want to yank out just the pieces of OpenSSL they need, particularly people who are working in embedded environments with memory constraints, or people working at a device driver level. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
On Mon, Mar 04, 2002 at 02:48:46PM +0100, Richard Levitte - VMS Whacker wrote: > From: John Viega <[EMAIL PROTECTED]> > > viega> I think it's a good idea to make algorithms easy to cut out. > > I disagree. We currently have a rather big compatibility mess with > libdes for the simple reason that libdes exists both as it's own > library and as part of SSLeay/OpenSSL. Unfortunately, certain things, > like the definition of DES_LONG, differ between libdes and > SSLeay/OpenSSL on some platforms. Not good. Is this because they are maintained separately? > I'm not sure why you need to yank out source when it's just as easy to > link with libcrypto and make sure you only use the specific > algorithms. In such a case, one should avoid using things like > EVP_get_cipherbyname() since that requires that all compiled > algorithms be linked in. I was thinking more of environments where dynamic linking doesn't exist, or everything you need has to be stored in a limited amount of space like a floppy or some sort of solid-state memory device. This is somewhat common. Off the top of my head, I don't see why a well-organized library couldn't have well-compartmentalized algorithms that can be easily ripped out, yet are all accessible through a generic interface such as EVP. That is, I don't see any disadvantage to such an approach, especially if there's no fear of people breaking out little parts and maintaining them separately. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
On Wed, Mar 06, 2002 at 10:13:55AM +1300, Geoff Thorpe wrote: > > Well yes, but as Richard was explaining - static linking with a libcrypto.a > full of stuff is not that different to linking with a custom-built > "./crypto/des/"-only libdes.a - your linked executable should just contain > the DES bits either way. There's no particular win, that I can see anyway, > to not *building* the rest of libcrypto ... any respectable linker will > only drag in object files from the archive that are required. True, but I've had people tell me that this isn't as easy as it sounds in particular development environments, such as when building Windows device drivers. Apparently, you have to do a lot of work to convert standard make dependencies to whatever process they use, otherwise you end up recompiling OpenSSL in toto almost every time. I don't know enough about the circumstances (not really caring so much about Windows development). All I know is that it's been something I've had people ask about on several occasions. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: SSL_pending() and SSL_ERROR_WANT_READ
Title: RE: SSL_pending() and SSL_ERROR_WANT_READ
Bodo,
Since s->rstate is set to SSL_ST_READ_HEADER prior to record decryption and decompression, wouldn't SSL_pending() still incorrectly indicate that there is data ready to be read in cases where either of these fail?
John Hughes
Software Engineer
F5 Networks, Inc.
www.f5.com
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 14, 2002 11:25 AM
> To: John Hughes
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: SSL_pending() and SSL_ERROR_WANT_READ
>
>
> John Hughes <[EMAIL PROTECTED]>:
>
> > I can confirm: There is a discrepancy between the SSL_pending()
> > manpage and the source. SSL_pending() returns rrec.length in
> > ssl3_pending() (as of 0.9.6a, we also verify that the SSL record
> > being processed is application data, else zero is returned). This
> > variable is updated in ssl3_get_record() when an SSL record header
> > is processed. If the remainder of that SSL record has not yet been
> > received, SSL_pending() will return a non-zero value even though
> > there may not be that amount of data ready. This contradicts the
> > SSL_pending() manpage, which indicates that its return value
> > represents the amount of data immediately available. I haven't yet
> > examined whether SSLv2 connections experience the same problem.
>
> This patch should fix the bug:
>
> diff -u -r1.57 s3_lib.c
> --- s3_lib.c 2001/10/20 17:56:35 1.57
> +++ s3_lib.c 2002/03/14 19:20:58
> @@ -943,6 +943,9 @@
>
> int ssl3_pending(SSL *s)
> {
> + if (s->rstate == SSL_ST_READ_BODY)
> + return 0;
> +
> return (s->s3->rrec.type == SSL3_RT_APPLICATION_DATA) ?
> s->s3->rrec.length : 0;
> }
>
>
>
> --
> Bodo Möller <[EMAIL PROTECTED]>
> PGP
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
Best way to handle includes?
Hi All; I need some comments. We've been creating some 'black boxes' for other developers in our company to work with. One of the black boxes is opensll. We want to distribute to our developers just 'enough'. So they'll be getting the libraries, but what do I have to give them in the way of includes. Should the developers just get the include/openssl directory or can I trim that down more. Interested in what others might think! Thanks very much in advance for your time. Best regards John Cebasek [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Best way to handle includes?
Hi: Well, the idea is some sort of configuration control. The developers get the headers and the libraries and they do some sort of work. When we get a new version and test it and all that good stuff, they get headers and libraries and continue to work. Also makes automated builds a little easier. Just get the files from here sort of idea. And that way they don't have to waste time building OpenSSL that really isn't going to change for them (much). Anyway. I think I'll just point then to include/openssl and that's the header files they use. Best Regards John Cebasek [EMAIL PROTECTED] > -- > From: Götz Babin-Ebell > Reply To: [EMAIL PROTECTED] > Sent: Friday, March 22, 2002 16:29 > To: [EMAIL PROTECTED] > Subject: Re: Best way to handle includes? > > John Cebasek wrote: > > > > Hi All; > Hello John, > > > I need some comments. > > > > We've been creating some 'black boxes' for other developers in our > company > > to work with. One of the black boxes is opensll. We want to distribute > to > > our developers just 'enough'. So they'll be getting the libraries, but > what > > do I have to give them in the way of includes. Should the developers > just > > get the include/openssl directory or can I trim that down more. > > Why would you do that ? > > You can't hide any information about OpenSSL that way. > If your developer want to see the full list of headers, > they can get them from www.openssl.org. > (besides the sources...) > > And figuring out which header they need costs time > you really should spent on doing something usefull. > > Bye > > Goetz > > -- > Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de > Sonninstr. 24-28, 20097 Hamburg, Germany > Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 > > __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP & DES, was: EVP_CipherInit() doesn't check for weak DES keys (0.9.6)
On Wed, Apr 03, 2002 at 11:12:40PM -0700, James Yonan wrote: > > (b) Some kind of *optional* EVP method (so it doesn't break interoperability > with non-OpenSSL clients) that, given an EVP_CIPHER and key, will > deterministically mutate the key into a correct form. Out of 2^56 DES keys, there are four weak keys and 12 semi-weak keys. The odds of getting a weak key are incredibly slight. Most people don't bother to check, and it isn't considered a security risk. Performing a transformation on semi-week keys seems like a bad idea compared to simply ignoring weak and semi-weak keys, because (in the case of DES) you've just made 16 keys twice as likely to be used. It's just as easy to test for 16 likely keys as it is to test for 16 semi-weak keys. Basically, you've just made the problem twice as bad (not that it was so bad in the first place). If you care about checking for weak keys, then you should simply generate a new key at random when you detect a weak key. Check for weakness before key agreement, period. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP & DES, was: EVP_CipherInit() doesn't check for weak DES keys (0.9.6)
On Thu, Apr 04, 2002 at 04:07:47AM -0700, James Yonan wrote: > > I was thinking more about maintaining proper key parity. Does a client of > EVP need to worry about making sure that if DES is the underlying cipher, > that passed keys have the proper parity? Generally, people just ignore the parity bits, however you can strictly check. IIRC, the default in OpenSSL (ie, the EVP interface) is to ignore them. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openssl-0.9.6c through openssl-0.9.5 fail if $PERL is defined notas the binary perl
Title: openssl-0.9.6c through openssl-0.9.5 fail if $PERL is defined n Greetings, First let me thank you for your wonderful product openssl. It works great and I am very thankful it is out there. I have found a small conflict in more recent version of the config or Configure script for version 0.9.c back through 0.9.5 that if $PERL is defined as anything but the binary location for perl the configure script will fail with a message: permission defined to /var/local/bin (or I guess whatever the path that $PERL is defined as). Personally I have $PERL defined as the source of perl and the place where I put new modules. I would think that your script should at least check if $PERL is defined to see if the path it is pointing to is a binary or not – it will try to use it as a binary executable even if it points to a directory! Not a good idea. Perhaps if $PERL is defined you could either prompt to see if it is the correct value, test to see if it is the correct value or unset and set it again before your configure scripts exit. It is a very small problem but I expect it could confuse some newer user users. Thanks, john
Re: [openssl.org #26] 64 bit Suse Linux on PowerPC
Thank you Lutz and Tim. By configuring with the following: ./Configure linux-ppc I was able to run "make" successfully and then run "make test" and "make install" successfully as well. I was able therefore to successfully build, run the build verification tests and install on the 64 bit Suse Linux on powerPC. Now all we need to do is get ./config to recognize this environment as "linux-ppc" and we will be fine. Thanks again. John "Lutz Jaenicke via RT" <[EMAIL PROTECTED]>@openssl.org on 05/09/2002 04:25:26 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:John Bihlmeyer/Raleigh/IBM@IBMUS cc:[EMAIL PROTECTED] Subject:[openssl.org #26] 64 bit Suse Linux on PowerPC [[EMAIL PROTECTED] - Thu May 9 22:13:32 2002]: > I am trying to compile on a 64 bit Suse sles7 powerpc system. > the error message indicates > > -m486 > > is an invalid compiler parameter. Anyone know the parameters I need to give > ./config to > get it to work for 64 bit Suse on a powerpc > > below are the results from running ./config without parameters and the > results from running the make command. > Operating system: ppc64-whatever-linux2 > Configuring for linux-elf Obviously "config" mistakenly selects the "linux-elf" target that is used for x86 platforms. (This is a bug that has to be fixed.) Configure also contains an entry for "linux-ppc", I however don't know whether it is suitable for 64bit PowerPC. Please try "Configure linux-ppc" directly instead of calling "config" and keep us updated, whether it works out. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #26] 64 bit Suse Linux on PowerPC
Lutz, I pulled the SNAP - openssl-0.9.6-stable-SNAP-20020513.tar.gz I took out the config file and ftped it to the SUSE linux 64 bit system on powerpc and ran the build over again and all worked well. ./config correctly set the system makeworked make test worked make install worked Thanks. John -- Forwarded by John Bihlmeyer/Raleigh/IBM on 05/14/2002 08:30 AM --- "Lutz Jaenicke via RT" <[EMAIL PROTECTED]>@openssl.org on 05/12/2002 03:47:11 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:John Bihlmeyer/Raleigh/IBM@IBMUS cc:[EMAIL PROTECTED] Subject:[openssl.org #26] 64 bit Suse Linux on PowerPC Thanks. I have added a corresponding entry into "config". Please check out a new snapshot for correct behaviour. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
OpenSSL is the cornerstone for Open Source projects using encryption. Has anyone done an analysis of what legalities need doing to use it legally in the United States? I have several charities and the like who'd love to use it but can't risk a legal conflict. TIA. __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #22] [PATCH] to dev build 20020428 for Win64on Itanium
Richard, Actually, I agree completely. Frankly I was a little afraid to say it, as it entails so many changes to the code base. The entire concept of the P64 memory model not allowing int's to be used naturally is foreign to the ideals set out by the C language. However there is a slim possibility that some cast will cause data to be lost (assuming Win64 implementations actually make use of all that extra memory and address space :), so I believe your approach is much better. At this time, win64 software is cross compiled on win32 machines. The needed tools are available in the Microsoft SDK - I would send it to you, but it's actually easier for you to simply download the free SDK from http://www.microsoft.com/msdownload/platformsdk/sdkupdate where you will find the entire November 2001 (latest) version of the platform sdk, including IA64 development libraries and tools. I suggest you either install directly from the web site, or choose the "download" menu option in the menu bar at the top of the web page, then choose "full download". It will take you to another page, where you can download the dozen (or so) cab files that will expand into a cd image. If you prefer, you can order the CD for a few dollars. You gotta give Microsoft credit for making development on their platforms simple... You only need the CoreSDK - that should save you some time if you install directly from the platform sdk web page. John >>> "Richard Levitte via RT" <[EMAIL PROTECTED]> 05/29/02 06:29AM >>> I understand the concern here, but I very strongly disagree with the solution. Casting everything from size_t to int is going in the wrong direction. I'll work on moving int to size_t where needed. If someone can tell me how to simulate have a 64-bit size_t on Linux, it would make it easier for me to do accurate tests. That or send me an Itanium box with the nedded software :-). -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #27] Legalizing OpenSSL in France
Please post the results of the registration. I donate time to an international charity. If I know OpenSSL is legal and registered in France, that's one less hurdle to having an international PKI 8-). My thanks in advance... jt --- Richard Levitte via RT <[EMAIL PROTECTED]> wrote: > > Loic, > > I've looked this over, and I think I'd be able to > help writing such > a declaration. Can I request your help with this > (I'm half-french, > but unfortunately my written french is a bit rusty)? > > > I'll start with writing the technical parts in > english as well as I > can and will ask the rest of the OpenSSL team to > review it for me. > > Note: my time is rather limited, so it will take a > few weeks before > you get anything constructive from me :-). > > Question: it looks like the DCSSI form requires some > kind of more or > less legal association or company to be responsible > for the > document. However, OpenSSL has no legal status in > that manner > (there's no registered association called OpenSSL). > However, if an > entity like "OpenSSL SE" (see > http://www.openssl.org/about/contacts.html) is > enough, the problem > should be solved... > > [[EMAIL PROTECTED] - Thu May 9 22:41:47 > 2002]: > > > > > Hi, > > > > In France each cryptographic software must be > declared to a > > government agency (DCSSI, see > > http://france.fsfeurope.org/dcssi/dcssi.fr.html > > for more information in french). > > > > In order to complete this declaration, we need to > fill a > short > > technical form. Could someone with intimate > OpenSSL knowledge fill > it > > for > > us in english ? You'll find a english translation > of the form at: > > > > > http://france.fsfeurope.org/dcssi/arrete-17-mars-1999.en.html > > > > and the technical form filled for GnuPG, also > available in > english > > will give you an idea of the answers expected. > > > > http://france.fsfeurope.org/dcssi/gnupg.en.html > > > > Thanks in advance, > > > -- > Richard Levitte > [EMAIL PROTECTED] > __ > OpenSSL Project > http://www.openssl.org > Development Mailing List > [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ANNOUNCE: "Network Security with OpenSSL" (+DC area SSL talk)
O'Reilly has just published our book, "Network Security with OpenSSL". First, the marketing speak: "Instead of getting bogged down in the technical details of how SSL/TLS works under the hood, this book focuses on the information that is necessary to use OpenSSL safely and effectively. The reader is taken step by step from understanding the challenges faced in communicating securely to using the OpenSSL tools to best meet those challenges. System and network administrators will benefit from the thorough treatment of the OpenSSL command-line interface, as well as from step-by-step directions for obtaining certificates and setting up their own certification authority. Developers will benefit from the in-depth discussions and examples of how to use OpenSSL in their own programs. Although OpenSSL is written in C, information on how to use OpenSSL with Perl, Python and PHP is also included." The book is available from the usual sources, such as Amazon: http://www.amazon.com/exec/obidos/ASIN/059600270X/ We'll also have a few signed copies available to people in the Washington DC area, this Thursday (the 27th). We'll have them at 30% off. Please email me to reserve a copy, as we only have a limited number. At the event, John Viega will be giving a FREE talk entitled, "Why SSL Isn't Securing Your Software". You can find more information on the event at: http://dc.securitygeeks.com/june2002.html John Viega Matt Messier Pravir Chandra msg12129/pgp0.pgp Description: PGP signature
S/MIME implemementation doesn't follow MIME spec. Patch included.
The OpenSSL S/MIME implementation doesn't follow the MIME
specification when writing out messages in that format. As a result,
messages created with this library will choke when passed through
strictly compliant SMTP libraries.
A patch is below, against today's mid-afternoon CVS tree (EST). The
problem was found and the patch created by Zachary Girouard
<[EMAIL PROTECTED]>.
diff --exclude=*Makefile* -ur openssl/apps/smime.c openssl-zakk/apps/smime.c
--- openssl/apps/smime.cWed May 8 11:12:59 2002
+++ openssl-zakk/apps/smime.c Tue Jul 16 01:31:09 2002
@@ -530,9 +530,9 @@
} else if(operation == SMIME_PK7OUT) {
PEM_write_bio_PKCS7(out, p7);
} else {
- if(to) BIO_printf(out, "To: %s\n", to);
- if(from) BIO_printf(out, "From: %s\n", from);
- if(subject) BIO_printf(out, "Subject: %s\n", subject);
+ if(to) BIO_printf(out, "To: %s\r\n", to);
+ if(from) BIO_printf(out, "From: %s\r\n", from);
+ if(subject) BIO_printf(out, "Subject: %s\r\n", subject);
if(outformat == FORMAT_SMIME)
SMIME_write_PKCS7(out, p7, in, flags);
else if(outformat == FORMAT_PEM)
diff --exclude=*Makefile* -ur openssl/crypto/dso/dso_lib.c
openssl-zakk/crypto/dso/dso_lib.c
--- openssl/crypto/dso/dso_lib.cMon Jul 15 11:35:39 2002
+++ openssl-zakk/crypto/dso/dso_lib.c Mon Jul 15 16:59:53 2002
@@ -394,7 +394,7 @@
{
char *result = NULL;
- if(dso == NULL || dir == NULL)
+ if(dso == NULL)
{
DSOerr(DSO_F_DSO_MERGE,ERR_R_PASSED_NULL_PARAMETER);
return(NULL);
diff --exclude=*Makefile* -ur openssl/crypto/pkcs7/pk7_mime.c
openssl-zakk/crypto/pkcs7/pk7_mime.c
--- openssl/crypto/pkcs7/pk7_mime.c Tue Jan 30 08:38:59 2001
+++ openssl-zakk/crypto/pkcs7/pk7_mime.cMon Jul 15 16:57:29 2002
@@ -164,34 +164,34 @@
bound[i] = c;
}
bound[32] = 0;
- BIO_printf(bio, "MIME-Version: 1.0\n");
+ BIO_printf(bio, "MIME-Version: 1.0\r\n");
BIO_printf(bio, "Content-Type: multipart/signed;");
BIO_printf(bio, " protocol=\"application/x-pkcs7-signature\";");
- BIO_printf(bio, " micalg=sha1; boundary=\"%s\"\n\n", bound);
+ BIO_printf(bio, " micalg=sha1; boundary=\"%s\"\r\n\r\n", bound);
BIO_printf(bio, "This is an S/MIME signed message\n\n");
/* Now write out the first part */
BIO_printf(bio, "--%s\n", bound);
- if(flags & PKCS7_TEXT) BIO_printf(bio, "Content-Type: text/plain\n\n");
+ if(flags & PKCS7_TEXT) BIO_printf(bio, "Content-Type:
+text/plain\r\n\r\n");
while((i = BIO_read(data, linebuf, MAX_SMLEN)) > 0)
BIO_write(bio, linebuf, i);
- BIO_printf(bio, "\n--%s\n", bound);
+ BIO_printf(bio, "\n--%s\r\n", bound);
/* Headers for signature */
- BIO_printf(bio, "Content-Type: application/x-pkcs7-signature;
name=\"smime.p7s\"\n");
- BIO_printf(bio, "Content-Transfer-Encoding: base64\n");
- BIO_printf(bio, "Content-Disposition: attachment;
filename=\"smime.p7s\"\n\n");
+ BIO_printf(bio, "Content-Type: application/x-pkcs7-signature;
+name=\"smime.p7s\"\r\n");
+ BIO_printf(bio, "Content-Transfer-Encoding: base64\r\n");
+ BIO_printf(bio, "Content-Disposition: attachment;
+filename=\"smime.p7s\"\r\n\r\n");
B64_write_PKCS7(bio, p7);
- BIO_printf(bio,"\n--%s--\n\n", bound);
+ BIO_printf(bio,"\r\n--%s--\r\n\r\n", bound);
return 1;
}
/* MIME headers */
- BIO_printf(bio, "MIME-Version: 1.0\n");
- BIO_printf(bio, "Content-Disposition: attachment; filename=\"smime.p7m\"\n");
- BIO_printf(bio, "Content-Type: application/x-pkcs7-mime;
name=\"smime.p7m\"\n");
- BIO_printf(bio, "Content-Transfer-Encoding: base64\n\n");
+ BIO_printf(bio, "MIME-Version: 1.0\r\n");
+ BIO_printf(bio, "Content-Disposition: attachment; filename=\"smime.p7m\"\r\n");
+ BIO_printf(bio, "Content-Type: application/x-pkcs7-mime;
+name=\"smime.p7m\"\r\n");
+ BIO_printf(bio, "Content-Transfer-Encoding: base64\r\n\r\n");
B64_write_PKCS7(bio, p7);
- BIO_printf(bio, "\n");
+ BIO_printf(bio, "\r\n");
return 1;
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SMIME question
It's impossible to make an interoperable, signed S/MIME message with OpenSSL at the moment due to a dumb bug in the OpenSSL implementation. Go figure, no one actually seems to USE the OpenSSL S/MIME stuff (perhaps not just because of the bugs... lack of v3 support is an issue for me). John On Wed, Jul 24, 2002 at 04:44:49PM +0900, Maya wrote: > Hello! > > I used SMIME command tool to create some SMIME messages. > > I can create signed, encrypted message and to verify and decrypt them with my >functions. > > Now I want to make this messages fully compliant with existing mail clients: > 1. My functions to can verify and decrypt message created by other mail clients. > 2. Messages created by my functions to can be verifed and decripted from other mail >clients (e.g Outlook Express). > > > When I create signed or encrypted message, I get as input param SMTP header + MIME >message. > Do I have to signed and encrypt both (SMTP header + MIME message) or just the second >part? > What should be the SMTP header of the Signed or(and) Encrypted message? > > I'll be very happy If someone can help me? > > Thanks > Maya __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
hash function slowdown in 0.9.7?
Title: hash function slowdown in 0.9.7? Has anyone else noticed a considerable decrease in performance of md5 and sha1 from 0.9.6* to 0.9.7-beta*? It doesn't seem so bad for large data sizes, but it's particularly bad for data sizes less than 1024 bytes. I've found consistent results on different operating systems and processors. Here are my results of 'openssl speed md5 sha1' for 0.9.6g and 0.9.7beta3, running RedHat7.3 on a PIII-933: OpenSSL 0.9.6g [engine] 9 Aug 2002 built on: Mon Sep 9 11:41:47 PDT 2002 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM The 'numbers' are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md5 9735.21k 52952.34k 103338.58k 134945.71k 154970.79k sha1 6202.44k 30235.64k 54472.18k 68353.02k 73571.83k OpenSSL 0.9.7-beta3 30 Jul 2002 built on: Mon Sep 9 14:02:53 PDT 2002 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=pentium -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md5 9167.94k 29791.80k 76580.05k 122172.19k 147694.36k sha1 8264.75k 23119.26k 47949.99k 65059.75k 73067.71k -John
Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl 0.9.7-beta3
On Thursday, October 17, 2002, at 04:22 PM, Richard Levitte - VMS
Whacker wrote:
Those modes *require* that a multiple of {block_size} bytes get
through to get properly encrypted/decrypted.
In case I wasn't clear last time (rereading, I'm afraid I wasn't), the
above quoted text is wrong.
CFB (in block-aligned sizes) does require a full block's worth of
ciphertext to generate the keystream for the NEXT block of ciphertext.
However, if you've got a partial block of plaintext, you just XOR that
partial block with the appropriate bytes from the one keystream block
you've already generated. You don't have to wait for more plaintext to
come in. And, if that plaintext turns out to be the last of it,
there's absolutely no reason to pad, because each bit of the output
corresponds directly with a bit of the input (thus blocks are ALWAYS
one bit if you want to think of it in terms of blocks).
OFB should never have a feedback size other than the block size.
Essentially, OFB generates a keystream by encrypting the IV, then
continually encrypting the previous block generated. With OFB, you can
precompute your keystream before you have data to encrypt (just as you
can with RC4). When data comes in, you simply XOR it with the
keystream, meaning that once again, if there's a notion of blocks,
they'd have to be one-bit blocks.
Hope I've communicated my message in some combination of these two
attempts :)
John
PGP.sig
Description: PGP signature
Re: Building for Win64?
Nathan, I've created a build for Win64, but it hasn't made it into the main dev code base yet because the patches I created were not entirely complete - there are some larger architectural issues regarding openssl's use of file handles. File (and socket) handles have traditionally been small integer numbers (usually indexes into a file handle table) on most platforms. Win32 however, uses kernel handle objects, which are opaque memory pointers. Thus, handles on Win64 are 64-bit values, while handles every where else (32- or 64-bit platforms) are still small integer values. The other main issue is the use of int rather than size_t for data size values. Many times, this doesn't matter, because most of these sizes are not going to be greater than 64k, much less the 4gb available to a 32-bit int. However, there are a few places where it does matter. John >>> [EMAIL PROTECTED] 10/16/02 01:02PM >>> Hi, I'm trying to build OpenSSL for Win64. Request Tracker #22, which is a patch adding support for Win64, doesn't seem to have made it into the 0.9.8-dev tree, and nothing seems to have happened on that front since the end of June. Does someone have a status update? If the hold-up is a lack of an environment to build/test please let me know -- I have fast machines with the official (Aug 2002) MS IA64 SDK, and access to Itaniums for testing. Has anyone successfully compiled for Win64? Any pointers would be greatly appreciated. -Nathan _ Nathan Kidd Builds Engineer Hummingbird Ltd. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CTR mode
CTR-mode would need to call the appropriate ECB mode function. That could be done without going through the EVP interface. Also, you could probably implement counter mode purely with macros if the right data items are in the cipher context, meaning that it wouldn't be any slower than calling any other encryption mode through the EVP interface. I need to write something like this anyway. I'll work on it tonight, and send it to you tomorrow. John On Thursday, October 17, 2002, at 04:30 PM, Richard Levitte - VMS Whacker wrote: In message <[EMAIL PROTECTED]> on Thu, 17 Oct 2002 16:19:23 -0400, John Viega <[EMAIL PROTECTED]> said: viega> > viega> Also, why isn't counter mode implemented in a generic fashion? viega> > It's viega> > viega> so simple, it should be usable with any block cipher without viega> > having to viega> > viega> write additional code. viega> > viega> > Ask yourself why OFB, CFB, CBC and ECB modes aren't implemented viega> > generically. A hint: speed. Someone made a test having a generic CBC viega> > that would take a pointer to the cipher function to use. The speed viega> > apparently decreased enough for it to be an issue. viega> viega> I mean have a generic implementation, not necessarily a generic viega> interface. I was more thinking a counter mode macro that could be used viega> to create counter mode instances for all block ciphers quickly. That's something I've thought of just a few days ago. I'll add that to my TODO. viega> Additionally, if you were to create a COUNTER wrapper along the lines viega> of the HMAC wrapper (clearly it'd need to be a bit different), you viega> wouldn't need the indirection of a function pointer whatsoever, and viega> would not need to explicitly instantiate macros. All the HMAC stuff I see (quick look) call EVP functions. If the mode functions did that, we'd see dramatic slowdown. Not a good thought. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See <http://www.stacken.kth.se/~levitte/mail/> for more info. PGP.sig Description: PGP signature
Re: CTR mode
On Thursday, October 17, 2002, at 04:10 PM, Richard Levitte - VMS Whacker wrote: viega> Additionally, a lot of stuff built on counter mode is using a few bits viega> of the counter for other purposes, so the effective counter size is viega> less than the actual counter size. It would be nice to be able to add viega> some sort of parameter that specifies the actual counter size, to viega> prevent counter mode from continuing to encrypt when it's run out of viega> counters. I'm not sure if I understood that. Look at the CCM-mode spec, or the IPSEC proposed bindings for AES-CTR mode, and I think you'll see what I mean. viega> Also, why isn't counter mode implemented in a generic fashion? It's viega> so simple, it should be usable with any block cipher without having to viega> write additional code. Ask yourself why OFB, CFB, CBC and ECB modes aren't implemented generically. A hint: speed. Someone made a test having a generic CBC that would take a pointer to the cipher function to use. The speed apparently decreased enough for it to be an issue. I mean have a generic implementation, not necessarily a generic interface. I was more thinking a counter mode macro that could be used to create counter mode instances for all block ciphers quickly. Additionally, if you were to create a COUNTER wrapper along the lines of the HMAC wrapper (clearly it'd need to be a bit different), you wouldn't need the indirection of a function pointer whatsoever, and would not need to explicitly instantiate macros. John PGP.sig Description: PGP signature
Re: [openssl.org #307] OFB, CFB padding in 0.9.7b3
On Thursday, October 17, 2002, at 05:16 PM, Olaf Kirch via RT wrote: On Thu, Oct 17, 2002 at 10:24:01PM +0200, Richard Levitte - VMS Whacker wrote: To make it easier to understand what you're talking about, it would be good to use terms like CFB-8, i.e. where the block size (in bits) is included in the identity. Okay. To make things clearer: I'm working on some code that processes PGP encrypted data. PGP uses CFB in the following fashion: encrypt IV XOR blocksize worth of ciphertext with IV to produce plain text set IV to cipher text encrypt IV ... Not sure if this is called CFB8 - I guess it is but even Schneier isn't totally clear on that, IMHO. No. This is regular old CFB, meaning the feedback size is the same as the block size. CFB with 8-bit feedback would take 8 bits of the first 8 bits of the ciphertext and shove out 8 bits of the IV (shifting 8 bits left), then use the result as the IV for generating the second block of keystream. IIRC (and I may not, since no one I've ever seen uses CFB with less than block-sized feedback), Keystream is still generated in block-sized increments using that algorithm. Did you try turning the padding off, as a temporary workaround? I seem to remember that breaking CFB, but I could have been wrong there. I have no problem either if OpenSSL 0.9.7 changes the default behavior of EVP_xxx_cfb() but provides EVP_xxx_cfb8() for those who need it. The EVP_CIPHER_CTX_set_padding() macro should be the right way to switch between padded and unpadded CFB. I don't see any reason to have padded CFB other than some standards document mentions it somewhere (I am pretty sure most apps do not use the padding), so I definitely feel padding off should be the default. With OFB, there's no reason for the padding whatsoever, and I don't even see a reason to support it. But, if it does get supported, it should most certainly default to off. John PGP.sig Description: PGP signature
Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl 0.9.7-beta3
On Thursday, October 17, 2002, at 04:22 PM, Richard Levitte - VMS
Whacker wrote:
In message <[EMAIL PROTECTED]> on Thu, 17 Oct 2002
14:15:22 -0400, John Viega <[EMAIL PROTECTED]> said:
I'm honestly unsure what you guys are talking about. Could it
confusion over the fact that we have only implemented CFB-xx and
OFB-xx, where xx is the block size of the underlying algorithm? This
means that for all algorithms other than AES, we have implemented
CFB-64 and OFB-64, and for AES we have implemented CFB-128 and
OFB-128.
The feedback size is important when calculating the keystream, but
encryption in these modes simply happens by XORing with a keystream.
It's okay to have more keystream generated than you have plaintext...
there's never any reason to block-align
Note that the actual encryption part is just XOR, and therefore has no
real notion of blocks. CFB, CTR and OFB modes are simply KEYSTREAM
GENERATORS in the way that RC4 is a keystream generator. They just
happen to be a generic way of turning a block cipher into a
pseudo-random number generator.
Perhaps it would help to show you how things work differently in 0.9.6
and 0.9.7. Try this code out in each one:
#include
int main(int argc, char **argv) {
EVP_CIPHER_CTX c;
char key[128] = {0,};
char iv[128] = {0,};
char in[256]={0,};
char out[256];
int olen,i, o2;
#define CIPHER() EVP_bf_cfb()
#define HOWMANY 148
EVP_EncryptInit(&c, CIPHER(), (char *)key, iv);
EVP_EncryptUpdate(&c, out, &olen, in, HOWMANY);
EVP_EncryptFinal(&c, out+olen,&o2);
olen += o2;
printf("Olen = %d\n", olen);
for(i=0;i
printf("%02x ", (unsigned char)out[i]);
}
printf("\n");
}
This returns 148 in 0.9.6, and it returns 152 in 0.9.7 (b3 at least).
The same thing happens in OFB mode. What's going on is that PKCS
padding is getting added when it never was previously.
The new behavior is technically right for CFB mode with block-sized
feedback. However, with block sized-feedback, it's particularly easy
to totally skip the shift register, and just generate a block of
keystream at a time by holding on to the previous block of ciphertext
as it becomes available.
The new behavior is quite wrong for OFB mode. OFB mode should NOT pad
by default (go to the NIST modes document and you'll see ECB, CBC and
CFB listed as the modes that should have padding; OFB and CTR should
not).
John
Those modes *require* that a multiple of {block_size} bytes get
through to get properly encrypted/decrypted.
I'm thinking of implementing CFB-8 as well. That would give the
streaming properties that you seem to desire.
viega> Hmm, I just noticed this problem yesterday, as well. As a
temporary
viega> work-around, you can turn off padding with OFB mode, and
everything
viega> works as expected. I'm pretty sure I got an error related to
block
viega> alignment when I turned off padding in CFB mode.
viega>
viega> However, the CFB mode behavior is now technically CORRECT
whereas it
viega> never was in previous versions, at least according to things
like the
viega> NIST specification of the mode, because the shift register is
always
viega> supposed to fill up before doing an encryption (Appendix A of
the new
viega> modes document explicitly states that CFB needs to be padded,
viega> reinforcing this interpretation). Yes, there are protocols
that rely
viega> on the streaming version of CFB, though. OpenSSL should clearly
viega> support both, but it's not as clear to me what the default
should be
viega> for CFB. For OFB, the default is clear (and the current state
of
viega> affairs is clearly wrong :).
viega>
viega> John
viega>
viega> On Thu, Oct 17, 2002 at 11:44:47AM +0200, Olaf Kirch via RT
wrote:
viega> >
viega> > Hi all,
viega> >
viega> > yesterday I came across a bug in OpenSSL 0.9.7-beta3. When
getting
viega> > an EVP_CIPHER in OFB/CFB mode, it reports as its block size
the
viega> > block size of the underlying encryption algorithm, rather
than 1.
viega> > Needless to say, this makes any application fail that uses a
viega> > cipher in CFB/OFB stream mode.
viega> >
viega> > If this isn't a bug, it's at least a departure from the
behavior
viega> > of previous versions... :)
viega> >
viega> > Looking at evp_locl.h, there are two monster macros for
setting
viega> > up an EVP_CIPHER suite - the one that's commented out at the
viega> > moment seems to do the right thing.
viega> >
viega> > Cheers,
viega> > Olaf
viega> > --
viega> > Olaf Kirch | Anyone who has had to work with X.509 has
probably
viega> > [EMAIL PROTECTED] | experienced what can best be described as
viega> > ---+ IS
Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl 0.9.7-beta3
Yes, it does indeed seem to be fixed. Seeing that OFB and CFB are
pretty fundamental, shouldn't a fix like that merit a b4 release,
particularly considering how long it's been since b3? :)
John
On Thursday, October 17, 2002, at 05:34 PM, Richard Levitte - VMS
Whacker wrote:
In message <[EMAIL PROTECTED]>
on Thu, 17 Oct 2002 16:34:55 -0400, John Viega
<[EMAIL PROTECTED]> said:
viega> Perhaps it would help to show you how things work differently
in 0.9.6
viega> and 0.9.7. Try this code out in each one:
viega>
viega> #include
viega>
viega> int main(int argc, char **argv) {
viega>EVP_CIPHER_CTX c;
viega>char key[128] = {0,};
viega>char iv[128] = {0,};
viega>char in[256]={0,};
viega>char out[256];
viega>int olen,i, o2;
viega>
viega> #define CIPHER() EVP_bf_cfb()
viega> #define HOWMANY 148
viega>EVP_EncryptInit(&c, CIPHER(), (char *)key, iv);
viega>EVP_EncryptUpdate(&c, out, &olen, in, HOWMANY);
viega>EVP_EncryptFinal(&c, out+olen,&o2);
viega>olen += o2;
viega>printf("Olen = %d\n", olen);
viega>for(i=0;i
viega> printf("%02x ", (unsigned char)out[i]);
viega>}
viega>printf("\n");
viega> }
viega>
viega> This returns 148 in 0.9.6, and it returns 152 in 0.9.7 (b3 at
least).
viega> The same thing happens in OFB mode. What's going on is that
PKCS
viega> padding is getting added when it never was previously.
Ah, yeah, right, that's a bug in beta3. It has been fixed, however.
Please try the latest 0.9.7 snapshot, and you'll see the difference.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
PGP.sig
Description: PGP signature
Re: CTR mode
On Thursday, October 17, 2002, at 04:30 PM, Richard Levitte - VMS
Whacker wrote:
In message <[EMAIL PROTECTED]>
on Thu, 17 Oct 2002 16:19:23 -0400, John Viega
<[EMAIL PROTECTED]> said:
viega> > viega> Also, why isn't counter mode implemented in a generic
fashion?
viega> > It's
viega> > viega> so simple, it should be usable with any block cipher
without
viega> > having to
viega> > viega> write additional code.
viega> >
viega> > Ask yourself why OFB, CFB, CBC and ECB modes aren't
implemented
viega> > generically. A hint: speed. Someone made a test having a
generic CBC
viega> > that would take a pointer to the cipher function to use. The
speed
viega> > apparently decreased enough for it to be an issue.
viega>
viega> I mean have a generic implementation, not necessarily a generic
viega> interface. I was more thinking a counter mode macro that could
be used
viega> to create counter mode instances for all block ciphers quickly.
That's something I've thought of just a few days ago. I'll add that
to my TODO.
I did spend some time on this tonight. I essentially designed a
framework and built one test mode, OFB (I'll get to the rest of the
modes tomorrow). Two files are attached (mode.h and mode.c).
Basically, where you would normally use the following code:
EVP_CIPHER_CTX ctx;
EVP_EncryptInit_ex(&ctx, EVP_bf_ofb(), 0, key, iv);
EVP_EncryptUpdate(&ctx, out, &outlen, in, inlen);
EVP_EncryptFinal(&ctx, out, &outlen); /* Shouldn't be necessary unless
an engine needs to clean up */
You instead write the following, very similar (but slightly less
complex) code:
MODE_OFB_CTX ctx;
MODE_OFB_Init(&ctx, BASE_bf(), 0, key, iv);
MODE_OFB_Update(&ctx, out, in, inlen); /* No need for an outlen
parameter */
MODE_OFB_Final(&ctx); /* Shouldn't be necessary unless an engine needs
to clean up */
You can also pre-compute keystream instead of encrypting by calling
MODE_OFB_KeyStream(&ctx, out, outlen);
I do borrow EVP_EncryptInit and EVP_EncryptFinal for my implementation
(just didn't feel like following the code; it can be unwound), but the
actual update function should have exactly the same number of
indirections as the EVP interface. So if this is significantly slower,
it's probably due to my poor OFB code :-).
There are some other things that probably need to happen, like taking
engines into account. If engines are done at a lower level of
indirection, they *might* already work, but I doubt it (I suspect they
replace the EVP_CIPHER_CTX do_encrypt pointer, which I ignore to avoid
building ON TOP OF EVP).
I use macros to generate specific implementations of OFB mode for every
block cipher. When you call MODE_OFB_Update, a function pointer gets
dereferenced, calling the cipher-specific function. That way, if you
make one call to encrypt a few gigs of data, we only dereference a
function through a pointer a single time. The remainder of the time,
we're calling our cipher's ECB encryption mechanism directly.
I'm going to finish this code tomorrow, adding support for CBC, CFB,
CTR and CCM modes (CCM mode is CTR+CBC-MAC mode; it's in the draft
802.11i standard). If there's a desire to have it in OpenSSL, that's
no problem.
John
#ifndef MODE_H__
#define MODE_H__
#include
#include
#define GENERATE_MODE_FUNCS(THISMODE_NAME,THISMODE_BLOCK_LEN,THISMODE_ENCF,\
THISMODE_INIT) \
int MODE_##THISMODE_NAME##_OFB_KeyStream(EVP_CIPHER_CTX *ctx, \
unsigned char *out, int n) {\
unsigned char *lastbl, *newbl /*, finalbl[THISMODE_BLOCK_LEN]*/;\
int i, base, num = 0;\
if(ctx->num) {\
if(ctx->num > n) {\
num = n;\
} else {\
num = ctx->num;\
}\
base = THISMODE_BLOCK_LEN - ctx->num;\
for(i=0; iiv[base+i];\
}\
n -= num;\
if(!n) {\
ctx->num -= num;\
return 1; /* Success. */\
} else {\
ctx->num = 0;\
}\
}\
/* If we get here, we have no buffered keystream left. */\
lastbl = ctx->iv;\
newbl = out + num;\
\
/* Within the below loop, we can encrypt directly into the output. */\
for(i=0;icipher_data, 1);\
lastbl = newbl;\
newbl += THISMODE_BLOCK_LEN;\
}\
\
/* Go ahead and generate one more block of key stream, even if it's\
never used at all. What's one block? */\
/* lastbl can be ctx->iv, do we need to encr into a tmp buf then copy? */\
/* See above for proper error handling strategy when appropriate. */\
THISMODE_ENCF(lastbl, ctx->iv, ctx->cipher_data, 1);\
/* memcpy(ctx->iv, finalbl, THISMODE_BLOCK_LEN);*/\
num += n-(newbl-out);\
for(i=0;iiv[i];\
}\
ctx->num = THISMODE_BLOCK_LEN - num;\
return 1; /* Success. */\
}\
int MODE_##THISMODE_NAME##_OFB_Update(EVP_CIP
Re: CTR mode
On Mon, Oct 21, 2002 at 11:53:41AM -0500, Stephen Sprunk wrote: > My reading of Rogaway's CTR submission was a nonce in the top half of > the counter with a simple increment (by one) of the whole counter. Is > there a new spec we need to comply with? Look at NIST Special Publication 800-38A. The specification for CTR mode does not mandate any format for the counter or any particular function for incrementing the counter. It mentions both the technique of combining a nonce with a counter and using a counter that starts at any possible value (such as 0). The problem with using half of the counter block as a nonce only really shows up when using ciphers with 64-bit blocks. A 32-bit counter value doesn't allow for a large number of possible messages all things considered (e.g., gigabit+ pipes with long-term connections). Basically, I believe that CTR mode should be the low-level API. The user should set the IV as appropriate, and his own counter function if it should be something other than "add 1 to this block-sized big-endian value". Higher level functionality that the end-user isn't going to screw up is also very important to provide in an API, IMHO. That's why CCM mode in particular is something I feel very strongly about... not only does it require a nonce and specify the packet layout, it also performs integrity checking all with a single key. If people used a high-level CCM-based interface instead of a low-level CBC-based API, many of the most common crypto errors I see in software would become pretty scarce. > What is the correct behavior of CTR when it reaches 2^64 (or whatever > lower limit IPsec et al may set)? I'd assumed that it was safe to > wrap to zero and keep counting. Do you have a suggested > implementation for how to set a lower limit? No, if you go through 2^64 counters when you're only using 64 bits for a counter, then it is incorrect to perform any operations whatsoever. The IPSec AES-CTR doc, IIRC specifies that you should error. I think in practice, 2^64 is a number people may not reach in practice. I think having an option to specify whether you want to skip the extra check is a good idea. BTW, I already provided Russ Housley with a second reference implementation of the CTR stuff for IPSec, so I definitely have working test vectors, etc. > The modes should probably be written as macros, yes. Unfortunately, > some cipher implementations don't call an ECB function but actually > implement the cipher inside the mode; switching to mode macros will be > very tricky. It's not actually very difficult. I've actually finished a first pass that works very well. I've implemented CBC, CFB, OFB, CTR and CCM, all on top of the API that the EVP ECB calls ultimately call. Along the way, I've also added a CBC-MAC implementation (particularly due to its use in CCM mode), and I'll probably implement RMAC as well. Basically, I'm writing an alternative to the EVP block cipher API. It is shaping up to be more powerful for the end user, including more high-level and even some new low-level things that aren't in the EVP interface. It will clearly be more extensible since you'll only have to add a single macro call to support every single mode for a new block cipher. Due to real life time constraints, I probably need a full week to polish everything up and to produce a comprehensive set of tests to help minimize the number of bugs. Currently I'm relying on EVP context objects and piggybacking off the EncryptInit call. I'm going to undo all of that, and I might take the time to properly hook this stuff up to the engine work. I'll definitely contribute the code when I'm about to move on to other things, though. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl 0.9.7-beta3
Hmm, I just noticed this problem yesterday, as well. As a temporary work-around, you can turn off padding with OFB mode, and everything works as expected. I'm pretty sure I got an error related to block alignment when I turned off padding in CFB mode. However, the CFB mode behavior is now technically CORRECT whereas it never was in previous versions, at least according to things like the NIST specification of the mode, because the shift register is always supposed to fill up before doing an encryption (Appendix A of the new modes document explicitly states that CFB needs to be padded, reinforcing this interpretation). Yes, there are protocols that rely on the streaming version of CFB, though. OpenSSL should clearly support both, but it's not as clear to me what the default should be for CFB. For OFB, the default is clear (and the current state of affairs is clearly wrong :). John On Thu, Oct 17, 2002 at 11:44:47AM +0200, Olaf Kirch via RT wrote: > > Hi all, > > yesterday I came across a bug in OpenSSL 0.9.7-beta3. When getting > an EVP_CIPHER in OFB/CFB mode, it reports as its block size the > block size of the underlying encryption algorithm, rather than 1. > Needless to say, this makes any application fail that uses a > cipher in CFB/OFB stream mode. > > If this isn't a bug, it's at least a departure from the behavior > of previous versions... :) > > Looking at evp_locl.h, there are two monster macros for setting > up an EVP_CIPHER suite - the one that's commented out at the > moment seems to do the right thing. > > Cheers, > Olaf > -- > Olaf Kirch | Anyone who has had to work with X.509 has probably > [EMAIL PROTECTED] | experienced what can best be described as > ---+ ISO water torture. -- Peter Gutmann > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
CTR mode
It should be possible to replace the counter increment function. The new NIST modes doc doesn't specify a mandatory increment function, but it does recommend one that's different from "add one every time". Additionally, a lot of stuff built on counter mode is using a few bits of the counter for other purposes, so the effective counter size is less than the actual counter size. It would be nice to be able to add some sort of parameter that specifies the actual counter size, to prevent counter mode from continuing to encrypt when it's run out of counters. Also, why isn't counter mode implemented in a generic fashion? It's so simple, it should be usable with any block cipher without having to write additional code. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
duplicate execution of callback with non-blocking SSL_accept
When a non-blocking SSL_accept() returns -1 with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE set, the appropriate thing to do is to call SSL_accept() again. This is fine, but the current state machine in ssl3_accept() doesn't seem to keep track of the fact that the callback may have succeeded already, causing the callback to be called again when SSL_accept() is retried. Is there some way around this that I'm missing? If not, wouldn't it be desirable to add something like this to the state machine in ssl3_accept()? I'm sure there are some cases where the callback should be called again (renegotiations, for example). Any ideas? -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #434] duplicate execution of callback with non-blockingSSL_accept
Lutz Jaenicke via RT wrote: [[EMAIL PROTECTED] - Fri Jan 3 08:21:38 2003]: When a non-blocking SSL_accept() returns -1 with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE set, the appropriate thing to do is to call SSL_accept() again. This is fine, but the current state machine in ssl3_accept() doesn't seem to keep track of the fact that the callback may have succeeded already, causing the callback to be called again when SSL_accept() is retried. Is there some way around this that I'm missing? If not, wouldn't it be desirable to add something like this to the state machine in ssl3_accept()? I'm sure there are some cases where the callback should be called again (renegotiations, for example). Any ideas? You are talking of the verify callback? Yes, the client verify_callback. Thanks, -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ocsp.c make_ocsp_response() fix
The handling of the thisupd and nextupd pointers in make_ocsp_response() is incorrect. The pointers should be the first parameter of x509_gmtime_adj(), rather than the return value. I've attached a patch that fixes this. -John --- ../../../orig/openssl-0.9.7/apps/ocsp.c 2002-12-03 08:34:23.0 -0800 +++ ocsp.c 2003-01-29 19:23:46.0 -0800 @@ -1043,9 +1043,11 @@ ca_id = OCSP_cert_to_id(EVP_sha1(), NULL, ca); bs = OCSP_BASICRESP_new(); - thisupd = X509_gmtime_adj(NULL, 0); + thisupd = ASN1_GENERALIZEDTIME_new(); + nextupd = ASN1_GENERALIZEDTIME_new(); + X509_gmtime_adj(thisupd, 0); if (ndays != -1) - nextupd = X509_gmtime_adj(NULL, nmin * 60 + ndays * 3600 * 24 ); + X509_gmtime_adj(nextupd, nmin * 60 + ndays * 3600 * 24 ); /* Examine each certificate id in the request */ for (i = 0; i < id_count; i++)
Re: [openssl.org #486] ocsp.c make_ocsp_response() fix
Stephen Henson via RT wrote: However a bug was introduced into 0.9.7 ASN1_TIME_to_generalizedtime() which causes problems in this conversion. This change would work around the problem without addressing the underlying cause. Since the ASN1_TIME_to_generalizedtime() bug has now been fixed in 0.9.7-stable I suggest the OP checks the latest stable snapshot. Steve. Thanks for pointing this out. Indeed, patching in the asn1 changes from the latest snapshot fixes the problems I was seeing. And sorry, I should have pointed out from the beginning that it was 0.9.7 release that I was using. Thanks! -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz
Compiles and tests fine on BSD/OS 4.1 (bsdi-elf-gcc) Bodo Moeller wrote: Please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz (or later), which will be available today around 8 p.m. GMT at ftp://ftp.openssl.org/snapshot;type=d >. We plan to release version 0.9.7a soon (next week if all goes well). OpenSSL 0.9.7a will be a bugfix release based on 0.9.7; thus there will be no beta releases. The snapshot should solve most problems that have been reported to [EMAIL PROTECTED]; please test it to help us avoid unforeseen problems with the new release. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl-dev] DRBG entropy
On 07/27/2016 05:13 AM, Leon Brits wrote: > > I have a chip (FDK RPG100) that generates randomness, but the > SP800-90B python test suite indicated that the chip only provides > 2.35 bits/byte of entropy. According to FIPS test lab the lowest > value from all the tests are used as the entropy and 2 is too low. I > must however make use of this chip. That's a problem on several levels. For starters, keep in mind the following maxim: Testing can certainty show the absence of entropy. Testing can never show the presence of entropy. That is to say, you have ascertained that 2.35 bits/byte is an /upper bound/ on the entropy density coming from the chip. If you care about security, you need a lower bound. Despite what FIPS might lead you to believe, you cannot obtain this from testing. The only way to obtain it is by understanding how the chip works. This might require a trmendous amount of effort and expertise. Secondly, entropy is probably not even the correct concept. For any given probability distribution P, i.e. for any given ensemble, there are many measurable properties (i.e. functionals) you might look at. Entropy is just one of them. It measures a certain /average/ property. For cryptologic security, depending on your threat model, it is quite possible that you ought to be looking at something else. It may help to look at this in terms of the Rényi functionals: H_0[P] = multiplicity = Hartley functional H_1[P] = plain old entropy = Boltzmann functional H_∞[P] = adamance The entropy H_1 may be appropriate if the attacker needs to break all messages, or a "typical" subset of messages. The adamance H_∞ may be more appropriate if there are many messages and the attacker can win by breaking any one of them. To say the same thing in other words: -- A small multiplicity (H_0) guarantees the problem is easy for the attacker. -- A large adamance (H_∞) guarantees the problem is hard for the attacker. Now let us fast-forward and suppose, hypothetically, that you have obtained a lower bound on what the chip produces. One way to proceed is to use a hash function. For clarity, let's pick SHA-256. Obtain from the chip not just 256 bits of adamance, but 24 bits more than that, namely 280 bits. This arrives in the form of a string of bytes, possibly hundreds of bytes. Run this through the hash function. The output word is 32 bytes i.e. 256 bits of high-quality randomness. The key properties are: a) There will be 255.99 bits of randomness per word, guaranteed with high probability, more than high enough for all practical purposes. b) It will be computationally infeasible to locate or exploit the missing 0.01 bit. Note that it is not possible to obtain the full 256 bits of randomness in a 256-bit word. Downstream applications must be designed so that 255.99 is good enough. As with all of crypto, this requires attention to detail. You need to protect the hash inputs, outputs, and all intermediate calculations. For example, you don't want such things to get swapped out. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Load secrets to context.
Hi, Can we use both the following APIs in the same application to load certificate to the SSL context? *SSL_CTX_use_certificate_file()* *SSL_CTX_use_certificate_chain_file()* If we can how to use them? Thanks in advance. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DRBG entropy
Let's play a guessing game. I provide a hardware-based random number generator of my choosing. It produces a stream of bytes. It has an entropy density greater than 2.35 bits per byte. This claim is consistent with all the usual tests, but it is also more than that; it is not just "apparent" entropy or an upper bound based on testing, but real honest-to-goodness Boltzmann entropy. The bytes are IID (independent and identically distributed). The design and implementation are open to inspection. On each move in this game, I try to predict the exact value of the next byte. Every time I succeed, you pay me a dollar; every time I fail, I pay you a dollar. We play at least 100 moves, to minimize stray fluctuations. The point is, if you think entropy is a good measure of resistance to guessing, then you should be eager to play this game, expecting a huge profit. Would anybody like to play? On 07/28/2016 12:40 AM, Leon Brits wrote: > Thanks for the helping me understand the whole entropy thing better. > It is still get the feeling that this is a "best effort" thing and > that nobody can actually proof what is correct. I am probably just > bringing the math down to my level - sorry. > > With that said for validation I still need to be sure that I give the > required entropy back from the OpenSSL callback. Now since I am not > allowed to use a hash with the DRBGs (FIPS lab and SP800-90B section > 8.4), can you please confirm that, with a source of raw 2b/B entropy > data, I need to return 4 times the data from the callback function? That depends on what the objective is. The objective is not obvious, as discussed below. > According to FIPS test lab the lowest value from all the tests are > used as the entropy and 2 is too low. 1a) I assume the idea that "2 is too low" comes from the FIPS lab. 1b) I assume the designer's boss doesn't directly care about this, so long as the FIPS lab is happy. 1c) This requirement has little if any connection to actual security. > I must however make use of this chip. 2a) I assume the FIPS lab doesn't care exactly which chip is used. 2b) I assume this requirement comes from the boss. 2c) This requirement has little if any connection to actual security. > I am not allowed to use a hash with the DRBGs (FIPS lab and > SP800-90B section 8.4), Where's That From? Section 8.4 says nothing about hashes. It's about health testing. The hash doesn't interfere with health testing, unless the implementation is badly screwed up. Furthermore, in sections 8.2 and 8.3, and elsewhere, there is explicit consideration of "conditioning", which is what we're talking about. 3a) Does this requirement really come from the FIPS lab? It certainly doesn't come from SP800-90B as claimed. 3c) This requirement has nothing to do with actual security. > It is still get the feeling that this is a "best effort" thing and > that nobody can actually proof what is correct. Where's That From? Proofs are available, based on fundamental physics and math, delineating what's possible and what's not. > can you please confirm that, with a source of raw 2b/B entropy data, > I need to return 4 times the data from the callback function? Two answers: -- My friend Dilbert says you should do that, in order to make the pointy-haired boss happy. -- You should not, however, imagine that it provides actual security. > I have a chip (FDK RPG100) that generates randomness, but the > SP800-90B python test suite indicated that the chip only provides > 2.35 bits/byte of entropy That means the chip design is broken in ways that the manufacturer does not understand. The mfgr data indicates it "should" be much better than that: http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf The mfgr has not analyzed the thing properly, and nobody else will be able to analyze it at all. The block diagram in the datasheet is a joke: http://www.fdk.com/cyber-e/pdf/HM-RAE106.pdf#Page=9 > I must however make use of this chip. My friend suggests you XOR the chip output with a decent, well- understood HRNG. That way you can tell the pointy-haired boss that you "make use of this chip". Bottom line: consider the contrast: -- I'm seeing a bunch of feelings and made-up requirements. -- I have not yet seen any sign of concern for actual security. Under such conditions it is not possible to give meaningful advice on how to proceed. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DRBG entropy
In the context of: >> I have a chip (FDK RPG100) that generates randomness, but the >> SP800-90B python test suite indicated that the chip only provides >> 2.35 bits/byte of entropy On 07/28/2016 09:08 AM, I wrote: > That means the chip design is broken in ways that the manufacturer > does not understand. The mfgr data indicates it "should" be much > better than that: > http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf To be scientific, we must consider all the relevant hypotheses. 1) For starters, let's consider the possibility that the python test suite is broken. Apply the test suite to a sufficiently random stream. -- An encrypted counter should be good enough. -- /dev/urandom is not a paragon of virtue, but it should be good enough for this limited purpose. 1a) If the test suite reports a low randomness for the truly random stream, then the test is broken. Find a better test suite and start over from Square One. 1b) If the test suite reports a high randomness for the random stream but a low randomness for the chip, the chip is broken and cannot be trusted for any serious purpose. -- You could derate it by another factor of 10 (down to 0.2 bits per byte) and I still wouldn't trust it. A stopped clock tells the correct time twice a day, but even so, you should not use it for seeding your PRNG. -- It must be emphasized yet again that for security you need a lower bound on the randomness of the source. Testing cannot provide this. A good test provides an upper bound. A bad test tells you nothing. In any case, testing does not provide what you need. Insofar as the chip passes some tests but not others, that should be sufficient to prove and illustrate the point. Seriously, if the FIPS lab accepts the broken chip for any purpose, with or without software postprocesing, then you have *two* problems: A chip that cannot be trusted and a lab that cannot be trusted. 2a) We must consider the possibility that the bare chip hardware is OK, but there is a board-level fault, e.g. wrong voltage, wrong readout timing, or whatever. 2b) Similarly there is the possibility that the bare chip hardware is OK but the data is being mishandled by the system-level driver software. This should be relatively easy to fix. === It must be emphasized yet again the entropy (p log 1/p) is probably not the thing you care about anyway. If the entropy density is high (nearly 8 bits per byte) *and* you understand why it is not higher, you may be able to calculate something you can trust ... but let's not get ahead of ourselves. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DRBG entropy
On 08/01/2016 02:17 AM, Leon Brits wrote: > Am I correct to state that for a tested entropy source of 2b/B and > the same assumptions as in the paragraph, I need to return 8 blocks > of 16B each in my get_entropy() callback? No, that is not correct, for the reasons previously explained. > Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and > nothing in the next 7). That assumption is invalid, if we believe the LRS test. Quoting from LRS.py: >> # Length of the Longest Repeated Substring Test - Section 5.2.5 >> # This test checks the IID assumption using the length of the longest >> repeated >> # substring. If this length is significantly longer than the expected value, >> # then the test invalidates the IID assumption. Accumulating 8 or more blocks might make sense if the data were IID, but it isn't. Either that or the LRS test itself is broken, which is a possibility that cannot be ruled out. By way of analogy, note that the p(max) reported by the Markov test is clearly impossible and inconsistent with the reported min-entropy. Suggestion: Modify LRS.py to print (in hex) the longest repeated substring. Then verify by hand that the string really does recur in the data. -- If it doesn't, then the test is broken. -- If it does, then either the chip is broken or you're using it wrong. Remind your boss that the whole point of the certification process is to make sure that broken hardware doesn't get certified. Also: *) Please stop using "entropy" as a synonym for randomness. Some things have very little entropy but are still random enough for a wide range of purposes. Meanwhile other things have large entropy but are not random enough. *) Please stop using "entropy" as a synonym for "min-entropy". The latter is a two-word idiomatic expression. A titmouse is not a mouse. Buckwheat is not a form of wheat. The Holy Roman Empire was neither holy, nor Roman, nor an empire. Just because openssl is sloppy about this doesn't make it OK. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OpenSSL_1_0_2-stable Windows build
Is anyone seeing the following error when building 1.0.2 stable on Windows: Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp IF EXIST out32dll\sslv2conftest.exe.manifest mt -nologo -manifest out32dll\sslv2conftest.exe.manifest -outputresource:out32dll\sslv2conftest.exe;1 cl /Fotmp32dll\dtlstest.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -IC:\Users\testuser\workspace\CiscoSSL\ciscossl-platform-tests-win32\fips/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_BASE_EC -DOPENSSL_NO_BASE_ECDSA -DOPENSSL_NO_BASE_ECDH -DOPENSSL_NO_GOST -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c .\ssl\dtlstest.c dtlstest.c link /nologo /subsystem:console /opt:ref /debug /out:out32dll\dtlstest.exe @C:\Users\testuser\AppData\Local\Temp\nm6DBA.tmp Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_objects referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_connection referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _mempacket_test_inject referenced in function _test_dtls_unprocessed out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460' Stop. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] status of libefence (electric fence)
On 10/21/2016 04:14 PM, Salz, Rich asked: > Is electric fence even available any more? It's bundled with current Debian and Ubuntu. >From the README: "This version should run on all systems that support POSIX mmap() and mprotect(). This includes Linux, Unix, and I think even BeOS." -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] github raw .patch ... also: still seeing heartbeat prolem in openssl 1.0.2 STABLE Daily releases
On 11/02/2016 09:50 AM, The Doctor wrote: > I usually use lynx and cannot see where to pull this. AFAICT here is the relevant patch, in a raw form suitable for direct download: https://github.com/openssl/openssl/commit/554ae58d09a9b09fa430553c3e6ba5bb5433150c.patch In general, the procedure goes like this: Given the URL of the PR, go there. For example, https://github.com/openssl/openssl/pull/1826 Click on the "Commits" tag In the list of commits, click on the SHA1 of the commit. (That is *not* the same as clicking on the name of the commit.) Example result: https://github.com/openssl/openssl/commits/554ae58d09a9b09fa430553c3e6ba5bb5433150c Munge the URL by changing /commits/ to /commit/ singular, and by adding .patch to the end. Truly an astonishing user interface. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Revert commit 10621ef white space nightmare
On 01/09/2017 10:46 AM, Leonard den Ottolander wrote: > I don't remember ever seeing directives being indented by adding > white space between the hash sign and the directive. In my world, that is quite common. > If one wants to indent directives space is normally inserted before > the hash sign. No, that is not normal. It is not even permitted by traditional versions of the preprocessor. I quote from https://gcc.gnu.org/onlinedocs/gcc-3.1/cpp/Traditional-Mode.html >> Preprocessing directives are recognized in traditional C only when >> their leading # appears in the first column. There can be no >> whitespace between the beginning of the line and the #. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Problem with Commit 3fd181a8b5b85a1f7383e82438da494a08f7d843, Remove an option related to a deprecated flag.
This commit removes the cms and smime "-nooldmime" option on the grounds
that the flags they use "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE"
are not used in the pkcs7/cms code.
But those flags *are* used.
In include/openssl/pkcs7.h we have:
# define PKCS7_NOOLDMIMETYPE 0x400
And in include/openssl/cms.h:
# define CMS_NOOLDMIMETYPE 0x400
And include/openssl/smime.h
# define SMIME_OLDMIME 0x400
And, in crypto/pkcs7/pk7mime.c:
int SMIME_write_PKCS7(BIO *bio, PKCS7 *p7, BIO *data, int flags)
{
...
flags ^= SMIME_OLDMIME;
return SMIME_write_ASN1(bio, (ASN1_VALUE *)p7, data, flags,
ctype_nid, NID_undef, mdalgs,
ASN1_ITEM_rptr(PKCS7));
And, finally in crypto/asn1/asn_mime.c:
int SMIME_write_ASN1(BIO *bio, ASN1_VALUE *val, BIO *data, int flags,
int ctype_nid, int econt_nid,
STACK_OF(X509_ALGOR) *mdalgs, const ASN1_ITEM *it)
{
...
if (flags & SMIME_OLDMIME)
mime_prefix = "application/x-pkcs7-";
else
mime_prefix = "application/pkcs7-";
That is to say the effect of setting the flag CMS_NOOLDMIMETYPE or
PKCS7_NOOLDMIMETYPE is to *unset* the flag SMIME_OLDMIME in calls to
SMIME_write_ASN1, and so tell SMIME_write_ASN1 to write new-style mime
headers "application/pkcs7-" instead of the horrid old
"application/x-pkcs7-".
TL; DR -- the flags "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE" *are*
used, and shouldn't be deprecated.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OSCP.
Could anyone point me to some OSCP samples? Needed to check whether CA certificate is still active. Thanks. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Streaming PKCS#7 decryption
I have an application which needs to do encryption and decryption of files which may not fit in main memory. I'm using the PKCS#7 enveloped-data format, and have implemented the encryption side of things using Steve Henson's work as a reference: <http://cvs.openssl.org/chngview?cn=15749> Don't worry Steve, I'm not actually using 0.9.9, I just used it as a reference for my own implementation. (Basically, I implemented the smallest subset of indefinite length encoding necessary for PKCS#7 enveloped-data.) Now it's time to implement streaming decryption. I've got it working via d2i_PKCS7() and PKCS7_decrypt(), but of course that requires the entire encoded data be in memory. As far as I can see, there's no support in either 0.9.8 or 0.9.9 for streaming decryption, so I'm without a reference this time. I think the right approach is to build up my own PKCS7 structure by using ASN1_d2i_bio() on the individual parts, and then use PKCS7_dataDecode(), passing my own read BIO. Does that sound right? Thanks, John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Streaming PKCS#7 decryption
Thanks to all who replied. I ended up implementing my own ASN1 encoding/decoding layer, just the bare minimum for the subset of PKCS7 that I needed. I piggybacked on OpenSSL for some of it, but didn't use any other third party libraries. If anyone else should need to go this route, this was a useful resource for me: http://luca.ntop.org/Teaching/Appunti/asn1.html John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
PRNG initialization fails when re-entering FIPS mode
Is it intended that it is not possible to re-enter FIPS mode via FIPS_mode_set(1) after previouly calling FIPS_mode_set(1) then FIPS_mode_set(0)? If you do so, the RAND_bytes() call at fips.c line 307 fails. It seem the sequence of events is this: 1. FIPS_mode_set(1), RAND_set_rand_method(FIPS_rand_method()) called. 2. FIPS_mode_set(0), FIPS mode disabled but rand_method not reset to non-FIPS method. 3. FIPS_mode_set(1), RAND_bytes() fails because it attempts to use fips_rand with an unkeyed context. This is with openssl-fips-test-1.2.0. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
asm vs. no-asm: performance test results, and security concern
An employee at my company recently ran some performance tests of RSA decryption comparing Windows OpenSSL libraries (openssl-fips-test-1.2.0) compiled without assembly optimizations versus those compiled with nasm assembled optimizations. We were somewhat surprised at how effective the assembly optimizations appeared to be. Our test consisted of repeated RSA decryption of a 2k document. We tested several key lengths: 1024 2048 4096 - - - no-asm 30148916 asm 13 46283 Those numbers are CPU time; only interesting relative to each other. Is a 2-4x speedup for RSA decryption consistent with what others have seen? We are trying to evaluate whether to go forward with assembly optimized versions of the library. Obviously, if there was no downside, we'd choose the optimized version. But on Windows, there is a significant disadvantage: the assembly optimizations preclude building the library with the /SafeSEH linker option, an important security countermeasure. And linking with a non-SafeSEH library means the feature is disabled for the entire executable. This is a significant cost to be weighed by anyone trying to follow Microsoft's recommendations for writing secure software. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: asm vs. no-asm: performance test results, and security concern
> First reaction is "how come?" Indeed, safe exception handling > is pretty > much about registering handlers in a special read-only > segment, and if a > module [such as any given OpenSSL assembler module] does not setup any > exception handlers, then how come can it prevent linking? But it's > apparently a fact... So I wondered what does it take to make linker > accept an .obj module without above mentioned segment for /safeseh > processing? As it turns out presence of absolute symbol named @feat.00 > with value of 1. In other words, if one can make nasm emit such symbol > into module's symbol table, then it's apparently possible to link this > module with /safeseh. As matter of experiment[!] open > crypto/perlasm/x86nasm.pl, locate ::file subroutine and > prepend 'section > .text code align=64' as following: > > absolute 1 > @feat.00: > section .text code align=64 > > and recompile... > > One can argue whether or not it's appropriate to hard-code such symbol > into nasm, so that all modules come out seh-"capable." But > it's probably > would be as appropriate to provide support for handler registration, > e.g. through safeseh or similar assembler directive... A. Thanks, this seems very promising. Did you figure this out by reverse engineering or did you find some documentation? Rolling this into the default build on Windows (along with the /SafeSEH, /NXCOMPAT, and /DYNAMICBASE flags) would probably be a good idea. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: asm vs. no-asm: performance test results, and security concern
> > Rolling this into the default build on Windows (along with > the /SafeSEH, > > /NXCOMPAT, and /DYNAMICBASE flags) would probably be a good idea. > > You mentioned *fips*. /dynamicbase won't work in that context. A. True, it conflicts with the in-core fingerprint mechanism. We're actually doing a "private label" FIPS binary certification with file-based fingerprints, in part because of that conflict. We lose the flexibility of a source-code level certification, but preserve the ability to use /dynamicbase. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
valgrind and openssl
In the wake of the issues with Debian, is it possible to modify the source so that it is possible to use valgrind with openssl without reducing the key space? Are we really relying on uninitialized memory for randomness? -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
> It is already possible to use openssl and valgrind - just build OpenSSL > with -DPURIFY, and it is quite clean. > > (we do it all the time here with WvStreams and Pathfinder, and it works like a > charm). The problem is that this may reduce the keyspace so that keys are guessable. http://blog.isotoma.com/2008/05/debians_openssl_disaster.html -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
> All of this is independent of proper entropy seeding to the PRNG, which is > what the debian patch crushed and which in turn led to the high seismic > reading in the blogosphere. But it may help explain why I do *not* want us to > unilaterally remove the use of uninitialised data in the PRNG. That seems to > be motivated by a capitulation to the weight of users (or packagers) who > don't know how to read the FAQ. Perhaps what we should do instead is I think we should be less worried how things "seem" and more worried about the practical consequences. > change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer > intention, so that debug packages (or even base packages that want to be > valgrind-friendly) have a straightforward mechanism to apply. Well, a > straightforward mechanism that doesn't kill the PRNG outright, I mean > (otherwise there is already a highly-publicised patch we could apply...) What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. Can someone provide a pointer to this highly-publicized patch? I'm afraid I'm dreadfully ignorant of the blogosphere. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
>> > It is already possible to use openssl and valgrind - just build OpenSSL >> > with -DPURIFY, and it is quite clean. Actually on my system, just -DPURIFY doesn't satisfy valgrind. What I'm asking for is something that both satisfies valgrind and doesn't reduce the keyspace. >> > (we do it all the time here with WvStreams and Pathfinder, and it works >> > like a charm). >> >> The problem is that this may reduce the keyspace so that keys are >> guessable. > > No it won't, it removes an "entropy source" whose quality is known to be > unknown, ie. it may add nothing useful, it gets used "just in case". Removing > it does not "reduce the keypsace" at all. All you can say is that leaving it > there *may* improve the PRNG depending on the user, the environment, the > application, and quite probably, the alignment of the planets... > > The debian patch went further than -DPURIFY, as it removed more than just > this "unreliable" source, it removed all use of reliable sources as well. > >> http://blog.isotoma.com/2008/05/debians_openssl_disaster.html > > This blog does not suggest that building with -DPURIFY would a problem and nor > should it. I think you may have misunderstood the details of this issue. I am clearly misunderstanding something. You seem to be saying that -DPURIFY satisfies valgrind but doesn't reduce the keyspace. I'm prepared to take it on faith that -DPURIFY doesn't reduce the keyspace. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 12:29 PM, Geoff Thorpe <[EMAIL PROTECTED]> wrote: > I forgot to mention something; > >> On Thursday 15 May 2008 12:38:24 John Parker wrote: >> > >> > It is already possible to use openssl and valgrind - just build >> > >> > OpenSSL with -DPURIFY, and it is quite clean. >> > >> > Actually on my system, just -DPURIFY doesn't satisfy valgrind. What >> > I'm asking for is something that both satisfies valgrind and doesn't >> > reduce the keyspace. >> >> If you're using an up-to-date version of openssl when you see this (ie. a >> recent CVS snapshot from our website, even if it's from a stable branch for >> compatibility reasons), then please post details. -DPURIFY exists to >> facilitate debuggers that don't like reading uninitialised data, so if >> that's not the case then please provide details. Note however that there >> are a variety of gotchas that allow you to create little leaks if you're >> not careful, and valgrind could well be complaining about those instead. > > Note that you should always build with "no-asm" if you're doing this kind of > debug analysis. The assembly optimisations are likely to operate at > granularities and in ways that valgrind could easily complain about. I don't > know that this is the case, but it would certainly make sense to compare > before posting a bug report. I'm still seeing a lot of errors from valgrind, even with the latest snapshot. 19 15:12 tar xvfz ../openssl-0.9.8-stable-SNAP-20080515.tar.gz 20 15:12 cd openssl-0.9.8-stable-SNAP-20080515/ 21 15:12 ls 22 15:12 ./config no-asm -DPURIFY 23 15:12 make 24 15:14 valgrind ./apps/openssl genrsa 1024 Please let me know if I'm doing something wrong with this test sequence. The problems occur on Red Hat 5.1 server x86_64. For what it's worth, I don't get errors on (updated :) Ubuntu 7.10. I do get errors even with Bodo's addition to randfile.c. I'd be happy to post the valgrind output if that would be helpful. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 4:41 PM, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Goetz Babin-Ebell wrote: > >> But here the use of this uninitialized data is intentional >> and the programmer are very well aware of what they did. > > The use of unititialized data in this case is stupid because the > entropy of this random data is close to zero. > > The only sane way to deal with this it to either make it zero > or make it truely random. > > Erik I disagree. If there's a performance cost to making openssl happy with valgrind, I'd rather have there be an option that defaults to optimize security and performance at the expense of debugging capability. Debugging is the infrequent case. Although I disagree, I understand your argument. However, you weaken your position by using the words "stupid" and "sane;" they make you seem disrespectful. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
Would a runtime flag for "don't seed with uninitialized memory", rather than (or in addition to) -DPURIFY, satisfy everybody? John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
> Everybody? > > It seems to me that only one or two people who don't really > understand what's going on are complaining. Wanting to get accurate runtime analysis results with a release build is not an unreasonable request. > OpenSSL should stay as it is. A contributed valgrind > suppressions file would be useful. It certainly would, but Valgrind isn't the only analysis tool people might want to use. A runtime flag provides a means of obtaining accurate results with any tool. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
>> The problems occur on Red Hat 5.1 server x86_64. For what it's worth, >> I don't get errors on (updated :) Ubuntu 7.10. >> >> I do get errors even with Bodo's addition to randfile.c. I'd be happy >> to post the valgrind output if that would be helpful. > > If this is environment/OS-specific, then it's probably indicative of a libc > (or valgrind, or gcc) issue with the fixed-in-the-past versions of those > packages on RH5.1-64bit. If compiling and running the same openssl source on > a different system doesn't give you problems, that would seem to imply that > the problem appears and disappears based on elements that vary rather than > elements that are invariant. :-) It's environment dependent. I'm not able to reproduce the valgrind errors even on other 64 bit RH5.1 machines. As far as I'm concerned, openssl valgrinds clean with ./config no-asm -DPURIFY: my goals are achieved. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Mon, May 19, 2008 at 10:48 PM, dean gaudet <[EMAIL PROTECTED]> wrote: > > > On Thu, 15 May 2008, Bodo Moeller wrote: > >> On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo >> <[EMAIL PROTECTED]> wrote: >> > Goetz Babin-Ebell wrote: >> >> >> But here the use of this uninitialized data is intentional >> >> and the programmer are very well aware of what they did. >> >> > The use of unititialized data in this case is stupid because the >> > entropy of this random data is close to zero. >> >> It may be zero, but it may be more, depending on what happened earlier >> in the program if the same memory locations have been in use before. >> This may very well include data that would be unpredictable to >> adversaries -- i.e., entropy; that's the point here. > > on the other hand it may be a known plaintext attack. OK, so I'll seed my random number generator with a bunch of bits you don't know, then you give me however much known plaintext you want, and I'll update the state with that too. Then, I'll start generating random numbers. If you can guess them, you win! Right? Essentially what you're claiming is that you can predict the output of SHA-1 when you know part of the input, but not all of the input. Please explain how! -JP > what are you guys smoking? > > -dean > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
BIO_pending/BIO_eof not reliable for cipher BIO?
I'm traced a problem in an application to what seems to be a bug in the implementation of BIO_pending and/or BIO_eof for the cipher BIO (bio_enc.c) in decryption mode. If I understand this code correctly (and I'm not absolutely certain that I do), the cipher BIO can reach a state where it has exhausted the "next BIO" from which it is reading and produced the final full decrypted block from its internal buffer (leaving it empty), but a partial block remains to be decrypted in the cipher context. This is the state where the next call to BIO_read will result in EVP_CipherFinal_ex being called. In this state BIO_pending returns 0 and BIO_eof returns 1. It seems to me that at least one of these results, if not both, are incorrect, because at this point a call to BIO_read will in fact succeed and produce the last decrypted bytes. I guess the traditional thing to do is ignore the eof and pending APIs and just see if BIO_read can read anything. But my application relies on being able to detect EOF without needing to attempt a read. Is there another solution? Thanks, John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
FIPS mode and SSE2
When compiled with SSE2 optimizations (OPENSSL_IA32_SSE2), FIPS_mode_set fails on x86 CPUs without SSE or SSE2 support due to an explict check of bits 25 and 26 of OPENSSL_ia32cap. Is there a particular reason for this? I thought that all SSE2 optimizations were conditional on a runtime CPUID check via OPENSSL_ia32cap, so should work fine with or without SSE/SSE2 support. Why fail FIPS mode unconditionally? Thanks, John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Compile warning using additonal CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W'
Hi, Ive just downloaded and compiled openssl-0.9.8h, but when I add the CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W' I get the following warnings that may need the attention of an developer : - unused parameter 'foo' - cast discards qualifiers from pointer target type - comparison between signed and unsigned Regards, John Smith. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
s_client -starttls feature request (will pay)
Hi, Currently the s_client command supports starttls for smtp, ftp etc. We're wanting to do the same for ldap, something like: openssl s_client -connect 1.2.3.4:389 -starttls ldap We're willing to pay (around 200 USD) to have this feature added. Anyone interested? Thanks, John. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: s_client -starttls feature request (will pay)
Howard, I appreciate that currently the s_client code is plain-text, this would have to change to support ASN.1. As you indicate "working" ldap once starttls done is hard/insane, but as with all protocols that's the user's problem. Actually we are primarily interested in seeing the certificate, rather than doing anything useful with the connection. I'll see if anyone's interested. John. 2009/6/3 Howard Chu : > John Carter wrote: >> >> Hi, >> >> Currently the s_client command supports starttls for smtp, ftp etc. >> We're wanting to do the same for ldap, something like: >> >> openssl s_client -connect 1.2.3.4:389 -starttls ldap >> >> We're willing to pay (around 200 USD) to have this feature added. >> >> Anyone interested? > > Just what do you expect s_client to be able to do once it's gotten this far? > The s_client code only speaks plaintext; LDAP is ASN.1. You're not going to > be able to type anything intelligible into s_client once it's done. > > And aside from that, the OpenLDAP libraries and tools already support > StartTLS... > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: s_client -starttls feature request (will pay)
Thanks Howard, but the problem we found with that was that the cert is dumped in what looks like DER format mixed in with lots of other binary data. However we also go nothing beyond doing -d 3. On the offchance your version of ldap is newer and dumps the certs nicely, what version of ldap have you got? Thanks again, John. 2009/6/4 Howard Chu : > John Carter wrote: >> >> Howard, >> >> I appreciate that currently the s_client code is plain-text, this >> would have to change to support ASN.1. >> >> As you indicate "working" ldap once starttls done is hard/insane, but >> as with all protocols that's the user's problem. Actually we are >> primarily interested in seeing the certificate, rather than doing >> anything useful with the connection. > > try "ldapsearch -ZZ -d7" ... > >> I'll see if anyone's interested. >> >> John. >> >> 2009/6/3 Howard Chu: >>> >>> John Carter wrote: >>>> >>>> Hi, >>>> >>>> Currently the s_client command supports starttls for smtp, ftp etc. >>>> We're wanting to do the same for ldap, something like: >>>> >>>> openssl s_client -connect 1.2.3.4:389 -starttls ldap >>>> >>>> We're willing to pay (around 200 USD) to have this feature added. >>>> >>>> Anyone interested? >>> >>> Just what do you expect s_client to be able to do once it's gotten this >>> far? >>> The s_client code only speaks plaintext; LDAP is ASN.1. You're not going >>> to >>> be able to type anything intelligible into s_client once it's done. >>> >>> And aside from that, the OpenLDAP libraries and tools already support >>> StartTLS... >>> -- > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: s_client -starttls feature request (will pay)
Howard, I'm building a framework for application servers, one generic task is to setup ldap servers for user authentication and SSO with kerberos. There will be situations where an ldap server will have a cert that our server can't verify. In that case we'd like to ask the user if they want to trust the cert on a permanent basis. To do that we were hoping to parse the cert from an s_client call. We can do this now for ldaps (with openssl s_client -connect x.x.x.x:636 < /dev/null) , but starttls is a problem. Obviously we can work round this and allow users to install certs before configuring ldap, but it would be smoother to allow it to import the cert automatically. Thanks, John. 2009/6/4 Howard Chu : > John Carter wrote: >> >> Thanks Howard, but the problem we found with that was that the cert is >> dumped in what looks like DER format mixed in with lots of other >> binary data. However we also go nothing beyond doing -d 3. >> >> On the offchance your version of ldap is newer and dumps the certs >> nicely, what version of ldap have you got? > > Nope, that's what all versions of OpenLDAP do. It also prints the cert > subject DNs, that's been enough for most debugging purposes: > > 0730: 3a 54 c2 b5 f4 b0 37 29 d0 12 38 ae f0 0c cc 16 :T7)..8. > 0740: ba 9d 72 59 be c7 f7 81 39 70 55 e9 37 08 ..rY9pU.7. > TLS certificate verification: depth: 1, err: 0, subject: > /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas > Keymaster/emailaddress=keymas...@symas.com, issuer: > /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas > Keymaster/emailaddress=keymas...@symas.com > TLS certificate verification: depth: 0, err: 0, subject: > /C=US/ST=California/L=Los Angeles/O=Symas Corp./OU=R&D/CN=violino.symas.net, > issuer: /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas > Keymaster/emailaddress=keymas...@symas.com > TLS trace: SSL_connect:SSLv3 read server certificate A > tls_read: want=5, got=5 > : 16 03 01 00 9f > > You haven't really explained enough of what you actually want to do yet, to > give anyone a clear idea of what you're really asking for. > >> Thanks again, >> >> John. >> >> >> 2009/6/4 Howard Chu: >>> >>> John Carter wrote: >>>> >>>> Howard, >>>> >>>> I appreciate that currently the s_client code is plain-text, this >>>> would have to change to support ASN.1. >>>> >>>> As you indicate "working" ldap once starttls done is hard/insane, but >>>> as with all protocols that's the user's problem. Actually we are >>>> primarily interested in seeing the certificate, rather than doing >>>> anything useful with the connection. >>> >>> try "ldapsearch -ZZ -d7" ... >>> >>>> I'll see if anyone's interested. >>>> >>>> John. >>>> >>>> 2009/6/3 Howard Chu: >>>>> >>>>> John Carter wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Currently the s_client command supports starttls for smtp, ftp etc. >>>>>> We're wanting to do the same for ldap, something like: >>>>>> >>>>>> openssl s_client -connect 1.2.3.4:389 -starttls ldap >>>>>> >>>>>> We're willing to pay (around 200 USD) to have this feature added. >>>>>> >>>>>> Anyone interested? >>>>> >>>>> Just what do you expect s_client to be able to do once it's gotten this >>>>> far? >>>>> The s_client code only speaks plaintext; LDAP is ASN.1. You're not >>>>> going >>>>> to >>>>> be able to type anything intelligible into s_client once it's done. >>>>> >>>>> And aside from that, the OpenLDAP libraries and tools already support >>>>> StartTLS... >>>>> -- >>> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Is it a bug of mem_ctrl in bss_mem.c ?
Hi Guys,
When BIO_reset the read-only memory, does the below code assume that:
the bm's init state is bm->length == bm->max ??
if not , the below code will cause the bm->data point to the wrong address.
case BIO_CTRL_RESET:
if (bm->data != NULL)
{
/* For read only case reset to the start again */
if(b->flags & BIO_FLAGS_MEM_RDONLY)
{
bm->data -= bm->max - bm->length;
bm->length = bm->max;
}
else
{
memset(bm->data,0,bm->max);
bm->length=0;
}
}
Thanks,
Qiang.
Version info missing from win64 dlls
Version information is missing from win64 dlls for openssl-0.9.8j,
openssl-0.9.8k. The following patch should fix this:
--- openssl-0.9.8k.orig\util\mk1mf.pl Thu Sep 17 11:32:28 2009
+++ openssl-0.9.8k\util\mk1mf.pl Thu Sep 17 11:48:17 2009
@@ -863,7 +863,7 @@
}
# hack to add version info on MSVC
-if (($platform eq "VC-WIN32") || ($platform eq "VC-NT")) {
+if (($platform eq "VC-WIN32") || ($platform eq "VC-WIN64A") || ($platform eq
"VC-NT")) {
$rules.= <<"EOF";
\$(OBJ_D)\\\$(CRYPTO).res: ms\\version32.rc
path
@@ -1143,7 +1143,7 @@
$ret.=$t;
}
# hack to add version info on MSVC
- if ($shlib && (($platform eq "VC-WIN32") || ($platform eq "VC-NT")))
+ if ($shlib && (($platform eq "VC-WIN32") || ($platform eq "VC-WIN64A") ||
($platform eq "VC-NT")))
{
if ($var eq "CRYPTOOBJ")
{ $ret.="\$(OBJ_D)\\\$(CRYPTO).res "; }
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
OS/2 support
Is there an OS/2 maintainer involved in developing OpenSSL? The reason I ask is that up until v0.9.7c came out, it compiled out of the box. Since then it doesn't. The problem seems to have arisen since the introduction (or change) of ./crypto/o_str.c and results in these errors:- tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strncasecmp' : unresolved external tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strcasecmp' : unresolved external -- John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OS/2 support
On Sun, Jan 09, 2005 at 10:05:42PM +0100, Andy Polyakov wrote: > > The reason I ask is that up until v0.9.7c came out, it compiled out of the > > box. Since then it doesn't. The problem seems to have arisen since the > > introduction (or change) of ./crypto/o_str.c and results in these errors:- > > > > tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strncasecmp' : unresolved > > external > > tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strcasecmp' : unresolved > > external > > This might have been inadvertently fixed another day. Check latest > 0.9.7-stable snapshot at ftp://ftp.openssl.org/snapshot/. A. I tried:- ftp://ftp.openssl.org/snapshot/openssl-SNAP-20050111.tar.gz and got these errors:- crypto\bn\asm\bn-os2.obj(bn-os2.obj) : error L2025: bn_sub_part_words : symbol defined more than once LINK386 : error L2022: ENGINE_load_gmp (alias ENGINE_load_gmp) : export undefined tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strncasecmp' : unresolved external tmp_dll\o_str.obj(o_str.obj) : error L2029: 'strcasecmp' : unresolved external As far as v0.9.7e goes the attatched patch has been suggested as the correct solution for OS/2. How could this get included in the next release? -- John *** openssl-0.9.7e/crypto/o_str.c~ Thu Jul 8 08:32:52 2004 --- openssl-0.9.7e/crypto/o_str.c Sun Jan 9 22:13:10 2005 *** *** 89,92 --- 89,94 #elif defined(OPENSSL_SYS_WINDOWS) return _strnicmp(str1, str2, n); + #elif defined(OPENSSL_SYS_OS2) + return strnicmp(str1, str2, n); #else return strncasecmp(str1, str2, n); *** *** 99,102 --- 101,106 #elif defined(OPENSSL_SYS_WINDOWS) return _stricmp(str1, str2); + #elif defined(OPENSSL_SYS_OS2) + return stricmp(str1, str2); #else return strcasecmp(str1, str2);
Re: Add GCM Mode for AES-128
There's plenty of hardware supporting GCM right now, including off-the-shelf stuff from Hifn and Elliptic Semiconductor. I know Safenet supports it, but am not sure if they have an accelerator card or not. The whole purpose of GCM was authenticated AES encryption that could scale more or less to arbitrary bit-rates in hardware, while still performing well enough in software.I'd definitely like to see GCM in the OpenSSL crypto library (not in a TLS cipher suite, unless the IETF sees a need for high-speed hardware accelerated TLS, then let them spec it first). NIST also just published a draft standard for GCM as FIPS SP 800-38D, and it's made its way into a few IEEE things and IPSec. So it's probably got enough momentum to belong in there. Similarly, I'd also like to see CCM supported...John
Segfault inside RSA_eay_private_decrypt => BN_bn2bin
I have been having segfaults inside SSL when using the dovecot imap server, specifically within the imap-login process. It happens from within both 0.9.7a and 0.9.8e, but only with the Mac Mail client. The trace, when compiled with debug/efence, is: #0 BN_bn2bin at bn_lib.c:651 651 *(to++)=(unsigned char)(l>>(8*(i% BN_BYTES)))&0xff; #1 RSA_eay_private_decrypt #2 RSA_private_decrypt #3 ssl3_get_client_key_exchange #4 ssl3_accept The relevant line inside RSA_eay_private_decrypt is: j=BN_bn2bin(ret,p); /* j is only used with no-padding mode */ The problem is that inside RSA_eay_private_decrypt BN_num_bytes(ret); has the value 254 whereas the buffer length: BN_num_bytes(rsa->n) has the value 128 (as does flen). I'm no expert on RSA but I assume that ret is read from the client and I suspect that Mail.app is sending invalid data. Should there not be a test for this condition and an intelligent response? If the buffer size is changed to the larger value will later routines be able to tell if the resulting data is valid? I obviously have the fear that other daemons are simply masking the problem in the classic buffer over-run way. I'm running 64-bit Scientific Linux 4.[34] (a RedHat Enterprise clone). I'm assuming that the fact that integers are 32 bits but pointers 64 is not the problem, despite the presence in bn_ctx.c of the statement: fprintf(stderr,"(%08x): ", (unsigned int)ctx); (!) Thanks for your help John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Windows build of FIPS 1.1.1 is not thread-safe
Following the Windows build instructions in the OpenSSL FIPS Users Guide (using MinGW and MSYS) results in OpenSSL libraries that may crash if used in a multithreaded program. The problem is due to the definition of MS_STATIC in e_os.h: #if defined(OPENSSL_SYS_MSDOS) && !defined(OPENSSL_SYSNAME_WIN32) # define MS_STATIC static #else # define MS_STATIC #endif When building with MinGW, OPENSSL_SYS_MSDOS is defined, and OPENSSL_SYSNAME_WIN32 is not defined (instead OPENSSL_SYSNAME_MINGW32 is defined). This results in key variables declared using MS_STATIC vulnerable to race conditions. See for example p_verify.c line 71. As I understand it, I cannot modify the source or build sequence for the FIPS Object Module, in which reside these problematic static variables, without invalidating the 140-2 certification. This rather limits my options for working around this bug. One option would be to serialize any and all calls to OpenSSL functions with a global mutex. Needless to say, this would be a very painful and expensive solution for any program that makes extensive use of OpenSSL APIs or relies on parallelization for performance. A second option would be to create a wrapper gcc executable that adds '-DOPENSSL_SYSNAME_WIN32' to the command line before passing it on to the real gcc. While this seems not to violate the letter of the Security Policy, it certainly seems shady. Anyone got a better idea? Thanks, John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Windows build of FIPS 1.1.1 is not thread-safe
Brad House wrote: > Are you then using VC++ to generate the final DLL which you use > with your multithreaded application? Correct. > If so, do you receive crashes regardless of if you're in FIPS mode > at the time or not? My guess is yes. I haven't tried it, but I would anticipate that the object code with the problematic static variables is used in both FIPS and non-FIPS modes. For example, p_verify.c appears to be one of those files that does not reside within the fips subdirectory, but is sequestered in the object module. I would be surprised if there was a separate copy of that object code for non-FIPS mode use. At one point I had a working FIPS-enabled build with debug symbols, but for some reason, my more recent attempts fail the runtime FIPS canister fingerprint test. Hence my inability to directly verify the above. > The whole point to the validation was that it is a source-level validation > which is totally independent of the OS. This is my understanding as well; as long as the Windows build is done in accordance with the Security Policy (which the instructions for Windows builds in the Users Guide are asserted to be), the result is validated. That is certainly what the Security Policy, Users Guide, and various other online sources (e.g. http://oss-institute.org/fips-faq.html#a9) lead one to believe. > So far no one has been able to have a technical discussion on the issue > which was reported, instead everyone is focusing on totally irrelevant > issues. I'm not sure why, but it doesn't seem particularly > productive. Agreed. The suggestion of modifying OpenSSL so that Windows builds don't require OPENSSL_SYS_MSDOS to be defined certainly seems like the best long-term solution, but doesn't help anyone trying to get 1.1.1 working on Windows today. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Windows build of FIPS 1.1.1 is not thread-safe
Perhaps what Douglas is getting at is that if Windows were made one of the tested platforms for validation, the result would be much less likely to contain serious bugs such as this one. This I wholeheartedly agree with, and I understand that better support for Windows is indeed a high priority for future validations (see section 6 of the User Guide). > First technical question could be: If a change is made to the code to > test for OPENSC_SYSNAME_MINGW32 will this fix his multi > thread problem? I've tried it; it does. It invalidates FIPS certification as well, of course. > So part of the technical discussion needs to address if code must be > changed and thus the code must be re-certified. Or can there be some > other way around the fix. That is my question. > If he is required to be FIPS compliant, then it is not irrelevant. If FIPS compliance was not a requirement I would just continue to use vanilla 0.9.8 compiled with VC++. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl-dev] OpenSSL support for 186-4
Can anyone tell me what versions of OpenSSL and the FIPS object module are needed to support 186-4? I have seen a few vague discussions on the subject but no definitive answer. Thanks This e-mail from Ultra Electronics and any attachments to it are confidential to the intended recipient and may also be privileged. If you have received it in error please notify the sender and delete it from your system. If you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute its contents to any other person. All communications may be subject to interception or monitoring for operational and/or security purposes. Please rely on your own virus checking as the sender cannot accept any liability for any damage arising from any bug or virus infection. Recipient shall control the disclosure & access of technical data, information, and other items received under this e-mail in accordance with U.S. export control laws & regulations, including but not limited to the ITAR. No technical data, information or other items provided by Ultra Electronics - DNE Technologies, Inc. in connection with this email shall be provided to any foreign persons or to a foreign entity, including without limitation, a foreign subsidiary of recipient without the express written authorization of Ultra Electronics - DNE Technologies, Inc.; dissemination to non-U.S. persons whether in the United States or abroad requires an export license or other authorization ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Seg fault during make test
Is anyone seeing a segmentation fault during the test_verify phase of make test on 32-bit systems? I haven't done a full triage yet. But it appears to have been introduced by 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer occurs when backing out this commit. This could be a faulty commit since the sizeof invocations in this commit would return different values for 32/64 bit systems. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seg fault during make test
I think you're wrong about sizeof and pointers. It'll return 4 or 8
depending if it's a 32 or 64 bit system. Try the following code:
#include
typedef struct _s1 {
int x;
int y;
int z;
} S1;
typedef struct _s2 {
double d1;
double d2;
double d3;
double d4;
int x1;
int x2;
} S2;
int main (int argc, char *argv[]) {
S1 *first;
S2 *second;
printf("%d %d\n", sizeof(first), sizeof(second));
}
You're right about the memset, good catch. So it appears there are two
issues with this commit.
On 05/04/2015 09:35 AM, Stephan Mühlstrasser wrote:
> Am 04.05.15 um 14:51 schrieb John Foley:
>> Is anyone seeing a segmentation fault during the test_verify phase of
>> make test on 32-bit systems? I haven't done a full triage yet. But it
>> appears to have been introduced by
>> 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer occurs
>> when backing out this commit. This could be a faulty commit since the
>> sizeof invocations in this commit would return different values for
>> 32/64 bit systems.
>
> The sizeof invocations do not return the pointer sizes, but the size
> of the structures pointed to.
>
> The problem is that there's apparently a copy&paste error:
>
> https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa
>
>
> 172 memset(param, 0, sizeof *paramid);
> 173 memset(paramid, 0, sizeof *paramid);
>
> The first memset should be fixed to use "*param" instead of "*paramid":
>
> memset(param, 0, sizeof *param);
>
> Regards
> Stephan
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seg fault during make test
My bad, I overlooked the dereference operator. Thanks for correcting me.
On 05/04/2015 10:36 AM, Stephan Mühlstrasser wrote:
> Am 04.05.15 um 16:19 schrieb John Foley:
>> I think you're wrong about sizeof and pointers. It'll return 4 or 8
>> depending if it's a 32 or 64 bit system. Try the following code:
>>
>> #include
>>
>> typedef struct _s1 {
>> int x;
>> int y;
>> int z;
>> } S1;
>>
>> typedef struct _s2 {
>> double d1;
>> double d2;
>> double d3;
>> double d4;
>> int x1;
>> int x2;
>> } S2;
>>
>> int main (int argc, char *argv[]) {
>> S1 *first;
>> S2 *second;
>>
>> printf("%d %d\n", sizeof(first), sizeof(second));
>> }
>
> Yes, but that is different from what is relevant in the commit
> 53ba0a9e91ad203de2943edaf1090ab17ec435fa.
>
> You're right that in your test program you will get always different
> output on 32-bit and 64-bit systems because the pointer size is
> different.
>
> But the code in the OpenSSL uses "sizeof(*pointer)" and not
> "sizeof(pointer)". "sizeof(*pointer)" gets the size of the structure
> to which "pointer" points.
>
> So try the following in your test program
>
> printf("%d %d\n", sizeof(*first), sizeof(*second));
>
> This might return different output on 32-bit and 64-bit systems, but
> it might also return the same output, depending on the size of the
> basic types and the padding in the structures.
>
>> You're right about the memset, good catch. So it appears there are two
>> issues with this commit.
>>
>>
>>
>> On 05/04/2015 09:35 AM, Stephan Mühlstrasser wrote:
>>> Am 04.05.15 um 14:51 schrieb John Foley:
>>>> Is anyone seeing a segmentation fault during the test_verify phase of
>>>> make test on 32-bit systems? I haven't done a full triage yet.
>>>> But it
>>>> appears to have been introduced by
>>>> 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer
>>>> occurs
>>>> when backing out this commit. This could be a faulty commit since the
>>>> sizeof invocations in this commit would return different values for
>>>> 32/64 bit systems.
>>>
>>> The sizeof invocations do not return the pointer sizes, but the size
>>> of the structures pointed to.
>>>
>>> The problem is that there's apparently a copy&paste error:
>>>
>>> https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa
>>>
>>>
>>>
>>> 172 memset(param, 0, sizeof *paramid);
>>> 173 memset(paramid, 0, sizeof *paramid);
>>>
>>> The first memset should be fixed to use "*param" instead of "*paramid":
>>>
>>> memset(param, 0, sizeof *param);
>>>
>>> Regards
>>> Stephan
>>> ___
>>> openssl-dev mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>>
>>
>> ___
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> .
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Kerberos
On 05/05/2015 01:21 AM, Matt Caswell wrote: > I am considering removing Kerberos support from OpenSSL 1.1.0. There are > a number of problems with the functionality as it stands, and it seems > to me to be a very rarely used feature. I don't understand what it means to say the feature "seems" rarely used. Is there any actual evidence about the number and/or importance of uses? > I'm interested in hearing any > opinions on this (either for or against). Opinions are not a good substitute for actual evidence. This thread has revealed that some people on this list would prefer something else, but that leaves unanswered (and almost unasked) the question of whether Kerberos is actually being used. Personally I don't use it, but that does not come close to answering the question. A few moments of googling suggest that some people are using Kerberos in conjunction with openssl. For example: http://linuxsoft.cern.ch/cern/slc61/i386/yum/updates/repoview/krb5-pkinit-openssl.html > I plan to start preparing the patches to remove it next week. Why do we think that's worth the trouble? What evidence is there that removal won't cause problems? It's hard to prove a negative, and the recent discussions on this list don't even come close. I don't care about Kerberos directly, but it seems like a poor use of resources to worry about Kerberos while more pressing issues are left unaddressed. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Kerberos
On 05/09/2015 05:21 AM, Douglas E Engert wrote: > > Removing the code might be the best thing that could happen. It "might" be. That's hardly a ringing endorsement. > Misuse of the older Kerberos code in OpenSSL with SSL is not as > secure as one might think. That's not proof -- that's not even evidence that it is necessary to remove the code. More specifically, it is an awfully high-handed way to inform the users what we think is "best" for them. As previously mentioned in a different context, it is a bedrock principle of sound reasoning and sound planning that one should /Consider all the plausible scenarios./ So let's consider the following scenario: Rather than extirpating the code, we could simply add in a few instances of something like this: #error This feature is insecure, obsolete, unsupported, and vehemently deprecated. #warning This code will be removed in a future release. and leave it that way for a couple of Debian release cycles. That serves the purpose of communicating with the users, without being quite so high-handed. Also it would be good to communicate exactly what is being deprecated. All of Kerberos? Some particular combination of Kerberos+SSL In this scenario, users who wish to communicate a reply to us can do so, on a non-emergency basis. They can search for other ways of doing what needs to be done, on a non-emergency basis. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Question about valgrind error in DH in 1.0.2
If you add the --show-reachable option to valgrind, you can see where the leaks originate. They appear to be in the ex_data code (see below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f as well as 1.0.2a. ==18173== HEAP SUMMARY: ==18173== in use at exit: 416 bytes in 6 blocks ==18173== total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated ==18173== ==18173== 24 bytes in 1 blocks are still reachable in loss record 1 of 6 ==18173==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173==by 0x40AFCB: def_get_class (ex_data.c:321) ==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173==by 0x404D11: DH_new (dh_lib.c:169) ==18173==by 0x401B66: main (dhh.c:63) ==18173== ==18173== 24 bytes in 1 blocks are still reachable in loss record 2 of 6 ==18173==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173==by 0x425063: lh_insert (lhash.c:191) ==18173==by 0x40AFF9: def_get_class (ex_data.c:333) ==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173==by 0x404D11: DH_new (dh_lib.c:169) ==18173==by 0x401B66: main (dhh.c:63) ==18173== ==18173== 32 bytes in 1 blocks are still reachable in loss record 3 of 6 ==18173==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173==by 0x42434B: sk_new_null (stack.c:162) ==18173==by 0x40AFE1: def_get_class (ex_data.c:325) ==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173==by 0x404D11: DH_new (dh_lib.c:169) ==18173==by 0x401B66: main (dhh.c:63) ==18173== ==18173== 32 bytes in 1 blocks are still reachable in loss record 4 of 6 ==18173==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173==by 0x424367: sk_new_null (stack.c:164) ==18173==by 0x40AFE1: def_get_class (ex_data.c:325) ==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173==by 0x404D11: DH_new (dh_lib.c:169) ==18173==by 0x401B66: main (dhh.c:63) ==18173== ==18173== 128 bytes in 1 blocks are still reachable in loss record 5 of 6 ==18173==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173==by 0x424C5D: lh_new (lhash.c:122) ==18173==by 0x40B054: def_get_class (ex_data.c:279) ==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173==by 0x404D11: DH_new (dh_lib.c:169) ==18173==by 0x401B66: main (dhh.c:63) ==18173== ==18173== 176 bytes in 1 blocks are still reachable in loss record 6 of 6 ==18173==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173==by 0x424C3D: lh_new (lhash.c:120) ==18173==by 0x40B054: def_get_class (ex_data.c:279) ==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173==by 0x404D11: DH_new (dh_lib.c:169) ==18173==by 0x401B66: main (dhh.c:63) ==18173== ==18173== LEAK SUMMARY: ==18173==definitely lost: 0 bytes in 0 blocks ==18173==indirectly lost: 0 bytes in 0 blocks ==18173== possibly lost: 0 bytes in 0 blocks ==18173==still reachable: 416 bytes in 6 blocks ==18173== suppressed: 0 bytes in 0 blocks On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote: > Hi. I have an application that generates Diffie-Hellman key pairs based > on some precomputed primes. > > In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives > valgrind errors (while still working). > > The error only occurs on x86_64, and it does not occur on 1024 bit DH. > > I've attached the source code of the small application. All it does is > generate a DH key pair using fixed primes. I'm not really sure where > the primes come from, but this is used for H.235 (video conferencing > call setup), and I think the primes are standardized. > > Output here: > > Using the native openssl on the box (1.0.1e): > $ gcc -o dh-1.0.1 dh.c -lcrypto > $ valgrind ./dh-1.0.1 > ==4730== Memcheck, a memory error detector > ==4730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==4730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==4730== Command: ./dh-1.0.1 > ==4730== > ==4730== > ==4730== HEAP SUMMARY: > ==4730== in use at exit: 416 bytes in 6 blocks > ==4730== total heap usage: 115 allocs, 109 frees, 31,224 bytes allocated > ==4730== > ==4730== LEAK SUMMARY: > ==4730==definitely lost: 0 bytes in 0 blocks > ==4730==indirectly lost: 0 bytes in 0 blocks > ==4730== possibly lost: 0 bytes in 0 blocks > ==4730==still reachable: 416 bytes in 6 blocks > ==4730== suppressed: 0 bytes in 0 blocks > ==4730== Rerun with --leak-check=full to see detail
Re: [openssl-dev] Question about valgrind error in DH in 1.0.2
Upon further investigation, it looks like the problem is in your sample code. You need to invoke CRYPTO_cleanup_all_ex_data() before terminating your program. On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote: > Hi. I have an application that generates Diffie-Hellman key pairs based > on some precomputed primes. > > In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives > valgrind errors (while still working). > > The error only occurs on x86_64, and it does not occur on 1024 bit DH. > > I've attached the source code of the small application. All it does is > generate a DH key pair using fixed primes. I'm not really sure where > the primes come from, but this is used for H.235 (video conferencing > call setup), and I think the primes are standardized. > > Output here: > > Using the native openssl on the box (1.0.1e): > $ gcc -o dh-1.0.1 dh.c -lcrypto > $ valgrind ./dh-1.0.1 > ==4730== Memcheck, a memory error detector > ==4730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==4730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==4730== Command: ./dh-1.0.1 > ==4730== > ==4730== > ==4730== HEAP SUMMARY: > ==4730== in use at exit: 416 bytes in 6 blocks > ==4730== total heap usage: 115 allocs, 109 frees, 31,224 bytes allocated > ==4730== > ==4730== LEAK SUMMARY: > ==4730==definitely lost: 0 bytes in 0 blocks > ==4730==indirectly lost: 0 bytes in 0 blocks > ==4730== possibly lost: 0 bytes in 0 blocks > ==4730==still reachable: 416 bytes in 6 blocks > ==4730== suppressed: 0 bytes in 0 blocks > ==4730== Rerun with --leak-check=full to see details of leaked memory > ==4730== > ==4730== For counts of detected and suppressed errors, rerun with: -v > ==4730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > > I've also built myself a 1.0.2 build, using './config -DPURIFY shared' > (purify to remove other valgrind warnings that would come when reading > uninitialized data). > > $ gcc -o dh-1.0.2 -L~/src/thirdparty/openssl -isystem > ~/src/thirdparty/openssl/include dh.c -lcrypto > $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 > ==14854== Memcheck, a memory error detector > ==14854== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==14854== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==14854== Command: ./dh-1.0.2 > ==14854== > ==14854== Invalid read of size 2 > ==14854== at 0x4F09198: bn_get_bits5 (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F32B47: generate_key (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854==by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > ==14854== Address 0x581d77f is 255 bytes inside a block of size 256 alloc'd > ==14854==at 0x4C29BFD: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14854== by 0x4E9DF62: CRYPTO_malloc (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFCAA7: bn_expand_internal (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFCFA4: bn_expand2 (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854==by 0x4EFD39F: BN_bin2bn (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854==by 0x4F010FA: BN_rand (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F32B0E: generate_key (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854==by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > ==14854== > ==14854== > ==14854== HEAP SUMMARY: > ==14854== in use at exit: 416 bytes in 6 blocks > ==14854== total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated > ==14854== > ==14854== LEAK SUMMARY: > ==14854==definitely lost: 0 bytes in 0 blocks > ==14854==indirectly lost: 0 bytes in 0 blocks > ==14854== possibly lost: 0 bytes in 0 blocks > ==14854==still reachable: 416 bytes in 6 blocks > ==14854== suppressed: 0 bytes in 0 blocks > ==14854== Rerun with --leak-check=full to see details of leaked memory > ==14854== > ==14854== For counts of detected and suppressed errors, rerun with: -v > ==14854== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) > > Then, same openssl version but with 1024 bit DH: > $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 1024 > ==14730== Memcheck, a memory error detector > ==14730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==14730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==14730== Command: ./dh-1.0.2 1024 > ==14730== > ==14730== > ==14730== HEAP SUMMARY: > ==14730== in use at exit: 416 bytes in 6 blocks > ==14730== total heap usage: 112 allocs, 106 frees, 14,472 bytes allocated > ==14730== > ==14730== LEAK SUMMARY: > ==14730==definitely lost: 0 bytes in 0 blocks > ==14730==indirectly lost: 0 bytes
Re: [openssl-dev] Question about valgrind error in DH in 1.0.2
Sorry for misinterpreting your question, my mistake. I was able to replicate the error. It looks like the invalid read is in code that's compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the X86_64 target. Looking at the diff of x86_64-mont5.pl between 1.0.1 and 1.0.2, there are quite a few changes. My guess is this was introduced in ec9cc70f72454b8d4a84247c86159613cee83b81. On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote: > John Foley writes: > >> If you add the --show-reachable option to valgrind, you can see where >> the leaks originate. They appear to be in the ex_data code (see >> below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f >> as well as 1.0.2a. > Ah, I forgot to mention. I'm not concerned about the leak, but the > invalid read that's in 1.0.2 only. > > This one: > >>> ==14854== Invalid read of size 2 >>> ==14854== at 0x4F09198: bn_get_bits5 (in >>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>> ==14854== by 0x4F32B47: generate_key (in >>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>> ==14854==by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Question about valgrind error in DH in 1.0.2
Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind error. But this isn't a valid fix since bn_get_bits5 no longer returns the correct data. My assembly skills are near nil. Maybe someone else can propose a valid fix. Having said this, this does show the problem appears to be due to the movzwl reading past the end of the buffer by a byte. Given the data allocated on the heap is likely surrounded by guard bytes, this is likely a benign read outside the buffer. But it should still be fixed. On 05/13/2015 10:46 AM, John Foley wrote: > Sorry for misinterpreting your question, my mistake. I was able to > replicate the error. It looks like the invalid read is in code that's > compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the > X86_64 target. Looking at the diff of x86_64-mont5.pl between 1.0.1 and > 1.0.2, there are quite a few changes. My guess is this was introduced > in ec9cc70f72454b8d4a84247c86159613cee83b81. > > > > > On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote: >> John Foley writes: >> >>> If you add the --show-reachable option to valgrind, you can see where >>> the leaks originate. They appear to be in the ex_data code (see >>> below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f >>> as well as 1.0.2a. >> Ah, I forgot to mention. I'm not concerned about the leak, but the >> invalid read that's in 1.0.2 only. >> >> This one: >> >>>> ==14854== Invalid read of size 2 >>>> ==14854== at 0x4F09198: bn_get_bits5 (in >>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>> ==14854== by 0x4F32B47: generate_key (in >>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>> ==14854==by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] FreeBSD build broken?
Is anyone having problems building 1.0.2-stable on FreeBSD? It appears the following commit may have broken the build: https://github.com/openssl/openssl/commit/f877da9cedb95df94105d7292f8e0963175e58dc Here's the error we're seeing: [jenkins@freebird ~/tmp/openssl-OpenSSL_1_0_2-stable]$ gmake depend making depend in crypto... gmake[1]: Entering directory '/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto' ../util/domd: makedepend: not found mv: Makefile.new: No such file or directory Makefile:136: recipe for target 'local_depend' failed gmake[1]: *** [local_depend] Error 127 gmake[1]: Leaving directory '/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto' Makefile:466: recipe for target 'depend' failed gmake: *** [depend] Error 1 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Build failure on SLES11
It could be the gcc version is too old. Trying to recall, gcc needs to be something like 4.4 or newer to support the Intel carry-less multiply instruction. On 06/11/2015 09:37 AM, Dimitrios Apostolou wrote: > Hello list, > > I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system. > It fails unless I configure with "no-asm". Here is the relevant output: > > gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC > -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s > ghash-x86_64.s: Assembler messages: > ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq > $17,%xmm2,%xmm0,%xmm1' > ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq > $0,%xmm2,%xmm0,%xmm0' > [ ... many identical errors omitted ] > > > I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is > failing. Here is relevant output that might be of help: > > $ uname -a > Linux buildslave3-sles-11-x86_64 2.6.27.19-5-default #1 SMP 2009-02-28 > 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux > $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null > GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU > Binutils; SUSE Linux Enterprise 11) 2.19 > > > Thanks in advance, > Dimitris > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Build issues for demos/engines/zencod on openssl_1_0_2
Hello All, I want to create a dynamic engine and am looking to the demos section for reference code on building, etc. So far I have found the demos rsaref and zencod not to compile out of the box in OpenSSL_1_0_2. I have hacked zencod to push it forward and now getting an error during the link, excerpted below. My question are: 1. Is dynamic engine support stable and expected to work in openssl_1_0_2? 2. Are there controls I need to enable to the build procedure or tool chain to get dynamic engine support/libcrypto.a in workable state? ~/test2/openssl_1_0_2/demos/engines/zencod$ make ... ar r libzencod.a hw_zencod.o ar: creating libzencod.a ranlib libzencod.a ALLSYMSFLAGS='--whole-archive' \ SHAREDFLAGS='-shared -Wl,-soname=libzencod.so' \ SHAREDCMD='gcc'; \ ld -r -o libzencod.o $ALLSYMSFLAGS libzencod.a && (nm -Pg libzencod.o | grep ' [BDT] ' | cut -f1 -d' ' > libzencod.exp; $SHAREDCMD $SHAREDFLAGS -o libzencod.so libzencod.o -L ../../.. -lcrypto -lc) /usr/bin/ld: ../../../libcrypto.a(cryptlib.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC ../../../libcrypto.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status make: *** [libzencod.so.gnu] Error 1 adminuser@debian-amd64-700:~/test2/openssl_1_0_2/demos/engines/zencod$ gcc -version gcc: error: unrecognized command line option ‘-version’ gcc: fatal error: no input files compilation terminated. adminuser@debian-amd64-700:~/test2/openssl_1_0_2/demos/engines/zencod$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) p...@bay2sierra.com Mobile: +1-415-420-8449 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
The URL is https://openssl-sanity.cisco.com:8443/ On 08/24/2015 05:08 AM, Ben Laurie wrote: > > > On Mon, 24 Aug 2015 at 03:56 Salz, Rich <mailto:rs...@akamai.com>> wrote: > > > >On Sat, 22 Aug 2015 at 01:56 Salz, Rich <mailto:rs...@akamai.com>> wrote: > >>Thanks! We have several cross-compile builds running on Cisco's > build farm. The more the merrier. I am sure ARM would be > appreciated. > > >Are these linked from the website somewhere? > > No. John Foley @Cisco posted bout them, I think, and Matt has a > login and is careful about failures. > > > Seems to me they should be on the website. BTW I tracked it down: > > http://openssl-sanity.cisco.com:8080/ > > However, doesn't appear to be up. :-( > > I believe it also (at least when working) sends email on failures - > would be nice if those went to a list... > > > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
If you click on one of the individual builds (left side), then click on the "Console Output" link, it'll show the full build log. You can find the commands issued for the build in this log. On 08/25/2015 05:49 AM, Ben Laurie wrote: > > > On Mon, 24 Aug 2015 at 19:35 Matt Caswell <mailto:m...@openssl.org>> wrote: > > On 24/08/2015 10:08, Ben Laurie wrote: > > > > > > On Mon, 24 Aug 2015 at 03:56 Salz, Rich <mailto:rs...@akamai.com> > > <mailto:rs...@akamai.com <mailto:rs...@akamai.com>>> wrote: > > > > > > >On Sat, 22 Aug 2015 at 01:56 Salz, Rich <mailto:rs...@akamai.com> > > <mailto:rs...@akamai.com <mailto:rs...@akamai.com>>> wrote: > > >>Thanks! We have several cross-compile builds running on > Cisco's > > build farm. The more the merrier. I am sure ARM would be > appreciated. > > > > >Are these linked from the website somewhere? > > > > No. John Foley @Cisco posted bout them, I think, and Matt has a > > login and is careful about failures. > > > > > > Seems to me they should be on the website. BTW I tracked it down: > > > > http://openssl-sanity.cisco.com:8080/ > > > > However, doesn't appear to be up. :-( > > It's up; link is wrong: > > https://openssl-sanity.cisco.com:8443/ > > > Ah, thanks. So, should we link to this (and any other CI sites) from > the website? > > Also, next stupid question, if I look there, I see for example: > > https://openssl-sanity.cisco.com:8443/job/1_0_1_mips/ > > How do I find out how that's being built? > > > > > Matt > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] ECDSA side-channel attack mitigation
Is OpenSSL planning to implement side-channel resistance against the following attack: https://eprint.iacr.org/2014/161.pdf ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] State machine rewrite
+1 It's great to see improvements in the state machine along with consolidated handlers for TLS/DTLS. Having said that, have you considered using a state transition table instead of long switch statements to enforce the state transition rules? This would improve the maintainability of the code. Here's a trivial example: http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/ On 09/11/2015 10:34 AM, Matt Caswell wrote: > I've just opened a github pull request to show recent work I have been > doing on rewriting the OpenSSL state machine (for version 1.1.0). See: > https://github.com/openssl/openssl/pull/394 > > My objectives for the rewrite were: > > - Remove duplication of state code between client and server > - Remove duplication of state code between TLS and DTLS > - Simplify transitions and bring the logic together in a single location > so that it is easier to validate > - Remove duplication of code between each of the message handling functions > - Receive a message first and then work out whether that is a valid > transition - not the other way around (the other way causes lots of > issues where we are expecting one type of message next but actually get > something else) > - Separate message flow state from handshake state (in order to better > understand each) > - message flow state = when to flush buffers; handling restarts in the > event of NBIO events; handling the common flow of steps for reading a > message and the common flow of steps for writing a message etc > - handshake state = what handshake message are we working on now > - Control complexity: only the state machine can change state: keep all > the state changes local to the state machine component > > The message flow state machine is divided into a reading sub-state > machine and a writing sub-state machine. See the source comments in > ssl/statem/statem.c for a more detailed description of the various > states and transitions possible. Also see ssl/statem/README for > additional info. > > One issue is that the patch as it is currently removes support for > DTLSv1_listen. I have another patch to add that back in (in a completely > different way) - but it needs a bit more work yet. > > I am interested in hearing any feedback you may have on the code > (ideally as comments in the pull request). I would also be keen to hear > of any problems you might encounter whilst using this code. You can > check it out from my github repo: > https://github.com/mattcaswell/openssl > > See the state-machine-rewrite branch. > > Thanks > > Matt > > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL 1.1.0 Release Timetable
Is the "Async support" you have listed the same code that Intel developed for Cave Creek? Or is the Intel contribution planned for a follow-on release? On 09/16/2015 10:54 AM, Matt Caswell wrote: > > > On 16/09/15 15:38, Alessandro Ghedini wrote: > > On Wed, Sep 16, 2015 at 11:16:18AM +0100, Matt Caswell wrote: > >> The OpenSSL Project team would like to announce the publication > >> of our current plans for the OpenSSL 1.1.0 release timetable. > >> This has been included in our release strategy available here: > >> > >> https://www.openssl.org/policies/releasestrat.html > > > Do you have any idea on what features are gonna be present in > > 1.1.0? I seem to remember someone mentioning that ChaCha20-Poly1305 > > support was being worked on by Andy Polyakov and is planned for the > > 1.1.0 release, is this still the case? > > > Same goes for Curve25519/Curve448. > > > The best place to look for all the 1.1.0 changes that have taken place > so far is the CHANGES file. This is available online here: > > https://www.openssl.org/news/changelog.html > > That only lists changes that have been committed so far. Off the top > of my head other big changes that are coming include: > - State machine rewrite > - Async support > - IPv6 > > I've not heard anything from Andy in a while on his stuff so I'm not > sure what the current state of play is with ChaCha/Poly. There's > probably a ton of other stuff that I've forgotten and my colleagues > will remind me about. > > Matt > > ___ > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined
I discovered that when OPENSSL_NO_SHA512 is defined, the openssl_1_0_2 stable branch build fails during the link step with unresolved symbol EVP_sha384. The attached patch fixes this issue. p...@bay2sierra.com Mobile: +1-415-420-8449 From 235d61e3b8d1c0635d18216384c72cdeded3c961 Mon Sep 17 00:00:00 2001 From: John Peck Date: Fri, 9 Oct 2015 09:29:08 -0700 Subject: [PATCH] Fixed compile error when OPENSSL_NO_SHA512 is defined --- ssl/t1_lib.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c index 210a5e8..8db3b93 100644 --- a/ssl/t1_lib.c +++ b/ssl/t1_lib.c @@ -886,8 +886,10 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md) /* Check to see we have necessary signing algorithm */ if (curve_id[1] == TLSEXT_curve_P_256) check_md = NID_ecdsa_with_SHA256; +# ifndef OPENSSL_NO_SHA512 else if (curve_id[1] == TLSEXT_curve_P_384) check_md = NID_ecdsa_with_SHA384; +# endif else return 0; /* Should never happen */ for (i = 0; i < c->shared_sigalgslen; i++) @@ -899,7 +901,11 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md) if (check_md == NID_ecdsa_with_SHA256) c->pkeys[SSL_PKEY_ECC].digest = EVP_sha256(); else +# ifndef OPENSSL_NO_SHA512 c->pkeys[SSL_PKEY_ECC].digest = EVP_sha384(); +# else + return 0; /* Should never happen */ +# endif } } return rv; -- 1.9.1 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Building OpenSSL on Windows
Take a look at the INSTALL.W32 file in the tarball. This details all the requirements and steps to compile the code. On 10/27/2015 01:15 PM, Tom Kacvinsky wrote: > Hi, > > I've seen several messages float by about building OpenSSL on > Windows. My understanding is that I'll need a Perl distribution, in > addition to a specific assembler (MS's Macro Assemble is not up to the > task is what I gather). Anything else I need to be aware of? I will > be building in a DOS shell with Visual Studio 2008. > > Thanks, > > Tom > > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
