Re: Static analysis?

[Ben Laurie]

On Tue, Apr 17, 2012 at 9:46 PM, Lubomír Sedlář lubomir.sed...@gmail.comwrote:

 Hello,
 I would like to ask if any static analysis tool was ever used to detect
 possible problems in OpenSSL source code. Is some tool used regularly?

 I tried running Clang Static Analyzer [1] on the source of OpenSSL. It
 found 222 possible bugs. You can see the full list here [2]. At least
 65 of them are false positives. Most of the ones that seem valid to me
 are classified as Dead Code. However, even some dead assignments look
 like real problems.

 Some examples follow:

 http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-JxXj0g.html#EndPath
 The variable 'al' is never read. The goto should probably jump to
 'f_err' in order not to lose the alert.

 http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-6OKYC8.html#EndPath
 The assignment to 'ret' is either useless or goto should jump to 'err'.

 http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-117dnV.html#EndPath
 http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-rT4fgM.html#EndPath
 Duplicit assignment to 'ret' and 'saved_state.epoch', respectively.

 http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-xy1iZT.html#EndPath
 'qbits' gets assigned the same value in following condition again.

 http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-IG0Qez.html#EndPath
 The 'E', 'e', 'G', 'g' cases don't seem to do anything. Is there some
 missing functionality?


Missing but not missed, I suspect :-)



 http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-euj1zH.html#EndPath
 Default port is assigned twice, on line 234.

 Would you be interested in some patches? How and where should I submit
 them?


Interesting bugs. I would be happy to work with you to get these fixed. I
like static analysis :-)



 Regards,
 Lubomír Sedlář

 [1]: http://clang-analyzer.llvm.org/
 [2]: http://www.fi.muni.cz/~xsedlar3/openssl-analysis/

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Static analysis?

[Ben Laurie]

On Fri, Apr 20, 2012 at 4:53 PM, Jean-Marc Desperrier jmd...@free.frwrote:

 On Tue, 17 Apr 2012, Lubomír Sedlář wrote:

 I would like to ask if any static analysis tool was ever used to detect
 possible problems in OpenSSL source code. Is some tool used regularly?
 I tried running Clang Static Analyzer [1] on the source of OpenSSL.


 Julia Lawall a écrit :

 A few years ago, we did some experiments on finding problems in error
 handling in OpenSSL using Coccinelle:

 Finding Error Handling Bugs in OpenSSL using Coccinelle
 http://coccinelle.lip6.fr/**papers/edcc10.pdfhttp://coccinelle.lip6.fr/papers/edcc10.pdf


 It's a bit surprising if none of those tools could identify the badness of
 the code involved in the just published memory corruption vulnerability.


Every now and then I look at trying to eliminate the possibility of this
kind of bug. Its really hard. I'd be interested if Clang could be persuaded
to spot the bug ... even more interested if it could find conversion bugs
generically.



 I fail to see anything subtle in that vulnerability.
 Now, the trouble might be in the eye of the reviewer who'd assume way too
 easily that the downcasting of a long is OK.

 I think it would be really interesting to understand *why* this wasn't
 seen earlier, and check all the rest of the code for potentially similar
 problem. Or similar case of assuming that doing this is not very clean but
 won't hurt us instead of cleaning the code to do things properly.


The core problem is that the language doesn't do things properly :-)

But seriously, this is an important problem that crops up all the time, but
is hard to deal with. I've long suspected that a combination of static
analysis, good idioms and annotation could go a long way towards making
things better, but haven't really had time/energy to do more than 
speculate__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2826] OpenSSL Buffer Overflow Vulnerability Notification

[Ben Laurie]

LOL!

On Thu, May 31, 2012 at 7:41 PM, David Anthony via RT r...@openssl.org wrote:
 Hello all,

 There has been a new security vulnerability we have reported over at
 Bugtraq (http://seclists.org/bugtraq/2012/May/155) and we feel that it
 should also be reported to the OpenSSL dev team. If there are any questions
 regarding the issue, please feel free to give us (Myself and Vincent
 Buccigrossi) an email at this address to discuss further.

 Thank you,

 David Anthony


 Hello all,

 There has been a new security vulnerability we have reported over at Bugtraq 
 (http://seclists.org/bugtraq/2012/May/155) and we feel that it should also be 
 reported to the OpenSSL dev team. If there are any questions regarding the 
 issue, please feel free to give us (Myself and Vincent Buccigrossi) an email 
 at this address to discuss further.

 Thank you,

 David Anthony

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [CVS] OpenSSL: openssl/crypto/evp/ e_rc4_hmac_md5.c openssl/crypto/mod...

[Ben Laurie]

The point of these changes is to reduce the skew between versions.
They are not random.

On Mon, Jun 4, 2012 at 11:12 PM, Andy Polyakov ap...@openssl.org wrote:
  OpenSSL CVS Repository
  http://cvs.openssl.org/
  

  Server: cvs.openssl.org                  Name:   Andy Polyakov
  Root:   /v/openssl/cvs                   Email:  ap...@openssl.org
  Module: openssl                          Date:   05-Jun-2012 00:12:10
  Branch: HEAD                             Handle: 2012060422120703

  Modified files:
    openssl/crypto          x86cpuid.pl
    openssl/crypto/evp      e_rc4_hmac_md5.c
    openssl/crypto/modes    gcm128.c

  Log:
    Revert random changes from commit#22606.

  Summary:
    Revision    Changes     Path
    1.7         +1  -2      openssl/crypto/evp/e_rc4_hmac_md5.c
    1.30        +1  -1      openssl/crypto/modes/gcm128.c
    1.27        +1  -1      openssl/crypto/x86cpuid.pl
  

  patch -p0 '@@ .'
  Index: openssl/crypto/evp/e_rc4_hmac_md5.c
  
  $ cvs diff -u -r1.6 -r1.7 e_rc4_hmac_md5.c
  --- openssl/crypto/evp/e_rc4_hmac_md5.c       3 Jun 2012 21:59:55 -      
  1.6
  +++ openssl/crypto/evp/e_rc4_hmac_md5.c       4 Jun 2012 22:12:10 -      
  1.7
  @@ -103,8 +103,7 @@
   #if  !defined(OPENSSL_NO_ASM)      ( \
        defined(__x86_64)       || defined(__x86_64__)  || \
        defined(_M_AMD64)       || defined(_M_X64)      || \
  -     defined(__INTEL__)              )  \
  -     !(defined(__APPLE__)  defined(__MACH__))
  +     defined(__INTEL__)              )
   #define      STITCHED_CALL
   #endif

  @@ .
  patch -p0 '@@ .'
  Index: openssl/crypto/modes/gcm128.c
  
  $ cvs diff -u -r1.29 -r1.30 gcm128.c
  --- openssl/crypto/modes/gcm128.c     3 Jun 2012 21:59:55 -       1.29
  +++ openssl/crypto/modes/gcm128.c     4 Jun 2012 22:12:08 -       1.30
  @@ -1752,7 +1752,7 @@

        GHASH((ctx),buf.c,sizeof(buf));
        start = OPENSSL_rdtsc();
  -     for (i=0;i100;++i) GHASH(ctx,buf.c,sizeof(buf));
  +     for (i=0;i100;++i) GHASH((ctx),buf.c,sizeof(buf));
        gcm_t = OPENSSL_rdtsc() - start;
        printf(%.2f\n,gcm_t/(double)sizeof(buf)/(double)i);
        }
  @@ .
  patch -p0 '@@ .'
  Index: openssl/crypto/x86cpuid.pl
  
  $ cvs diff -u -r1.26 -r1.27 x86cpuid.pl
  --- openssl/crypto/x86cpuid.pl        3 Jun 2012 21:59:49 -       1.26
  +++ openssl/crypto/x86cpuid.pl        4 Jun 2012 22:12:07 -       1.27
  @@ -196,7 +196,7 @@

   function_begin_B(OPENSSL_far_spin);
        pushf  ();
  -     pop    (eax)
  +     pop    (eax);
        bt     (eax,9);
        jnc    (label(nospin));     # interrupts are disabled

  @@ .
 __
 OpenSSL Project                                 http://www.openssl.org
 CVS Repository Commit List                     openssl-...@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: [CVS] OpenSSL: openssl/crypto/evp/ e_rc4_hmac_md5.c openssl/crypto/mod...

[Ben Laurie]

On Sun, Jun 10, 2012 at 11:15 AM, Andy Polyakov ap...@openssl.org wrote:
 The point of these changes is to reduce the skew between versions.
 They are not random.


 Consider my
 http://cvs.openssl.org/filediff?f=openssl/crypto/x86cpuid.plv1=1.24v2=1.25.

 What is the criteria for two changes being propagated downwards and one
 reverted? Random.

It was a mistake. Sorry.

 Have closer look at your
 http://cvs.openssl.org/filediff?f=openssl/crypto/modes/gcm128.cv1=1.28v2=1.29

 What is the criteria for changing +- line but not two lines above? Random.

It was the line that was different between the two versions. I'm sorry
I didn't notice that GHASH is a badly written macro and so I should've
chosen the other one (or fixed the macro, I guess).
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [CVS] OpenSSL: OpenSSL_1_0_1-stable: openssl/crypto/ cryptlib.c

[Ben Laurie]

On Mon, Sep 17, 2012 at 6:24 PM, Bodo Moeller b...@openssl.org wrote:
   OpenSSL CVS Repository
   http://cvs.openssl.org/
   

   Server: cvs.openssl.org  Name:   Bodo Moeller
   Root:   /v/openssl/cvs   Email:  b...@openssl.org
   Module: openssl  Date:   17-Sep-2012 19:24:44
   Branch: OpenSSL_1_0_1-stable Handle: 2012091717244400

   Modified files:   (Branch: OpenSSL_1_0_1-stable)
 openssl/crypto  cryptlib.c

   Log:
 Fix warning.

 Submitted by: Chromium Authors

   Summary:
 RevisionChanges Path
 1.75.2.5.2.8+1  -1  openssl/crypto/cryptlib.c
   

   patch -p0 '@@ .'
   Index: openssl/crypto/cryptlib.c
   
   $ cvs diff -u -r1.75.2.5.2.7 -r1.75.2.5.2.8 cryptlib.c
   --- openssl/crypto/cryptlib.c 8 Jun 2012 09:18:32 -   1.75.2.5.2.7
   +++ openssl/crypto/cryptlib.c 17 Sep 2012 17:24:44 -  1.75.2.5.2.8
   @@ -504,7 +504,7 @@
 CRYPTO_THREADID_set_numeric(id, (unsigned long)find_thread(NULL));
#else
 /* For everything else, default to using the address of 'errno' */
   - CRYPTO_THREADID_set_pointer(id, errno);
   + CRYPTO_THREADID_set_pointer(id, (void*)errno);

This seems like a terrible idea. On some platforms...

#define errno (* __error())

Clearly you do _not_ want to be writing to a function pointer...

If you get a warning from passing errno as a void *, then you should
probably pay attention to it, not make it go away...

#endif
 }

   @@ .
 __
 OpenSSL Project http://www.openssl.org
 CVS Repository Commit List openssl-...@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: [CVS] OpenSSL: OpenSSL_1_0_1-stable: openssl/crypto/ cryptlib.c

[Ben Laurie]

On Tue, Sep 18, 2012 at 9:47 AM, Ben Laurie b...@links.org wrote:
 On Mon, Sep 17, 2012 at 6:24 PM, Bodo Moeller b...@openssl.org wrote:
   OpenSSL CVS Repository
   http://cvs.openssl.org/
   
 

   Server: cvs.openssl.org  Name:   Bodo Moeller
   Root:   /v/openssl/cvs   Email:  b...@openssl.org
   Module: openssl  Date:   17-Sep-2012 19:24:44
   Branch: OpenSSL_1_0_1-stable Handle: 2012091717244400

   Modified files:   (Branch: OpenSSL_1_0_1-stable)
 openssl/crypto  cryptlib.c

   Log:
 Fix warning.

 Submitted by: Chromium Authors

   Summary:
 RevisionChanges Path
 1.75.2.5.2.8+1  -1  openssl/crypto/cryptlib.c
   
 

   patch -p0 '@@ .'
   Index: openssl/crypto/cryptlib.c
   
 
   $ cvs diff -u -r1.75.2.5.2.7 -r1.75.2.5.2.8 cryptlib.c
   --- openssl/crypto/cryptlib.c 8 Jun 2012 09:18:32 -   1.75.2.5.2.7
   +++ openssl/crypto/cryptlib.c 17 Sep 2012 17:24:44 -  1.75.2.5.2.8
   @@ -504,7 +504,7 @@
 CRYPTO_THREADID_set_numeric(id, (unsigned long)find_thread(NULL));
#else
 /* For everything else, default to using the address of 'errno' */
   - CRYPTO_THREADID_set_pointer(id, errno);
   + CRYPTO_THREADID_set_pointer(id, (void*)errno);

 This seems like a terrible idea. On some platforms...

 #define errno (* __error())

 Clearly you do _not_ want to be writing to a function pointer...

 If you get a warning from passing errno as a void *, then you should
 probably pay attention to it, not make it go away...

Doh. I see it doesn't write to it. Nevertheless, seems like a bad
piece of code - its assuming errno is thread local, right?


#endif
 }

   @@ .
 __
 OpenSSL Project http://www.openssl.org
 CVS Repository Commit List openssl-...@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: OpenSSL and CRIME

[Ben Laurie]

On Mon, Oct 8, 2012 at 5:13 PM, Tomas Hoger tho...@redhat.com wrote:

 Hi!

 Are there any plans to apply any changes to OpenSSL related to the
 recent CRIME attack?  Unlike other libraries (e.g. GnuTLS or NSS),
 OpenSSL enables zlib by default.  Is there a plan to change the default
 in response to the published attack?  I'm aware of the existing
 SSL_OP_NO_COMPRESSION option as a workaround.

 Thank you!


Its an interesting point - perhaps we should change the default.



 --
 Tomas Hoger
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Question on OpenSSL internals

[Ben Laurie]

On Sat, Oct 20, 2012 at 5:08 AM, Joe Pletcher joepletc...@gmail.com wrote:
 Hello all,

 I hope this question is more appropriate for this list. I tried openssl-users 
 with no luck. If not, I apologize in advance.

 I'm working on an OpenSSL project, and I could use some help. I am writing a 
 library which will be loaded into the environment via LD_PRELOAD which will 
 take calls to SSL_get_verify_result and as opposed to verifying them against 
 the CA tree, will use Marlinspike's Convergence system to perform certificate 
 validation (similar to libval_shim for some DNS functions). I have a very 
 small proof of concept of this working, yet I've run into some issues. I have 
 the following questions:

 1) Is this a architecturally a bad idea? I understand writing code like this 
 is exceptionally tricky, and plan to open source all of it for peer review, 
 and slap huge caveats on it about how it has not beed tested, but 
 fundamentally is there anything wrong with this approach?

One obvious problem is, I think, that it does

 2) The biggest question I have, is for this to work well I need to be able to 
 get the hostname and port from the SSL object that gets passed into 
 SSL_get_verify_result. I've found sometimes this is available in 
 ssl-rbio-ptr-param_hostname/param_port, and it looks like other times it 
 might be available in ssl-tlsext_hostname, but it doesn't seem to be 
 standard. Is there anywhere where I can reliably find the hostname and port 
 from the SSL object (or a few places that it would be in one of?). I 
 understand this isn't using the API and could potentially break from 
 upgrades, but to a certain extent if you're using an LD_PRELOAD shim you 
 don't have a reasonable expectation of compatibility...

The problem is that OpenSSL doesn't actually manage the connection to
the host, and so doesn't necessarily know the name/port at all.

 Additionally, if this data isn't located anywhere I can access, I can grab 
 the hostname out of the x509 certificate sometimes (obviously I would lose 
 the port number, and dealing with wildcard certificates would be a huge PITA, 
 but it's doable). Also, I recognize that'd I'd probably also need to deal 
 with custom verification callbacks, and that this approach wont work with all 
 software, but I'd like to try to cover most straight forward SSL apps.

 If you have any other tips or things you think I should be aware of, please 
 feel free to let me know.

 Thank you very much for your time and help,

 Joe
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [CVS] OpenSSL: OpenSSL_1_0_2-stable: openssl/ CHANGES openssl/apps/ s_...

[Ben Laurie]

Why go via SSL_CTX_ctrl and SSL_ctrl? In fact, why do those exist at all?

On Wed, Dec 26, 2012 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote:
   OpenSSL CVS Repository
   http://cvs.openssl.org/
   

   Server: cvs.openssl.org  Name:   Dr. Stephen Henson
   Root:   /v/openssl/cvs   Email:  st...@openssl.org
   Module: openssl  Date:   26-Dec-2012 15:25:40
   Branch: OpenSSL_1_0_2-stable Handle: 2012122614252009

   Modified files:   (Branch: OpenSSL_1_0_2-stable)
 openssl CHANGES
 openssl/appss_client.c s_server.c
 openssl/ssl s3_lib.c s3_srvr.c ssl.h ssl_cert.c ssl_locl.h
 t1_lib.c tls1.h

   Log:
 Add support for application defined signature algorithms for use with
 TLS v1.2. These are sent as an extension for clients and during a 
 certificate
 request for servers.

 TODO: add support for shared signature algorithms, respect shared 
 algorithms
 when deciding which ciphersuites and certificates to permit.
 (backport from HEAD)

   Summary:
 RevisionChanges Path
 1.1481.2.56.2.86.2.38+5  -0  openssl/CHANGES
 1.123.2.6.2.15.2.8+12 -0  openssl/apps/s_client.c
 1.136.2.15.2.18.2.11+21 -0  openssl/apps/s_server.c
 1.126.2.4.2.17.2.12+12 -0  openssl/ssl/s3_lib.c
 1.171.2.21.2.24.2.14+1  -1  openssl/ssl/s3_srvr.c
 1.221.2.24.2.29.2.15+11 -0  openssl/ssl/ssl.h
 1.68.2.3.2.1.2.11+20 -5  openssl/ssl/ssl_cert.c
 1.100.2.10.2.17.2.16+16 -4  openssl/ssl/ssl_locl.h
 1.64.2.14.2.32.2.17+147 -18openssl/ssl/t1_lib.c
 1.40.2.3.2.14.2.3+8  -0  openssl/ssl/tls1.h
   

   patch -p0 '@@ .'
   Index: openssl/CHANGES
   
   $ cvs diff -u -r1.1481.2.56.2.86.2.37 -r1.1481.2.56.2.86.2.38 CHANGES
   --- openssl/CHANGES   26 Dec 2012 14:18:48 -  1.1481.2.56.2.86.2.37
   +++ openssl/CHANGES   26 Dec 2012 14:25:20 -  1.1481.2.56.2.86.2.38
   @@ -4,6 +4,11 @@

 Changes between 1.0.1 and 1.0.2 [xx XXX ]

   +  *) Add new functions to allow customised supported signature algorithms
   + for SSL and SSL_CTX structures. Add options to s_client and s_server
   + to support them.
   + [Steve Henson]
   +
  *) New function SSL_certs_clear() to delete all references to 
 certificates
 from an SSL structure. Before this once a certificate had been added
 it couldn't be removed.
   @@ .
   patch -p0 '@@ .'
   Index: openssl/apps/s_client.c
   
   $ cvs diff -u -r1.123.2.6.2.15.2.7 -r1.123.2.6.2.15.2.8 s_client.c
   --- openssl/apps/s_client.c   20 Nov 2012 00:28:22 -  
 1.123.2.6.2.15.2.7
   +++ openssl/apps/s_client.c   26 Dec 2012 14:25:21 -  
 1.123.2.6.2.15.2.8
   @@ -605,6 +605,7 @@
