Goodbye

2020-07-03 Thread Salz, Rich via openssl-users
  *   topic: Change some words by accepting PR#12089

  *

  *   4 against, 3 for, no absensions

I am at a loss for words.

I can’t contribute to a project that feels this way.  The OMC (list at [1], a 
picture of some of them at [2] although it includes non-OMC members) is, in my 
view, on the wrong side of history. I hope that in time, the four men who voted 
against it will develop more – what, empathy? – and that sometime in the future 
this PR [3], or similar, will be merged.  Until then, I will do what I have to 
in order to insure that Akamai’s needs for FIPS are met and once 3.0 is 
released, I will be fully applying my modest talents elsewhere.

I have closed all non-FIPS PR’s, and as soon as I see this message in my inbox, 
I will unsubscribe from this list. I can be reached as rsalz at akamai.com.

[1] https://www.openssl.org/community/omc.html
[2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/
[3] https://github.com/openssl/openssl/pull/12089



Re: Monolith compile verify.c

2020-06-24 Thread Salz, Rich via openssl-users
C mandates that any “missing” initializers are as if 0/null were present.


{NULL, -1, 'Q', "unused end of list"} this is the change I’d like to offer



Turn off the warning.


Re: endless loop in probable_prime

2020-06-18 Thread Salz, Rich via openssl-users
>BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
should also be 4. If BN_BYTES is being incorrectly set to 8 on your
platform then that would explain the discrepancy. Can you check?

This seems HIGHLY likely since Ronny said earlier that the same 
config/toolchain is used for 32bit userspace and 64bit kernel, right?



Re: freefunc - name clash with Python.h

2020-06-13 Thread Salz, Rich via openssl-users
I dlon't lnow about Python's freefunc, no idea what it is, but the OpenSSL line 
is defining a function with a local parameter named freefunc. Those names 
shouldn't clash; what compiler and flags?

It should be possible to rename the one in safestack.h to be "freefuncarg" or 
something.  Can you switch the include order?




Re: OpenSSL in FIPS mode, does FIPS mode provide any extra set of ciphersuites?

2020-05-28 Thread Salz, Rich via openssl-users
  *   >FIPS ciphers are a subset of the ciphers that OpenSSL supports.

  *   Is this true of both OpenSSL 2.0 FIPS version and OpenSSL 3.0 FIPS 
version. (I suppose yes). But still your confirmation will be helpful.

Yes it is true for both.


  *   Also, current version is considered outdated, even before new version is 
ready.

This is true.  But you got it for free.



Re: OpenSSL in FIPS mode, does FIPS mode provide any extra set of ciphersuites?

2020-05-28 Thread Salz, Rich via openssl-users
Are you asking about the current (outdated) 2.0 module or the 3.0 module that 
is still being developed?
In 2.0, once you enter FIPS mode you cannot leave it.  In 3.0 you can switch 
among FIPS and non-FIPS as you need to.  See 
https://www.openssl.org/docs/OpenSSL300Design.html for a description of 3.0

FIPS ciphers are a subset of the ciphers that OpenSSL supports.


Re: distributed secret key

2020-05-24 Thread Salz, Rich via openssl-users
  *   In any case, I am unaware of any existing system which meets your 
requirement 3.  Admittedly, I haven't specifically searched for such.

CertCo (now defunct, don’t know who has the intellectual property) had a patent 
that did ALL of the things.  RSA keygen, split the key, each key signs the 
data, looks like an RSA signature, then when enough have been done, combine 
them and it matches the original pre-split public key.  That, and the followon 
patents, are cool.  Don’t know if they’re expired or not.

To answer the main question: OpenSSL doesn’t do anything remotely in this area. 
 The closest is multi-prime RSA.


Re: How to get all certs into a .der file.

2020-05-22 Thread Salz, Rich via openssl-users
  *   application/pkix-pkipath

  *   Defined in RFC4366 (section 8) and RFC6066 (section 10.1)

I doubt that it is worth doing this.  First, because OpenSSL doesn’t support it 
now, then CURL (what the original poster was talking about) can’t use it when 
using OpenSSL.  Instead, as others have pointed out, they should use a text 
file that has a bunch of PEM blobs concatenated.

Do we know any application that needs this?


Re: How to debug a TLSv1.3 protocol problem?

2020-05-20 Thread Salz, Rich via openssl-users
>Speaking of which, I've recently discovered (a documented interface
landmine) that:

status = SSL_read(ssl, ...);
err = SSL_get_error(ssl, status);

>is an anti-pattern, because the "correct" usage is:

It's not unlike checking errno without knowing if the syscall actually failed.



Re: Export regulation / EAR 742.15

2020-05-03 Thread Salz, Rich via openssl-users
You might find https://github.com/openssl/openssl/issues/10923 to have some 
useful information.

OpenSSL is publically available.




Re: liblegacy.a does not work unless compiled with -static

2020-05-01 Thread Salz, Rich via openssl-users
Hm, so DSO support is a requirement for legacy crypto now?  That probably needs 
to be made explicit, and see if the project gets pushback.




Re: 04/26/2020 openssl smime question...

2020-04-26 Thread Salz, Rich via openssl-users
  *   I have seen scripts that have the openssl smime option of -inform, or 
-outform set to DEM.

That’s an error.  PEM or DER.  Interesting mixup. :)



Re: OpenSSL key agent available?

2020-04-26 Thread Salz, Rich via openssl-users
It has been done. For example, we leverage the ASYNC interface to make the 
private-key operations remote. There was also an RT ticket that had an 
implementation for a version years ago.  (I can't find the RT but I know it was 
there.)  The PKCS#11 stuff might also be appropriate.




Re: OpenSSL version 3.0.0-alpha1 published

2020-04-25 Thread Salz, Rich via openssl-users
>Yes, nice, why not reduce compile time and save prescious compiler
memory by getting rid of all-inline one-liners.

And link-time collapsing the identical code.  I think this is an issue on some 
Solaris, for example.

