Re: [openssl-dev] Patch for grep on Solaris
On 18/01/16 15:34, Richard Levitte wrote: > In message <569cf670.3020...@cfengine.com> on Mon, 18 Jan 2016 15:28:00 > +0100, Kristian Amlie said: > > kristian.amlie> Simple build fix for Solaris. See commit message in the patch > for details. > kristian.amlie> > kristian.amlie> I hope this can make it into the openssl repository. > > On it. It will hopefully appear fairly soon in our repo. I see it's in now. Thanks! -- Kristian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Usage of the enable-capieng
Hello, I am attempting to use the Microsoft Windows CA trust store for openssl using Mingw32, Do you have any samples/tests for the new interfaces in engines/e_capi.c that I can refer to? I also found one minor issue below in the openssl s_client implementation: The openssl s_client for TLS hostname validation parameter is -verify_host in the help usage, but it should be -verify_hostname. Thanks! Gowri ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] "openssl s_client" memory leak
There seems to be some memory leak(s) somewhere during the life
of 's_client_main()'. Example from a client.bat here:
set OPENSSL_DEBUG_MEMORY=on
echo -e GET /ssltest/viewMyClient.html\r\n | openssl.exe s_client ^
-connect www.ssllabs.com:443
('echo -e' is from Cygwin32).
All .html output gets produced correctly; ends with:
read:errno=0
and dumped okay in Lynx.
But the mem-tracker reports:
[12:06:07] 6930 file=crypto/bio/bio_lib.c, line=68, thread=1092, number=72,
address=0x284ef78
72 bytes leaked in 1 chunks
And adding other options show additional leaks.
E.g. '-nbio_test -reconnect' results in 12 leaks:
[12:15:17] 13704 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccf468
[12:15:15] 13016 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccedb0
[12:15:18] 14345 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccf238
[12:15:14] 6906 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2c7e618
[12:15:17] 13705 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccf2a8
[12:15:15] 13017 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccee20
[12:15:16] 13363 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccf078
[12:15:14] 6907 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2c7e688
[12:15:18] 14344 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccf0e8
[12:15:17] 14022 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2cceeb8
[12:15:16] 13364 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccef28
[12:15:17] 14021 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72,
address=0x2ccf628
864 bytes leaked in 12 chunks
line 68 in bio_lib.c is inside BIO_new() which gives me no clue as to
the caller(s). And these order-values in column 2, what exactly are they?
All this is with a ver 0x1013L, MingW + gcc 5.1 build on Win-10.
Maybe someone can verify this happening on other OSes too?
BTW. 'memleaktest.exe freeit' reports nothing. So the mem-dbg seems okay
in this memtleaktest program. But maybe not in the 'big-picture'?
--
--gv
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
FYI, The branch has been updated, the Makfile template now has install targets as well, and I did the mods I could see would be necessary for Cygwin and Mingw. I would appreciate it if someone could help me try those out. Remember to configure with --unified. Next thing coming up is install targets on VMS. And with that, I have to rethink the defaults for the installation directories. Cheers, Richard In message <20160114.215903.813205413779228431.levi...@openssl.org> on Thu, 14 Jan 2016 21:59:03 +0100 (CET), Richard Levitte said: levitte> Hi, levitte> levitte> there's an effort going on to revamp the build system for future levitte> OpenSSL, coining it as "unified". The intention is to have one and levitte> the same base of information for all platforms, instead of having to levitte> maintain one set of files for Unixly platforms, one makefile generator levitte> for Windowsy platforms, and one pile of scripts with a serious case of levitte> bit rot for VMS. levitte> levitte> In particular, this is of interest for the VMS folks, as it's the only levitte> currently workable build system for upcoming version 1.1. levitte> levitte> levitte> Finding it levitte> == levitte> levitte> For now, this change is available on here: levitte> levitte> https://github.com/levitte/openssl/tree/refactor-build levitte> levitte> which is git repo https://github.com/levitte/openssl.git, branch levitte> refactor-build. levitte> levitte> levitte> Using it levitte> levitte> levitte> Requirements levitte> levitte> levitte> On all platforms, it requires levitte> levitte> - Perl! Reports tell me that version 5.10.1 works fine but might need levitte> some extra perl modules (Test::More and possibly others. Feedback levitte> welcome!). Unix usually has it installed or easy to find. For VMS, levitte> there's an install kit on sourceforge levitte> (https://sourceforge.net/projects/vmsperlkit/files/Archive/), and levitte> Windows, we've always recommended ActiveState Perl levitte> (http://www.activestate.com/ActivePerl). levitte> - The Perl module Text::Template, which is the driver behind the levitte> generation Makefile and other files. This branch relies quite levitte> heavily on templates. levitte> levitte> On Unix, it requires levitte> levitte> - the usual developmemt stuff. cc, as and make would be the really levitte> bare minimum, and maybe I'm forgetting something, but what is levitte> usually considered the normal tool chain should work out. levitte> levitte> On VMS, it requires levitte> levitte> - DEC C... It's called HP C these days and might be called something levitte> else again when VSI starts shipping. It needs to be recent enough levitte> to support the qualifiers /NAMES=(AS_IS,SHORTENED) and /REPOSITORY levitte> (I welcome feedback on which the minimum version for this is!) levitte> - DECset, at the very least MMS. Alternatively, MMK can be used if levitte> you can find it (if anyone knows of a place that has it for sure, levitte> feedback is welcome!) levitte> - Of course, the rest of the tool chain, but that comes with the levitte> operating system, no worries there. levitte> levitte> [I certainly hope I didn't forget anything, but if I did, feedback is levitte> welcome!] levitte> levitte> Config and build levitte> levitte> levitte> For Unix users, who are used to the usual generation of a top Makefile levitte> from Makefile.org... that is, Makefile.in since recently, this it levitte> still the default, but you can always use the unified build as an levitte> alternative by adding the flag --unified, like so: levitte> levitte> ./config --unified levitte> make levitte> make test levitte> # There is no install target yet, it's coming up! levitte> levitte> You will get One Top Makefile that does everything. It will not touch levitte> any other Makefile. levitte> levitte> levitte> For VMS users, the unified build is the only one available in this levitte> branch, the old scripts are simply gone. Instead, you configure just levitte> like you would on any other platform (well, almost, there isn't any levitte> config.com yet, so you'll have to jump directly to the Configure levitte> script), and that will generate a descrip.mms: levitte> levitte> perl Configure vms-alpha ! or vms-ia64 levitte> mms levitte> mms test levitte> ! There is no install target yet. levitte> ! As a matter of fact, I'd like to talk about exactly where it levitte> ! should install. Let's talk! levitte> levitte> levitte> Features levitte> levitte> levitte> There are a few features in the unified build that are worth testing: levitte> levitte> 1. Out of source tree builds! It's perfectly possible to do this: levitte> levitte> mkdir ../build levitte> cd ../build levitte> perl ../openssl-src/config levitte> make levitte> make test levitte> levitte>(
[openssl-dev] Manually created CRL for OpenSSL
I am looking around the OpenSSL code and is trying to figure out where I can specify the location of a manually created CRL. My device at this time does not support OCSP. I am looking at the .../crypto/X509 directory. Any suggestion that can help me look into this faster? Another question: Is OCSP support built-in for OpenSSL? Thanks for the help, Anthony. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MSVC 2015 internal compiler error
Gisle Vanem in gmane.comp.encryption.openssl.devel (Sun, 17 Jan 2016 09:50:55 +0100): >I think I have this "update 1" from the cl version: > Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86 There is a newer one: Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86 Did you install SP1 manually? It was not included in the normal Windows Update. https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx Jan ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine
On 1/16/16, 09:52, "openssl-dev on behalf of Douglas E Engert"
wrote:
>Yes, #548 is similar but for the pkeyutl.c
>
>I would have changed:
>
>{"keyform", OPT_KEYFORM, 'F', "Private key format - default PEM"},
>to
>{"keyform", OPT_KEYFORM, 'f', "Private key format - default PEM"},
Will do, thanks.
>The patch also adds an additional parameter,
>{"engine_impl", OPT_ENGINE_IMPL, '-', "Also use engine given by -engine
>for crypto operations"},
>
>I would ask the author about the engine_impl .
I’m not sure I understand. I’m the author of this addition (including
addition of “-engine_impl” option, which was added exclusively to make
sure the previous/original behavior is available if somebody would want
it), and it’s made upon suggestion by Steve Henson.
Or do you mean the author of the original pkeyutl.c? He can’t know
anything about the flag I’m adding.
Also note that this patch is a copy (as close as the difference in the
source base allowed) of the one accepted for OpenSSL_1_0_2-stable.
>It looks to me that to keep the previous behavior of the command
>one would need to add this option if an engine is used.
IMHO it (the previous behavior) could never work with real keys on a real
hardware token the way it was written (perhaps it could work with other
kinds of engines). As always, I’d be happy to learn any evidence to the
contrary. :-)
And I’ve accumulated plenty of experience using OpenSSL with a few
different PIV tokens (PKCS11-accessible via OpenSC). So far I’ve done
plenty of RSA signing/verifying and encrypting/decrypting, and ECDSA
signing. ECDH derivation works only when the public key is on the token -
because engine_pkcs11 doesn’t support ec_derive yet.
>IIt could also be an issue with the ordering
>of the parameters, or to try and not use the engine when the public key
>is used.
>(I could be wrong on this.)
Yes, parameter ordering is strict at the moment. I don’t want to mess with
the code too much to make the it work regardless of the parameter order.
For right now I’d be happy if the mainstream code would just work - and
this patch accomplishes exactly that.
>The author is also active on the OpenSC list trying to use EC with the
>OpenSC engine.
Are we talking about Michael?
BTW, on a separate issue - I’m rather concerned about the apparent
circular dependency between OpenSSL and OpenSC. This makes it problematic
to use OpenSC with another software library like Botan or Crypto++. But
that’s for a different message thread.
>On 1/15/2016 5:24 PM, Blumenthal, Uri - 0553 - MITLL via RT wrote:
>> Doug, could you please take a look at PR #548 (or is it #549)? It also
>>addresses this KEY_FORM issue.
>>
>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE
>>network.
>>Original Message
>> From:deeng...@gmail.com via RT
>> Sent: Friday, January 15, 2016 17:10
>> Reply To:r...@openssl.org
>> Cc:openssl-dev@openssl.org
>> Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl
>>req fails to use engine
>>
>> req.c (and many of the other apps) appear to have lost the ability to
>>use an engine.
>> The attached diff is against the github.com verison using Tag
>>OpenSSL_1_1-pre2
>> In the req_options[] table:
>> OPT_KEY is set to "S" so pre- checking of the parameters does not drop
>>the string passed to the engine.
>> OPT_KEY_FORM is set to "f" so pre-checking will allow engine
>>
>> The engine is saved:
>> e = setup_engine(opt_arg(), 1);
>>
>> (I turned on debug, may want that off. )
>>
>> to allow the theOPT_KEY_FORM to be an engine:
>> if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform))
>>
>> This was tested with a modified version of OpenSC using ECDSA key on
>>card to generate a self signed certificate.
>>
>> openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11
>>-keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509
>>-text
>>
>>
>> P.S. The EC_KEY_* functions appear to be working too (#4225) Have not
>>tried the ECDH yet.
>>
>> -- Douglas E. Engert
>>
>>
>>
>>
>
>--
>
> Douglas E. Engert
>
>
>___
>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 #4246] OpenSSL-1.1-pre2 openssl req fails to use engine
On 1/16/16, 09:52, "openssl-dev on behalf of Douglas E Engert"
wrote:
>Yes, #548 is similar but for the pkeyutl.c
>
>I would have changed:
>
>{"keyform", OPT_KEYFORM, 'F', "Private key format - default PEM"},
>to
>{"keyform", OPT_KEYFORM, 'f', "Private key format - default PEM"},
Will do, thanks.
>The patch also adds an additional parameter,
>{"engine_impl", OPT_ENGINE_IMPL, '-', "Also use engine given by -engine
>for crypto operations"},
>
>I would ask the author about the engine_impl .
I’m not sure I understand. I’m the author of this addition (including
addition of “-engine_impl” option, which was added exclusively to make
sure the previous/original behavior is available if somebody would want
it), and it’s made upon suggestion by Steve Henson.
Or do you mean the author of the original pkeyutl.c? He can’t know
anything about the flag I’m adding.
Also note that this patch is a copy (as close as the difference in the
source base allowed) of the one accepted for OpenSSL_1_0_2-stable.
>It looks to me that to keep the previous behavior of the command
>one would need to add this option if an engine is used.
IMHO it (the previous behavior) could never work with real keys on a real
hardware token the way it was written (perhaps it could work with other
kinds of engines). As always, I’d be happy to learn any evidence to the
contrary. :-)
And I’ve accumulated plenty of experience using OpenSSL with a few
different PIV tokens (PKCS11-accessible via OpenSC). So far I’ve done
plenty of RSA signing/verifying and encrypting/decrypting, and ECDSA
signing. ECDH derivation works only when the public key is on the token -
because engine_pkcs11 doesn’t support ec_derive yet.
>IIt could also be an issue with the ordering
>of the parameters, or to try and not use the engine when the public key
>is used.
>(I could be wrong on this.)
Yes, parameter ordering is strict at the moment. I don’t want to mess with
the code too much to make the it work regardless of the parameter order.
For right now I’d be happy if the mainstream code would just work - and
this patch accomplishes exactly that.
>The author is also active on the OpenSC list trying to use EC with the
>OpenSC engine.
Are we talking about Michael?
BTW, on a separate issue - I’m rather concerned about the apparent
circular dependency between OpenSSL and OpenSC. This makes it problematic
to use OpenSC with another software library like Botan or Crypto++. But
that’s for a different message thread.
>On 1/15/2016 5:24 PM, Blumenthal, Uri - 0553 - MITLL via RT wrote:
>> Doug, could you please take a look at PR #548 (or is it #549)? It also
>>addresses this KEY_FORM issue.
>>
>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE
>>network.
>>Original Message
>> From:deeng...@gmail.com via RT
>> Sent: Friday, January 15, 2016 17:10
>> Reply To:r...@openssl.org
>> Cc:openssl-dev@openssl.org
>> Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl
>>req fails to use engine
>>
>> req.c (and many of the other apps) appear to have lost the ability to
>>use an engine.
>> The attached diff is against the github.com verison using Tag
>>OpenSSL_1_1-pre2
>> In the req_options[] table:
>> OPT_KEY is set to "S" so pre- checking of the parameters does not drop
>>the string passed to the engine.
>> OPT_KEY_FORM is set to "f" so pre-checking will allow engine
>>
>> The engine is saved:
>> e = setup_engine(opt_arg(), 1);
>>
>> (I turned on debug, may want that off. )
>>
>> to allow the theOPT_KEY_FORM to be an engine:
>> if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform))
>>
>> This was tested with a modified version of OpenSC using ECDSA key on
>>card to generate a self signed certificate.
>>
>> openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11
>>-keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509
>>-text
>>
>>
>> P.S. The EC_KEY_* functions appear to be working too (#4225) Have not
>>tried the ECDH yet.
>>
>> -- Douglas E. Engert
>>
>>
>>
>>
>
>--
>
> Douglas E. Engert
>
>
>___
>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-users] pkeyutl does not invoke hash?
My preference would be to explain exactly - to avoid confusion and problems arising from possible misunderstanding. As I said, however, I can live with either - as by now *I* at least understand what this code does. ;-) But it doesn't seem fair for those who did not benefit from studying the piles of openssl-users and openssl-dev archives. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Hubert Kario Sent: Monday, January 18, 2016 06:23 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > > > > wrote: > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > >> Okay, how about this. First, remove the NOTES subhead. Add this > > >> to > > >> > > >>the end of the first paragraph: > > >> This program does not hash the input data and requires the input > > >> data > > >> to be of the proper size, and must not be greater than the size > > >> of > > >> the public key field or modulus. See dgst(1) for a unified > > >> Interace. > > > > > >The comment about the public key field or modulus is only true for > > >some public > > >key algorithms (e.g. RSA). > > > > Public key modulus would be true for RSA and DSA. Field would be > > true for ECDSA (and I daresay EdDSA). What other signatures do we > > have? > For RSA the maximum size depends on the padding mode and is typically > less than the modulus. > > For ECDSA it can be exceed the field size: it is truncated in that > case. True, but what should we put in the man page? Explain the above exactly, or just not mention the limit at all? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] ABI structure in detail for OpenSSL 1.0.2e
This is interesting, thanks. I am not sure how to read the charts; I'm probably being dumb. I wonder how master compares? -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] ABI structure in detail for OpenSSL 1.0.2e
Hello, I'm developing a new tool for visualization of the ABI (App. Binary Interface) structure and high-detailed binary compatibility analysis of C/C++ libraries (in addition to the abi-compliance-checker tool). And I've recently tested it on the latest release of the OpenSSL. I think that the results might be interesting for some of you: libssl.so: http://abi-laboratory.pro/tracker/abi_view/openssl/1.0.2e/a2cf7/symbols.html libcrypto.so: http://abi-laboratory.pro/tracker/abi_view/openssl/1.0.2e/c93f7/symbols.html You can find detailed information on the calling conventions and used registers for each function and memory layout for each data type in the ABI. I can share this report as tarball if you are interested to host it somewhere in the infrastructure of the OpenSSL. Thank you. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Patch for grep on Solaris
In message <569cf670.3020...@cfengine.com> on Mon, 18 Jan 2016 15:28:00 +0100, Kristian Amlie said: kristian.amlie> Simple build fix for Solaris. See commit message in the patch for details. kristian.amlie> kristian.amlie> I hope this can make it into the openssl repository. On it. It will hopefully appear fairly soon in our repo. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Patch for grep on Solaris
Simple build fix for Solaris. See commit message in the patch for details.
I hope this can make it into the openssl repository.
--
Kristian
>From 2e535aeb08ae275c13e93440641a1c4577bbd42d Mon Sep 17 00:00:00 2001
From: Kristian Amlie
Date: Mon, 18 Jan 2016 15:18:56 +0100
Subject: [PATCH] Don't use "grep -q", "-q" is not POSIX, and fails on
Solaris.
---
util/domd |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/domd b/util/domd
index e39d3e3..16de5c7 100755
--- a/util/domd
+++ b/util/domd
@@ -16,8 +16,8 @@ fi
if [ "$MAKEDEPEND" = "" ]; then MAKEDEPEND=makedepend; fi
cp Makefile Makefile.save
-if ${MAKEDEPEND} --version 2>&1 | grep -q "clang" ||
- echo $MAKEDEPEND | grep -q "gcc"; then
+if ${MAKEDEPEND} --version 2>&1 | grep "clang" > /dev/null ||
+ echo $MAKEDEPEND | grep "gcc" > /dev/null; then
args=""
while [ $# -gt 0 ]; do
if [ "$1" != "--" ]; then args="$args $1"; fi
--
1.7.9.5
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?
On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > > > > wrote: > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > >> Okay, how about this. First, remove the NOTES subhead. Add this > > >> to > > >> > > >>the end of the first paragraph: > > >> This program does not hash the input data and requires the input > > >> data > > >> to be of the proper size, and must not be greater than the size > > >> of > > >> the public key field or modulus. See dgst(1) for a unified > > >> Interace. > > > > > >The comment about the public key field or modulus is only true for > > >some public > > >key algorithms (e.g. RSA). > > > > Public key modulus would be true for RSA and DSA. Field would be > > true for ECDSA (and I daresay EdDSA). What other signatures do we > > have? > For RSA the maximum size depends on the padding mode and is typically > less than the modulus. > > For ECDSA it can be exceed the field size: it is truncated in that > case. True, but what should we put in the man page? Explain the above exactly, or just not mention the limit at all? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4248] Link error under Windows
Indeed, and the same with "no-deprecated". So I asssume it's solved in the trunk. Thanks On 16-01-2016 07:17, Joey Yandle via RT wrote: > This appears to be the same issue as when building with no-engine: > > https://github.com/openssl/openssl/issues/536 > > Hopefully Richard Levitte's new build system will be able to handle > this. Presumably in the old system this would be handled by the last > lines of ms\do_win64a.bat: > > perl util\mkdef.pl 32 libeay > ms\libeay32.def > perl util\mkdef.pl 32 ssleay > ms\ssleay32.def > > > On 1/15/2016 7:14 PM, marc.st...@approach.be via RT wrote: >> On any version of Windows (32 or 64 bits), if using the "no-deprecated" >> configure flag, some functions (see list below) are not compiled but >> they are still referenced in LIBEAY32.DEF. This gives the following >> error: LIBEAY32.def : error LNK2001: unresolved external symbol ... >> >> List of functions: >> - BN_BLINDING_get_thread_id >> - BN_BLINDING_set_thread_id >> - BN_CTX_init >> - BN_generate_prime >> - BN_get_params >> - BN_is_prime >> - BN_is_prime_fasttest >> - BN_set_params >> - CRYPTO_get_id_callback >> - CRYPTO_set_id_callback >> - CRYPTO_thread_id >> - DH_generate_parameters >> - DSA_generate_parameters >> - ERR_remove_state >> - RSA_generate_key >> - bn_dup_expand >> >> >> ___ >> 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