#ifndef OPENSSL_NO_TLSEXT
 char *servername = NULL;
 char *curves=NULL;
   + char *sigalgs=NULL;
tlsextctx tlsextcbp =
{NULL,0};
# ifndef OPENSSL_NO_NEXTPROTONEG
   @@ -948,6 +949,11 @@
 if (--argc  1) goto bad;
 curves= *(++argv);
 }
   + else if (strcmp(*argv,-sigalgs) == 0)
   + {
   + if (--argc  1) goto bad;
   + sigalgs= *(++argv);
   + }
#endif
#ifndef OPENSSL_NO_JPAKE
 else if (strcmp(*argv,-jpake) == 0)
   @@ -1192,6 +1198,12 @@
 ERR_print_errors(bio_err);
 goto end;
 }
   + if (sigalgs != NULL)
   + if(!SSL_CTX_set1_sigalgs_list(ctx,sigalgs)) {
   + BIO_printf(bio_err,error setting signature algorithms 
 list\n);
   + ERR_print_errors(bio_err);
   + goto end;
   + }
 if (servername != NULL)
 {
 tlsextcbp.biodebug = bio_err;
   @@ .
   patch -p0 '@@ .'
   Index: openssl/apps/s_server.c
   
   $ cvs diff -u -r1.136.2.15.2.18.2.10 -r1.136.2.15.2.18.2.11 s_server.c
   --- openssl/apps/s_server.c   20 Nov 2012 00:28:22 -  
 1.136.2.15.2.18.2.10
   +++ openssl/apps/s_server.c   26 Dec 2012 14:25:21 -  
 1.136.2.15.2.18.2.11
   @@ -271,6 +271,7 @@
#ifndef OPENSSL_NO_TLSEXT
static const char *s_cert_file2=TEST_CERT2,*s_key_file2=NULL;
static char *curves=NULL;
   +static char *sigalgs=NULL;
#endif
static char *s_dcert_file=NULL,*s_dkey_file=NULL, *s_dchain_file=NULL;
#ifdef FIONBIO
   @@ -1193,6 +1194,11 @@
   

OpenSSL infrastructure changes

[Ben Laurie]

The sharp-eyed will have already noticed we're moving to git.

Well, it looks like that's actually happened now. We're also shifting
pretty much everything to new infrastructure.

So, there may be outages, unexpected changes and general weirdness for
a little while.

We'll let you know when we're done.

In the meantime, you can check out the git repo like this:

git clone git://openssl.net/openssl

Please let us know if you see anything weird.

Happy New Year!
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Windows: race condition (perl/nasm) building OpenSSL

[Ben Laurie]

On 16 January 2013 13:55, Bruce Cran br...@cran.org.uk wrote:
 We've been having regular build problems on Windows: sometimes nasm claims
 there are unresolved symbols. For example:

   set ASM=nasm -f win64 -DNEAR -Ox -g
   perl crypto\x86_64cpuid.pl tmp32dll.dbg\x86_64cpuid.asm

   nasm -f win64 -DNEAR -Ox -g -o tmp32dll.dbg\x86_64cpuid.obj
 tmp32dll.dbg\x86_64cpuid.asm
  tmp32dll.dbg\x86_64cpuid.asm:4: error: symbol `OPENSSL_cpuid_setup'
 undefined
  tmp32dll.dbg\x86_64cpuid.asm:17: error: symbol `L$spin' undefined
  tmp32dll.dbg\x86_64cpuid.asm:53: error: symbol `L$intel' undefined
  tmp32dll.dbg\x86_64cpuid.asm:64: error: symbol `L$intel' undefined
 ...
 NMAKE : fatal error U1077: 'C:\Program Files (x86)\nasm\nasm.EXE' : return
 code '0x1'
 Stop.

 Running the command manually shows that perl quits before printing all the
 assembly to stdout.

 The command that seems to be going wrong is line 14 of x86_64cpuid.pl (from
 git head):

 open STDOUT,| \$^X\ $xlate $flavour $output;

 Does the script need to close STDOUT *and* wait for the subprocess to exit?

Sounds not implausible. Particularly on Windows :-)


 --
 Bruce Cran
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix IV check and padding removal.

[Ben Laurie]