>  Sorry for coming
over sarcastic, i am listening to "This monkeys gone to heaven"
from The Pixies (from the 80s), it seemed due  :-))

Henh.  I can give a boatload of Boston bands.  Sometimes while working on 
OpenSSL I think of https://www.youtube.com/watch?v=F6z0Cv4PYvs (




Re: OpenSSL version 3.0.0-alpha1 published

2020-04-25 Thread Salz, Rich via openssl-users
>I do not understand one thing at the moment.  If i use
no-deprecated then the stack handling is not available:

If you use no-deprecated you have to use DEFINE_STACK_OF in exactly one file.  
And use DECLARE_STACK in your common header file.
Let me know if this works, or not, for you.




Re: How to disable renegation before compiling openssl

2020-04-21 Thread Salz, Rich via openssl-users
  *   Sorry for being unclear, the goal would be to just not send the SCSV 
value in the ClientHello.

Why?


Re: TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3

2020-04-01 Thread Salz, Rich via openssl-users
>- Do you think any use for supporting some kind of alias for families of 
> cipher in SSL_set_ciphersuites, like for example "TLSv1.3"

Suppose someone finds out that chacha/poly is insecure and the IETF issues a 
new RFC that says "TLS 1.3 MUST NOT use" that cipher.  Should the openssl alias 
change?

It can be wordy, but explicitly listing ciphers and not using aliases (HIGH 
EXPORT etc) is really better.

As for ease of use, just don't allow the ciphers to be configured.



Re: Program works with older libssl, but not with newer

2020-03-31 Thread Salz, Rich via openssl-users
Isn't this the SSL EOF thing?
 



Re: 1.OU or OU.1 ?

2020-03-30 Thread Salz, Rich via openssl-users
Just to close the loop:  I decided better documentation is the only answer for 
now: https://github.com/openssl/openssl/pull/11431

I'll copy the info below into a new issue.

On 3/21/20, 9:47 AM, "Salz, Rich via openssl-users" 
 wrote:

Argh.  Thanks for the detailed explanation.

It seems to me that if I add suffixes ".nnn" support to auto_info() than we 
can move xxx.field to deprecated at some point?

On 3/20/20, 10:45 PM, "Richard Levitte"  wrote:

The correct answer is, it depends.  This is an unfortunate
evolutionary artefact, and is governed by very different pieces of
code.

The config.pod example revolves around subject names and the config
for 'openssl req'.  The code that uses this is the function
auto_info(), found in apps/req.c.

The x509v3_config.pod example revolves around X.509 v3 extensions, and
the config for those is used by diverse functions in crypto/x509v3/
(1.1.1) or crypto/x509/ (masterand upcoming 3.0), and ultimately, the
key name comparison is done by name_cmp(), found in v3_utl.c.

So both manuals are correct.  Unfortunately...

Cheers,
Richard

On Fri, 20 Mar 2020 22:12:08 +0100,
    Salz, Rich via openssl-users wrote:
> 
> 
> The doc/man5/config.pod file says to use
> 
> 1.OU = “My first OU”
> 
> 2.OU = “My second OU”
> 
> But doc/man5/x509v3_config.pod says to append the numeric, as in
> 
> email.1 = steve@here
> 
> email.2 = steve@there
> 
> I believe the second form is correct.  Can anyone confirm?
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/






Re: Handshake failure: TLSv1.3 early data?

2020-03-24 Thread Salz, Rich via openssl-users
>It seems some browsers open three to five sockets at the same time and
then don't complete SSL negotiation on all of them, just closing them
in various states.  
  
Yes, this is exactly what they do.



Re: 3.0 FIPS related questions

2020-03-24 Thread Salz, Rich via openssl-users
 
>> The second question is somewhat related.  Has there been a decision yet 
> whether the FOM 3.0 will go through a 140-2 or a 140-3 validation?

>We are going through 140-2.
  
Has the list of validated platforms been made public yet?

For people using a different platform, will they still be able to claim "vendor 
affirmed" if they follow particular build steps?



Re: Handshake failure: TLSv1.3 early data?

2020-03-23 Thread Salz, Rich via openssl-users
Is it possible the browsers are trying to send early data?



Re: 1.OU or OU.1 ?

2020-03-21 Thread Salz, Rich via openssl-users
Argh.  Thanks for the detailed explanation.

It seems to me that if I add suffixes ".nnn" support to auto_info() than we can 
move xxx.field to deprecated at some point?

On 3/20/20, 10:45 PM, "Richard Levitte"  wrote:

The correct answer is, it depends.  This is an unfortunate
evolutionary artefact, and is governed by very different pieces of
code.

The config.pod example revolves around subject names and the config
for 'openssl req'.  The code that uses this is the function
auto_info(), found in apps/req.c.

The x509v3_config.pod example revolves around X.509 v3 extensions, and
the config for those is used by diverse functions in crypto/x509v3/
(1.1.1) or crypto/x509/ (masterand upcoming 3.0), and ultimately, the
key name comparison is done by name_cmp(), found in v3_utl.c.

So both manuals are correct.  Unfortunately...

Cheers,
Richard

On Fri, 20 Mar 2020 22:12:08 +0100,
Salz, Rich via openssl-users wrote:
> 
> 
> The doc/man5/config.pod file says to use
> 
> 1.OU = “My first OU”
> 
> 2.OU = “My second OU”
> 
> But doc/man5/x509v3_config.pod says to append the numeric, as in
> 
> email.1 = steve@here
> 
> email.2 = steve@there
> 
> I believe the second form is correct.  Can anyone confirm?
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/




1.OU or OU.1 ?

2020-03-20 Thread Salz, Rich via openssl-users
The doc/man5/config.pod file says to use
1.OU = “My first OU”
2.OU = “My second OU”

But doc/man5/x509v3_config.pod says to append the numeric, as in
email.1 = steve@here
email.2 = steve@there

I believe the second form is correct.  Can anyone confirm?



Re: TLS 1.3 protocol question