On 11 February 2013 13:19, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2013-02-11 at 20:59 +, David Woodhouse wrote:
  From 32cc2479b473c49ce869e57fded7e9a77b695c0d Mon Sep 17 00:00:00 2001
  From: Dr. Stephen Henson st...@openssl.org
  Date: Thu, 7 Feb 2013 21:06:37 +
  Subject: [PATCH] Fix IV check and padding removal.
 ...
 +   if (s-version = TLS1_1_VERSION || s-version == DTLS1_VERSION)


 That's redundant, isn't it? DTLS1_VERSION (0xfeff) is greater than
 TLS1_1_version (0x302) anyway.

 DTLS1_BAD_VER isn't though. Changing the DTLS1_VERSION to DTLS1_BAD_VER
 makes OpenConnect work again...

 diff --git a/ssl/s3_cbc.c b/ssl/s3_cbc.c
 index 2e93657..1db1d8c 100644
 --- a/ssl/s3_cbc.c
 +++ b/ssl/s3_cbc.c
 @@ -146,7 +146,7 @@ int tls1_cbc_remove_padding(const SSL* s,
   unsigned padding_length, good, to_check, i;
   const unsigned overhead = 1 /* padding length byte */ + mac_size;
   /* Check if version requires explicit IV */
 - if (s-version = TLS1_1_VERSION || s-version == DTLS1_VERSION)
 + if (s-version = TLS1_1_VERSION || s-version == DTLS1_BAD_VER)
   {
   /* These lengths are all public so we can test them in
* non-constant time.

 Ah, it looks like you only moved the offending code; it was actually
 Ben's fault in commit 9f27de17 / 014265eb.

Gah! I wish tests would pick up stuff like this!

 (I'm so happy you finally moved to git :)

 --
 dwmw2

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: TPM decryption

[Ben Laurie]

On 3 March 2013 04:36, Jonathan Buhacoff jonat...@buhacoff.net wrote:
 Hi,

 I have a school project to make use of a TPM to store the server's RSA 
 private key for use with openssl.  Specifically, that private key would be 
 sealed to certain PCR values that are also encoded in the X509 certificate so 
 that, when clients make a TLS connection to the server, clients trusting that 
 particular X509 certificate know that a connection can only be established if 
 the server's state corresponds to the what is on the certificate.

 When a server needs to decrypt the client challenge in order to prepare the 
 server-verify message, instead of loading its private key from disk and 
 performing an RSA decryption, in this project the server would use the 
 trousers library to pass the material to be decrypted to the TPM and get the 
 results.  Everything before and after this step should stay the same.

 I think the relevant code is in ssl3_get_client_key_exchange,  because it 
 calls RSA_private_decrypt.

 My question is -  should I be writing a patch for the default engine to allow 
 this option to keep the private key in the TPM?  or should I be writing a new 
 engine that is essentially a copy of the default engine except for this one 
 change?   What makes more sense if I'm going to contribute the code after my 
 project is done?

 A related consideration is that the configuration would need to accommodate 
 this option, either by allowing another format for the private key file 
 option or by creating a new custom option.

 All opinions welcome...

You should already be able to do this via PKCS 11 (note: I haven't
actually tried it).
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl] OpenSSL source code branch master updated. e942c15451e1dedbe3a86e0e21a5312e5c43403e

[Ben Laurie]

Hey - why not make this a test?

On 5 March 2013 18:31, Dr. Stephen Henson st...@openssl.org wrote:
 This is an automated email from the git hooks/post-receive script. It was
 generated because a ref change was pushed to the repository containing
 the project OpenSSL source code.

 The branch, master has been updated
via  e942c15451e1dedbe3a86e0e21a5312e5c43403e (commit)
   from  897dfd4eaa6eff4d5184df9698f32289f5e93a8f (commit)

 Those revisions listed above that are new to this repository have
 not appeared on any other notification email; so we list those
 revisions in full, below.

 - Log -
 commit e942c15451e1dedbe3a86e0e21a5312e5c43403e
 Author: Dr. Stephen Henson st...@openssl.org
 Date:   Tue Mar 5 18:29:14 2013 +

 Initial CCM code.

 Simple example of CCM code use: translated from the FIPS self tests.

 ---

 Summary of changes:
  demos/evp/aesccm.c |  115 
 
  1 file changed, 115 insertions(+)
  create mode 100644 demos/evp/aesccm.c

 diff --git a/demos/evp/aesccm.c b/demos/evp/aesccm.c
 new file mode 100644
 index 000..375d834
 --- /dev/null
 +++ b/demos/evp/aesccm.c
 @@ -0,0 +1,115 @@
 +/* Simple AES CCM test program, uses the same NIST data used for the FIPS
 + * self test but uses the application level EVP APIs.
 + */
 +#include stdio.h
 +#include openssl/bio.h
 +#include openssl/evp.h
 +
 +/* AES-CCM test data from NIST public test vectors */
 +
 +static const unsigned char ccm_key[] = {
 +   0xce,0xb0,0x09,0xae,0xa4,0x45,0x44,0x51,0xfe,0xad,0xf0,0xe6,
 +   0xb3,0x6f,0x45,0x55,0x5d,0xd0,0x47,0x23,0xba,0xa4,0x48,0xe8
 +};
 +
 +static const unsigned char ccm_nonce[] = {
 +   0x76,0x40,0x43,0xc4,0x94,0x60,0xb7
 +};
 +
 +static const unsigned char ccm_adata[] = {
 +   0x6e,0x80,0xdd,0x7f,0x1b,0xad,0xf3,0xa1,0xc9,0xab,0x25,0xc7,
 +   0x5f,0x10,0xbd,0xe7,0x8c,0x23,0xfa,0x0e,0xb8,0xf9,0xaa,0xa5,
 +   0x3a,0xde,0xfb,0xf4,0xcb,0xf7,0x8f,0xe4
 +};
 +
 +static const unsigned char ccm_pt[] = {
 +   0xc8,0xd2,0x75,0xf9,0x19,0xe1,0x7d,0x7f,0xe6,0x9c,0x2a,0x1f,
 +   0x58,0x93,0x9d,0xfe,0x4d,0x40,0x37,0x91,0xb5,0xdf,0x13,0x10
 +};
 +
 +static const unsigned char ccm_ct[] = {
 +   0x8a,0x0f,0x3d,0x82,0x29,0xe4,0x8e,0x74,0x87,0xfd,0x95,0xa2,
 +   0x8a,0xd3,0x92,0xc8,0x0b,0x36,0x81,0xd4,0xfb,0xc7,0xbb,0xfd
 +};
 +
 +static const unsigned char ccm_tag[] = {
 +   0x2d,0xd6,0xef,0x1c,0x45,0xd4,0xcc,0xb7,0x23,0xdc,0x07,0x44,
 +   0x14,0xdb,0x50,0x6d
 +};
 +
 +void aes_ccm_encrypt(void)
 +   {
 +   EVP_CIPHER_CTX *ctx;
 +   int outlen, tmplen;
 +   unsigned char outbuf[1024];
 +   printf(AES CCM Encrypt:\n);
 +   printf(Plaintext:\n);
 +   BIO_dump_fp(stdout, ccm_pt, sizeof(ccm_pt));
 +   ctx = EVP_CIPHER_CTX_new();
 +   /* Set cipher type and mode */
 +   EVP_EncryptInit_ex(ctx, EVP_aes_192_ccm(), NULL, NULL, NULL);
 +   /* Set nonce length if default 96 bits is not appropriate */
 +   EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_IVLEN, sizeof(ccm_nonce), 
 NULL);
 +   /* Set tag length */
 +   EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_TAG, sizeof(ccm_tag), NULL);
 +   /* Initialise key and IV */
 +   EVP_EncryptInit_ex(ctx, NULL, NULL, ccm_key, ccm_nonce);
 +   /* Set plaintext length: only needed if AAD is used */
 +   EVP_EncryptUpdate(ctx, NULL, outlen, NULL, sizeof(ccm_pt));
 +   /* Zero or one call to specify any AAD */
 +   EVP_EncryptUpdate(ctx, NULL, outlen, ccm_adata, sizeof(ccm_adata));
 +   /* Encrypt plaintext: can only be called once */
 +   EVP_EncryptUpdate(ctx, outbuf, outlen, ccm_pt, sizeof(ccm_pt));
 +   /* Output encrypted block */
 +   printf(Ciphertext:\n);
 +   BIO_dump_fp(stdout, outbuf, outlen);
 +   /* Finalise: note get no output for CCM */
 +   EVP_EncryptFinal_ex(ctx, outbuf, outlen);
 +   /* Get tag */
 +   EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_GET_TAG, 16, outbuf);
 +   /* Output tag */
 +   printf(Tag:\n);
 +   BIO_dump_fp(stdout, outbuf, 16);
 +   EVP_CIPHER_CTX_free(ctx);
 +   }
 +
 +void aes_ccm_decrypt(void)
 +   {
 +   EVP_CIPHER_CTX *ctx;
 +   int outlen, tmplen, rv;
 +   unsigned char outbuf[1024];
 +   printf(AES CCM Derypt:\n);
 +   printf(Ciphertext:\n);
 +   BIO_dump_fp(stdout, ccm_ct, sizeof(ccm_ct));
 +   ctx = EVP_CIPHER_CTX_new();
 +   /* Select cipher */
 +   EVP_DecryptInit_ex(ctx, EVP_aes_192_ccm(), NULL, NULL, NULL);
 +   /* Set nonce length, omit for 96 bits */
 +   EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_IVLEN, sizeof(ccm_nonce), 
 NULL);
 +   /* Set expected tag value */
 +   EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_TAG,
 +   sizeof(ccm_tag), (void *)ccm_tag);
 +   /* Specify 

Re: Are Openssl Random Number Generator NIST compliant ?

[Ben Laurie]

On 6 March 2013 03:55, Nayna Jain naynj...@in.ibm.com wrote:

 Hi all,

 Are RAND_seed(), RAND_add() NIST SP 800-151A compliant ?

800-151 does not appear to exist, got a link?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Wiki

[Ben Laurie]

On 19 March 2013 18:53, Steve Marquess marqu...@opensslfoundation.com wrote:
 On 03/19/2013 10:47 AM, Pierre DELAAGE wrote:
 Dear Steve, I was wondering whether the wiki could be fed at the
 beginning by all the Documents available at
 http://www.openssl.org/docs/;.

 Very often people are able to comment, eg, a command page with some
 samples or error comments, instead of rewriting from scratch a man
 page.

 And this could be a way to only have one unique set of docs to
 maintain, and to refer to, instead of having two...

 That's an interesting suggestion; I'll kick it around and see what kind
 of traction it gets.

Seems like a good idea to me. It does raise the question of how you
export back to the docs tho...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Wiki

[Ben Laurie]

On 19 March 2013 23:27, Steve Marquess marqu...@opensslfoundation.com wrote:
 On 03/19/2013 04:59 PM, Matt Caswell wrote:
 On 19 March 2013 19:38, Steve Marquess marqu...@opensslfoundation.com 
 wrote:
 I took a quick look to see what utilities might be available to convert
 between pod and mediawiki markup formats. pod2markdown (CPAN) is close
 but not quite there.

 The pod markup language is pretty basic. If something isn't already
 out there I would have thought a bit of clever regex search and
 replace would do the job.

 Yes, I think in principle conversion both ways is feasible, though by
 the time we automate the database I/O it gets complicated. The harder
 issue is how the markdown and pod content will be synchronized.

 What I'm not clear on is if you imported them onto the wiki how that
 would work in practice. It's kind of a one way operation - I can't
 really see how you could keep both the pod version and the wiki
 version going - they would inevitably start to divergeunless you
 could somehow keep wiki as the master and then import them back in
 again?? Alternatively we just ditch pod altogether - but that would
 lose the ability to create man pages (does anyone still read man
 pages)?

 That is the dilemma. Currently most of the documentation content at
 openssl.org is generated from source files in the repository, so there
 is no ready mechanism for feeding any changes back to that source.

When you say source files, that's a little misleading - they're
generated from .pods which contain no actual source.

 If
 the wiki works out we could conceivably drop the repository controlled
 files entirely. That approach hasn't been proven viable yet.

 So perhaps a content page in the wiki consisting of a link to the
 openssl.org static content so the talk page could collect commentary?

 BTW I still read man pages daily ... I have CRS syndrome (Can't Remember
 Sh^h^hStuff).

 -Steve M.

 --
 Steve Marquess
 OpenSSL Software Foundation, Inc.
 1829 Mount Ephraim Road
 Adamstown, MD  21710
 USA
 +1 877 673 6775 s/b
 +1 301 874 2571 direct
 marqu...@opensslfoundation.com
 marqu...@openssl.com
 __
 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: OCB Authenticated Encryption

[Ben Laurie]

On 27 March 2013 12:04, Matt Caswell fr...@baggins.org wrote:
 On 27 March 2013 11:52, Michael Sierchio ku...@tenebras.com wrote:
 Does Phil still teach at UC Davis?  You could always ask him directly
 for clarification or a waiver.

 Hi contact details are on the web page describing the various license
 options (and yes its a UC Davis email address). It would be good if
 someone from OSF at least had a discussion with him. It would be a
 shame not to implement this excellent mode simply for not asking the
 right questions!

The OSF is not actually the one that would benefit from such a
licence, so the whole idea that it (or we) should pay for one seems
weird to me.


 Matt
 __
 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

Apple are, apparently, dicks...

[Ben Laurie]

...and don't intend to fix their broken ECDSA support in Safari.

It is therefore suggested that I pull this patch:

https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

What do people think?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Apple are, apparently, dicks...

[Ben Laurie]

On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote:
 On 13/06/13 17:39, Ben Laurie wrote:

 ...and don't intend to fix their broken ECDSA support in Safari.


 Ben, you've got your wires a bit crossed there.

 The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to
 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).


 It is therefore suggested that I pull this patch:


 https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

 What do people think?


 The unfortunate reality is that significant numbers of OSX 10.8.x users
 won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and
 easy to install.

Precisely my point - so how were my wires crossed?

 No server administrator will want to deploy ECDHE-ECDSA if it means breaking
 compatibility with even a small fraction of deployed browsers.  Hence why
 this patch is, unfortunately, necessary.

What is _necessary_ is that Apple accept responsibility for their errors :-)

Why are we chasing after them cleaning up their messes?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Apple are, apparently, dicks...

[Ben Laurie]

On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote:
 On 14/06/13 10:20, Ben Laurie wrote:

 On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote:

 On 13/06/13 17:39, Ben Laurie wrote:


 ...and don't intend to fix their broken ECDSA support in Safari.


 Ben, you've got your wires a bit crossed there.

 The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to
 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).

 It is therefore suggested that I pull this patch:


 https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

 What do people think?


 The unfortunate reality is that significant numbers of OSX 10.8.x users
 won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and
 easy to install.


 Precisely my point - so how were my wires crossed?


 Ah, so you're criticizing Apple for not being willing to force all OSX
 10.8.x users to update to 10.8.4.

No.

 If OSX 10.8.x has a mechanism that allows Apple to force updates to be
 installed, then I agree.  But my suspicion is that it doesn't, and if so,
 Apple's willingness isn't the key issue here.

It has a mechanism to nag you endlessly until you do install updates.
Which makes me wonder why you think people won't install the OS
update?



 No server administrator will want to deploy ECDHE-ECDSA if it means
 breaking
 compatibility with even a small fraction of deployed browsers.  Hence why
 this patch is, unfortunately, necessary.


 What is _necessary_ is that Apple accept responsibility for their errors
 :-)


 Agreed.

 Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix.


 Why are we chasing after them cleaning up their messes?


 Because we want ECDHE-ECDSA to be deployable.


 --
 Rob Stradling
 Senior Research  Development Scientist
 COMODO - Creating Trust Online

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Apple are, apparently, dicks...

[Ben Laurie]

On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote:
 On 14/06/13 12:31, Ben Laurie wrote:

 On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote:

 snip

 Ah, so you're criticizing Apple for not being willing to force all OSX
 10.8.x users to update to 10.8.4.


 No.

 If OSX 10.8.x has a mechanism that allows Apple to force updates to be
 installed, then I agree.  But my suspicion is that it doesn't, and if so,
 Apple's willingness isn't the key issue here.


 It has a mechanism to nag you endlessly until you do install updates.
 Which makes me wonder why you think people won't install the OS
 update?


 Safari's User-Agent string reveals the OSX version that it is running on.  A
 few weeks ago I analyzed some webserver logs to get an idea of historical
 OSX update rates.  Based on that analysis, I forecast that the majority of
 OSX 10.8.x users will install the 10.8.4 update, but that a significant
 minority won't.

I guess then we need to know why? And would they upgrade Safari alone?



 No server administrator will want to deploy ECDHE-ECDSA if it means
 breaking
 compatibility with even a small fraction of deployed browsers.  Hence
 why
 this patch is, unfortunately, necessary.



 What is _necessary_ is that Apple accept responsibility for their errors
 :-)



 Agreed.

 Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA
 bugfix.


 Why are we chasing after them cleaning up their messes?



 Because we want ECDHE-ECDSA to be deployable.


 --
 Rob Stradling
 Senior Research  Development Scientist
 COMODO - Creating Trust Online



 --
 Rob Stradling
 Senior Research  Development Scientist
 COMODO - Creating Trust Online
 Office Tel: +44.(0)1274.730505
 Office Fax: +44.(0)1274.730909
 www.comodo.com

 COMODO CA Limited, Registered in England No. 04058690
 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

 This e-mail and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed.
 If you have received this email in error please notify the sender by
 replying to the e-mail containing this attachment. Replies to this email may
 be monitored by COMODO for operational or business reasons. Whilst every
 endeavour is taken to ensure that e-mails are free from viruses, no
 liability can be accepted and the recipient is requested to use their own
 virus checking software.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Apple are, apparently, dicks...

[Ben Laurie]

On 14 June 2013 13:54, The Doctor doc...@doctor.nl2k.ab.ca wrote:
 On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote:
 ...and don't intend to fix their broken ECDSA support in Safari.

 It is therefore suggested that I pull this patch:

 https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

 What do people think?

 No keep the patch.

I am not sure what you mean by this.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Apple are, apparently, dicks...

[Ben Laurie]

On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote:
 On 14/06/13 13:58, Ben Laurie wrote:

 On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote:

 snip

 Safari's User-Agent string reveals the OSX version that it is running on.
 A
 few weeks ago I analyzed some webserver logs to get an idea of historical
 OSX update rates.  Based on that analysis, I forecast that the majority
 of
 OSX 10.8.x users will install the 10.8.4 update, but that a significant
 minority won't.


 I guess then we need to know why? And would they upgrade Safari alone?


 Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral
 component of OSX.

https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html
seems to suggest it is a library.



 No server administrator will want to deploy ECDHE-ECDSA if it means
 breaking
 compatibility with even a small fraction of deployed browsers.  Hence
 why
 this patch is, unfortunately, necessary.




 What is _necessary_ is that Apple accept responsibility for their
 errors
 :-)




 Agreed.

 Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA
 bugfix.


 Why are we chasing after them cleaning up their messes?




 Because we want ECDHE-ECDSA to be deployable.


 --
 Rob Stradling
 Senior Research  Development Scientist
 COMODO - Creating Trust Online



 --
 Rob Stradling
 Senior Research  Development Scientist
 COMODO - Creating Trust Online
 Office Tel: +44.(0)1274.730505
 Office Fax: +44.(0)1274.730909
 www.comodo.com

 COMODO CA Limited, Registered in England No. 04058690
 Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

 This e-mail and any files transmitted with it are confidential and
 intended
 solely for the use of the individual or entity to whom they are
 addressed.
 If you have received this email in error please notify the sender by
 replying to the e-mail containing this attachment. Replies to this email
 may
 be monitored by COMODO for operational or business reasons. Whilst every
 endeavour is taken to ensure that e-mails are free from viruses, no
 liability can be accepted and the recipient is requested to use their own
 virus checking software.



 --
 Rob Stradling
 Senior Research  Development Scientist
 COMODO - Creating Trust Online
 Office Tel: +44.(0)1274.730505
 Office Fax: +44.(0)1274.730909
 www.comodo.com

 COMODO CA Limited, Registered in England No. 04058690
 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

 This e-mail and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed.
 If you have received this email in error please notify the sender by
 replying to the e-mail containing this attachment. Replies to this email may
 be monitored by COMODO for operational or business reasons. Whilst every
 endeavour is taken to ensure that e-mails are free from viruses, no
 liability can be accepted and the recipient is requested to use their own
 virus checking software.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Apple are, apparently, dicks...

[Ben Laurie]

On 14 June 2013 16:10, Bodo Moeller bmoel...@acm.org wrote:

 Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
 libraries are updated to include the patch existing applications wont set
 it:
 they'd all need to be recompiled.


 That's a valid point.


 This is true, unfortunately.





 Possibly alternative is to reuse one of the existing *ancient* flags.
 Does
 anyone really care about compatibility with a bug in SSLeay 0.80 for
 example?


 Wouldn't it be better to reverse the meaning of the flag and not set it in
 SSL_OP_ALL?


 Hm, without any SSL_OP_... settings, the expectation generally is that we
 kind of sort of follow the specs and don't do any weird stuff like this for
 interoperability's sake. If we switch semantics around for certain options,
 the resulting inconsistencies would make all that even more confusing.

 In theory we could create an explicit SSL_OP_ALL-equivalent bit
 (SSL_OP_ALL_ALL?) that enables all current SSL_OP_ALL features and doesn't
 allow further masking, but that seems hard to deploy given that some current
 applications may expressly want SSL_OP_ALL *without* certain flags. Of
 course the legacy flag an application disables could be the one that we're
 about to recycle ... SSL_OP_ALL ideally would always have included some
 unused bits for future use, but that again is hard to pull off retroactively
 -- it's probably a good idea for a later release (with an incompatible .so
 version so that we can safely change SSL_OP_ALL).

 If we can find an appropriate ancient flag that no one should care about
 (which sounds plausible), recycling that one sounds like a good idea. If we
 can't, using reverted semantics might be the best option we have.

We could just add an SSL_OP_ALL_FROM_FUTURE flag that did this, and
leave SSL_OP_ALL as it is?

If you really want to get funky, you could make it so any bit set with
SSL_OP_ALL_FROM_FUTURE disables the corresponding feature. This would
mean you could never re-use bits, tho...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [Patch] ALPN Implementation for OpenSSL

[Ben Laurie]

On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH)
jemen...@microsoft.com wrote:
 -Original Message-
 From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org]
 On Behalf Of Piotr Sikora
 Sent: Thursday, June 20, 2013 10:41 AM
 To: openssl-dev@openssl.org
 Subject: Re: [Patch] ALPN Implementation for OpenSSL

 We simply cannot drop support for NPN (i.e. SPDY) just to add support for
 ALPN.

 The idea is to have the choice as a ./config option. The default will stay as 
 NPN, as to not disrupt anyone. I don't have this in the patch yet.

That doesn't make any sense. How would a server serve both NPN and ALPN?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [Patch] ALPN Implementation for OpenSSL

[Ben Laurie]

On 21 June 2013 02:29, Thor Lancelot Simon t...@panix.com wrote:
 On Thu, Jun 20, 2013 at 09:30:32PM +, Jeff Mendoza (MS OPEN TECH) wrote:
  Yeah, my point was that in the perfect world, you'd support both at
  runtime (at least on the server-side) and either ALPN or NPN could be
  used. I want to have a library that supports both, not either-or.

 Yes, supporting both at runtime would be best. But having a compile-time 
 option now, and defaulting to NPN should keep this from being a blocking 
 issue with the patch, correct?

 I don't speak for the OpenSSL project, but I'd suggest they should treat
 it as one.  It positively reeks of embrace and extend.  After all, the
 effect is to force all build systems producing system default packages
 of OpenSSL to pick one way or the other, ensuring that both won't work
 at the same time.

That's not really embrace and extend, but nevertheless it seems like
an unacceptable design choice.

I suggest you need to figure out how to make both ALPN and NPN work in
a single build to have any chance of acceptance at all.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: parallel make broken

[Ben Laurie]

On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote:
 On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote:
 On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote:
  On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote:
  While building openssl-1.0.1e I noticed that the parallel build
  is broken.
 
  yes, it's pretty much always been broken
 
  I found this patch on the net:
  http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl
  /fi les/openssl-1.0.1-parallel-build.patch With it applied openssl
  builds fine in parallel.
 
  heh, you've found me!  the referenced ticket says it's been merged, but
  it doesn't seem that way (at least for the latest branch).

 You are right it hasn't been merged. One problem with it is it doesn't
 work with BSD make (BSD make doesn't understand | in dependencies).

 true, but the patch posted to RT didn't include that, and that usage shows up
 only twice in the current Gentoo patch.  plenty of the other parts can be
 merged now so it's not nearly as terrible.

 i wonder if the | can be written instead like:
 lib:
 $(MAKE) subdirs
 $(MAKE) $(LIB)
 @touch lib
 $(LIB): $(LIBOBJ)
 ...

I don't know, but FWIW, I've also been working on -j stuff, but using
the mk1mf script (see the GitConfigure and GitMake scripts in master
and 1.0.2). My version is at least twice as fast as yours - on my
machine :-)

Possibly the right answer is to simply move to a single makefile...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: parallel make broken

[Ben Laurie]

On 22 June 2013 23:06, Mike Frysinger vap...@gentoo.org wrote:
 On Saturday 22 June 2013 15:07:49 Ben Laurie wrote:
 On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote:
  On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote:
  On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote:
   On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote:
   While building openssl-1.0.1e I noticed that the parallel build
   is broken.
  
   yes, it's pretty much always been broken
  
   I found this patch on the net:
   http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/open
   ssl /fi les/openssl-1.0.1-parallel-build.patch With it applied
   openssl builds fine in parallel.
  
   heh, you've found me!  the referenced ticket says it's been merged,
   but it doesn't seem that way (at least for the latest branch).
 
  You are right it hasn't been merged. One problem with it is it doesn't
  work with BSD make (BSD make doesn't understand | in dependencies).
 
  true, but the patch posted to RT didn't include that, and that usage
  shows up only twice in the current Gentoo patch.  plenty of the other
  parts can be merged now so it's not nearly as terrible.
 
  i wonder if the | can be written instead like:
  lib:
  $(MAKE) subdirs
  $(MAKE) $(LIB)
  @touch lib
  $(LIB): $(LIBOBJ)
  ...

 I don't know, but FWIW, I've also been working on -j stuff, but using
 the mk1mf script (see the GitConfigure and GitMake scripts in master
 and 1.0.2). My version is at least twice as fast as yours - on my
 machine :-)

 to be fair, i was just trying to make it work rather than rewrite things

 unfortunately mk1mf is a perl script, and i've been doing my damnedest to make
 sure perl isn't a requirement to build a base system.  we've been able to
 avoid this so far w/openssl ...

Well, you need perl to run Configure already, so presumably you do
that in advance. You could do the same with mk1mf.


 Possibly the right answer is to simply move to a single makefile...

 that might work
 -mike
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [Patch] ALPN Implementation for OpenSSL

[Ben Laurie]

On 24 June 2013 22:00, Jeff Mendoza (MS OPEN TECH)
jemen...@microsoft.com wrote:
  We simply cannot drop support for NPN (i.e. SPDY) just to add support
  for ALPN.
 
  The idea is to have the choice as a ./config option. The default will
 stay as NPN, as to not disrupt anyone. I don't have this in the patch yet.

 That doesn't make any sense. How would a server serve both NPN and ALPN?

 Ben, does the proposed solution (on the other thread) work for you?

Sounds OK to me, yes.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Fwd: [Foundations] 2013 Doc Camp CFP

[Ben Laurie]

Since people are always complaining about OpenSSL docs, I thought this
might be of interest.


-- Forwarded message --
From: adam a...@flossmanuals.net
Date: 1 August 2013 08:23
Subject: [Foundations] 2013 Doc Camp CFP
To: Foundations List foundati...@lists.freedesktop.org


hi

If any projects on the list are lacking good documentation (surely no
one here ;) then consider applying for the 2013 Doc Camp. The CFP is
open to any free software project or any individual to apply.

Its a great event:
http://www.flossmanuals.org/news/2013-doc-camp-call-proposals

Apps close Aug 7.

Not only is it productive (each project walks away with a book) its a
heap of fun and great for building out your documentation volunteer base


adam


___
foundations mailing list
foundati...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/foundations
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

bsdmake mystery

[Ben Laurie]

I'm trying to figure out why bsdmake on MacOS does this using the
standard Makefiles:

cc -c -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long
-Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror
-DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK
-DOPENSSL_NO_DEPRECATED -Wno-language-extension-token
-Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int
-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 -c -o
x86_64cpuid.o x86_64cpuid.s

but does this when using the single makefile:

as   -o tmp.master/x86_64cpuid.o tmp.master/x86_64cpuid.s

anyone got any ideas? Its driving me crazy (and stops the single
makefile from working on macos).

AFAICS, both routes should use a .s.o rule which invokes as, so ... wtf?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: AES GCM considerations in regards to SP800-38D

[Ben Laurie]

On 15 August 2013 09:21, Tomas Mraz tm...@redhat.com wrote:

 Hello OpenSSL developers,

 in a review of the AES GCM code it was found that there might be some
 requirements that are placed by SP800-38D document missing.

 Especially there is no checking that the key is not used with more than
 2^32 different IV values. Did I overlook it and the test is there? Or is
 the test not needed because in real life situation this cannot happen? I
 suppose it might happen if the key is not renegotiated during lengthy
 connections with transfer of data in TB range?


How would you propose that the code tests this property?


 --
 Tomas Mraz
 No matter how far down the wrong road you've gone, turn back.
   Turkish proverb
 (You'll never know whether the road is wrong though.)

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: bsdmake mystery

[Ben Laurie]

Thanks for this ... haven't had the chance to test it yet (travel) but will
do shortly.


On 12 August 2013 05:49, Andy Polyakov ap...@openssl.org wrote:

  I'm trying to figure out why bsdmake on MacOS does this using the
  standard Makefiles:
 
  cc -c -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT
  -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long
  -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror
  -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK
  -DOPENSSL_NO_DEPRECATED -Wno-language-extension-token
  -Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int
  -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 -c -o
  x86_64cpuid.o x86_64cpuid.s
 
  but does this when using the single makefile:
 
  as   -o tmp.master/x86_64cpuid.o tmp.master/x86_64cpuid.s
 
  anyone got any ideas? Its driving me crazy (and stops the single
  makefile from working on macos).
 
  AFAICS, both routes should use a .s.o rule which invokes as, so ... wtf?

 From Makefile.

 ...
 ASFLAG=$(CFLAG)

 BUILD_CMD=... $(MAKE) -e $(BUILDENV) ...

 build_crypto:
 ... AS='$(CC) -c' ...
 $(BUILD_ONE_CMD)
 ...

 For reference, idea behind -e $(BUILDENV) is to achieve consistent
 behaviour among different make flavours, BSD vs. SysV.

 For unification sake, i.e. to harmonize rules usage on all platforms, it
 might be appropriate to switch to .S on x86_64. I mean a number of
 platforms use .S files as output from perlasm scripts, i.e. assembly
 code that needs C pre-processing, which can arguably serve as common
 denominator for all platforms.

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: [openssl] OpenSSL source code branch supplemental-data-api-2 updated. 85b2ca671513df2b21df404d3dfa76cf681e553d

[Ben Laurie]

FWIW, I pushed this to the openssl repo instead of my own by mistake, but I
guess since it is in a branch its not that big a deal.


On 5 September 2013 14:45, Ben Laurie b...@openssl.org wrote:

 This is an automated email from the git hooks/post-receive script. It was
 generated because a ref change was pushed to the repository containing
 the project OpenSSL source code.

 The branch, supplemental-data-api-2 has been updated
via  85b2ca671513df2b21df404d3dfa76cf681e553d (commit)
via  0314741417bf45549bab1c94a49b33d40476d844 (commit)
via  6381b3cbcd8e8626f3fdfcfd54ed5a1a980847dd (commit)
via  a66d5a4a77bc086c9eff36a096e9e74d8bca8be5 (commit)
via  976fac84e0920feb9aaa9cb67002c4eb64bccde8 (commit)
via  b3943dbb18ea920c6bd71a52762ba16728e27e3d (commit)
via  65616e81a11106002e0d4509de2b0507e83cca44 (commit)
via  e21ff60d6146868fdfed8cb0795ac8a36f8b7db8 (commit)
   from  664c69432740670e8d93e0fd8d8d29f84b15fe3d (commit)

 Those revisions listed above that are new to this repository have
 not appeared on any other notification email; so we list those
 revisions in full, below.

 - Log -
 commit 85b2ca671513df2b21df404d3dfa76cf681e553d
 Merge: 664c694 0314741
 Author: Ben Laurie b...@links.org
 Date:   Thu Sep 5 14:45:25 2013 +0100

 Merge remote-tracking branch 'scott2/ben-openssl' into
 supplemental-data-api-2

 Conflicts:
 apps/s_client.c
 apps/s_server.c

 commit 0314741417bf45549bab1c94a49b33d40476d844
 Author: Scott Deboy sde...@secondstryke.com
 Date:   Thu Aug 1 11:54:09 2013 -0700

 Free generated supp data after handshake completion, add comment
 regarding use of num_renegotiations in TLS and supp data generation
 callbacks

 commit 6381b3cbcd8e8626f3fdfcfd54ed5a1a980847dd
 Author: Ben Laurie b...@links.org
 Date:   Thu Aug 1 15:17:23 2013 +0100

 More cleanup.

 commit a66d5a4a77bc086c9eff36a096e9e74d8bca8be5
 Author: Ben Laurie b...@links.org
 Date:   Thu Aug 1 12:33:15 2013 +0100

 More cleanup.

 commit 976fac84e0920feb9aaa9cb67002c4eb64bccde8
 Author: Ben Laurie b...@links.org
 Date:   Thu Aug 1 11:14:23 2013 +0100

 Make it build.

 commit b3943dbb18ea920c6bd71a52762ba16728e27e3d
 Author: Scott Deboy sde...@secondstryke.com
 Date:   Wed Jul 31 11:28:30 2013 -0700

 Remove end-of-line whitespace, change an int i to size_t i

 commit 65616e81a11106002e0d4509de2b0507e83cca44
 Merge: e21ff60 0b2bde7
 Author: Scott Deboy sde...@secondstryke.com
 Date:   Wed Jul 31 10:51:19 2013 -0700

 Merge remote-tracking branch 'openssl-github/master' into
 supplemental-data-api

 Conflicts:
 ssl/s23_clnt.c
 ssl/ssl_rsa.c

 commit e21ff60d6146868fdfed8cb0795ac8a36f8b7db8
 Author: Scott Deboy sde...@secondstryke.com
 Date:   Tue Jun 18 14:34:38 2013 -0700

 Add callbacks supporting generation and retrieval of supplemental data
 entries, facilitating RFC 5878 (TLS auth extensions)
 Removed prior audit proof logic - audit proof support was implemented
 using the generic TLS extension API
 Tests exercising the new supplemental data registration and callback
 api can be found in ssltest.c.
 Implemented changes to s_server and s_client to exercise supplemental
 data callbacks via the -auth argument, as well as additional flags to
 exercise supplemental data being sent only during renegotiation.

 ---

 Summary of changes:
  apps/s_client.c |   24 ++--
  apps/s_server.c |   24 ++--
  2 files changed, 36 insertions(+), 12 deletions(-)

 diff --git a/apps/s_client.c b/apps/s_client.c
 index a17917c..fa98d5b 100644
 --- a/apps/s_client.c
 +++ b/apps/s_client.c
 @@ -225,8 +225,10 @@ static int c_brief=0;

  #ifndef OPENSSL_NO_TLSEXT

 -static const unsigned char *most_recent_supplemental_data;
 -static size_t most_recent_supplemental_data_length;
 +static unsigned char *generated_supp_data = NULL;
 +
 +static unsigned char *most_recent_supplemental_data = NULL;
 +static size_t most_recent_supplemental_data_length = 0;

  static int server_provided_server_authz = 0;
  static int server_provided_client_authz = 0;
 @@ -1768,6 +1770,13 @@ SSL_set_tlsext_status_ids(con, ids);
 CONNECTION
 ESTABLISHED\n);
 print_ssl_summary(bio_err, con);
 }
 +   /*handshake is complete - free the
 generated supp data allocated in the callback */
 +   if (generated_supp_data)
 +   {
 +   OPENSSL_free(generated_supp_data);
 +   generated_supp_data = NULL

Re: [openssl] OpenSSL source code branch master updated. 5e3ff62c345c976cd1ffbcc5e6042f55264977f5

[Ben Laurie]

On 8 September 2013 13:35, Dr. Stephen Henson st...@openssl.org wrote:


 To enable it set the appropriate extension number (0x10 for the test
 server)
 using e.g. -DTLSEXT_TYPE_encrypt_then_mac=0x10


That's unfortunate, 16 is already allocated:
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Re: [openssl.org #3125] [PATCH 1.0.1e] openssl/crypto/armcap.c: fix a typo in OPENSSL_rdtsc

[Ben Laurie]

I find these easier to deal with as pull requests...


On 12 September 2013 17:14, Kyle McMartin via RT r...@openssl.org wrote:

 a | 1 is always true, regardless of OPENSSL_armcap_P, and
 mrc cp15 will fail on = v6.

 --- a/crypto/armcap.c
 +++ b/crypto/armcap.c
 @@ -23,7 +23,7 @@ unsigned int _armv7_tick(void);

  unsigned int OPENSSL_rdtsc(void)
 {
 -   if (OPENSSL_armcap_P|ARMV7_TICK)
 +   if (OPENSSL_armcap_P  ARMV7_TICK)
 return _armv7_tick();
 else
 return 0;

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: [openssl.org #3124] potential bug in ssl/s3_cbc.c

[Ben Laurie]

On 12 September 2013 17:14, Arthur Mesh via RT r...@openssl.org wrote:

 I am not 100% sure this is a real bug, hence first tried mailing
 openssl-users instead of rt@. But since there was no reply, I am sending
 this to rt@


 641 if (is_sslv3)
 642 {
 snip
 647 unsigned overhang =
 header_length-md_block_size;
 648 md_transform(md_state.c, header);
 649 memcpy(first_block, header + md_block_size,
 overhang);

 My suspicion lies in line 649, where we're copying overhang number of bytes
 from (header + md_block_size). I believe that copying from (header +
 md_block_size) is out-of-bound access (overrun).

 header is an array of 13 unsigned chars, and md_block_size == 64 (or 128
 in some
 cases). Hence (header + md_block_size) points outside of header[13].
 Assuming
 overhang  0, by doing a memcpy(), we have a problem, no?


Well, in fact, this code is only run when |is_sslv3|, and in that case,
|header| is actually 75 bytes. So, the documentation is at fault.

But I guess an interesting question is: can |md_block_size| be 128 when
|is_sslv3|?

Mixing time into the pool

[Ben Laurie]

I just pushed 3cd8547a2018ada88a4303067a2aa15eadc17f39 to master, which
adds time to the random pool.

Before I cherry-pick back to earlier branches, it'd be nice if people let
me know about any platform dependencies...

Re: bsdmake mystery

[Ben Laurie]

I finally got around to taking another look at this.

The next weird thing is MacOS thinks it _is_ a .S file, even though
there's only mention of .s in the makefile.

MacOS is, of course, case-insensitive, which probably doesn't help.

On 19 August 2013 15:39, Ben Laurie b...@links.org wrote:
 Thanks for this ... haven't had the chance to test it yet (travel) but will
 do shortly.


 On 12 August 2013 05:49, Andy Polyakov ap...@openssl.org wrote:

  I'm trying to figure out why bsdmake on MacOS does this using the
  standard Makefiles:
 
  cc -c -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT
  -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long
  -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror
  -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK
  -DOPENSSL_NO_DEPRECATED -Wno-language-extension-token
  -Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int
  -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 -c -o
  x86_64cpuid.o x86_64cpuid.s
 
  but does this when using the single makefile:
 
  as   -o tmp.master/x86_64cpuid.o tmp.master/x86_64cpuid.s
 
  anyone got any ideas? Its driving me crazy (and stops the single
  makefile from working on macos).
 
  AFAICS, both routes should use a .s.o rule which invokes as, so ... wtf?

 From Makefile.

 ...
 ASFLAG=$(CFLAG)

 BUILD_CMD=... $(MAKE) -e $(BUILDENV) ...

 build_crypto:
 ... AS='$(CC) -c' ...
 $(BUILD_ONE_CMD)
 ...

 For reference, idea behind -e $(BUILDENV) is to achieve consistent
 behaviour among different make flavours, BSD vs. SysV.

 For unification sake, i.e. to harmonize rules usage on all platforms, it
 might be appropriate to switch to .S on x86_64. I mean a number of
 platforms use .S files as output from perlasm scripts, i.e. assembly
 code that needs C pre-processing, which can arguably serve as common
 denominator for all platforms.

 __
 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: Self-initialization of locking/threadid callbacks and auto-detection of features

[Ben Laurie]

On 22 October 2013 06:47, Nico Williams n...@cryptonector.com wrote:

 On Monday, October 21, 2013, Salz, Rich wrote:

 I like your proposal, but I'd prefer to see an already initialized
 error code returned. Or a flag to the (new?) init api that says ignore if
 already set


 Thanks for your reply!

 I can add an error, but note that the caller can set then get the
 callbacks and compare to check whether the caller's callbacks were taken.
  I could also add a new set of callback setters with ignore-if-set flags.
  As long as the existing ones behave reliably in the already-set case.

 In the already-set case I think it may well be best to ignore without
 failing on the theory that the caller that first set the callbacks must
 have set sufficiently useful ones anyways... and that where the OS has a
 good enough default threading library, that's the one that will be used by
 all DSOs calling OpenSSL in the same process, as otherwise all hell would
 already be breaking loose anyways!  (I can imagine twisted cases where this
 would not be true, but they seem exceedingly unlikely.)

 If you want to see the half-baked bits I have (which build on Linux, but
 which aren't tested) to see what I'm up to, see
 https://github.com/nicowilliams/openssl, specifically the thread_safety
 branch.  See the XXX comments in rand_lib.c in particular.  The outline:
 add a thread-safe one-time initialization function, built on whatever the
 OS provides, then use that to make callback init thread-safe.

 What I need to know:

  - should i add new targets to ./Configure?  for now I modified the
 linux-elf target, but this feels wrong to me.

  - what about Windows?  I either need to have different targets for
 pre-vista/2008 or. i have to write a once initialization function for older
 Windows (which I can and know how to do, it's just more work that, and in
 particular i couldn't test it, so I'm not inclined to do it).

  - if so, should ./config automatically pick the new targets where there
 is appropriate threading support?


I've been musing about a more autoconf-like approach for some time now
(but, for the love of all that is fluffy, not using autoconf itself, which
sucks) - it seems this is a good reason to go down that path.

Interesting question is: what to do if no appropriate locking mechanism is
discovered?



  - how to allocate error codes for already initialized errors that you
 suggest?

  - should I work to make sure that it's possible to change the default
 RAND method after it's been set once?

The code in rand_lib.c is currently fundamentally thread-unsafe, though
 it could be accidentally thread-safe if, e.g., ENGINE_finish() doesn't
 actually tear down state at all.  The simplest fix involves setting the
 default only once, as wih the callbacks, but here I feel that's a shaky
 idea, that I should allow RAND method changes at any time, in a thread-safe
 manner -- more work for me, but less surprising.

 Nico
 --

 (sent from a mobile device with lousy typing options, and no plain text
 button)
 (my patches need rebasing to squash and split up, need tests, need
 finishing, but if you have comments I would love them sooner than later! :)

Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable

[Ben Laurie]

On 11 December 2013 08:55, Tomas Mraz tm...@redhat.com wrote:
 On Út, 2013-12-10 at 14:45 +0100, Dr. Stephen Henson wrote:
 On Mon, Dec 09, 2013, geoff_l...@mcafee.com wrote:

  Shouldn't the code read:
 
   if (!FIPS_mode())
CRYPTO_w_[un]lock(CRYPTO_LOCK_RAND);
 
  Note the '!' operator.
 

 Yes it should, sorry about that. Fixed now.

 But given skipping the locking in the FIPS mode doesn't that mean that
 the reseed operation is now not being protected under lock at all? The
 FIPS DRBG does not lock before calling the add/reseed callbacks.

Why would you need a lock? FIPS compliant modules are single threaded...

(Yes, I know this is stupid).
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Ben Laurie]

On 20 December 2013 18:51, Stephen Henson via RT r...@openssl.org wrote:
 On Fri Dec 20 19:04:32 2013, d...@fifthhorseman.net wrote:

 I can do whatever you think is most useful, but i need a bit more
 guidance to be sure i'm giving you what will be most useful for you.


 I've pulled the update now, thanks.

 Well I have to admit to being far from a git expert. For me it's best if it's
 easy to get the patches with commit messages and authorship somewhere I can
 review them. If I manually have to apply multiple patches and add appropriate
 credit it's a pain.

Pull requests on Github are quite useful - that way they also get
tracked (so long as we remember to close them when applied, that is!).
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Ben Laurie]

On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 On 01/01/2014 12:48 PM, Ben Laurie wrote:
 Pull requests on Github are quite useful - that way they also get
 tracked (so long as we remember to close them when applied, that is!).

 OK, i've rebased the series against the current master, and submitted a
 github-specific pull request:

  https://github.com/openssl/openssl/pull/37

Cool, tho didn't I read that Steve already pulled it?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

How to help OpenSSL

[Ben Laurie]

Note that this is just how to help me, not a consensus view from the
whole team, though I have no doubt much of it will be helpful to the
team, too.

1. Triage RT (https://rt.openssl.org/).

RT has been neglected for a long time. People could usefully go
through it and identify:

a) Tickets that can be closed

b) Tickets that should have action taken, and how urgent that action is.

If a ticket describes a potential security issue, then please don't
just announce it to the list. Instead send it to
openssl-secur...@openssl.org.

In order to avoid duplication of effort, perhaps someone should set up
a github repo (or something else) assigning ranges to volunteers? It
might also be useful to use the same repo to hold the triage results
(so things can be ticked off as they are actioned).

See also points 3, 4 and 5.

2. Triage Github pull requests

There are less of these, and I do try to look at them from time to
time, nevertheless I think we are behind.

3. Write fixes

Where an issue does not come with a patch, write a fix for it. Please
try to remain consistent with local style (yes, I know style is all
over the place, sorry about that, but there's no need to make it
worse).

Please make sure fixes build and that make test passes.

4. Convert fixes to pull requests

Pull requests are the easiest way to deal with incoming code. Note:
please _don't_ make public pull requests for security issues!

5. Port pull requests across all branches

Whilst it is often possible to cherry-pick pulls across the branches,
it also fairly often fails. Having someone do the legwork to fix that
is very helpful (or say that the pull works across all branches).

6. Write new tests

Our test suite sucks. More tests is better.

NOTE: I have not suddenly got more time to deal with OpenSSL stuff, so
this process may well result in a backlog, but it will certainly make
the use of what time I have more efficient.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to help OpenSSL

[Ben Laurie]

I should've said: if a fix is for a potential security issue, please
don't create a pull request (they are public), instead send a patch to
openssl-secur...@openssl.org.

You can create an appropriate patch file by doing something like this:

$ git format-patch revision to diff against --stdout  your.patch


On 24 April 2014 10:06, Ben Laurie b...@links.org wrote:
 Note that this is just how to help me, not a consensus view from the
 whole team, though I have no doubt much of it will be helpful to the
 team, too.

 1. Triage RT (https://rt.openssl.org/).

 RT has been neglected for a long time. People could usefully go
 through it and identify:

 a) Tickets that can be closed

 b) Tickets that should have action taken, and how urgent that action is.

 If a ticket describes a potential security issue, then please don't
 just announce it to the list. Instead send it to
 openssl-secur...@openssl.org.

 In order to avoid duplication of effort, perhaps someone should set up
 a github repo (or something else) assigning ranges to volunteers? It
 might also be useful to use the same repo to hold the triage results
 (so things can be ticked off as they are actioned).

 See also points 3, 4 and 5.

 2. Triage Github pull requests

 There are less of these, and I do try to look at them from time to
 time, nevertheless I think we are behind.

 3. Write fixes

 Where an issue does not come with a patch, write a fix for it. Please
 try to remain consistent with local style (yes, I know style is all
 over the place, sorry about that, but there's no need to make it
 worse).

 Please make sure fixes build and that make test passes.

 4. Convert fixes to pull requests

 Pull requests are the easiest way to deal with incoming code. Note:
 please _don't_ make public pull requests for security issues!

 5. Port pull requests across all branches

 Whilst it is often possible to cherry-pick pulls across the branches,
 it also fairly often fails. Having someone do the legwork to fix that
 is very helpful (or say that the pull works across all branches).

 6. Write new tests

 Our test suite sucks. More tests is better.

 NOTE: I have not suddenly got more time to deal with OpenSSL stuff, so
 this process may well result in a backlog, but it will certainly make
 the use of what time I have more efficient.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Attribution of pull requests in git

[Ben Laurie]

I just noticed that if I merge a pull request, then both author and
committer are set to whoever made the pull request.

From the POV of figuring out what went wrong, when things go wrong,
that seems bad.

Is there an easy way to fix that? That is, I would expect it to show
me as the committer and the original author as the author.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to help OpenSSL

[Ben Laurie]

On 24 April 2014 18:44, Mike Bland mbl...@acm.org wrote:
 On Thu, Apr 24, 2014 at 1:31 PM, Ben Laurie b...@links.org wrote:

 6. Write new tests

 Our test suite sucks. More tests is better.


 Shall I send a pull request for this:

 https://github.com/mbland/openssl/commit/a7a9e18b550edf059dfd54683ac1f45170ff9fb2

Yes, please! Ideally, as I say, for all branches.

Have you verified that the test fails pre-fix?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to help OpenSSL

[Ben Laurie]

On 25 April 2014 00:08, Matt Caswell fr...@baggins.org wrote:
 Ben - Is it possible for some of us to get RT users created? The above
 assumes we can configure RT statuses - is this possible?

I think you now have RT access, right?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to help OpenSSL

[Ben Laurie]

On 24 April 2014 19:54, Kurt Roeckx k...@roeckx.be wrote:
 On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote:
 Note that this is just how to help me, not a consensus view from the
 whole team, though I have no doubt much of it will be helpful to the
 team, too.

 1. Triage RT (https://rt.openssl.org/).

 RT has been neglected for a long time. People could usefully go
 through it and identify:

 a) Tickets that can be closed

 b) Tickets that should have action taken, and how urgent that action is.

 If a ticket describes a potential security issue, then please don't
 just announce it to the list. Instead send it to
 openssl-secur...@openssl.org.

 In order to avoid duplication of effort, perhaps someone should set up
 a github repo (or something else) assigning ranges to volunteers? It
 might also be useful to use the same repo to hold the triage results
 (so things can be ticked off as they are actioned).

 I already created a github branch for this,

I'm a little unclear what this is? Also, how this fits into Matt's
coordinated effort?

 but I stopped adding
 patches at it since I didn't know if this was going to be useful
 or not.

 See:
 https://github.com/kroeckx/openssl/commits/master-proposed


 2. Triage Github pull requests

 There are less of these, and I do try to look at them from time to
 time, nevertheless I think we are behind.

 I've looked over them several time already, and I've merged a few
 of those.  But it's hard for me to know what you would find an
 acceptable change and what not, so I've tried to be conservative.

 3. Write fixes
 4. Convert fixes to pull requests

 I'll try to work on that.

 5. Port pull requests across all branches

 I wasn't really sure what to do here, and was planning to have
 branches you can pull for the various branches.



 Kurt

 __
 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: Attribution of pull requests in git

[Ben Laurie]

On 26 April 2014 12:16, Kurt Roeckx k...@roeckx.be wrote:
 On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote:
 Is there an easy way to fix that? That is, I would expect it to show
 me as the committer and the original author as the author.

 That is how it should always work, and I'm not sure why you would
 see anything else.  git really keeps the author and date of the
 patch seperated from the commiter and date of commit.

My point is that it doesn't work like that. I agree it should :-)
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: test/heartbleed_test.c

[Ben Laurie]

On 20 May 2014 06:40, The Doctor,3328-138 Ave Edmonton AB T5Y
1M4,669-2000,473-4587 doc...@doctor.nl2k.ab.ca wrote:
 Found that strndup would not work.

 I had to add

 #if !HAVE_STRNDUP

 #include stdio.h
 #include string.h
 #include sys/types.h
 #include malloc.h

 /* Find the length of STRING, but scan at most MAXLEN characters.
If no '\0' terminator is found in that many characters, return MAXLEN.  */
 size_t
 strnlen (const char *string, size_t maxlen)
 {
   const char *end = memchr (string, '\0', maxlen);
   return end ? end - string : maxlen;
 }

 char *
 strndup (const char *s, size_t n)
 {
   size_t len = strnlen (s, n);
   char *new = malloc (len + 1);

   if (new == NULL)
 return NULL;

   new[len] = '\0';
   return memcpy (new, s, len);
 }

 #endif

 Please see how you can add this.

There is already a strndup replacement: BUF_strndup(). Switching to
use that would be better.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Fwd: Using Frankencerts for Automated Adversarial,Testing of Certificate Validation,in SSL/TLS Implementations

[Ben Laurie]

-- Forwarded message --
From: Martin Haufschild martin.haufsch...@uni-rostock.de
Date: 23 May 2014 07:34
Subject: Using Frankencerts for Automated Adversarial,Testing of
Certificate Validation,in SSL/TLS Implementations


Hello,

FYI

https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf

There seem to be two discrepancies with OpenSSL on page 11.

Regards
Martin
--

This is a pretty nice paper, well worth a read, IMO.

Anyway, the two discrepancies: not clear to me that accepting basic
constraints in V1 certs is a bug. In any case it can only (I think)
tighten the constraints on the chain, so doesn't seem harmful.
Rejecting a leaf CA below an intermediate with zero path length may be
strictly incorrect, but ... what does it mean? Would you ever see such
a thing? When?

In any case, for the second issue at least, patches welcome.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Prime generation

[Ben Laurie]

On 27 May 2014 09:16, Joseph Birr-Pixton jpix...@gmail.com wrote:
 On 27 May 2014 08:45, Peter Waltenberg pwal...@au1.ibm.com wrote:
 ...
 I did change the RNG sources for some of the OpenSSL code in our hacked
 version to help with the performance problems using the wrong source causes,
 for example RSA blinding data can safely come from a DRBG
 (pseudo_rand_bytes()).

 I assume you mean RAND_pseudo_bytes. In which case you should know
 that RAND_pseudo_bytes has a broken interface and cannot ever be used
 safely in a way which makes it different from RAND_bytes.

 To restate:

 Callers of RAND_pseudo_bytes are either unreliable, or equivalent to
 RAND_bytes. Do not use it.

Have I missed something? What are you referring to here?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: open ssl rsa key generation improvement idea

[Ben Laurie]

Nice idea.

It inspired my son, Felix, and I to think about a related idea:
generate random numbers which are inherently coprime to small primes.
Felix went on to implement the idea, and include benchmarks and tests.

Not finished - while implementing, we noticed that the existing prime
number generators have a bias. We decided to remove that, which caused
prime candidate generation to take more than twice as long (it was 42%
of the speed on Felix' laptop) - but the good news is our technique
doubled the speed, getting most of the loss back.

We also don't currently deal with the case where add != 2 or rem != 1.
But its clearly possible without too much work.

You could use his branch as a basis for testing this idea:
https://github.com/openssl/openssl/pull/116.

On 26 May 2014 02:31, Russell Harkins russ...@russellharkins.info wrote:
 Hi SSL Team,

 I was looking for ways to make calculating RSA public/private keys faster.
 I noticed that trial division was being done to test if a number is
 divisible by small primes.
 Roughly 2/3 of all odd numbers are divisible by primes less than 25. I
 found a faster way to test the divisibility than using division.
 In school, I learned some divisibility rules. For instance, when
 determining if a large number is divisible by 3, add the sum of all the
 digits.  To see if a large number is divisible by 5, check the last digit
 to see if it’s a zero or 5.

 I’ve converted these divisibility rules into binary. For instance, to see
 if a large number is divisible by 3, add the sum of all the bytes of the
 large number and see if that sum is divisible by 3.
 I’ve converted all the divisibility rules for all the primes less than 25
 into binary. All the sums can be calculated at once.

 I wrote a function to do this based on the BIGNUM that openssl uses:
 BN_isdivisiblebyprimeslessthan25
 The easiest way to test my function is to generate random numbers and test
 the results of BN_isdivisiblebyprimeslessthan25 with another function that
 does the division the old way.

 Attached is a paper detailing the math behind the change.

 Here’s the function and where to put it in openssl:

 In file crypto\bn\bn_prime.c,
 function BN_is_prime_fasttest_ex
 After if (do_trial_division), add
   if (BN_isdivisiblebyprimeslessthan25(a))
return 0;

 bool bn:: BN_isdivisiblebyprimeslessthan25 (const BIGNUM *p)
 {
 int total3and5and17 = 0; // 256 mod 3 = 1, 256 mod 5 = 1, 256 mod 17 = 1
 int total7 = 0;
 int total11 = 0;
 int total13 = 0;
 int total19 = 0;
 int total23 = 0;

 const char sumBytes7[] = { 1, 4, 2}; // 1 mod 7 = 1, 256 mod 7 = 4,
 65536 mod 7 = 2
 const char sumBytes11[] = { 1, 3, 9, 5, 4}; // 1 mod 11 = 1, 256 mod 11
 = 3, 65536 mod 11 = 9
 const char sumBytes13[] = { 1, 9, 3}; // 1 mod 13 = 1, 256 mod 13 = 9,
 65536 mod 13 = 3
 const char sumBytes19[] = { 1, 9, 5, 7, 6, 16, 11, 4, 17};
 const char sumBytes23[] = { 1, 3, 9, 4, 12, 13, 16, 2, 6, 18, 8};

 int index7or13 = 0; // Array indexes for 7 and 13 are the same because
 the array is the same size.
 int index11 = 0;
 int index19 = 0;
 int index23 = 0;
 int byteLoop;
 int top;
 BN_ULONG item;
 int itemByte;
 BN_ULONG *itemptr;
 BN_ULONG *lastItem;

 top = p-top;
 if (top = 0)
 {
 return true;
 }

 itemptr = p-d;
 lastItem = itemptr+top-1;
 while(true)
 {
 item = *itemptr;
 for(byteLoop=0;byteLoopsizeof(BN_ULONG);byteLoop++)
 {
 itemByte = (int)(item  255);
 item = 8;
 total3and5and17 += itemByte;
 total7 += (sumBytes7[index7or13] * itemByte);
 total13 += (sumBytes13[index7or13] * itemByte);
 total11 += (sumBytes11[index11] * itemByte);
 total19 += (sumBytes19[index19] * itemByte);
 total23 += (sumBytes23[index23] * itemByte);
 // Keep the array indexes in bounds.
 index7or13 = (index7or13 + 1) % 3;
 index11 = (index11 + 1) % 5;
 index19 = (index19 + 1) % 9;
 index23 = (index23 + 1) % 11;
 }
 // Move to the next item.
 if (itemptr == lastItem)
 {
 break;
 }
 itemptr++;
 }
 bool returnValue = (((total3and5and17 % 3) == 0)
 || ((total3and5and17 % 5) == 0)
 || ((total7 % 7) == 0)
 || ((total11 % 11) == 0)
 || ((total13 % 13) == 0)
 || ((total3and5and17 % 17) == 0)
 || ((total19 % 19) == 0)
 || ((total23 % 23) == 0));

 return returnValue;
 }

 Russell 

Re: open ssl rsa key generation improvement idea

[Ben Laurie]

Also, I should note that this approach is not portable. You need to
operate in the same base as BIGNUM does, or account for endianness is
the byte-level operations.

On 26 May 2014 02:31, Russell Harkins russ...@russellharkins.info wrote:
 Hi SSL Team,

 I was looking for ways to make calculating RSA public/private keys faster.
 I noticed that trial division was being done to test if a number is
 divisible by small primes.
 Roughly 2/3 of all odd numbers are divisible by primes less than 25. I
 found a faster way to test the divisibility than using division.
 In school, I learned some divisibility rules. For instance, when
 determining if a large number is divisible by 3, add the sum of all the
 digits.  To see if a large number is divisible by 5, check the last digit
 to see if it’s a zero or 5.

 I’ve converted these divisibility rules into binary. For instance, to see
 if a large number is divisible by 3, add the sum of all the bytes of the
 large number and see if that sum is divisible by 3.
 I’ve converted all the divisibility rules for all the primes less than 25
 into binary. All the sums can be calculated at once.

 I wrote a function to do this based on the BIGNUM that openssl uses:
 BN_isdivisiblebyprimeslessthan25
 The easiest way to test my function is to generate random numbers and test
 the results of BN_isdivisiblebyprimeslessthan25 with another function that
 does the division the old way.

 Attached is a paper detailing the math behind the change.

 Here’s the function and where to put it in openssl:

 In file crypto\bn\bn_prime.c,
 function BN_is_prime_fasttest_ex
 After if (do_trial_division), add
   if (BN_isdivisiblebyprimeslessthan25(a))
return 0;

 bool bn:: BN_isdivisiblebyprimeslessthan25 (const BIGNUM *p)
 {
 int total3and5and17 = 0; // 256 mod 3 = 1, 256 mod 5 = 1, 256 mod 17 = 1
 int total7 = 0;
 int total11 = 0;
 int total13 = 0;
 int total19 = 0;
 int total23 = 0;

 const char sumBytes7[] = { 1, 4, 2}; // 1 mod 7 = 1, 256 mod 7 = 4,
 65536 mod 7 = 2
 const char sumBytes11[] = { 1, 3, 9, 5, 4}; // 1 mod 11 = 1, 256 mod 11
 = 3, 65536 mod 11 = 9
 const char sumBytes13[] = { 1, 9, 3}; // 1 mod 13 = 1, 256 mod 13 = 9,
 65536 mod 13 = 3
 const char sumBytes19[] = { 1, 9, 5, 7, 6, 16, 11, 4, 17};
 const char sumBytes23[] = { 1, 3, 9, 4, 12, 13, 16, 2, 6, 18, 8};

 int index7or13 = 0; // Array indexes for 7 and 13 are the same because
 the array is the same size.
 int index11 = 0;
 int index19 = 0;
 int index23 = 0;
 int byteLoop;
 int top;
 BN_ULONG item;
 int itemByte;
 BN_ULONG *itemptr;
 BN_ULONG *lastItem;

 top = p-top;
 if (top = 0)
 {
 return true;
 }

 itemptr = p-d;
 lastItem = itemptr+top-1;
 while(true)
 {
 item = *itemptr;
 for(byteLoop=0;byteLoopsizeof(BN_ULONG);byteLoop++)
 {
 itemByte = (int)(item  255);
 item = 8;
 total3and5and17 += itemByte;
 total7 += (sumBytes7[index7or13] * itemByte);
 total13 += (sumBytes13[index7or13] * itemByte);
 total11 += (sumBytes11[index11] * itemByte);
 total19 += (sumBytes19[index19] * itemByte);
 total23 += (sumBytes23[index23] * itemByte);
 // Keep the array indexes in bounds.
 index7or13 = (index7or13 + 1) % 3;
 index11 = (index11 + 1) % 5;
 index19 = (index19 + 1) % 9;
 index23 = (index23 + 1) % 11;
 }
 // Move to the next item.
 if (itemptr == lastItem)
 {
 break;
 }
 itemptr++;
 }
 bool returnValue = (((total3and5and17 % 3) == 0)
 || ((total3and5and17 % 5) == 0)
 || ((total7 % 7) == 0)
 || ((total11 % 11) == 0)
 || ((total13 % 13) == 0)
 || ((total3and5and17 % 17) == 0)
 || ((total19 % 19) == 0)
 || ((total23 % 23) == 0));

 return returnValue;
 }

 Russell Harkins
 650-481-5261

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: open ssl rsa key generation improvement idea

[Ben Laurie]

On 28 May 2014 00:03, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
 On Tue, May 27, 2014 at 09:04:20PM +0100, Ben Laurie wrote:

 It inspired my son, Felix, and I to think about a related idea:
 generate random numbers which are inherently coprime to small primes.
 Felix went on to implement the idea, and include benchmarks and tests.

 When you say small, you mean really small right?  Not the first
 2048 primes as in the OpenSSL code, but say the first few, for
 example those less than 25?

Yeah - we went up to 11 for the tests.

 Not finished - while implementing, we noticed that the existing prime
 number generators have a bias. We decided to remove that, which caused
 prime candidate generation to take more than twice as long (it was 42%
 of the speed on Felix' laptop) - but the good news is our technique
 doubled the speed, getting most of the loss back.

 Do the resulting candidates also avoid having small odd factors in
 (p-1)?  This means p != 0 or 1 mod each of the first batch of odd
 primes.

No, but the method could be extended to do that pretty easily.

 For the first 9 primes:

 2, 3, 5, 7, 11, 13, 17, 19, 23

 this leaves only

 7,952,175 = 1 * 1 * 3 * 5 * 9 * 11 * 15 * 17 * 21

 acceptable odd values modulo:

 223,092,870 = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23

 or ~7.1% of the odd candidates.

 --
 Viktor.
 __
 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: Prime generation

[Ben Laurie]

On 28 May 2014 01:47, mancha manc...@zoho.com wrote:
 Fouque and Tibouchi [3] offer the differing view that it's preferable to
 minimize bias and generate primes that are almost uniform even if it is
 not immediately clear how such biases can help an adversary. They
 suggest a few algorithms that improve on naive discard  repeat by
 discarding only the top N bits of a candidate at each iteration, among
 other innovations.

This paper assumes two things that don't appear to be true:

a) That prime generation attempts consume entropy - why? Seems fine to
me to just stir the pool and try again.

b) That repeated random number generation is much more expensive than,
say, addition. Our experiments show that generating a new random
number each time is only half the speed of incrementing.

I'm guessing these incorrect assumptions are common in the literature?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Re : Re: open ssl rsa key generation improvement idea Prime generation

[Ben Laurie]

On 28 May 2014 13:32,  nicolas@free.fr wrote:
 Hi,

 it seems that the two discussions are somehow related

 the idea of generating only prime candidates not dividible by small primes is 
 interesting but, due to incremental search, it will not apply to next 
 candidates

a) The incremental search introduces bias, so not clear we should
really maintain that