2020-03-14 Thread Salz, Rich via openssl-users
The TLS RFC describes the “bytes on the wire” – the syntax for how client and 
server communicate, and the semantics of those exchanges.

Is it a specification or standard?  Yup both.

Is OpenSSL implementation of the spec?  Yup.

What language used in the spec?  It’s described in the RFC; see “presentation 
language”



Re: TLS version 1.3 in Production servers.

2020-03-14 Thread Salz, Rich via openssl-users
> Please suggest me books or tutorials to understand OpenSSL and TLS 
> cryptographic protocol in detail. I look forward to hearing from you. Thanks 
> in advance.

Start with the RFC’s, then look for crypto basics – there are free books online.


Re: TLS version 1.3 in Production servers.

2020-03-14 Thread Salz, Rich via openssl-users
  *   I am reading this article 
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3
 I have a followup question regarding TLS version 1.3. Can we use it in 
production servers or it is good to be on TLS version 1.2? I look forward to 
hearing from you.

There are no problems with the protocol; it has had extensive analysis. There 
are no known implementation bugs, but of course that doesn’t mean there are 
none.  Most browsers will use TLS 1.3 if the server supports it. Many big 
websites or providers use it.  Go ahead. It does a smidgen more crypto work, 
but client/server latency is reduced.

As for TLS 1.2, it has not had as much analysis, but has no known protocol 
flaws. It is also considered safe to use.

Do not use TLS 1.1, TLS 1.0 or SSL 3.



Re: Problems porting Openssl 1.1.1d to zos.

2020-03-04 Thread Salz, Rich via openssl-users
Perhaps someone should writeup and submit a "NOTES.zos" file to add?




Re: Support FFDHE?

2020-02-27 Thread Salz, Rich via openssl-users
>Per section Supported Groups in RFC 8446 [1], FFDHE groups could be supported.

I was wrong, sorry for the distraction.

As others have pointed out, it will be in the next (3.0) release.


Re: OpenSSL 3.0

2020-02-27 Thread Salz, Rich via openssl-users
None of those choices address what happens in the 1.0.2 module goes to historic 
on Sept 1.  See 
https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
 for details.





Re: OpenSSL 3.0

2020-02-27 Thread Salz, Rich via openssl-users
  *   That's fair. So the only option is to use another module? Extended 1.0.2 
support does not resolve this either, correct?

I do not think that is the only option.  For example, you might be able to use 
3.0 and say it’s “in evaluation.” There might be other options, that was all I 
could think of while composing this email.

HOWEVER, note that the set of validated platforms for 3.0 is very different 
from the current FOM.  Someone officially with the project will have to provide 
details on that, not me.


Re: OpenSSL 3.0

2020-02-27 Thread Salz, Rich via openssl-users
  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module 
will be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?

Without their free lunch?


Re: OpenSSL 3.0

2020-02-27 Thread Salz, Rich via openssl-users

>It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.
  
This needs to be real user documentation as part of the FIPS deliverable, right?



Re: Support FFDHE?

2020-02-27 Thread Salz, Rich via openssl-users
  *   Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port

TLS 1.3 doesn’t have those groups.



Re: OpenSSL 3.0

2020-02-26 Thread Salz, Rich via openssl-users
> That's 5 weeks from now, I'd thought the basic structure might be present 
> now.
   
It is.   You probably have to look at the tests to see how to use things.



Re: OpenSSL 3.0

2020-02-26 Thread Salz, Rich via openssl-users
The 3.0 release is a work in progress and is not done yet.

FIPS 3.0 === OpenSSL 3.0, using a FIPS-validated crypto provider which will be 
part of OpenSSL 3.0.

The architecture documents are at https://www.openssl.org/docs

On 2/26/20, 2:40 PM, "Sam Roberts"  wrote:

On Wed, Feb 26, 2020 at 8:36 AM Salz, Rich  wrote:
>
> >I'd like to give this a spin, to get an idea what's going to be
> involved in porting from FIPS2.0 to 3.0, any pointers on where to
> start?
>
> Per the blog post, "most applications should just need to be recompiled." 
:)
>
> Get the source via instructions here: https://www.openssl.org/source/

I want to build against ***FIPS3.0***. I don't find any routes to
FIPS3.0 in the above link.

We've already ported to openssl 1.1.1, so the non-FIPS APIs should be
fine when compiled against openssl-3.0 (the promise was API
compatible).

My expectations based on the blog posts and arch/design docs is the
FIPS3.0 will be an OpenSSL 3.0 provider, and I am guessing it will be
necessary, somehow?, to tell OpenSSL which provider to use, either
programmatically or via openssl.cfg?

Or maybe I'm off track, and its a configure mode, and the provider
will be hard-coded in if openssl-3.0 is built with FIPS? But again,
how to do that?

I've spent some time poking around in the source and git logs, and
(again, could have missed it), I didn't see any FIPS specific doc
changes or hints as what to do for FIPS3.0, and it wasn't clear where
to start.

Sam




Re: OpenSSL 3.0

2020-02-26 Thread Salz, Rich via openssl-users
>I'd like to give this a spin, to get an idea what's going to be
involved in porting from FIPS2.0 to 3.0, any pointers on where to
start?
  
Per the blog post, "most applications should just need to be recompiled." :)

Get the source via instructions here: https://www.openssl.org/source/




Re: CRYPTO_secure_malloc_init() fails without error message

2020-02-20 Thread Salz, Rich via openssl-users
Are you running as root?  If not, that's likely to be the problem.



Re: Questions about using Elliptic Curve ciphers in OpenSSL

2020-02-11 Thread Salz, Rich via openssl-users
I believe you just load your ECDSA cert and the other stuff – Dhparams!! – is 
not needed.




Re: Questions about using Elliptic Curve ciphers in OpenSSL

2020-02-11 Thread Salz, Rich via openssl-users
The first thing I would suggest is to separate ECDH, the session key exchange, 
from ECDSA, the signature.  Try to make ECDH with RSA work.  Then just load 
your ECDSA cert; you can load one cert of each type (RSA DSA) and the runtime 
will figure out what to do, depending on what the client offers.



Re: Problems adding specific extensions to signed certificates

2020-02-07 Thread Salz, Rich via openssl-users
I think the mismatch is that CSR extensions are not carried over; they have to 
be added at signing time.
See https://github.com/openssl/openssl/issues/10458




QUIC support

2020-02-06 Thread Salz, Rich via openssl-users
A month ago Tim said[2] that PR 8797[1] requires on OMC decision on “whether or 
not QUIC in this manner of approach should be added into OpenSSL at this time.”

To save you a click, this PR adds API’s to OpenSSL so that Google’s open source 
QUIC implementation can be built on top of OpenSSL.  For more details, perhaps 
my comment [3] explains the situation best.

I am asking the OMC to come to call a vote on this *NOW*  I am CC’ing 
openssl-users so that the community can comment.


[1] 
https://github.com/openssl/openssl/pull/8797
[2] https://github.com/openssl/openssl/pull/8797#issuecomment-571899829
[3] https://github.com/openssl/openssl/pull/8797#issuecomment-485002590



Re: Openssl 3.0 fips usage

2020-02-04 Thread Salz, Rich via openssl-users
  *   If  both default and fips provider are loaded and application generate 
Rsa key pair(2048 bits) from fips provider and  try to use default provider to 
sign with sha1,  is this allowed?

The application will have to explicitly “export” the key from the FIPS provider 
and “import” it into the default (non-FIPS) provider. So you can share keys. 
Whether or not that is allowed would perhaps depend on the details of the 
export/import process and key protection required by FIPS. I think you would 
have to get an accredited validation lab to answer that question for you.

HOWEVER, this doesn’t your real question:


  *   According to FIPS 140-2 IG document, CSP defined in approved mode of 
operation shall not be accessed or shared with non-approved mode of  
operation.If allowed, will it not break the fips rules?

The OpenSSL FIPS-validated provider will only operate in FIPS mode and will not 
have a non-approved mode of operation as long as you follow the configuration 
and installation procedures (not yet written).

Disclaimer: I am not employed by an accredited lab.


Re: writev over OpenSSL

2020-02-02 Thread Salz, Rich via openssl-users
TLS/TLS will take your data and wrap it inside it’s own record structure.  It 
has to, that’s the nature of the protocol.  Thinking that a single writev() is 
“encrypt buffers and then do analogous syscall” is wrong.


Poll on manpages

2020-01-28 Thread Salz, Rich via openssl-users
The next release of OpenSSL splits the “help” for commands into sections, like 
this:

; ./apps/openssl rehash --help
Usage: rehash [options] [directory...]

General options:
-helpDisplay this summary
-h   Display this summary
-compat  Create both new- and old-style hash links
-old Use old-style hash to generate links
-n   Do not remove existing links

Output options:
-v   Verbose output

Parameters:
directoryOne or more directories to process (optional)

Should the order of options in the manpages follow this layout?  Should there 
be a blank line (in the SYNOPSIS section!) between the option sections?  Please 
take a look at https://github.com/openssl/openssl/pull/10885 which does this 
for s_client.  You can see just the changed file here: 
https://github.com/openssl/openssl/blob/71d8c19554a65cf0717f6b7e7b34849456e76888/doc/man1/openssl-s_client.pod.in

Replies to me will be summarized for the list.  Thanks!



Re: intermittent Apache/OpenSSL error hangs server

2020-01-09 Thread Salz, Rich via openssl-users
>Once we get that error, every time we try to serve a request in Apache using 
>that pid, it errors out.  So, it seems like something randomly corrupts that 
>PID.  Can someone provide some information about FIPS_CHECK_EC: pairwise test 
>failed.

Once FIPS detects an error, it will stay stuck in error-state until you 
re-initialize.  Sorry, can’t provide more details about the specific test 
that’s failing.


Re: X25519 Unlisted by -list_curves and Any Trusted Python Code for X, Y Coordinates

2019-12-25 Thread Salz, Rich via openssl-users
  *   I want to us ECDSA for my Web server's SSL certificate via an ACME client 
to Let's Encrypt and maybe later BuyPass.

That’s fine.


  *   I thought that EC is better than RSA, but now I don't think so. The 
answer seems to be: it depends.

There are trade-offs.  The biggest one is that EC gives equivalent security 
with a much smaller keysize.


  *   Safe Curves (SafeCurves: 
Introduction)
 says …

FWIW, SafeCurves is mostly the guy behind 25519 :) This is not a slam against 
djb, who’s kinda brilliant.

If you’re not sure what to do, perhaps follow what the browsers do.  That way 
if something’s wrong you’ll just be going up in flames with the rest of the 
world.

If you don’t trust the NSA and therefore don’t trust NIST, do you accept AES? 
What about when they approve 25519?



Reviewer statistics

2019-11-20 Thread Salz, Rich via openssl-users
The attached script summarizes git log data and generates CSV lines for each 
commit.  For example,
; git log -2 | ~/reviews.pl
8984, 2019-05-23, levi...@openssl.org, O, paul.d...@oracle.com, O
9624, 2019-08-18, bernd.edlin...@hotmail.de, C, levi...@openssl.org, O
It ignores log entries that don’t follow the common format of having 
“Reviewed-by” and “Merged from” lines.