b) It isn't very hard to incorporate incremental search in our scheme

I am not suggesting that your idea is not also worthwhile - in
particular, you can probably go to higher primes than our scheme - the
tables quickly become pretty large...

 however, it may be possible to use bit counting to perform a less biased walk 
 AND efficiently avoid prime dividible by first primes :

 let say we generate randomly the first bytes of a key, except the last byte

 it is then possible to compute quickly all possible values for the last byte 
 (or first depending on endianness) such that it is not dividible by first 
 primes (as well as (p-1)/2 using a bit shift)
 looking at the last test of code provided, it can even be made quite 
 efficiently using CRT

 given these values, we can test them in a random order in order to reduce the 
 bias of incremental search
 in case of fail, just change last bit of second-to-last byte, and try again

 it should be statistically correct to do this on the byte of highest weight, 
 but by applying this on the first byte we are sure that it will spawn a 
 (strong) prime, just like incremental search


 This is just an idea as I didn't implement anything yet
 however with full optimization this could be quicker than incremental search

 And sorry if I'm mistaking anyhow


 Nico



 - Mail d'origine -
 De: Ben Laurie b...@links.org
 À: OpenSSL development openssl-dev@openssl.org
 Envoyé: Wed, 28 May 2014 11:10:25 +0200 (CEST)
 Objet: Re: open ssl rsa key generation improvement idea

 On 28 May 2014 00:03, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
 On Tue, May 27, 2014 at 09:04:20PM +0100, Ben Laurie wrote:

 It inspired my son, Felix, and I to think about a related idea:
 generate random numbers which are inherently coprime to small primes.
 Felix went on to implement the idea, and include benchmarks and tests.

 When you say small, you mean really small right?  Not the first
 2048 primes as in the OpenSSL code, but say the first few, for
 example those less than 25?

 Yeah - we went up to 11 for the tests.

 Not finished - while implementing, we noticed that the existing prime
 number generators have a bias. We decided to remove that, which caused
 prime candidate generation to take more than twice as long (it was 42%
 of the speed on Felix' laptop) - but the good news is our technique
 doubled the speed, getting most of the loss back.

 Do the resulting candidates also avoid having small odd factors in
 (p-1)?  This means p != 0 or 1 mod each of the first batch of odd
 primes.

 No, but the method could be extended to do that pretty easily.

 For the first 9 primes:

 2, 3, 5, 7, 11, 13, 17, 19, 23

 this leaves only

 7,952,175 = 1 * 1 * 3 * 5 * 9 * 11 * 15 * 17 * 21

 acceptable odd values modulo:

 223,092,870 = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23

 or ~7.1% of the odd candidates.

 --
 Viktor.
 __
 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

 __
 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: New unbiased prime generator function fixes

[Ben Laurie]

You didn't update the test...

On 1 June 2014 21:26, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
 On Sun, Jun 01, 2014 at 08:14:00PM +, Viktor Dukhovni wrote:

 The new prime generator does not ensure that generated primes are
 safe modulo 2, 3, 5, 7 or 11. In particular (p-1)/2 might not
 be co-prime to 2310.

 The patch below my signature addresses this problem.

 Oops, previous patch neglected the fact that the multiplier needs to be
 a multiple of 4 to ensure that all the residues are 3 mod 4.

 Updated fix below (just double the multiplier).

 --
 Viktor.

 diff --git a/crypto/bn/bn_prime.c b/crypto/bn/bn_prime.c
 index 2d66b61..e74a98f 100644
 --- a/crypto/bn/bn_prime.c
 +++ b/crypto/bn/bn_prime.c
 @@ -132,48 +132,32 @@ static int probable_prime(BIGNUM *rnd, int bits);
  static int probable_prime_dh_safe(BIGNUM *rnd, int bits,
 const BIGNUM *add, const BIGNUM *rem, BN_CTX *ctx);

 -static const int prime_offsets[480] = {
 -   13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 
 83,
 -   89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 
 163,
 -   167, 169, 173, 179, 181, 191, 193, 197, 199, 211, 221, 223, 227, 229,
 -   233, 239, 241, 247, 251, 257, 263, 269, 271, 277, 281, 283, 289, 293,
 -   299, 307, 311, 313, 317, 323, 331, 337, 347, 349, 353, 359, 361, 367,
 -   373, 377, 379, 383, 389, 391, 397, 401, 403, 409, 419, 421, 431, 433,
 -   437, 439, 443, 449, 457, 461, 463, 467, 479, 481, 487, 491, 493, 499,
 -   503, 509, 521, 523, 527, 529, 533, 541, 547, 551, 557, 559, 563, 569,
 -   571, 577, 587, 589, 593, 599, 601, 607, 611, 613, 617, 619, 629, 631,
 -   641, 643, 647, 653, 659, 661, 667, 673, 677, 683, 689, 691, 697, 701,
 -   703, 709, 713, 719, 727, 731, 733, 739, 743, 751, 757, 761, 767, 769,
 -   773, 779, 787, 793, 797, 799, 809, 811, 817, 821, 823, 827, 829, 839,
 -   841, 851, 853, 857, 859, 863, 871, 877, 881, 883, 887, 893, 899, 901,
 -   907, 911, 919, 923, 929, 937, 941, 943, 947, 949, 953, 961, 967, 971,
 -   977, 983, 989, 991, 997, 1003, 1007, 1009, 1013, 1019, 1021, 1027, 
 1031,
 -   1033, 1037, 1039, 1049, 1051, 1061, 1063, 1069, 1073, 1079, 1081, 
 1087,
 -   1091, 1093, 1097, 1103, 1109, 1117, 1121, 1123, 1129, 1139, 1147, 
 1151,
 -   1153, 1157, 1159, 1163, 1171, 1181, 1187, 1189, 1193, 1201, 1207, 
 1213,
 -   1217, 1219, 1223, 1229, 1231, 1237, 1241, 1247, 1249, 1259, 1261, 
 1271,
 -   1273, 1277, 1279, 1283, 1289, 1291, 1297, 1301, 1303, 1307, 1313, 
 1319,
 -   1321, 1327, 1333, 1339, 1343, 1349, 1357, 1361, 1363, 1367, 1369, 
 1373,
 -   1381, 1387, 1391, 1399, 1403, 1409, 1411, 1417, 1423, 1427, 1429, 
 1433,
 -   1439, 1447, 1451, 1453, 1457, 1459, 1469, 1471, 1481, 1483, 1487, 
 1489,
 -   1493, 1499, 1501, 1511, 1513, 1517, 1523, 1531, 1537, 1541, 1543, 
 1549,
 -   1553, 1559, 1567, 1571, 1577, 1579, 1583, 1591, 1597, 1601, 1607, 
 1609,
 -   1613, 1619, 1621, 1627, 1633, 1637, 1643, 1649, 1651, 1657, 1663, 
 1667,
 -   1669, 1679, 1681, 1691, 1693, 1697, 1699, 1703, 1709, 1711, 1717, 
 1721,
 -   1723, 1733, 1739, 1741, 1747, 1751, 1753, 1759, 1763, 1769, 1777, 
 1781,
 -   1783, 1787, 1789, 1801, 1807, 1811, 1817, 1819, 1823, 1829, 1831, 
 1843,
 -   1847, 1849, 1853, 1861, 1867, 1871, 1873, 1877, 1879, 1889, 1891, 
 1901,
 -   1907, 1909, 1913, 1919, 1921, 1927, 1931, 1933, 1937, 1943, 1949, 
 1951,
 -   1957, 1961, 1963, 1973, 1979, 1987, 1993, 1997, 1999, 2003, 2011, 
 2017,
 -   2021, 2027, 2029, 2033, 2039, 2041, 2047, 2053, 2059, 2063, 2069, 
 2071,
 -   2077, 2081, 2083, 2087, 2089, 2099, 2111, 2113, 2117, 2119, 2129, 
 2131,
 -   2137, 2141, 2143, 2147, 2153, 2159, 2161, 2171, 2173, 2179, 2183, 
 2197,
 -   2201, 2203, 2207, 2209, 2213, 2221, 2227, 2231, 2237, 2239, 2243, 
 2249,
 -   2251, 2257, 2263, 2267, 2269, 2273, 2279, 2281, 2287, 2291, 2293, 
 2297,
 -   2309, 2311 };
 -static const int prime_offset_count = 480;
 -static const int prime_multiplier = 2310;
 -static const int prime_multiplier_bits = 11; /* 2^|prime_multiplier_bits|
 +/*
 + * Residues $r$ modulo $4620 = 4 \cdot 3 \cdot 5 \cdot 7 \cdot 11$ for which
 + * both $r$ and $r-1$ are co-prime to $2310$.
 + */
 +static const int prime_offsets[134] = {
 + 47,59,83,   107,   167,   179,   227,   263,
 +299,   347,   359,   383,   443,   467,   479,   503,
 +527,   563,   587,   599,   647,   719,   767,   779,
 +839,   863,   887,   899,   923,   983,  1007,  1019,
 +   1103,  1139,  1187,  1223,  1259,  1283,  1307,  1319,
 +   1367,  1403,  1427,  1439,  1487,  1523,  1559,  1619,
 +   1643,  1679,  1703,  1763,  1787,  1823,  1847,  1907,
 +   1943,  1979,  2027,  2039,  2063,  2099,  2147,  2159,
 +   2183,  2207,  2243,  2279,  2327,  2363,  2447,  2459,
 +   2483,  2543,  2567,  2579,  2603,  2627,  2687,  

Re: [PATCH] 1.0.1h does not build nor test HEARBEAT bug on OpenVMS

[Ben Laurie]

On 6 June 2014 22:21, Zoltan Arpadffy z...@polarhome.com wrote:
 Hi,

 after some testing the new release I realized that 1.0.1h does not build nor 
 run HEARBEAT bug unit test on OpenVMS.
 The following patch corrects the problem.

Best as a pull request on github.


 Thanks,
 Z


 -

 SYSTEM@ia64$ mc DKA0:[UTIL]gdiff.exe -p 
 DKA0:[WORK.openssl-101h.test]maketests.com;1 
 DKA0:[WORK.openssl-101h.test]maketests.com;2
 *** dka0:[work.openssl-101h.test]maketests.com;1Thu Jun  5 10:44:33 
 2014
 --- dka0:[work.openssl-101h.test]maketests.com;2Fri Jun  6 21:23:03 
 2014
 *** $!   A-Com Computing, Inc.
 *** 6,11 
 --- 6,12 
   $!   b...@mail.all-net.net
   $!
   $!  Changes by Richard Levitte rich...@levitte.org
 + $! Zoltan Arpadffy arpad...@polarhome.com
   $!
   $!  This command files compiles and creates all the various different
   $!  test programs for the different types of encryption for OpenSSL.
 *** $ TEST_FILES = BNTEST,ECTEST,ECDSATEST,
 *** 147,153 
RANDTEST,DHTEST,ENGINETEST,+ -
BFTEST,CASTTEST,SSLTEST,EXPTEST,DSATEST,RSA_TEST,+ -
EVP_TEST,IGETEST,JPAKETEST,SRPTEST,+ -
 !  ASN1TEST
   $! Should we add MTTEST,PQ_TEST,LH_TEST,DIVTEST,TABTEST as well?
   $!
   $! Additional directory information.
 --- 148,154 
RANDTEST,DHTEST,ENGINETEST,+ -
BFTEST,CASTTEST,SSLTEST,EXPTEST,DSATEST,RSA_TEST,+ -
EVP_TEST,IGETEST,JPAKETEST,SRPTEST,+ -
 !  ASN1TEST,HEARTBEAT_TEST
   $! Should we add MTTEST,PQ_TEST,LH_TEST,DIVTEST,TABTEST as well?
   $!
   $! Additional directory information.
 *** $ T_D_IGETEST:= [-.test]
 *** 185,190 
 --- 186,192 
   $ T_D_JPAKETEST  := [-.crypto.jpake]
   $ T_D_SRPTEST:= [-.crypto.srp]
   $ T_D_ASN1TEST   := [-.test]
 + $ T_D_HEARTBEAT_TEST := [-.test]
   $!
   $ TCPIP_PROGRAMS = ,,
   $ IF COMPILER .EQS. VAXC THEN -
 SYSTEM@ia64$ mc DKA0:[UTIL]gdiff.exe -p 
 DKA0:[WORK.openssl-101h.test]tests.com;1 
 DKA0:[WORK.openssl-101h.test]tests.com;4
 *** dka0:[work.openssl-101h.test]tests.com;1Thu Jun  5 10:44:33 2014
 --- dka0:[work.openssl-101h.test]tests.com;4Fri Jun  6 22:07:23 2014
 *** $   tests := -
 *** 56,62 
 test_enc,test_x509,test_rsa,test_crl,test_sid,-
 test_gen,test_req,test_pkcs7,test_verify,test_dh,test_dsa,-
 test_ss,test_ca,test_engine,test_evp,test_ssl,test_tsa,test_ige,-
 !   test_jpake,test_srp,test_cms
   $ endif
   $ tests = f$edit(tests,COLLAPSE)
   $
 --- 56,62 
 test_enc,test_x509,test_rsa,test_crl,test_sid,-
 test_gen,test_req,test_pkcs7,test_verify,test_dh,test_dsa,-
 test_ss,test_ca,test_engine,test_evp,test_ssl,test_tsa,test_ige,-
 !   test_jpake,test_srp,test_heartbeat,test_cms
   $ endif
   $ tests = f$edit(tests,COLLAPSE)
   $
 *** $   IGETEST :=  igetest
 *** 95,100 
 --- 95,101 
   $ JPAKETEST :=jpaketest
   $ SRPTEST :=  srptest
   $ ASN1TEST := asn1test
 + $   HEARTBEATTEST := heartbeat_test
   $!
   $ tests_i = 0
   $ loop_tests:
 *** $ test_srp:
 *** 366,371 
 --- 367,376 
   $ write sys$output Test SRP
   $ mcr 'texe_dir''srptest'
   $ return
 + $ test_heartbeat:
 + $   write sys$output Test HEARTBEAT
 + $   mcr 'texe_dir''heartbeattest'
 + $   return
   $
   $
   $ exit:

 __
 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: Crash in openSSL 1.0.1g

[Ben Laurie]

You should be using 1.0.1h.

Also, not familiar with MacOS X heap checking, but it looks like heap
corruption, which may or may not be OpenSSL's fault. Probably hard to
diagnose without a test case!

On 10 June 2014 07:25, Navneet Kumar (navneeku) navne...@cisco.com wrote:
 Update : Crashes are seen only on MAC OS X and not seen on windows.

 Thanks  Regards,
 -NK


 From: Cisco Employee navne...@cisco.com
 Reply-To: openssl-dev@openssl.org openssl-dev@openssl.org
 Date: Tuesday, 10 June 2014 11:20 AM
 To: openssl-dev@openssl.org openssl-dev@openssl.org
 Subject: Crash in openSSL 1.0.1g

 Hello Team,
 We have recently done the upgrade to openSSL version 1.0.1g and facing many
 crashes in below code path. Crashes are seen consistently.
 Any pointer on what went wrong will be really helpful. Thanks for your time
 !!

 ==Crash stack trace=

 (lldb) bt

 * thread #30: tid = 0x6fdcc, 0x97f34a6a
 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT

 frame #0: 0x97f34a6a libsystem_kernel.dylib`__pthread_kill + 10

 frame #1: 0x911a2b2f libsystem_c.dylib`pthread_kill + 101

 frame #2: 0x911d95f3 libsystem_c.dylib`__abort + 199

 frame #3: 0x911d952c libsystem_c.dylib`abort + 232

 frame #4: 0x911c3227 libsystem_c.dylib`szone_error + 443

 frame #5: 0x911c4482 libsystem_c.dylib`free_list_checksum_botch + 50

 frame #6: 0x911c7a43 libsystem_c.dylib`tiny_malloc_from_free_list + 458

 frame #7: 0x911c811a libsystem_c.dylib`szone_malloc_should_clear + 880

 frame #8: 0x911bda9e libsystem_c.dylib`szone_malloc + 24

 frame #9: 0x911bb5ab libsystem_c.dylib`malloc_zone_malloc + 75

 frame #10: 0x911bbfe7 libsystem_c.dylib`malloc + 53

 frame #11: 0x0026100d libxxcrypto.dylib`default_malloc_ex + 45

 frame #12: 0x0026190f libxxcrypto.dylib`CRYPTO_malloc + 175

 frame #13: 0x002766e0 libxxcrypto.dylib`pkey_hmac_init + 48

 frame #14: 0x002f4159 libxxcrypto.dylib`int_ctx_new + 601

 frame #15: 0x002f460c libxxcrypto.dylib`EVP_PKEY_CTX_new_id + 44

 frame #16: 0x002f66cf libxxcrypto.dylib`EVP_PKEY_new_mac_key + 63

 frame #17: 0x004a3b07 libxxssl.dylib`tls1_P_hash + 423

 frame #18: 0x004a42d2 libxxssl.dylib`tls1_PRF + 770

 frame #19: 0x004a6119 libxxssl.dylib`tls1_final_finish_mac + 633

 frame #20: 0x00496fea libxxssl.dylib`ssl3_do_change_cipher_spec + 394

 frame #21: 0x00496b23 libxxssl.dylib`ssl3_read_bytes + 3347

 frame #22: 0x0049829e libxxssl.dylib`ssl3_get_message + 334

 frame #23: 0x0049795a libxxssl.dylib`ssl3_get_finished + 90

 frame #24: 0x0048700f libxxssl.dylib`ssl3_connect + 3103

 frame #25: 0x004b8463 libxxssl.dylib`SSL_connect + 51

 frame #26: 0x00031bcf
 x`boost::asio::ssl::detail::engine::do_connect(this=0xb12c8a54,
 =0x, =0) + 19 at engine.ipp:272

 frame #27: 0x000bee79
 x`boost::asio::ssl::detail::engine::perform(this=unavailable,
 data=unavailable, length=unavailable, ec=unavailable,
 bytes_transferred=unavailable, op=unavailable)(void*, unsigned long),
 void*, unsigned long, boost::system::error_code, unsigned long*) + 73 at
 engine.ipp:215

 =End ==

 Thanks  Regards,
 -NK

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3375] Patch: Off-by-one errors in ssl_cipher_get_evp()

[Ben Laurie]

On 12 June 2014 23:15, Matt Caswell m...@openssl.org wrote:


 On 12/06/14 22:43, Otto Moerbeek wrote:
 On Thu, Jun 12, 2014 at 10:26:56PM +0200, Matt Caswell via RT wrote:

 Patch applied:
 https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=abfb989fe0b749ad61f1aa4cdb0ea4f952fc13e0

 Many thanks for your contribution.

 Matt

 http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ssl_ciph.c.diff?r1=1.38;r2=1.39

 Again no attribution in problem report and commit. Claiming
 independent discovery is not going to be credible.

 The commit *is* attributed. The author is listed as Kurt Cancemi - this
 is as it is attributed in the patch supplied in the problem report.

I presume he meant in the OpenBSD repo...

Kurt does not appear to be attributed there:
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ssl_ciph.c?rev=1.39.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Makedepend bug?

[Ben Laurie]

I've been trying to figure out why my make depend differs from other
developers, and why it appears to be wrong.

For example, apps/dsa.o depends, according to makedepend, on dh.o, but
with the standard developer flags ($gcc_devteam_warn) it should not.

AFAICS, makedepend gets passed the right flags, and normally processes
#ifndef lines correctly.

Anyone got any clues what's going on? (I'm on FreeBSD 9.1)
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Very old release, unsupported platform