This can be useful to get a handle on PR’s and reviewer activity.  I don’t yet 
know what questions to ask :) but it will be nice to have numbers that prove 
that the project needs to improve its reviewer flow :( There’s rumors that the 
project will be announcing some restructuring or policy changes soon, and maybe 
this will be helpful input to that process.


#! /usr/bin/env perl

# Read "git log" output (usually a subset, not the whole log) and print
# summary lines for each PR showing author, date, reviewers (one per line).
# A typical use, see who reviewed PR's in the first quarter of 2019:
#   git log --since 1/1/2019 --until 3/31/2019 | perl reviews.pl
use strict;
use warnings;
use Date::Parse;

# Things we log.
my $author = '-';
my $when = '-';
my $pr = 0;
my @reviewers;


# List of OMC members who use non-openssl.org addresses
my %omc_email = (
'paul.d...@oracle.com' => 1,
'k...@roeckx.be' => 1,
'b...@links.org' => 1,
'openssl-us...@dukhovni.org' => 1,
);
my %committers = (
'matthias.st.pie...@ncp-e.com' => 1,
'beld...@gmail.com' => 1,
'bernd.edlin...@hotmail.de' => 1,
'bka...@akamai.com' => 1,
'david...@google.com' => 1,
'ka...@mit.edu' => 1,
'nic@gmail.com' => 1,
'patrick.ste...@de.ibm.com' => 1,
'paulyang@gmail.com' => 1,
'shane.lon...@oracle.com' => 1,
'tm...@fedoraproject.org' => 1,
);

# Return "O" if |$1| is an OMC member, "C" if they are a committer, or
# "N" otherwise.
sub user_type {
my $email = shift;

return "O" if $email =~ m/\@openssl.org/ or defined $omc_email{$email};
return "C" if defined $committers{$email};
return "N";
}


# If this commit is a new PR, print a CSV line.
my $savedpr = 0;
sub process {
if ( $savedpr != $pr ) {
for my $r ( @reviewers ) {
my $a_type = user_type($author);
my $r_type = user_type($r);
print "$pr, $when, $author, $a_type, $r, $r_type\n";
}
}
$savedpr = $pr;
$author = '-';
$pr = 0;
$when = '-';
@reviewers = ();
}


# Get input source.
my $LOG;
if ( -t STDIN ) {
open $LOG, "git log|" or die "Can't popen git log $!,";
} else {
$LOG = *STDIN;
}

# Read/parse/process input.
while ( <$LOG> ) {
chop;
if ( /^commit / ) {
process();
} elsif ( /^Author:.*<(.*)>/ ) {
$author = $1;
} elsif ( /^Date:\s+... (.*) [-+]\d+/ ) {
my @f = strptime($1);
$when = sprintf "%4.4d-%02.2d-%02.2d", $f[5] + 1900, $f[4] + 1, $f[3];
} elsif ( /Reviewed-by: .*<(.*)>/) {
push @reviewers, $1;
} elsif ( m@Merged from https://github.com/openssl/openssl/pull/(\d+)@ ) {
$pr = $1;
}
}
process();


Re: Help on Diffie Hellman key exchange

2019-11-13 Thread Salz, Rich via openssl-users
>For using 1.1.0, we only need to call RAND_bytes() ?

Yes.  But do check the return value of RAND_bytes.


Re: Help on Diffie Hellman key exchange

2019-11-13 Thread Salz, Rich via openssl-users
>RAND_seed(seed, ::strlen(seed));
>RAND_bytes(buf, keySize / 8);

I don’t know where you are getting the seed, but it is typically binary data, 
not a C string.

If you are using 1.1.0 or later, you do not need to seed things.


Re: dsaparam error OpenSSL 1.1.1d

2019-11-11 Thread Salz, Rich via openssl-users
The question about -rand option is valid, but Viktor’s post is right and the 
rest of my post is wrong :(

From: openssl-users 
Reply-To: Rich Salz 
Date: Monday, November 11, 2019 at 8:10 AM
To: shiva kumar , openssl-users 

Subject: Re: dsaparam error OpenSSL 1.1.1d


  *   openssl dsaparam 128 -rand file

Why are you using the -rand option?  Unless this is a special platform, don’t 
do that.


  *   is taking long time processing the command and not producing any output.

What is your hardware and software?

Can you run it under a debugger, and interrupt it sometimes to see where it is?



Re: dsaparam error OpenSSL 1.1.1d

2019-11-11 Thread Salz, Rich via openssl-users
  *   openssl dsaparam 128 -rand file

Why are you using the -rand option?  Unless this is a special platform, don’t 
do that.


  *   is taking long time processing the command and not producing any output.

What is your hardware and software?

Can you run it under a debugger, and interrupt it sometimes to see where it is?



Re: Force the use of engine in config file

2019-11-02 Thread Salz, Rich via openssl-users
If you are changing openssl, why not just change the init function to load your 
engine and abort/exit/fail if it doesn’t load?



Re: Remove All Software Generators

2019-10-31 Thread Salz, Rich via openssl-users
Why not just change things so that if your module fails to load, the library 
exits?

Don't change the RAND code, change the INIT code.
 



Re: Retrieve CA for client cert from SSL*

2019-10-25 Thread Salz, Rich via openssl-users
Is looking at the IssuerDN good enough?



Re: Preferred way of passing user context void* inside SSL*

2019-10-23 Thread Salz, Rich via openssl-users
>Is there a way for me to piggyback a void* inside the SSL structure so
that I can access it from within the callback?
  
Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented in 
https://github.com/openssl/openssl/pull/10216 (and due to be merged to master 
soon)




Re: openssl 1.0.2 with TLS 1.2

2019-10-22 Thread Salz, Rich via openssl-users


  *   I can’t find documentation on how to tell TLS where to look.

Not sure about 1.0.2, but “openssl version -a” should show you the CERT 
directory.

BTW, that’s an old release, you should upgrade if possible.


Re: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module

2019-10-21 Thread Salz, Rich via openssl-users
  *   Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2 
till the new FIPS module/OpenSSL 3.0 becomes available?

This question gets asked a great deal.  Why?

The OpenSSL project has not done any 1.0.2-FIPS work for years. This means that 
if there are any CVE-level bugs in 1.0.2 that affect(ed) that FIPS module, they 
weren’t getting fixed and the module wasn’t being revalidated. This has been 
the situation for several years. By 1.0.2 going out of support, all this means 
is that the OpenSSL project will not be posting bugfixes.  Nobody is going to 
come and make you delete your own copies.

So why do people  care if it goes out of support?  I suspect the answer is 
this: by using the open source code, you didn’t have to pay anything or do any 
support and maintenance, and now they are worried about having to do so.

Is there another reason?



Need a .gitignore fix on master

2019-10-18 Thread Salz, Rich via openssl-users

>; git status
>On branch master
>Your branch is up-to-date with 'origin/master'.
>Untracked files:
>  (use "git add ..." to include in what will be committed)
>
>include/openssl/opensslv.h
>
>nothing added to commit but untracked files present (use "git add" to
>track)
>;





Re: Questions about secure curves

2019-10-15 Thread Salz, Rich via openssl-users
There is nothing known to be wrong with NIST P256.  If you don't have a known 
reason to use 384, then don't use it.

 



Re: building OpenSSL 1.1.1 with -DPURIFY

2019-10-09 Thread Salz, Rich via openssl-users
Emilia's work removed the need to add -DPURIFY; you never need to add it.

Note that the BN code is clever, it doesn't bother to zero everything when it 
knows which bits within a word it is using.

 



Re: OpenSSL compilation errors in Windows

2019-10-01 Thread Salz, Rich via openssl-users
Several people have told you the following:
That is an *internal* openssl header file; do not use it. 
Remove the include statement from your code.  Your code is wrong.
That file is a C file, not compatible with C++

Why do you not listen?


Re: Regarding using OpenSSL along with optee

2019-09-30 Thread Salz, Rich via openssl-users
>Greetings. I was checking for the support for Trusted 
> Execution Environment (TEE) in OpenSSL.

I’m curious – what do you think would be required?



Proposed change to linux kernel about random numbers

2019-09-18 Thread Salz, Rich via openssl-users
Please take a look at 
https://lore.kernel.org/lkml/CAHk-=wiGg-G8JFJ=r7qf0b+utqa_weouk6v+mcmfsljlrq6...@mail.gmail.com/
 and consider giving your comments.

TL;DR:  see the comment below.
+ * Hacky workaround for the fact that some processes
+ * ask for truly secure random numbers and absolutely want
+ * to wait for the entropy pool to fill, and others just
+ * do "getrandom(0)" to get some ad-hoc random numbers.
+ *
+ * If you're generating a secure key, you'd better ask for
+ * more than 128 bits of randomness. Otherwise it's not
+ * really all that secure by definition.
+ *
+ * We should add a GRND_SECURE flag so that people can state
+ * this "I want secure random numbers" explicitly.



Re: DH group cipher suites getting rejected

2019-09-18 Thread Salz, Rich via openssl-users
  *   However if I try ECDHE, it works fine. Is DHE only cipher suites less 
common now ?
  *   I believe its responsibility of server to generate DHparam of large 
enough size.

Yes, DHE has dropped because it is hard to get right, and it takes more CPU 
cycles than ECDHE.



Re: 1.1.1d LD_LIBRARY_PATH

2019-09-14 Thread Salz, Rich via openssl-users
On restart on my host with version 1.1.1d , I have this problem:

I hope you are not replacing your system OpenSSL with one you built.  Don't do 
that.
 



Re: MD2 or RC5?

2019-09-13 Thread Salz, Rich via openssl-users
  *   I'd still like to know if it's possible to enable to both.  If it's not, 
though, then which one is best to enable?  MD2 or
RC5?  Thanks in advantage for the reply and sorry for the new email thread.

They do different things; MD2 is a digest (“hash”) function, and RC5 is a block 
(encrypt/decrypt) cipher.

Both are obsolete.

You should be able to enable both, but you should only do so if you need to 
work with some really old software.


Re: CSR with only public key

2019-09-12 Thread Salz, Rich via openssl-users
>I used CX509CertificateRequestCertificate  class to create CSR with only
public key. 

  
Those functions/classes/names/whatever are not part of OpenSSL.

The OpenSSL "req" command cannot process as CSR unless it is signed by the 
private key.  If you have a requirement to sign a CSR with the public key, then 
probably other things within OpenSSL will not be able to handle it.
 



Re: Compiling OpenSSL 1.1 - certs directory is empty, how to obtain?

2019-09-09 Thread Salz, Rich via openssl-users
Another great source is https://github.com/nabla-c0d3/trust_stores_observatory

One-stop shopping for all of apple, Android, Windows, NSS, OpenJDK, Oracle Java.




Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

2019-08-29 Thread Salz, Rich via openssl-users
  *   I've another question, based on your suggestion Salz Rich, this config 
@SECLEVEL can be set per host/domain, or is it impossible?

It totally depends on which webserver you are running and what it’s 
configuration allows. I’m not able to answer webserver config questions BTW.


Re: client certs with no subjectName only SAN

2019-08-16 Thread Salz, Rich via openssl-users
>In the same paragraph, the sentence before the one you're quoting says "If 
> the subject field contains an empty sequence, then the issuing CA MUST 
> include a subjectAltName extension that is marked as critical."

>It's not possible to have a missing subject name in a certificate, the 
> field is not OPTIONAL.
  
You are of course correct.  Thanks Erwann.  (He has forgotten more about ASN1 
than I ever knew :)



Re: Acquire Entropy for embedded platform

2019-08-16 Thread Salz, Rich via openssl-users
  *   Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default 
entropy sources.
  *   I dread the effort that this would entail.

Open an issue and maybe someone with an older platform will work on doing it.

I don’t think the project has any need to support such things.  (Members of the 
project working for companies, perhaps)


Re: client certs with no subjectName only SAN

2019-08-15 Thread Salz, Rich via openssl-users
subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD 
mark subjectAltName as non-critical"

I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, 
with no relative disintuished name components, is not the same as not present.




Re: IPv6 address encoding in commonName

2019-08-14 Thread Salz, Rich via openssl-users
RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty 
subjectName.

Non-empty subjectName or non-empty commonName within the subject name?

Shrug.  Doesn't matter, I guess.  Just populate it with the string version of 
the HIT name, something like
CN=IP Address 2001:27:dcfc:cb8:d53g:5364:48bj
?

>My searches today have come up empty.
  
I tried crt.sh and also came up empty; https://crt.sh/?CAName=%25%3A%25  This 
is not surprising since I would not expect any public CA's to have this kind of 
thing.

  



Re: 1.0.2 to 1.1 migration problem with verify_callback()

2019-08-08 Thread Salz, Rich via openssl-users
> (why doesn't it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?).

History; OpenSSL reserved some exdata indices for itself.


Re: OPENSSL_thread_stop() equivalent

2019-08-06 Thread Salz, Rich via openssl-users
  *   Had to downgrade the OpenSSL used in an application from 1.1.0k to 1.0.2s.

That’s too bad, given 1.0.2 is going to become unsupported at year-end.  Was it 
because the application wasn’t ready to handle opaque structures?

>Due to this I have to remove the usage of OPENSSL_thread_stop(), want to know 
>the equivalent call in OpenSSL 1.0.2s? if applicable.

1.0.2 has no concept/support for threads, so you probably don’t need to do 
anything.




Re: openssl hash value - how to generate ?

2019-07-30 Thread Salz, Rich via openssl-users
>At the bottom of the man page for x509 it states the following:
The hash algorithm used in the -subject_hash and -issuer_hash options 
before OpenSSL 1.0.0 was based on the deprecated MD5
algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and 
later it is based on a canonical version of the DN
using SHA1.

The text isn't great.  In both cases the printed form is not what is used. 
Instead, by "canonical form" is meant the X.509 ASN1/DER encoding.

Your guess -- "I think I'm using a different string" -- is correct.




Re: Openssl binary with statically linked libssl and libcrypto

2019-07-25 Thread Salz, Rich via openssl-users
>Sadly, I can not make use of the "no-shared" option as I still need the
shared libraries to be built.
  
Statically linking against files built for shared libraries is possible on many 
platforms (link against the .a even though .so exists), but not all platforms.

You can always build twice.



Re: help - building OpenSSL fips for 64 bit Android

2019-07-22 Thread Salz, Rich via openssl-users
>that the setenv-android.sh script doesn't account for 64 bit architectures.

Correct.  The current FIPS module has not been modified for quite some time, 
and your platform is not supported.

If you cannot follow the steps *exactly* you cannot claim FIPS validation.  The 
OpenSSL project is working on a new FIPS validation for the next release, but 
it will only support a few platforms (those of the sponsors funding the work, 
mainly).  Whichever release you use, you will have to hire a lab to get your 
own validation, or hope that a vendor provides one.





What's up with ectest?

2019-07-11 Thread Salz, Rich via openssl-users
Ectest has been broken for quite some time.  What are the plans to get it fixed?


Re: looks like the support for Heart beat extension is removed from openssl

2019-07-11 Thread Salz, Rich via openssl-users
  *   Why the support for Heart beat extension is removed from openssl.

It’s intended use was to check MTU along the path.  That is not very useful any 
more.



  *   How to handle abnormal disconnection in DTLS?

You should be able to detect time-outs and “failure to close” in your 
application.


Re: Will my application be FIPS 140-2 Certified under following conditions?

2019-07-08 Thread Salz, Rich via openssl-users
> It seems to me that the easiest thing to do is maintain that release of 
OpenSSL by themselves.

>Which would be another variation of such unofficial work.
  
You could look at things like that.  I consider it to be more like "your free 
FIPS ride is done, time to pay up"

>That policy page is half the problem, the other half being the decision
not to make a FIPS module for the current 1.1.x series.
  
There are many problems with the current FOM.  One notable example, is that you 
cannot have a single executable that handles both FIPS and non-FIPS TLS 
connections at the same time.  Another is the way the whole integrity check is 
done. I could go on and on, but won't.  The project spent a long time 
discussing and considering alternatives and decided a new start was the best 
way to move forwards. It was a carefully-considered decision.  The fact that it 
"left a coverage gap" in FIPS/1.0.2 was also discussed.

It's too bad not everyone is pleased. Probably those who didn't plan well, 
and/or who just got "FIPS for free" and expected that to last forever seem to 
be among those particular unhappy. Speaking for myself, AND NOT THE PROJECT, 
too bad.




Re: Will my application be FIPS 140-2 Certified under following conditions?

2019-07-06 Thread Salz, Rich via openssl-users

>> They would have to get their own validation, their own lab to verify, 
etc., etc.
>That seems to contradict the other answer, which is that legally, the
>FIPS cannister (properly built) can be used with any software outside
>the cryptographic boundary, the soon-to-be-deprecated OpenSSL 1.0.2
>library just being the normal default.
  
You are correct.  My statement, which was technically incorrect, is more likely 
to be realistic :)
  
>The point is that some people may soon be in a desperate need to find a
FIPS-capable replacement for OpenSSL 1.0.x.
  
It seems to me that the easiest thing to do is maintain that release of OpenSSL 
by themselves.

If someone is thinking of fitting OpenSSL 1.1.x to become a user of the 
existing FOM, then they will probably find it easier to, well, just maintain 
what currently works.

Just because something is past "end of life" does not mean that anyone's 
ability to use it is revoked.  It just means that keeping it working is their 
responsibility.  Anyone can use the FOM until it expires (sunsets is the term 
used), which lasts one year beyond 1.0.2 as I recall.  See 
https://www.openssl.org/blog/blog/2018/05/18/new-lts/ for some more information 
on this.




Re: Will my application be FIPS 140-2 Certified under following conditions?

2019-07-04 Thread Salz, Rich via openssl-users
>Is the use of OpenSSL an actual legal requirement of the certification of
the FIPS object module, or just the easiest way to use it?
  
I'm not sure who you are asking this.

The exiting FIPS validations for OpenSSL only cover the 1.0.2 based source code.
  
>Difference would be particularly significant in case someone created code
to use the validated FOM 2.0 module with the OpenSSL 1.1.x feature
enhancements (as the project itself has indicated no desire to do so).
  
They would have to get their own validation, their own lab to verify, etc., etc.




Re: Can applications built with 'FIPS Capable OpenSSL' be called as 'FIPS 140-2' certified?

2019-07-03 Thread Salz, Rich via openssl-users
Didn’t you just ask this question? :)