[Ben Laurie]

On 1 July 2014 06:52, Zoltan Arpadffy z...@polarhome.com wrote:
 Hi,

 I see that Rich is doing a fantastic job by cleaning up the backlog...
 I absolutely agree that very old releases cannot be supported, but what about 
 the platforms?

 I thought until now, that as long there are developers who are willing to 
 develop for a certain platform and there is some community interest in using 
 that - the platform will be supported as odd might it be in the Windows and 
 Linux dominated World.

 I just started to wonder, will soon come the time when my patches will be 
 also refused with the unsupported platform comment?

Our soon-to-be-released roadmap has this to say on supported platform:

* Currency, i.e. a platform is widely deployed and in current use
* Vendor support
* Available to the dev team, i.e. the dev team have access to a
suitable environment in which to test builds and deal with tickets and
issues
* Dev team ownership, i.e. at least one person on the team is willing
to take some responsibility for a platform
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Reward for proactive security improvements

[Ben Laurie]

In case people haven't noticed, Google has announced a reward program
for this (last year, in fact):

https://www.google.com/about/appsecurity/patch-rewards/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Makedepend bug?

[Ben Laurie]

On 1 July 2014 17:21, Mike Bland mbl...@acm.org wrote:
 Ah! Sorry for the spam, but I think I got it. According to the
 makedepend man page:

 http://www.x.org/archive/current/doc/man/man1/makedepend.1.xhtml

 Makedepend makes assumptions about the #includes for files appearing
 later on the command line:

 But when the program parses file2.c and discovers that it, too,
 includes header.h, it does not parse the file, but simply adds
 header.h, def1.h anddef2.h to the list of dependencies for file2.o.

 Long story short, I narrowed it down to apps/req.c and apps/gendh.c
 both #ifdef/undeffing OPENSSL_NO_DEPRECATED. Execute the command with
 those two files removed, and dh.h disappears from dsa.o's deps.

 dsaparam.c, genrsa.c, and s_server.c also have this #undef, but coming
 later on the command line than dsa.c, they don't trigger makedepend to
 generate the dh.h include for dsa.o. Put them before dsa.c, and they
 do.