If you followed the Win32 build instructions *exactly* and you build your 
application to turn on FIPS mode and link against the canister, then yes.

If you made changes to the process, then no.



Re: Building a DER sequence

2019-07-01 Thread Salz, Rich via openssl-users
>I see those macros, but ... is there any documentation?
  
No.
 



Re: error: dereferencing pointer to incomplete type DH {aka struct dh_st}

2019-06-28 Thread Salz, Rich via openssl-users
>I'm attempting to build our RHEL 7 based product on RHEL 8 and running 
> into a lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL 
> 8).  I haven't found a good guide to adapting the sources to these changes.

Web search for "openssl opaque accessors" turns up many hits; these two seem 
useful:
  
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes
http://vega.pgw.jp/~kabe/vsd/migrate2openssl-1.1.html 
 
PS: A long confidential email disclaimer is silly, particularly when posting to 
a large public mailing list. :)



Re: Building a DER sequence

2019-06-26 Thread Salz, Rich via openssl-users
Do I construct a sequence and add items to it - top down?

No, because then you have to go back and patch the sequence length and perhaps 
slide everything up or down a copule of bytes.

I would look at an existing simple sequence and start writing your own based on 
that; look for ASN1_SEQUENCE macros in crypto/x509/x*.c files.  Another set of 
macros will declare the i2d/d2i and PEM functions if needed.