Aha! Well done.

I suspect there's not really any reason to support makedepend anymore
- should perhaps just switch to always using gcc/clang for
dependencies?


 Mike


 On Tue, Jul 1, 2014 at 11:59 AM, Mike Bland mbl...@acm.org wrote:
 Whoops, of course, I meant it generates the same output for dsa.o, and
 only dsa.o.

 Mike

 On Tue, Jul 1, 2014 at 11:58 AM, Mike Bland mbl...@acm.org wrote:
 Investigating... It seems to be an issue with the makedepend tool itself.

 I hacked util/domd to show the makedepend command line, and got this
 command for apps/:

 makedepend -D OPENSSL_DOING_MAKEDEPEND -- -O -I..  -I../include
 -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128
 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5
 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE
 -DOPENSSL_NO_STORE -- openssl.c verify.c asn1pars.c req.c dgst.c dh.c
 enc.c passwd.c gendh.c errstr.c ca.c pkcs7.c crl2p7.c crl.c rsa.c
 rsautl.c dsa.c dsaparam.c ec.c ecparam.c x509.c genrsa.c gendsa.c
 genpkey.c s_server.c s_client.c speed.c s_time.c apps.c s_cb.c
 s_socket.c app_rand.c version.c sess_id.c ciphers.c nseq.c pkcs12.c
 pkcs8.c pkey.c pkeyparam.c pkeyutl.c spkac.c smime.c cms.c rand.c
 engine.c ocsp.c prime.c ts.c srp.c

 Running that through util/clean-depend.pl produces the existing
 makedepend output. But just running this:

 makedepend -D OPENSSL_DOING_MAKEDEPEND -- -O -I..  -I../include
 -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128
 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5
 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE
 -DOPENSSL_NO_STORE -- dsa.c

 Produces the same output except *without* ../include/openssl/dh.h. (I
 presume you meant dh.h, not dh.o earlier.)

 Of course, with your GitConfigure/GitMake scripts, you're using the
 compiler to regenerate dsa.d in isolation from other files.

 I'll see if I can dig up a little more info here...but it does seem
 that your normal flags are doing the right thing.

 Mike



 On Tue, Jul 1, 2014 at 5:38 AM, Ben Laurie b...@links.org wrote:
 I've been trying to figure out why my make depend differs from other
 developers, and why it appears to be wrong.

 For example, apps/dsa.o depends, according to makedepend, on dh.o, but
 with the standard developer flags ($gcc_devteam_warn) it should not.

 AFAICS, makedepend gets passed the right flags, and normally processes
 #ifndef lines correctly.

 Anyone got any clues what's going on? (I'm on FreeBSD 9.1)
 __
 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
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Makedepend bug?

[Ben Laurie]

On 1 July 2014 18:34, Tim Rice t...@multitalents.net wrote:
 On Tue, 1 Jul 2014, Ben Laurie wrote:

 Aha! Well done.

 I suspect there's not really any reason to support makedepend anymore
 - should perhaps just switch to always using gcc/clang for
 dependencies?

 So now gcc/clang is required to build OpenSSL?

As noted, makedepend doesn't actually do dependencies right - so, a
tool that does dependencies correctly is required...


 --
 Tim RiceMultitalents
 t...@multitalents.net


 __
 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: Makedepend bug?

[Ben Laurie]

On 1 July 2014 19:15, Salz, Rich rs...@akamai.com wrote:
 I was wondering why 'make depend' output was saved in the Makefiles.

 Because way back when (think like early X and xmkmf) that's the way things 
 were done.

 So I guess adding the .d files to the repository and using include statements
 in the Makefiles is a reasonable possibility? (That's the angle I'm taking 
 with
 my experiment, though I hadn't thought to add the .d's to the repo.)

 Oh gaak, I hope we don't add the .d files and I hope also that there is only 
 one per directory.  But all that's open.

Really? Its much more efficient to update the .d files when you
compile the (changed) source - which more-or-less implies one per
source file.


 /r$

 --
 Principal Security Engineer
 Akamai Technologies, Cambridge, MA
 IM: rs...@jabber.me; Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3277] OpenSSL s_client doc missing option

[Ben Laurie]

On 2 July 2014 23:17, Rich Salz via RT r...@openssl.org wrote:
 Fixed, added -servername to the pod file.

Looks to me like you've only fixed this (and many others) in master -
surely should also go to 1.0.2 at least (and probably older branches,
too)?

Also, we generally rebase rather than merge...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3277] OpenSSL s_client doc missing option

[Ben Laurie]

On 3 July 2014 12:04, Salz, Rich rs...@akamai.com wrote:
 Looks to me like you've only fixed this (and many others) in master - surely
 should also go to 1.0.2 at least (and probably older branches, too)?

 Okay, tell me which branches.

Since this is a bug, all active branches (that it applies to - not
sure if this option exists in all branches).

 Also, we generally rebase rather than merge...

 I don't know the difference.  But okay, if that's the practice, I'll figure 
 it out.  Everything I've seen said the git model is branch/merge, so I just 
 used the obvious command. :)

Rebasing replays your work on top of the current head of branch.
There's been a lot of debate, but it seems the team prefer rebasing to
merging because merging makes diffing/binary chopping harder.

We should write this up somewhere, because rebase + merge also makes
sense when you're importing someone else's patches (otherwise you tend
to lose who did the import).
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3277] OpenSSL s_client doc missing option

[Ben Laurie]

On 3 July 2014 12:21, Salz, Rich rs...@akamai.com wrote:
 Thanks for the explanation.

 Which are the currently active branches?

OpenSSL_0_9_8-stable
OpenSSL_1_0_0-stable
OpenSSL_1_0_1-stable
OpenSSL_1_0_2-stable
master


 --
 Principal Security Engineer
 Akamai Technologies, Cambridge, MA
 IM: rs...@jabber.me; Twitter: RichSalz


 -Original Message-
 From: owner-openssl-...@openssl.org [mailto:owner-openssl-
 d...@openssl.org] On Behalf Of Ben Laurie
 Sent: Thursday, July 03, 2014 7:15 AM
 To: OpenSSL development
 Cc: Jeffrey Walton
 Subject: Re: [openssl.org #3277] OpenSSL s_client doc missing option

 On 3 July 2014 12:04, Salz, Rich rs...@akamai.com wrote:
  Looks to me like you've only fixed this (and many others) in master -
  surely should also go to 1.0.2 at least (and probably older branches, 
  too)?
 
  Okay, tell me which branches.

 Since this is a bug, all active branches (that it applies to - not sure if 
 this option
 exists in all branches).

  Also, we generally rebase rather than merge...
 
  I don't know the difference.  But okay, if that's the practice, I'll
  figure it out.  Everything I've seen said the git model is
  branch/merge, so I just used the obvious command. :)

 Rebasing replays your work on top of the current head of branch.
 There's been a lot of debate, but it seems the team prefer rebasing to
 merging because merging makes diffing/binary chopping harder.

 We should write this up somewhere, because rebase + merge also makes
 sense when you're importing someone else's patches (otherwise you tend
 to lose who did the import).
 __
 
 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: OpenSSL roadmap

[Ben Laurie]

On 3 July 2014 14:13, Theodore Ts'o ty...@mit.edu wrote:
 However, in the kernel we are much more lax about who gets access to
 the Coverity project.  Part of this is the sure and certain knowledge
 that the bad guys are quite willing to pay for a Coverity license, and
 so for us the balance of increasing the pool of those can who are
 looking through the Coverity scans, and contribute to fix bugs, and
 thus grow the development community, tips in favor of being more open
 about who gets access to Coverity.

Right, I agree, but clearly there isn't unanimity amongst the dev
team. I think we'd be a bit more relaxed if we were actually on top of
Coverity, which I would hope would happen soon, now we have full-time
developer(s).
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL roadmap

[Ben Laurie]

On 3 July 2014 15:28, Salz, Rich rs...@akamai.com wrote:
 release processes at various distributions.  (Given that Microsoft has weekly
 patch Tuesdays, if even slow moving *Microsoft* can turn around a
 security update in a week, what's your excuse?  :-)

 They have a regular release train, but it doesn't mean that everything gets 
 fixed in one week.  Sorry to stomp your punchline.

3 months to a year is more usual. :-)
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Google Patch rewards updated to include refactoring

[Ben Laurie]

https://www.google.com/about/appsecurity/patch-rewards/

Refactorings that make it easier to reason about the security
properties of the code.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

[Ben Laurie]

On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
 On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
 I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
 and 96, or ?:

 The line before that:

 dp=d;
 l2c(v0,dp);--- Uninitialized variable: d
 l2c(v1,dp);--- Uninitialized variable: d
 while (l--)
 {
 if (n == 0)
 {
 DES_encrypt1(ti,schedule,DES_ENCRYPT);
 dp=d;
 t=ti[0]; l2c(t,dp);
 t=ti[1]; l2c(t,dp);
 save++;
 }
 *(out++)= *(in++)^d[n];--- Uninitialized variable: d
 n=(n+1)0x07;
 }

 d is uninitialized, but it's being written to, not read from,
 so I don't see a problem with this.

What?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

[Ben Laurie]

On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote:
 On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
 On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
  On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
  I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
  and 96, or ?:
 
  The line before that:
 
  dp=d;
  l2c(v0,dp);--- Uninitialized variable: d
  l2c(v1,dp);--- Uninitialized variable: d
  while (l--)
  {
  if (n == 0)
  {
  DES_encrypt1(ti,schedule,DES_ENCRYPT);
  dp=d;
  t=ti[0]; l2c(t,dp);
  t=ti[1]; l2c(t,dp);
  save++;
  }
  *(out++)= *(in++)^d[n];--- Uninitialized variable: d
  n=(n+1)0x07;
  }
 
  d is uninitialized, but it's being written to, not read from,
  so I don't see a problem with this.

 What?

 So l2c is:
 #define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
  *((c)++)=(unsigned char)(((l) 8L)0xff), \
  *((c)++)=(unsigned char)(((l)16L)0xff), \
  *((c)++)=(unsigned char)(((l)24L)0xff))

 It reads v0 and v1 and writes to d (dp).  d being uninitialized
 shouldn't be an issue.  Or am I missing something?

It writes to *d, surely? Which means d uninitialised is very much an issue, no?

However, now I've read the code (it'd help if people posted enough
snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
array, so the diagnosis is basically incorrect. And therefore I agree
with you, not a problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

[Ben Laurie]

It'd be nice, btw, if someone would report the bug to cppcheck.

On 4 July 2014 10:15, Ben Laurie b...@links.org wrote:
 On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote:
 On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
 On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
  On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
  I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
  and 96, or ?:
 
  The line before that:
 
  dp=d;
  l2c(v0,dp);--- Uninitialized variable: d
  l2c(v1,dp);--- Uninitialized variable: d
  while (l--)
  {
  if (n == 0)
  {
  DES_encrypt1(ti,schedule,DES_ENCRYPT);
  dp=d;
  t=ti[0]; l2c(t,dp);
  t=ti[1]; l2c(t,dp);
  save++;
  }
  *(out++)= *(in++)^d[n];--- Uninitialized variable: d
  n=(n+1)0x07;
  }
 
  d is uninitialized, but it's being written to, not read from,
  so I don't see a problem with this.

 What?

 So l2c is:
 #define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
  *((c)++)=(unsigned char)(((l) 8L)0xff), \
  *((c)++)=(unsigned char)(((l)16L)0xff), \
  *((c)++)=(unsigned char)(((l)24L)0xff))

 It reads v0 and v1 and writes to d (dp).  d being uninitialized
 shouldn't be an issue.  Or am I missing something?

 It writes to *d, surely? Which means d uninitialised is very much an issue, 
 no?

 However, now I've read the code (it'd help if people posted enough
 snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
 array, so the diagnosis is basically incorrect. And therefore I agree
 with you, not a problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Preventing the next Heartbleed

[Ben Laurie]

Interesting paper by David Wheeler:
http://www.dwheeler.com/essays/heartbleed.html.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

[Ben Laurie]

On 4 July 2014 15:20, Toralf Förster toralf.foers...@gmx.de wrote:
 On 07/04/2014 11:17 AM, Ben Laurie wrote:
 It'd be nice, btw, if someone would report the bug to cppcheck.
 http://5.150.254.56:443/trac-cppcheck/ticket/5970#ticket

Thanks.


 Thx

 On 4 July 2014 10:15, Ben Laurie b...@links.org wrote:
 On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote:
 On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
 On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
 On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
 I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
 and 96, or ?:

 The line before that:

 dp=d;
 l2c(v0,dp);--- Uninitialized variable: d
 l2c(v1,dp);--- Uninitialized variable: d
 while (l--)
 {
 if (n == 0)
 {
 DES_encrypt1(ti,schedule,DES_ENCRYPT);
 dp=d;
 t=ti[0]; l2c(t,dp);
 t=ti[1]; l2c(t,dp);
 save++;
 }
 *(out++)= *(in++)^d[n];--- Uninitialized variable: d
 n=(n+1)0x07;
 }

 d is uninitialized, but it's being written to, not read from,
 so I don't see a problem with this.

 What?

 So l2c is:
 #define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
  *((c)++)=(unsigned char)(((l) 8L)0xff), \
  *((c)++)=(unsigned char)(((l)16L)0xff), \
  *((c)++)=(unsigned char)(((l)24L)0xff))

 It reads v0 and v1 and writes to d (dp).  d being uninitialized
 shouldn't be an issue.  Or am I missing something?

 It writes to *d, surely? Which means d uninitialised is very much an issue, 
 no?

 However, now I've read the code (it'd help if people posted enough
 snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
 array, so the diagnosis is basically incorrect. And therefore I agree
 with you, not a problem.



 --
 Toralf

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

*_ctrl() functions

[Ben Laurie]

I've been experimenting with more type correctness and less casting.

Some of the big casting culprits are the various _ctrl() functions,
e.g. SSL_ctrl().

Does anyone have any clue why these exist?

Is there any reason to not replace them with direct function calls
(other than API stability)?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3436] Platform strategy

[Ben Laurie]

On 5 July 2014 18:46, Zoltan Arpadffy z...@polarhome.com wrote:
 Hi,

 I absolutely agree, that other less popular platforms need support.

 Unfortunately, reading the conversation in the last few days, I got a
 feeling that the OpenSSL core development is not willing to support those
 platforms in the main line, but will come up with a separate branch or other
 merging strategy keeping the core code clean.

I don't think that's the plan at all - but if no-one cares enough
about them to make sure we can actually test and fix them on those
platforms, _then_ we'll almost certainly drop support. I am not
promising that we'll support any random platform that we can test and
fix on, but that's surely a minimum requirement.

And if someone out there is prepared to do the fixing for us, even better.

 Whatever this solution will be - I silently accept this decision - moreover
 understand the reasoning behind too.
 ...but can not let the less popular platforms decline, therefore I decided
 to set up Jenkins builds on polarhome.com's 30+ rare operating systems and
 run daily builds and tests feeding the core team with propper test data and
 eventually bugs from those environments right after a change occured in the
 main code.

 This CI approach will improve the code quality generaly and reduce the gap
 between the less supported platforms code and the main code.