Re: Proposal to remove some platforms

2019-06-23 Thread Salz, Rich via openssl-users
>Yes NetBSD cares about PARISC... We still build and run on it.

Thanks.  The targets removed in that PR were for hpux-parisc.


Re: Make file removed in openssl 1.1.1

2019-06-17 Thread Salz, Rich via openssl-users
>It depends on what you want to achieve. The top level template Makefile is 
> in
Configureations/unix-Makefile.tmpl. Each individual directory contains a
build.info file which allows you to make per-directory changes to things 
like
the sources to be compiled, etc.
  
And also important, these are all processed to build a single Makefile.  
There's only one now.



Re: failing in reproducing .so files

2019-06-14 Thread Salz, Rich via openssl-users
If you are adding new functions to the library, you need to
1A   Make sure there is a prototype in one of the existing OpenSSL 
header files;
OR
1B   If your prototype is in a new header file, you will have to edit 
Configurations/unix-Makefile.tmpl to pick up that file.

2  Run configure

3.Do “make update”  Verify that the previous steps worked by 
looking for your new function(s) being declared in util/libcrypto.num

4.Run make

This could be documented somewhere; anyone want to copy this email into a new 
issue?


Re: building openssl for windows - missing do_win64a from ms directory.

2019-06-11 Thread Salz, Rich via openssl-users
  *   The issue I have is that I don’t see ‘do_win64a’ within the ‘ms’ 
directory (I’m following build instructions here: 
http://eran.geek.co.il/wp/archives/3897
 and https://wiki.openssl.org/index.php/Compilation_and_Installation#W64 )

Those files are outdated; look at the NOTES.WIN file.

(PS that email disclaimer is obnoxious, it’d be great if you could get it 
disabled.)



Re: debugging a make/dependency issue

2019-06-07 Thread Salz, Rich via openssl-users
Thanks.

I had a trailing backslash on a source list, and it gobbled up the next line 
which was an INCLUDE directive.
 



debugging a make/dependency issue

2019-06-04 Thread Salz, Rich via openssl-users
I am importing some code into openssl and getting a strange build error:

make[1]: *** No rule to make target 'crypto/bn/crypto/include.o', needed by 
'libcrypto.a'.  Stop.

Any common ideas on what to look for (e.g., missing header file, wrong INCLUDE 
settings in build.info, etc) ?



Re: why does RAND_add() take "randomness" as a "double"?

2019-05-21 Thread Salz, Rich via openssl-users
>Then just set it to 1.0 and be done with it.

>That hardly helps on systems that don't have floating point at all. 

No it doesn't.  Such systems aren't supported by OpenSSL.  There are many 
places were floating point is used/supported.
Removing the second arg to RAND_add is the least of the problems (look at 
various asm files)



Re: why does RAND_add() take "randomness" as a "double"?

2019-05-21 Thread Salz, Rich via openssl-users
>If it's a sarcasm, I'm missing the point.
  
I was't being sarcastic, I was trying to show that the team, recently, still 
liked the use of floating point.

>There are use cases when one wants to mix/add extra randomness from, e.g., 
> an external source (that, for whatever reasons, is trusted more than what's 
> provided by the system).
 
Then just set it to 1.0 and be done with it.






Re: why does RAND_add() take "randomness" as a "double"?

2019-05-21 Thread Salz, Rich via openssl-users
When I overhauled the RAND mechanism, I tried to deprecate this use of floating 
point, in favor of just a number from 0 to 100 but was voted down.

It *is* stupid.  Luckily, on a modern system with system-provided randomness to 
seed the RNG, you never need this call.




Re: Reg slowness seen in openssl 1.1.1

2019-05-09 Thread Salz, Rich via openssl-users
>  Could you please look into the program and let me know if anything  I am 
> doing wrong ?
> Or else What could be the issue ?

Sorry, no not me.  Maybe someone else on the list has ideas.


Re: Reg slowness seen in openssl 1.1.1

2019-05-09 Thread Salz, Rich via openssl-users
So now you know where to start looking, I guess.  You might also change your 
test program so that it calls the functions multiple times, to “smooth out” the 
overhead.


Re: Reg slowness seen in openssl 1.1.1

2019-05-09 Thread Salz, Rich via openssl-users
I would start with doing profiling on old and new versions to see where the 
slowdown is.


  1   2   3   4   5   >