+1.


 polarhome has AIX, HP-UX, OpenVMS, QNX Ultrix, IRIX and many other platforms
 and architectures that would be of interest.

 The service will be soon publicly available.

 Regards,
 Z



 Quoting hmbrand via RT r...@openssl.org:

 In the new roadmap I read on platform strategy:
 --8---
 Platform Strategy

 Moving forward OpenSSL will adopt the following policy:

 • There will be a defined set of primary platforms. The primary
 platforms will be Linux and FreeBSD. A primary platform is one where
 most development occurs.

 • In addition there will be a list of secondary platforms which are
 supported by the development team.

 • Platform specific code will be moved out of the main codebase
 (removing overuse of ifdef).

 • Legacy platforms that are unlikely to have wide deployment will be
 removed from the code.

 • Non-supported platforms requiring regular maintenance activities will
 eventually be removed from the code after first seeking community owners
 to support the platforms in platform specific repositories.

 Necessary criteria for a platform to be included in the secondary
 platform list includes:

 • Currency, i.e. a platform is widely deployed and in current use

 • Vendor support

 • Available to the dev team, i.e. the dev team have access to a suitable
 environment in which to test builds and deal with tickets and issues

 • Dev team ownership, i.e. at least one person on the team is willing to
 take some responsibility for a platform

 In addition the secondary list will be as small as possible so as not to
 spread the development team too thinly.

 The secondary platforms are still to be defined but will be based on the
 above criteria. For each primary/secondary platform, we should have, at
 least, a continuous integration box and a dev machine we can access for
 test/debug. We will seek support from the platform vendors or the
 community to provide access to these platforms. The secondary platform
 list will change over time, but an initial list will be produced within
 three months.

 The Platform Strategy will be phased in over a period of time based on
 how quickly we can refactor the code.
 --8---

 I think it is highly thinkable that the dev-team does not have access to
 proprietary OS's like HP-UX or AIX. Personally I give a shit about AIX,
 but I value HP-UX a lot and I might be the only one left still releasing
 software-depots (what HP uses for binary distributions) for a lot of
 OpenSource products for HP-UX back to 10.20, long dead and gone
 according to HP itself.

 Looking at the download-statistics, it is still used quite a lot
 worldwide. Who am I to judge that. I just have access to development
 boxes for HP-UX 10.20, 11.00, 11.11 (11iv1), 11.23 (11iv2 PA2), 11.23
 (11iv2 ia64) and 11.31 (11iv3 ia64 and as I have a warm heart for
 OpenSourse, with perl5 especially, I will try to continue to release
 modern recent packages of heavily used OpenSource software for thes
 OS's. OpenSSL is one of those (you can check that on
 http://mirrors.develooper.com/hpux/ )

 If you remove native code to support the OS versions the developers have
 no access to or do not care about, you will make it harder for the
 volunteers like me to post OpenSSL to those systems. We do this in our
 free time, as the big vendors do not support the OS releases they have
 declared end-of-life.

 This ticket is a plea to keep the code related to HP-UX in place or at
 least easily available: That might include *not* using libtool, as that
 was once created to make linking on other systems than Linux easier, but
 it only complicated things for those 

Re: BIO_get_accept_socket weirdness

[Ben Laurie]

On 5 July 2014 12:37, Kurt Roeckx k...@roeckx.be wrote:
 But then I found some MSDN documentation that says that Windows
 allows others to hijack your socket when you've set SO_REUSEADDR
 and the results are non-deterministic.  They also created an
 SO_EXCLUSIVEADDRUSE and I'm getting confused what it really does,
 but they say that server applications should set it.

If you think that opening the socket first is a security measure, then
you've got some pretty serious problems.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

JPAKE?

[Ben Laurie]

Does anyone use it?

We're considering removing or refactoring it...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Unit Testing/statically analysing OpenSSL

[Ben Laurie]

On 9 July 2014 14:38, Paul Morriss paul.morr...@tokenbay.co.uk wrote:
 I am keen to get more involved in the development of OpenSSL, I am curious,
 has the code been run through a static analysis tool (such as Coverity)?

Coverity do run OpenSSL through their tool. The false positive rate is
depressingly high (or was last I looked).

 There are self checks, are there unit tests (e.g. Google Test/Mock)created
 for any part of OpenSSL?

Some :-)

More would be good.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command

[Ben Laurie]

On 11 July 2014 11:56, Andy Polyakov ap...@openssl.org wrote:
 Bottom line [still] is that enc is not the place to perform XTS,
 *unless* it's treated specially. In other words question should not be
 about setting IV, but about *if* XTS should be supported by enc, and if
 so, how exactly.

 It seems to me this is why jamming modes like XTS into standard EVP as
 if they were like other modes is a less than great idea.

 But providing own interface for every specific mode is also hardly fun.
 I mean there ought to be balance. Now we have EVP that implies different
 semantic in different modes. In other words application might have to
 perform extra calls depending on mode (and in this particular case
 problem is that enc doesn't do those calls). What would be alternative?
 Distinct interface for every class of modes?

Yes.

 Can we define what makes up
 such class? What do we expect from interface? Also note that either way,
 the fact that it needs to be treated in enc in special way doesn't
 change. It's not like I'm rejecting alternatives to EVP, but discussion
 have to be more constructive.

Right, agree that there has to be support for it, whatever happens.
The problem with the current situation is that because the same
interface is used (sometimes in strange ways) for incompatible modes,
s/w can _think_ it is capable of doing, e.g., XTS, when in fact it is
not.

It doesn't seem helpful to give that appearance by re-using the API
when it isn't actually true.

That said, there's certainly something to be said for having a common
API for the common parts.

Perhaps the thing to do is to make it so when you create an XTS_EVP,
that has the extra stuff needed to support XTS, but you can also
extract from it an EVP (or whatever the common interface is) that can
be used for the common subset.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Default Security Level

[Ben Laurie]

On 16 August 2014 19:50, Dominyk Tiller dominyktil...@gmail.com wrote:
 Ah! That's where my confusion lies, I'm getting myself tied up between
 development  stable. Thanks for the clarity on that.

 Homebrew is currently on 1.0.1i stable. These are the ssl2 ciphers active:

 /usr/local/cellar/openssl/*/bin/openssl ciphers -ssl2
 IDEA-CBC-MD5:RC2-CBC-MD5:RC4-MD5:DES-CBC3-MD5:DES-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5

 Is that a security concern? Would there be any active consequences to
 turning off those remaining -ssl2 ciphers? I tested the change with
 pretty much every dependent formula that ships from Homebrew and
 didn't encounter any issues. Would we gain any appreciable security by
 knocking out those last few ssl2 ciphers?

Err, yes. Almost all of them are weak and some are _very_ weak.


 Cheers,

 Dom


 On 16 August 2014 18:05, Viktor Dukhovni openssl-us...@dukhovni.org wrote:

 On Sat, Aug 16, 2014 at 07:45:43AM +0100, Dominyk Tiller wrote:

  I'm pretty sure I read somewhere in the OpenSSL documentation that the
  recommended default level for compile is level 1, which kills the ssl2
  option, but effectively Homebrew has been building with level 0
  default thus far.

 SSLv2 is off by default (excluded by the DEFAULT cipherlist), even
 without disabling support for it at compile time.

 Security levels are only on the master development branch of OpenSSL,
 which has not been officially released.  Homebrew users should be
 using 1.0.1 or soon 1.0.2 after than is released.

 So security levels, whose design IMHO is not yet entirely done,
 should not be in the picture at this time.

  Did I completely hallucinate the documentation recommendation of
  default level 1 security or is that actually somewhere?

 You may be confusing the master branch with stable releases.

 --
 Viktor.
 __
 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: [openssl.org #2917] [PATCH] dsa: fix return code when -noout is used

[Ben Laurie]

On 17 August 2014 06:44, Rich Salz via RT r...@openssl.org wrote:
 This will be fixed in the post-1.0.2 release.

Why not fix in 1.0.2?

 Thanks. (rsalz-monolith branch on github, akamai/openssl)
 --
 Rich Salz, OpenSSL dev team; rs...@openssl.org

 __
 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

1.0.2 head doesn't build...

[Ben Laurie]

Workaround (I wasn't sure if the functions were intended to be used
somewhere, so not deleted yet):

diff --git a/crypto/constant_time_test.c b/crypto/constant_time_test.c
index 1b4b18d..78e7fca 100644
--- a/crypto/constant_time_test.c
+++ b/crypto/constant_time_test.c
@@ -195,7 +195,7 @@ static int test_select_int(int a, int b)
}
return 0;
}
-
+/*
 static int test_eq_int(int a, int b)
{
unsigned int equal = constant_time_eq_int(a, b);
@@ -235,7 +235,7 @@ static int test_eq_int_8(int a, int b)
}
return 0;
}
-
+*/
 static unsigned int test_values[] = {0, 1, 1024, 12345, 32000, UINT_MAX/2-1,
  UINT_MAX/2, UINT_MAX/2+1, UINT_MAX-1,
  UINT_MAX};
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

HOST_c2l warnings...

[Ben Laurie]

Building 1.0.2 with gcc 4.9 and no-asm, I get a lot of:

ADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-DL_ENDIAN -DTERMIOS -O3 -Wall -c sha256.c
In file included from sha256.c:115:0:
sha256.c: In function 'sha256_block_data_order':
../md32_common.h:248:41: warning: right-hand operand of comma
expression has no effect [-Wunused-value]
 l|=(((unsigned long)(*((c)++)))),  \
 ^
sha256.c:243:3: note: in expansion of macro 'HOST_c2l'
   HOST_c2l(data,l); T1 = X[0] = l;  ROUND_00_15(0,a,b,c,d,e,f,g,h);
   ^

I don't think anything actually uses the value of HOST_c2l, so we
could just drop the final comma and make the whole thing (void)?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] FreeBSD build broken?

[Ben Laurie]

On 8 June 2015 at 13:27, John Foley fol...@cisco.com wrote:

 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


makedepend is provided by the port devel/makedepend.



 ___
 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

[Ben Laurie]

On Sat, 22 Aug 2015 at 01:56 Salz, Rich 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?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Continuous Integration for OpenSSL

[Ben Laurie]

On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com wrote:


 On Sat, 22 Aug 2015 at 01:56 Salz, Rich 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

Re: [openssl-dev] Continuous Integration for OpenSSL

[Ben Laurie]

On Mon, 24 Aug 2015 at 09:53 Alessandro Ghedini alessan...@ghedini.me
wrote:

 On Sat, Aug 22, 2015 at 12:55:43am +, Salz, Rich 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.

 Does this mean that you are not oging to enable Travis CI? If anything this
 buildfarm didn't seem to catch the 25efcb44 build failure. Additionally
 Travis
 automatically builds pull requests submitted on GitHUb, in order to give
 immediate feedback to submitter and reviewer.

 So I think it still makes sense to have Travis alongside this Cisco
 buildfarm
 (as you said, the more the merrier), but if you don't agree then both #63
 and
 #373 pull requests can be closed (if anything, two less open PRs...).


I've just +1'ed #373 - if another OpenSSL dev will also do that, I'll push
it...
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] common factors in (p-1) and (q-1)

[Ben Laurie]

On Sat, 1 Aug 2015 at 14:22 mancha manc...@zoho.com wrote:

 On Fri, Jul 31, 2015 at 06:46:22PM +, Viktor Dukhovni wrote:
  On Fri, Jul 31, 2015 at 11:19:39AM -0700, Bill Cox wrote:
 
   Cool observation.  From running a bit of Python code, it looks like
   the probability that GCD(p-1, p-q) == 4 is a bit higher than 15%, at
   least for random numbers between 2048 and 4096 bits long.  It looks
   like putting in a GCD(p-1, q-1) check will slow down finding
   suitable p and q by around a factor of 6.5.
 
  A smaller slow-down would be incurred one were to restrict both of p,q
  to 3 mod 4. In that case 2 would be the largest common even factor of
  (p-1) and (q-1), and any appreciably large common odd factor
  (necessarily above 17863 due to how each of p/q is chosen) would be
  very rare.
 
  Is there a good argument for adding the gcd test?  How big does the
  common factor have to be for any information it might provide to be
  substantially useful in finding 1/e mod phi(m)?
 
  The larger the common factor is, the smaller the probability of p-1
  and q-1 sharing it (for a given sufficiently large prime factor r of
  (p-1), the probability of (q-1) also having that factor is 1/(r-1)).
  If say r needs be 80 bits long to be useful in attacking RSA 1024,
  then only ~1 in 2^80 (p-1,q-1) pairs will have such a common factor,
  which is sufficiently rare not warrant any attention.
 
  Also one still needs to be able to fully factor (n-1).  After tens of
  thousands of trials, I managed to generate a (p,q,n) triple with a
  1024-bit modulus n in which (p-1,q-1) have a common odd factor.
 
  n =
 
  
 123727085863382195696899362818055010267368591819174730632443285012648773223152448218495408371737254282531468855140111723936275062312943433684139231097953508685462994307654703316031424869371422426773001891452680576333954733056995016189880381373567072504551999849596021790801362257131899242011337424119163152403
 
  e = F_4 = 65537
 
  gcd(p-1,q-1) = 2 * 28559
 
  What can the OP tell us about d, p or q?  Can anyone produce a full
  factorization of n - 1?

 n-1 = 2 * 3^3 * 7 * 13 * 67 * 2399 * 28559 *

 5485062554686449262177590194597345407327047899375366044215091312099734701911004226037445837630559113651708968440813791318544450398897628672342337619064712331937685677843283385813601700381667290503026724160750373906990713551823941904482040860073543880341612964100618466865014941425056336718955019


That is not a prime factorisation.



 --
 https://twitter.com/mancha140
 ___
 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.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled

[Ben Laurie]

On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org wrote:

 This code does open-coded division on 64-bit quantities and thus when
 building with GCC on 32-bit platforms will require functions such as
 __umoddi3 and __udivdi3 from libgcc.

 In constrained environments such as firmware, those functions may not
 be available. So make it possible to compile out SCT support, which in
 fact (in the case of UEFI) we don't need anyway.


I am curious why you think you don't need CT for UEFI?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Ben Laurie]

On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT  wrote:

>
>
> On 15/10/15 20:53, Alexander Cherepanov via RT wrote:
> > On 2015-10-15 15:41, Matt Caswell via RT wrote:
> >> The purpose of the sanity check is not then for security, but to guard
> >> against programmer error. For a correctly functioning program this test
> >> should never fail. For an incorrectly functioning program it may do. It
> >> is not guaranteed to fail because the test could be compiled away but,
> >> most likely, it will. We can have some degree of confidence that the
> >> test works and does not get compiled away in most instances because, as
> >> you point out, an explicit check for it appears in packettest.c and, to
> >> date, we have had no reported failures.
> >
> > What was not entirely clear from the original bug report is that, while
> > the check is not compiled away, it's compiled into something completely
> > different from what is written in the source. Specifically, the check
> > "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e.
> > "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for
> > overflow at all, it doesn't even depend on the value of "buf".
> >
> > If this is what was intended then it's better to write it explicitly. If
> > this is not what was intended then some other approach is required.
>
> I'd say that is an instance of the compiler knowing better than us how
> big |len| would have to be in order to trigger an overflow. Those rules
> are going to be platform specific so we should not attempt to second
> guess them, but instead let the optimiser do its job.
>

If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff,
and len is 1, you get an overflow, which the optimised version does not
catch.

What I'm not understanding from this thread is what the argument is against
avoiding undefined behaviour?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Ben Laurie]

On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx via RT  wrote:

> On Fri, Oct 16, 2015 at 09:44:22PM +, Kaduk, Ben via RT wrote:
> > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote:
> > > On Fri, Oct 16, 2015 at 06:50:36PM +, Kurt Roeckx via RT wrote:
> > >> On Fri, Oct 16, 2015 at 04:50:59PM +, Matt Caswell via RT wrote:
> > >>> In a well-behaved program there is no undefined behaviour. The "buf +
> > >>> len < buf" check will always evaluate to false, so in that sense is
> > >>> useless but it *is* well defined.
> > >> The defined behaviour for the "buf + len" part is as far as I know
> > >> that you're that the pointer should point inside the allocated
> > >> object or 1 byte after it.  So as long as "len" is in the valid
> > >> range, the "buf + len" part should be well defined.  The test with
> > >> -1 is clearly undefined.
> > >>
> > >> As far as I know in the comparison pointers they should point
> > >> to the same object.  But the check seems to imply that they might
> > >> not point to the same object or that buf is not the base of the
> > >> object.  But since len is unsigned only the option that they don't
> > >> point to the same object seems to be left.
> > >>
> > >> So it's unclear to me if this is defined behaviour or not.
> > > So thinking about this some more, it seems to be a check for
> > > undefined behaviour that probably itself is still defined.
> > >
> > > That probably also means the compiler can assume that it's always
> > > false and eliminate the check, it's probably just not smart enough
> > > yet.
> > >
> >
> > I think it is unambiguous that there are values of unsigned char *buf
> > and size_t len for which evaluating (bug + len < buf) invokes undefined
> > behavior -- the sheer act of performing the addition buf + len can
> > produce undefined behavior, even before any comparison.  I am as-yet
> > uncertain whether the case when buf points into the middle of an object
> > and len is (size_t)-1 invokes undefined behavior, but I am inclined to
> > believe that it is also undefined behavior.
>
> Just to clarify what I mean, buf + len can both have defined and
> undefined meaning, it depends on the value of len, so the compiler
> can probably not say anything about that part without knowing all
> the callers of that code.  As long as it has a defined meaning the
> compiler will probably do it.  buf + len < buf also seems to have
> a defined meaning, but in all defined meanings it's false, and so
> the compiler can just optimize that part away.
>
> Anyway, I would really like this to be changed.
>

+1


>
>
> Kurt
>
>
> ___
> 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

[Ben Laurie]

On Mon, 24 Aug 2015 at 19:35 Matt Caswell m...@openssl.org wrote:

 On 24/08/2015 10:08, Ben Laurie wrote:
 
 
  On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com
  mailto:rs...@akamai.com wrote:
 
 
   On Sat, 22 Aug 2015 at 01:56 Salz, Rich 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