[openssl-users] RNG behavior by default

[Mike Blaguszewski]

I am using the EVP API (version 1.1.1) for performing public key and symmetric 
key operations across a variety of platforms (macOS, Windows, Linux, iOS and 
Android). I am currently not doing anything to explicitly seed OpenSSL’s random 
number generator. My understanding is that the default behavior 
<https://www.openssl.org/blog/blog/2017/08/12/random/> should be 
cryptographically secure.

So my concerns are:
1. Whether I really can count on getting a high-entropy PRNG across these 
various platforms, without any explicit initialization.
2. If something goes wrong with PRNG initialization, that it will fail hard 
rather than fall back to something less secure. And if so how I detect such a 
failure.

Our current implementation uses libsodium, which relies on the usual system 
calls to generate entropy, so if I can count on OpenSSL always doing this then 
I’m happy. 

Thanks,
Mike-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problems with deriving EC public key from private

[Mike Blaguszewski]

On Dec 17, 2018, at 11:42 PM, Billy Brumley  wrote:
> 
> But 0.4% is suspiciously close to 1/256, so I'm willing to bet your
> problem surrounds your size assumptions in various functions. Check
> the manpage of e.g. EC_POINT_point2oct and grep for usage in the
> library, but the idea is to pass NULL first, then malloc, then pass
> that pointer. BN_bn2bin is different. Probably the size won't be fixed
> (e.g., there is a 1/256 chance you'll have one byte less, i.e. leading
> zero).

Thanks so much! That was exactly it. Switching from BN_bn2bin() to 
EC_KEY_priv2oct() resolves the problem. (As does BN_bn2binpad(), but using the 
more standard binary format seems preferable.) I will also look into 
pre-flighting the calls with a NULL buffer.

Mike

P.S. not sure why it crashed for you, but I’d guess some combination of 
different OpenSSL versions and an error return being ignored by the sample 
code. I appreciate you taking a look despite that.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problems with deriving EC public key from private

[Mike Blaguszewski]

Some code of mine reads a NIST P256 private key from bytes and derives the 
public key from it, and this derived public key is incorrect about 0.4% of the 
time. I’ve attached a sample program that does the following.

1. Generate a key-pair of type NID_X9_62_prime256v1
2. Write the public and private components to memory
3. Read the private key back from memory, derive the public key, and write that 
back out.
4. Compare this “round-tripped” public key to the public key generated in step 
2.

The public key from step 2 almost always matches the public key from step 3, 
but about 0.4% of the time they will differ. (The sample program runs a loop to 
determine this.) Further experiments suggest it’s the private_key_from_binary() 
function that is the problem, where I derive the public key using 
EC_POINT_mul(). The sample program omits error checking, but in the production 
code no errors are reported.

Does anyone see a flaw in my logic, especially in how I’m deriving the public 
key from the private key? Also let me know if this would be better submitted as 
a GitHub issue, or even if it needs to be handled as a paid support request.

Thanks,
Mike



ec_key_example.cxx
Description: Binary data
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Of course OpenSSL contains hand-optimized assembly routines.  However, GMP
has been around since at least 1993 and the library specifically targets
heavily optimized multiple precision arithmetic.  OpenSSL is a TLS/SSL
toolkit, and necessarily focuses on implementing SSL/TLS correctly - I'd
argue that the bigint subsystem is almost tangential to the other parts of
any SSL library.  A less optimized bigint subsystem should be reasonably
expected.  I would be surprised if the native bigint code could compete
against GMP performance-wise, even when OpenSSL's optimized assembly code
is used.  I haven't benchmarked OpenSSL's bigint subsystem and would be
interested in seeing a comparison against a correctly configured GMP.

On Tue, Feb 7, 2017 at 4:46 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:

> OpenSSL also has a lot of handwritten assembly language for ARM,
> x86 etc.  Most of it written by Andy Polyakov.
>
> His response about what can and cannot be done on various ARM CPU
> models is most probably a result of this work.
>
> Also, OpenSSL has a more permissive license than the GMP, so using
> GMP in OpenSSL would cause problems for many OpenSSL using
> applications.
>
> On 08/02/2017 00:31, Mike Mohr wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code
>> and the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander" <vijay.chan...@gmail.com
>> <mailto:vijay.chan...@gmail.com>> wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a
>> lower priority).
>>
>> Thanks,
>> -vijay
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov <ap...@openssl.org
>> <mailto:ap...@openssl.org>> wrote:
>>
>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>> hopefully
>> > get down to -1:5.
>>
>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>> that is).
>> Which I'd say is a fair result. Well, still could have been a bit
>> better, but it's not unreasonable given ISA differences. Keep
>> in mind
>> that presented x86_64 result is for code utilizing
>> Intel-specific code
>> extensions.
>>
>> > There is no L3 cache on the A72 eval board and performance
>> counters do
>> > show 9x more DRAM accesses for ARM compared to x86.
>>
>> This is unexpected, because it takes *less* references to
>> memory to
>> perform it on ARMv8. Because it has larger register bank. And
>> cache
>> requirement is not that high for L3 to kick in... But at any
>> case memory
>> is not bottleneck here...
>>
>>
>
> --
> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10  +4531131610>
> This message is only for its intended recipient, delete if misaddressed.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Licensing issues are indeed thorny. Why can't openssl perform a dynamic
link? The soversion should handle any ABI issues introduced in later
versions of GMP.

Are you cross compiling GMP for your use on a target device? If so, you'll
need to ensure that the MPN_PATH is set appropriately. If you don't do so,
you'll get the generic c code instead of optimized assembly routines. The
performance difference can be dramatic, potentially several orders of
magnitude. I had to deal with this myself when cross compiling GMP for
Android.

On Feb 7, 2017 4:51 PM, "Vijay Chander" <vijay.chan...@gmail.com> wrote:

Yes. Already took Andy's word from his previous replies for precisely this
reason.

GMP exercise was easy enough to get it out of the way.

Thanks,
Vijay

On Feb 7, 2017 4:46 PM, "Jakob Bohm" <jb-open...@wisemo.com> wrote:

> OpenSSL also has a lot of handwritten assembly language for ARM,
> x86 etc.  Most of it written by Andy Polyakov.
>
> His response about what can and cannot be done on various ARM CPU
> models is most probably a result of this work.
>
> Also, OpenSSL has a more permissive license than the GMP, so using
> GMP in OpenSSL would cause problems for many OpenSSL using
> applications.
>
> On 08/02/2017 00:31, Mike Mohr wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code
>> and the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander" <vijay.chan...@gmail.com
>> <mailto:vijay.chan...@gmail.com>> wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a
>> lower priority).
>>
>> Thanks,
>> -vijay
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov <ap...@openssl.org
>> <mailto:ap...@openssl.org>> wrote:
>>
>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>> hopefully
>> > get down to -1:5.
>>
>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>> that is).
>> Which I'd say is a fair result. Well, still could have been a bit
>> better, but it's not unreasonable given ISA differences. Keep
>> in mind
>> that presented x86_64 result is for code utilizing
>> Intel-specific code
>> extensions.
>>
>> > There is no L3 cache on the A72 eval board and performance
>> counters do
>> > show 9x more DRAM accesses for ARM compared to x86.
>>
>> This is unexpected, because it takes *less* references to
>> memory to
>> perform it on ARMv8. Because it has larger register bank. And
>> cache
>> requirement is not that high for L3 to kick in... But at any
>> case memory
>> is not bottleneck here...
>>
>>
>
> --
> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10  +4531131610>
> This message is only for its intended recipient, delete if misaddressed.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Have you considered using GMP as a big integer backed for openssl?  It has
support for several arm variants using handwritten assembly code and the
developers go to great lengths to find optimize runtime on all supported
platforms.

On Feb 7, 2017 2:26 PM, "Vijay Chander"  wrote:

Andy,
   1:2.5 is pretty in my opinion for ARM !

   We  will check out Mongoose.

   Hmm - will try to get to the bottom of those cache misses (at a lower
priority).

Thanks,
-vijay



On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov  wrote:

> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
> > get down to -1:5.
>
> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
> Which I'd say is a fair result. Well, still could have been a bit
> better, but it's not unreasonable given ISA differences. Keep in mind
> that presented x86_64 result is for code utilizing Intel-specific code
> extensions.
>
> > There is no L3 cache on the A72 eval board and performance counters do
> > show 9x more DRAM accesses for ARM compared to x86.
>
> This is unexpected, because it takes *less* references to memory to
> perform it on ARMv8. Because it has larger register bank. And cache
> requirement is not that high for L3 to kick in... But at any case memory
> is not bottleneck here...
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] good riddance to PayPal

[Mike]

On Fri, 6 May 2016 08:06:48 -0400
Steve Marquess <marqu...@openssl.com> wrote:

> On 05/06/2016 07:45 AM, Salz, Rich wrote:
> >> Consider having the non-U.S. person do the account setup too.
> >>
> >> Banks are as scared of US jurisdiction as crypto engineers.
> > 
> > Yeah, we've done that.  Even to the point where one of the team was
> > going to get on a plane to fly to the Isle of Mann.
> > 
> > It's amazingly painful and difficult and so far not productive.
> > 
> > ...
> 
> FATCA means that no "U.S. person" can have any access to the bank
> account; we are well and painfully aware of that, and it's not a
> problem. Only three of us fall in that category anyway; OpenSSL is
> not a U.S. centric organization. Our U.S. connections are only due to
> the circumstantial fact that the OpenSSL team member (me) who
> initially set up our banking arrangements happened to be American.
> 

Lower left column:
https://www.irs.gov/Businesses/Corporations/Foreign-Account-Tax-Compliance-Act-FATCA

You just have to love that:
...in addition to FoBAR reporting.  ;)

= = = = =

Seriously,
As copyright owners you can rescind license permissions as you wish.

Contact this person:
https://www.irs.gov/uac/Commissioner-John-Koskinen
and give them 30 days to purge any and all use of OpenSSL from the
irs.gov network.
A specific license withdrawal.

You should at least be able to start a useful conversation that way.

Mike

> -Steve M.
> 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] TLS 1.2 Client hello missing SessionTicket

[Mike Gagnon]

Hi Folks,

I'm working on an issue where something seems to be going wrong with our 
internal state after a while, and one of our sessions will have suddenly lost 
its SessionTicket during the Client Hello.

To debug the issue, I'm wondering if someone can point me to the right internal 
variable in openssl that I might want to put a data breakpoint on so I can see 
the call stack that led to the problem.  A wireshark trace shows that the 
SessionTicket length is zero when the problem occurs.

Thanks for any suggestions,

Mike
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Mike Mohr]

During the linking process, parts of fipscanister.o are removed (discarded)
by the linker. Also, jumps and call instructions have their operands
changed (addresses are filled in or relocation information is added) and
the machine code is fundamentally altered.

Imagine the linking process as something analogous to baking a cheese
quiche with tomatoes. The can of tomatoes you use (i.e., the fipscanister.o
file) is opened. The metal can is discarded along with any liquid inside
the can. Then the tomatoes are placed into the quiche and baked. Melting
cheese seeps into the tomatoes and the tomatoes are physically deformed and
soften. At the end you have a delicious quiche. Can you get the original
can of tomatoes back, in its unmodified form, at this point? Can you
identify exactly which can of tomatoes was used to make this quiche, given
only photos of all the cans prior to opening them?
On Mar 15, 2016 11:22 AM, "Satya Das"  wrote:

> Hello Steve,
>
> Thank you for your comments.
>
> Is there a way to verify that the correct version of object module
> (fipscanister.o) was assimilated into the libcrypto.so ?
> I just need some surefire way to run an engineering check on the build.
> Essentially what my question boils down to, is
> that there is code in there somewhere that comes up with the run time hash
> and compares with the embedded hash.
> Is there a way to use those code pieces to somehow double check that the
> embedded hash matches the object module that
> libcrypto should have been linked to ?
>
> Please note that I am not automating the build, which has been discouraged
> in the User Guide
> (yes I have read probably around 40% of it). However because of the
> complex build flow I want
> to have a post build manual check before using the openssl rpm in rest of
> the product.
>
> Thanks
>
> 
> From: openssl-users  on behalf of
> Steve Marquess 
> Sent: Tuesday, March 15, 2016 6:02 AM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
>
> On 03/14/2016 08:30 PM, Satya Das wrote:
> > Hello,
> >
> >
> >
> > I have a simple problem I am trying to solve. I have built a fips
> > capable openssl shared object (.so). I also have the sha1 hash of the
> > fipscanister.o in a file called fipscanister.o.sha1. I also have the
> > sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In
> > order to make sure the build is good, I want to make sure that the .so
> > was indeed built with these versions of fipscanister.o and fips_premain.
> >
> >
> >
> > Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> > object module 2.0.11 from openssl 1.0.1e with patches.
>
> H.  Several comments:
>
> 1) Please read the OpenSSL FIPS User Guide,
> https://openssl.org/docs/fips/UserGuide-2.0.pdf. It answers most (I
> would even say all) of your questions. Yes, it's a long dull slog to
> read but then open source FIPS 140-2 is a horribly convoluted topic.
>
> 2) The libcrypto shared library is just an application in the context of
> FIPS 140-2, and in general you're not going to be able to reconstruct an
> object module file (foo.o) from an executable binary image that was
> built from it. Nor is there any FIPS 140-2 related requirement to do so.
>
> 3) The fipscanister.o file is a little bit more (and less) that your
> typical object module ("module" in the usual software engineering sense.
> It is discussed in the OpenSSL FIPS User Guide, in particular section
> 2.3.2.
>
> Note the SHA1 digest of the libcrypto shared library file, or of any
> other application, is completely irrelevant to FIPS 140-2. In fact the
> CMVP specifically disallowed any integrity test that contained such
> "extraneous" data (see section 2.3.1). We were told at the time that was
> because of the risk of SHA1 digest collision.
>
> 3) The "file integrity chain" (section 2.4) requires that the interim
> files created from the official source distribution tarball be verified
> using SHA1 hashes. Somewhat oddly, given the rather intense focus on
> ideological righteousness elsewhere, you're allowed to do this with an
> un-sanctified SHA1 implementation. Notice for instance that the stock
> build process uses an interim utility ("./fips/fips_standalone_sha1")
> built from the same code as used in the FIPS module.
>
> Also note that this is first and foremost a procedural or paperwork
> chain. You can have two software products that claim to use FIPS 140-2
> validated crypto, and those can be bit-for bit identical, yet with one
> satisfying the FIPS 140-2 validation requirements and one not; no
> conceivable technical test can distinguish them (we call this difference
> FIPS "magical pixie dust").
>
> 4) The canonical FIPS module integrity test, common to all FIPS modules,
> takes the form of the "incore integrity 

Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Mike Mohr]

During the final linking stage, when the shared object is built, the
compiler is free to insert functions from compiled object files anywhere it
sees fit in the final shared object's code segment.  The object file is
fundamentally transformed by this process; information which was present in
the original object file may or may not end up in the resulting shared
object.  Although the machine code in the subroutines should be copied into
the final shared object unmodified, the original object file is effectively
gone and cannot be recovered.  Without the original object file, we cannot
calculate its cryptographic hash.

"As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance."

Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
page 163). Carbondale, IL: Southern Illinois University Press.

On Mon, Mar 14, 2016 at 9:26 PM, Satya Das  wrote:

> Hello Ethan,
>
> I am tweaking the centos rpmspec to use my fips object module.  That seems
> to be downloading source tar ball, patching etc.
>
> Please note that the sha1 of the so is not so interesting as the embedded
> sha1 check inside so (when one calls FIPS_mode_set). Essentially if I can
> get the embedded sha1in the so, I can compare that with the sha1 I have as
> part of the object module I have built. I am assuming the embedded sha1 is
> that of fipscanister.o.
>
> Hope that makes sense ?
>
> Thanks.
>
>
> From: Ethan Rahn
> Sent: Monday, March 14, 6:11 PM
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> To: openssl-users@openssl.org
>
> Is there a reason why you cannot build it from a controlled build
> environment and record the hash of the final .so?
>
> It seems that it would be pretty non-trivial if not impossible to pull a
> .o file from a .so in the exact same format that it went in, such that you
> could check the hash. Being able to check if a .c file is in the same state
> in the .so afterwards seems pretty much impossible given all the things
> that would change in the code with compiling and linking in between the .c
> state and the final .so state.
>
> On Mon, Mar 14, 2016 at 5:30 PM, Satya Das 
> wrote:
>
> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips capable
> openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1
> hash of fips_premain.c in a file called fips_premain.c.sha1. In order to
> make sure the build is good, I want to make sure that the .so was indeed
> built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.
>
>
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https
> ://
> mta.openssl.org
> /mailman/
> listinfo
> /
> openssl-users
> 
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] glibc detected *** xxx: double free or corruption (!prev): 0x097b8750

[Mike Mohr]

You'll need to rebuild your application and openssl with debugging symbols
and no optimization, then run it inside gdb to produce a more useful stack
trace. Since you don't include any context or source code snippets it isn't
really possible to help. Can you produce a reduced test case with source
code which reproduces the bug?

As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance.

John Dewey: The Later Works, 1925-1953; Volume 6, pp. 163
On Feb 24, 2016 11:33 PM, "Vikas TM"  wrote:

> Hi,
>
> While running my application with openSSL 102d and I encountered double
> free error or corruption.
>
> As per few threads suggestion, I have changed getpid() with pthread_self()
> in CRYPTO_thread_id(). Still the result is same.
>
> Please let me know if any fix available to this issue.
>
> *** glibc detected *** xxx: double free or corruption (!prev): 0x097b8750
> ***
>
> === Backtrace: =
>
> /lib/libc.so.6[0x1768b6]
>
> /lib/libc.so.6(cfree+0x90)[0x179e00]
>
> xxx(CRYPTO_free+0x3a)[0x81b89be]
>
> xxx(ssl_cert_free+0x13f)[0x826fa23]
>
> xxx(SSL_free+0x14d)[0x81d7e08]
>
> Thanks & Regards,
> Vikas
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] using a random number file for generation of keys/certificates

[Mike Mohr]

Once you've written the random data to secondary storage you've permanently
compromised the integrity of any cryptographic secrets generated from it.
Depending on your threat model, underlying storage media, filesystem, and
other factors the data files may be recoverable indefinitely (especially if
you're using solid-state disks, due to their internal wear-leveling
algorithms).  Don't do that.

The cryptographic secrets contained in your existing CA infrastructure were
presumably generated using some sort of PRNG, so you'd have to regenerate
them if you think the PRNG was somehow compromised.  If not, you can use
the TRNG for all newly issued certificates moving forward.  However, I'd
suggest not using one of the proprietary devices which are encased in epoxy
... you have no way to verify that they're doing what they say they are.
The data quality coming out of those is fairly suspect in my mind (despite
any positive results from e.g. dieharder, etc).

On Wed, Sep 2, 2015 at 9:53 PM, Kevin Long  wrote:

>
>
> Hello,
>
> I’m using openssl to administer a root/intermediate CA  and I use the
> certificates for a number of web servers and other applications. All of my
> users install my root CA certificate for trust.
>
> I’ve been asked to use a hardware random number generator to create the
> keys/certificates going forward. I have a hardware RNG, and have created
> several files of random numbers using it, and I would like to know:
>
> 1) Can I specify my random numbers file to create keys/certificates from
> my CA (openssl command line, mac or linux)
>
> 2) Will this actually do any good, security wise,  given how openssl
> certs/keys “work”.  My users and superiors are concerned with backdoors in
> PRNGs and RNG predictabilities.
>
> 3) If I can indeed use my own random numbers, does this mean I have to
> start my CA from scratch to take advantage of any benefit using “true”
> random numbers from my hardware RNG? or would simply using my RN’s for the
> generation of  keys for new certificates going forward allow for the
> benefit the true randomness gives.
>
> Thank you.
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Regarding the security of the keys

[Mike Mohr]

On Tue, Jul 21, 2015 at 9:46 PM, Salz, Rich rs...@akamai.com wrote:


  Actually that isn't quite right.  A properly configured and
 tuned RBAC policy, when combined with PaX, can very effectively limit all
 userspace activity (including root access!).

 How do you know that the module is installed and actually doing things?
 How do you know what kernel is actually booted?


Of course you're right.  One might also consider attack vectors from an
unsecured BMC or the IME - they probably have undetectable DMA access to
the host, after all.  But that isn't the point ... steps can and should be
taken to lock down the host operating system.



  It helps if you can also use a hardware security module to protect your
 key material.

 How do you know that the operations that YOU request are actually the ones
 being performed?  How do you know that the operating system isn't making
 additional requests of its own?

 You have to trust root.  No two ways about it.


The first question has no bearing on the second statement.  With or without
grsecurity/selinux, you have no way to guarantee that the kernel is
operating the way you expect it to at any given time.  I suppose it boils
down to the threat model.  However, limiting root's power is a good idea,
and grsecurity provides an excellent framework in which to do so.  Caveat
emptor.



 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Regarding the security of the keys

[Mike Mohr]

Actually that isn't quite right.  A properly configured and tuned RBAC
https://en.wikipedia.org/wiki/Grsecurity#Role-based_access_control policy,
when combined with PaX https://en.wikipedia.org/wiki/Grsecurity#PaX, can
very effectively limit all userspace activity (including root access!).  It
helps if you can also use a hardware security module
https://en.wikipedia.org/wiki/Hardware_security_module to protect your
key material.

On Tue, Jul 21, 2015 at 1:48 AM, Salz, Rich rs...@akamai.com wrote:

  If some one build their own openssl and add few lines to print the keys
 during encrypt and decrypt and put in the library in the LD_LIBRARY_PATH,
 may result in compromising the security of the keys.

 Can anyone other than root do this?  You have to trust root.  They could
 just cat your keyfile anyway.

 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Regarding the security of the keys

[Mike Mohr]

Securing a system against this kind of attack can be done in several ways,
depending on the level of assurance you desire.  You might start out with
Tripwire:

https://en.wikipedia.org/wiki/Open_Source_Tripwire
http://www.tripwire.org/

You could also implement mandatory access control and ACLs using either
grsecurity or SELinux:

http://grsecurity.net/
http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf
https://en.wikipedia.org/wiki/Security-Enhanced_Linux

Personally I prefer grsecurity, but it is not supported in mainline by any
major distribution that I am aware of.  You'll have to patch, build, and
and support your own kernel image in order to use it.  SELinux is supported
out of the box on CentOS 6 and 7, so it would probably be a good place to
start.

If your concern is solely in the realm of protecting your RSA keys, you
might consider some HSM product from e.g. Yubico:

https://www.yubico.com/
https://en.wikipedia.org/wiki/Hardware_security_module

These tiny USB keys store the RSA keys on a secure element which is
physically tamper-resistant.  The key material never leaves the hardware
token.  However, you'd probably have to write a custom provider for
OpenSSL, and the throughput would probably only be sufficient for a very
small amount of traffic.  If you need something that can handle a higher
load, you might consider purchasing one of Cavium's cards:

http://www.cavium.com/overview.html

However, they are 10 gigabit passthrough devices and will unwrap / re-wrap
the SSL session in hardware.  They are not cheap.

Good luck!


On Mon, Jul 20, 2015 at 11:46 PM, James james.arivazha...@gmail.com wrote:

 Hi there,
 I have a concern regarding the private keys we use in the https (say
 apache) server.
 The https server links with openssl.so file, and uses the APIs provided by
 it.
 If some one build their own openssl and add few lines to print the keys
 during encrypt and decrypt and put in the library in the LD_LIBRARY_PATH,
 may result in compromising the security of the keys.

 Does any of you faced this problem and if you could share the solution it
 would be helpful.

 regards,
 James Arivazhagan Ponnusamy

 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Stand alone AES-CTR module

[Mike Mohr]

If you don't know about list comprehension in Python, you can simply
construct a list in a loop to get the job done.  The end result is the same
no matter which approach you take.

The same is not true for cryptography.  While Sec_Aficionado is quite
eloquent and makes several valid points, I think his overall argument does
not hold water.  I have audited the crypto implementations in a number of
open-source projects over the years found wide variance in their quality.
In one instance a popular piece of software included a feature which
claimed to encrypt its data using AES-256.  It turned out that the code
copied the user's password directly into the key buffer, either padding
with null bytes or truncating depending on the length.  The data was then
encrypted using AES-256 in ECB mode.  The software's primary purpose was
not cryptography, and it provided innovative and creative features
otherwise.  This type of bug is insidious, since it doesn't really protect
the data in any meaningful way and lulls its users into a false sense of
security.

I am not advocating that the realm of information security be forever
relegated to a select few.  That is also dangerous, as Sec_Aficionado
correctly pointed out.  However, the study of cryptography should never be
undertaken without the guidance of an experienced practitioner.  I had the
extraordinary opportunity to study information security at university under
the guidance of an ex-NSA analyst.  I recognize that I am extremely lucky
to have had this chance, and that this kind of education is only available
to a select set of people worldwide.  I also don't have a solution to the
problem of training the next generation of cryptographers.  However, having
yet another potentially compromised AES implementation written by a novice
programmer is not something that I want to encourage.

On Mon, May 11, 2015 at 6:12 AM, Sec_Aficionado secaficion...@gmail.com
wrote:

 While implementing one's own security and/or cryptography is certainly not
 advisable for a novice (or even advanced programmers), creating cipher
 implementations from scratch is probably one of the best ways to learn and
 understand the intricacies of the problem at hand.

 Learning about the pitfalls and advantages of the algorithms is key for a
 future security expert. Moreover, denying someone access to help on an open
 source project is antithetical to the OSS philosophy. How can anyone hope
 to understand code that by its very nature is cryptic and complex if
 there's no one willing to help disentangle, at least at a high level, the
 routines and functions?

 InfoSec is a black art today, but it needs to get out of that mode. After
 the last few years it is clear that unless we open up the understanding of
 these disciplines, we will be at the mercy of experts with hidden agendas.
 Only educated users can hope to make correct use of cryptography, or be
 able to choose the best application for their needs. As we know, even a
 robust cipher is useless if utilized for the wrong purpose or poorly
 configured. We can't turn away those with a genuine interest in learning
 how to use cryptography without dooming ourselves to continue with the
 status quo.

 I appeal to those of you who routinely share your knowledge and try to
 make a difference here, that you provide some guidance and not turn away
 people with basic questions like this one. These are the users who may
 become one day contributors. They should be nurtured and not shunned.

 OK, I'll get off my soapbox now. Have a great week everyone.

 On May 10, 2015, at 5:58 PM, Mike Mohr akih...@gmail.com wrote:

 The task of implementing AES should not be undertaken by a novice
 programmer.  Please save the world another heartbleed and pick something
 more in line with your skill level.
 On May 10, 2015 11:48 AM, konstantinos Alexiou 
 konstantinako...@gmail.com wrote:

 Dear Sirs,


 I am new to C programming and i am trying to create an independent to
 libraries source code for demonstration purposes for AES-CTR mode.Could i
 have some help on doing that using the source code contained under
 crypto/aes.


 Thank you very much in advance.

 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Stand alone AES-CTR module

[Mike Mohr]

The task of implementing AES should not be undertaken by a novice
programmer.  Please save the world another heartbleed and pick something
more in line with your skill level.
On May 10, 2015 11:48 AM, konstantinos Alexiou konstantinako...@gmail.com
wrote:

 Dear Sirs,


 I am new to C programming and i am trying to create an independent to
 libraries source code for demonstration purposes for AES-CTR mode.Could i
 have some help on doing that using the source code contained under
 crypto/aes.


 Thank you very much in advance.

 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.0.1 upgrade issue

[Mike Collins]

Created a new toolchain with crosstool-ng using glibc 2.13, gcc 4.9.1,
binutils 2.22 and headers 2.6.27.

Using the new toolchain v1.0.1l seems to now work on my board although I
will have to do some more in depth testing. My guess is it was a glibc
issue but am not positive. I am limited to glibc 2.13 due to constraints
with the Busybox version I am using.

Thanks for the help and suggestions.

Mike


On 2/18/2015 8:03 AM, Mike Collins wrote:

My build script is doing the same.

Not sure where to go next except to update libc to a newer version. Due to
the toolchain (not created by me) it may be a major undertaking.

Mike

From: Jay Foster jayf0s...@roadrunner.com
To: openssl-users@openssl.org
Cc:
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you skipping
the 'make depend' step?  My build script does, './Configure args', 'make
depend', 'make'.

Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or kernel
version? I am currently building against libc version 2.5 with the kernel
at 2.6.30.

Mike

-- Forwarded message --
From: Jay Foster jayf0s...@roadrunner.com
To: openssl-users@openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an
ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others).  I found that it works with and without
the ARM assembly accelerations (no-asm option), even though the ARM926EJ is
an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I
assume you are also using the appropriate '--cross-compile-prefix=prefix'
option.   You might try adding -mlittle-endian -mcpu=arm926ej-s
-DL_ENDIAN to the CFLAGS, although that should be redundant (the compiler
should already know this).  Also, make sure there are no '-nostdinc' (or
similar) type compiler options creeping in.  These change the search order
of header files, which can cause OpenSSL to be built against the (old)
headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a'
command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:

I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a
requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using openssl
genrsa -out testkey.pem 2048 I get a response of Generating RSA private
key, 2048 bit long modulus. At this point it seems to get stuck in a loop;
I am seeing the progress indicators (.) but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

Mike
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.0.1 upgrade issue

[Mike Collins]

Thanks Jay.

My build script is doing the same.

Not sure where to go next except to update libc to a newer version. Due to
the toolchain (not created by me) it may be a major undertaking.

Mike

From: Jay Foster jayf0s...@roadrunner.com
To: openssl-users@openssl.org
Cc:
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you skipping
the 'make depend' step?  My build script does, './Configure args', 'make
depend', 'make'.

Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or kernel
version? I am currently building against libc version 2.5 with the kernel
at 2.6.30.

Mike

-- Forwarded message --
From: Jay Foster jayf0s...@roadrunner.com
To: openssl-users@openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an
ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others).  I found that it works with and without
the ARM assembly accelerations (no-asm option), even though the ARM926EJ is
an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I
assume you are also using the appropriate '--cross-compile-prefix=prefix'
option.   You might try adding -mlittle-endian -mcpu=arm926ej-s
-DL_ENDIAN to the CFLAGS, although that should be redundant (the compiler
should already know this).  Also, make sure there are no '-nostdinc' (or
similar) type compiler options creeping in.  These change the search order
of header files, which can cause OpenSSL to be built against the (old)
headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a'
command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:

I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a
requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using openssl
genrsa -out testkey.pem 2048 I get a response of Generating RSA private
key, 2048 bit long modulus. At this point it seems to get stuck in a loop;
I am seeing the progress indicators (.) but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

Mike
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.0.1 upgrade issue

[Mike Collins]

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or kernel
version? I am currently building against libc version 2.5 with the kernel
at 2.6.30.

Mike

-- Forwarded message --
From: Jay Foster jayf0s...@roadrunner.com
To: openssl-users@openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an
ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others).  I found that it works with and without
the ARM assembly accelerations (no-asm option), even though the ARM926EJ is
an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I
assume you are also using the appropriate '--cross-compile-prefix=prefix'
option.   You might try adding -mlittle-endian -mcpu=arm926ej-s
-DL_ENDIAN to the CFLAGS, although that should be redundant (the compiler
should already know this).  Also, make sure there are no '-nostdinc' (or
similar) type compiler options creeping in.  These change the search order
of header files, which can cause OpenSSL to be built against the (old)
headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a'
command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:
 I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to
a requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

 Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

 I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using openssl
genrsa -out testkey.pem 2048 I get a response of Generating RSA private
key, 2048 bit long modulus. At this point it seems to get stuck in a loop;
I am seeing the progress indicators (.) but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

 I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

 I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

 Mike
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 1.0.1 upgrade issue

[Mike Collins]

I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a
requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using openssl
genrsa -out testkey.pem 2048 I get a response of Generating RSA private
key, 2048 bit long modulus. At this point it seems to get stuck in a loop;
I am seeing the progress indicators (.) but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

Mike
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: Still one outstanding issue sine 20140909 releases

[Mike Bland]

As I mentioned a few days ago, can you tell whether the top-level
'rehash' target is getting executed as a prerequisite? Can you try
execting 'make rehash  make test' to see if that fixes the problem?
I suggest this because this looks very similar to an error I
encountered during my build system work.

Mike


On Thu, Sep 11, 2014 at 2:20 PM, The Doctor doc...@doctor.nl2k.ab.ca wrote:

 Script started on Thu Sep 11 11:27:05 2014
 doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20140911$ make test
 testing...
 (cd ..; make DIRS=crypto all)
 making all in crypto...
 ar  r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o 
 cpt_err.o ebcdic.o  uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o 
 fips_ers.o mem_clr.o
 test -z  || ar  r ../libcrypto.a fipscanister.o
 /usr/bin/ranlib ../libcrypto.a || echo Never mind.
 making all in crypto/objects...
 making all in crypto/md2...
 making all in crypto/md4...
 making all in crypto/md5...
 making all in crypto/sha...
 making all in crypto/mdc2...
 making all in crypto/hmac...
 making all in crypto/ripemd...
 making all in crypto/whrlpool...
 making all in crypto/des...
 making all in crypto/aes...
 making all in crypto/rc2...
 making all in crypto/rc4...
 making all in crypto/rc5...
 making all in crypto/idea...
 making all in crypto/bf...
 making all in crypto/cast...
 making all in crypto/camellia...
 making all in crypto/seed...
 making all in crypto/modes...
 making all in crypto/bn...
 making all in crypto/ec...
 making all in crypto/rsa...
 making all in crypto/dsa...
 making all in crypto/ecdsa...
 making all in crypto/dh...
 making all in crypto/ecdh...
 making all in crypto/dso...
 making all in crypto/engine...
 making all in crypto/buffer...
 making all in crypto/bio...
 making all in crypto/stack...
 making all in crypto/lhash...
 making all in crypto/rand...
 making all in crypto/err...
 making all in crypto/evp...
 making all in crypto/asn1...
 making all in crypto/pem...
 making all in crypto/x509...
 making all in crypto/x509v3...
 making all in crypto/conf...
 making all in crypto/txt_db...
 making all in crypto/pkcs7...
 making all in crypto/pkcs12...
 making all in crypto/comp...
 making all in crypto/ocsp...
 making all in crypto/ui...
 making all in crypto/krb5...
 making all in crypto/cms...
 making all in crypto/pqueue...
 making all in crypto/ts...
 making all in crypto/jpake...
 making all in crypto/srp...
 making all in crypto/store...
 making all in crypto/cmac...
 if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then  (cd ..; make 
 libcrypto.so.1.0.0);  fi
 [ -z  ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
 -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 
 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
 -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
 -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  
 -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c 
 fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
 ( :;LIBDEPS=${LIBDEPS:-../libssl.a ../libcrypto.a  -lgmp -ldl -lm -lc}; 
  LDCMD=${LDCMD:-gcc3}; LDFLAGS=${LDFLAGS:--fPIC -DOPENSSL_PIC 
 -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT 
 -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer 
 -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
 -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM};  LIBPATH=`for x 
 in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;  
 LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`;  
 LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH  ${LDCMD} ${LDFLAGS} -o 
 ${APPNAME:=heartbeat_test} heartbeat_test.o ${LIBDEPS} )
 making all in apps...
 (cd ..; make DIRS=crypto all)
 making all in crypto...
 ar  r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o 
 cpt_err.o ebcdic.o  uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o 
 fips_ers.o mem_clr.o
 test -z  || ar  r ../libcrypto.a fipscanister.o
 /usr/bin/ranlib ../libcrypto.a || echo Never mind.
 making all in crypto/objects...
 making all in crypto/md2...
 making all in crypto/md4...
 making all in crypto/md5...
 making all in crypto/sha...
 making all in crypto/mdc2...
 making all in crypto/hmac...
 making all in crypto/ripemd...
 making all in crypto/whrlpool...
 making all in crypto/des...
 making all in crypto/aes...
 making all in crypto/rc2...
 making all in crypto/rc4...
 making all in crypto/rc5...
 making all in crypto/idea...
 making all in crypto/bf...
 making all in crypto/cast...
 making all in crypto/camellia...
 making all in crypto/seed...
 making all in crypto/modes...
 making all in crypto/bn...
 making all

Re: OPenssl 20140909 issues

[Mike Bland]

Is the top-level rehash target not getting executed? It should be a
dependency of test (via the tests target).

Mike

On Tue, Sep 9, 2014 at 1:41 AM, The Doctor doc...@doctor.nl2k.ab.ca wrote:
 Just found this in the latest openssl 1.0.2 snapshot


 Script started on Mon Sep  8 23:19:16 2014
 doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20140909$ make test
 testing...
 (cd ..; make DIRS=crypto all)
 making all in crypto...
 ar  r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o 
 cpt_err.o ebcdic.o  uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o 
 fips_ers.o mem_clr.o
 test -z  || ar  r ../libcrypto.a fipscanister.o
 /usr/bin/ranlib ../libcrypto.a || echo Never mind.
 making all in crypto/objects...
 making all in crypto/md2...
 making all in crypto/md4...
 making all in crypto/md5...
 making all in crypto/sha...
 making all in crypto/mdc2...
 making all in crypto/hmac...
 making all in crypto/ripemd...
 making all in crypto/whrlpool...
 making all in crypto/des...
 making all in crypto/aes...
 making all in crypto/rc2...
 making all in crypto/rc4...
 making all in crypto/rc5...
 making all in crypto/idea...
 making all in crypto/bf...
 making all in crypto/cast...
 making all in crypto/camellia...
 making all in crypto/seed...
 making all in crypto/modes...
 making all in crypto/bn...
 making all in crypto/ec...
 making all in crypto/rsa...
 making all in crypto/dsa...
 making all in crypto/ecdsa...
 making all in crypto/dh...
 making all in crypto/ecdh...
 making all in crypto/dso...
 making all in crypto/engine...
 making all in crypto/buffer...
 making all in crypto/bio...
 making all in crypto/stack...
 making all in crypto/lhash...
 making all in crypto/rand...
 making all in crypto/err...
 making all in crypto/evp...
 making all in crypto/asn1...
 making all in crypto/pem...
 making all in crypto/x509...
 making all in crypto/x509v3...
 making all in crypto/conf...
 making all in crypto/txt_db...
 making all in crypto/pkcs7...
 making all in crypto/pkcs12...
 making all in crypto/comp...
 making all in crypto/ocsp...
 making all in crypto/ui...
 making all in crypto/krb5...
 making all in crypto/cms...
 making all in crypto/pqueue...
 making all in crypto/ts...
 making all in crypto/jpake...
 making all in crypto/srp...
 making all in crypto/store...
 making all in crypto/cmac...
 if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then  (cd ..; make 
 libcrypto.so.1.0.0);  fi
 [ -z  ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
 -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 
 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
 -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
 -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  
 -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c 
 fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
 (cd ..; make DIRS=ssl all)
 making all in ssl...
 if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then  (cd ..; make 
 libssl.so.1.0.0);  fi
 [ -z  ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
 -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 
 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
 -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
 -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  
 -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c 
 fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
 ( :;LIBDEPS=${LIBDEPS:-../libssl.a ../libcrypto.a  -lgmp -ldl -lm -lc}; 
  LDCMD=${LDCMD:-gcc3}; LDFLAGS=${LDFLAGS:--fPIC -DOPENSSL_PIC 
 -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT 
 -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer 
 -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
 -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM};  LIBPATH=`for x 
 in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;  
 LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`;  
 LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH  ${LDCMD} ${LDFLAGS} -o 
 ${APPNAME:=heartbeat_test} heartbeat_test.o ${LIBDEPS} )
 making all in apps...
 (cd ..; make DIRS=crypto all)
 making all in crypto...
 ar  r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o 
 cpt_err.o ebcdic.o  uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o 
 fips_ers.o mem_clr.o
 test -z  || ar  r ../libcrypto.a fipscanister.o
 /usr/bin/ranlib ../libcrypto.a || echo Never mind.
 making all in crypto/objects...
 making all in crypto

Re: OpenSSL 1.0.1h for android ?? Please help.

[Mike Mohr]

Openssl does not directly support Android AFAIR. You can try some manual
changes to e.g. CC or write your own make file.
On Jun 23, 2014 11:18 AM, Abhishek Gupta abhis...@meddiff.com wrote:

 Hello Users,

 I am at task to compile OpenSSL 1.0.1h for android platform and link it
 with an application.

 Can somebody give some pointers on how to do it. My problem is that there
 are no Android.mk files for this. And how can I user ndk-build here?

 Development env:
 1. Ubuntu 14.04 / 12.04
 2. Android NDK-r9d

 Regards
 Abhishek.

Re: OpenSSL version 1.0.1g fails to link on Win32

[Mike Bonnain]

Hi Geoffrey,

It's defined in e_os.h because it's been deprecated in Win8. Microsoft
wants you to use GetVersionEx() or VerifyVersionInfo(). Part of their plot
to convince us old-timers that the world is no longer flat and that COM is
actually a reasonable way to write code... Next thing they will tell us
will probably be that the earth is no longer the center of the universe.

-mike


On Thu, Apr 10, 2014 at 1:52 AM, Thomas J. Hruska 
shineli...@shininglightpro.com wrote:

 On 4/9/2014 8:03 PM, Jeremy Farrell wrote:

 Googling check_winnt suggests openssl/e_os.h.


 findstr /sic:check_winnt *

 Is, IMO, easier and more informative than using Google.  Results in:

 apps\apps.c:if (check_winnt())
 crypto\bio\bss_log.c:   if (check_winnt())
 crypto\cryptlib.c:if (check_winnt()  OPENSSL_isservice()  0)
 crypto\rand\rand_win.c:  if (check_winnt()  OPENSSL_isservice()0)
 e_os.h:#  define check_winnt() (1)
 e_os.h:#  define check_winnt() (GetVersion()  0x8000)

 Used four times, has two #defines.

 --
 Thomas Hruska
 Shining Light Productions

 Home of BMP2AVI and Win32 OpenSSL.
 http://www.slproweb.com/

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Anyone implementing RFC 7030: Enrollment over Secure Transport (EST)?

[Mike Luken (mluken)]

If you need access to this SW before we get it published (no ETA yet on
when it will be published), contact me and we can talk about getting it to
you via a no-cost license arrangement.

On 3/26/14 10:10 AM, John Foley (foleyj) fol...@cisco.com wrote:

We plan to publish an open source EST stack in the near future.  This
will support both client-side and server-side capabilities.  The code
will be hosted here:

https://github.com/cisco/libest

I've also recently setup an EST test server, which is available here:

http://ec2-54-204-91-178.compute-1.amazonaws.com/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Cross compiling 1.2.2 for the Analog Devices Blackfin -- FIPS_text_start()/FIPS_text_end() returns 0 on the target

[Mike Crowe]

Hi folks,

I'm almost out of my depth, and really need help on the next step.

I've that the in-system fingerprint comparison fails with a
FINGERPRINT_premain: FIPS_signature mismatch error

incore DEBUG=1 output gives:
=
TARGET: elf32-bfinfdpic
FIPS_rodata_end=000D5374
FIPS_rodata_start=000D00A0
FIPS_signature=00107F34
FIPS_text_end=000622F4
FIPS_text_start=0003CD28
FINGERPRINT_ascii_value=000D5D68
DOTrodata=000D00A0
DOTrodata_OFF=000D00A0
DOTtext=0003CAF0
DOTtext_OFF=0003CAF0
TSTART 568
TLEN 153036
TOFF 249132
INCORE_ADJUST 4
RSTART 0
RLEN 21204
ROFF 852128
FSTART 23752
FLEN 40
FOFF 875880
Signature is: 9b51309edb5d373a6f1e5b0c3cc8e554317539ae
=


I've created a test file to examine the various parameters.  On the
device, it shows:
=
Computed: c1133792c1ced10fadfe2ab6eb7946d79bfec490
HMAC_SHA1_SIG: 9b51309edb5d373a6f1e5b0c3cc8e554317539ae

FIPS_text_start(): 0
FIPS_text_end()=0
FIPS_rodata_start=48038048 (0x2DD00A0)
FIPS_rodata_end=48059252 (0x2DD5374)
=

So, I see these issues:
1) FIPS_text_start()/FIPS_text_end() returns 0
2) rodata start/end both offset by 0x2D0


Can anybody help point me to my next steps?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Cross compiling 1.2.2 for the Analog Devices Blackfin -- FIPS_text_start()/FIPS_text_end() returns 0 on the target

[Mike Crowe]

Hi Stacy, sorry, should have included that:


On Fri, Jan 17, 2014 at 12:17 PM, Stacy Devino childoftheh...@gmail.com wrote:
 Are you compiling for the uclinux distro or something similar?

ucLinux -- 2.6.34

 Are you using the 16 or 32-bit arch?

The blackfin is a 32-bit little-endian machine


 Are you utilizing the DSP or trying to?

Not utilizing DSP.  Running the FIPS code as-is.


A typical compile looks like:

bfin-linux-uclibc-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -O3
-fomit-frame-pointer -Wall -DHMAC_EXT=\${HMAC_EXT:-sha1}\ -DEMBED
-D__uClinux__ -I/opt/uclinux-usb34-rc5-bootecc-prod1  -mcpu=bf524-any
-c -o fips.o fips.c

The link for fipscanister looks like:

bfin-linux-uclibc-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -O3
-fomit-frame-pointer -Wall -DHMAC_EXT=sha1 -r -nostdlib -o
fipscanister.o fips_start.o fips.o ../crypto/aes/aes_cfb.o
../crypto/aes/aes_ecb.o ../crypto/aes/aes_ofb.o ../crypto/bn/bn_add.o
../crypto/bn/bn_blind.o ../crypto/bn/bn_ctx.o ../crypto/bn/bn_div.o
../crypto/bn/bn_exp2.o ../crypto/bn/bn_exp.o ../crypto/bn/bn_gcd.o
../crypto/bn/bn_lib.o ../crypto/bn/bn_mod.o ../crypto/bn/bn_mont.o
../crypto/bn/bn_mul.o ../crypto/bn/bn_prime.o ../crypto/bn/bn_rand.o
../crypto/bn/bn_recp.o ../crypto/bn/bn_shift.o ../crypto/bn/bn_sqr.o
../crypto/bn/bn_word.o ../crypto/bn/bn_x931p.o
../crypto/buffer/buf_str.o ../crypto/cryptlib.o
../crypto/des/cfb64ede.o ../crypto/des/cfb64enc.o
../crypto/des/cfb_enc.o ../crypto/des/ecb3_enc.o
../crypto/des/ecb_enc.o ../crypto/des/ofb64ede.o
../crypto/des/ofb64enc.o ../crypto/des/fcrypt.o
../crypto/des/set_key.o ../crypto/dsa/dsa_utl.o
../crypto/dsa/dsa_sign.o ../crypto/dsa/dsa_vrf.o ../crypto/err/err.o
../crypto/evp/digest.o ../crypto/evp/enc_min.o ../crypto/evp/e_aes.o
../crypto/evp/e_des3.o ../crypto/evp/p_sign.o ../crypto/evp/p_verify.o
../crypto/mem_clr.o ../crypto/mem.o ../crypto/rand/md_rand.o
../crypto/rand/rand_egd.o ../crypto/rand/randfile.o
../crypto/rand/rand_lib.o ../crypto/rand/rand_os2.o
../crypto/rand/rand_unix.o ../crypto/rand/rand_win.o
../crypto/rsa/rsa_lib.o ../crypto/rsa/rsa_none.o
../crypto/rsa/rsa_oaep.o ../crypto/rsa/rsa_pk1.o
../crypto/rsa/rsa_pss.o ../crypto/rsa/rsa_ssl.o
../crypto/rsa/rsa_x931.o ../crypto/sha/sha1dgst.o
../crypto/sha/sha256.o ../crypto/sha/sha512.o ../crypto/uid.o
../crypto/bn/bn_asm.o ../crypto/aes/aes_core.o ../crypto/aes/aes_cbc.o
../crypto/des/des_enc.o ../crypto/des/fcrypt_b.o
sha/fips_sha1_selftest.o hmac/fips_hmac.o hmac/fips_hmac_selftest.o
rand/fips_rand.o rand/fips_rand_selftest.o des/fips_des_selftest.o
aes/fips_aes_selftest.o dsa/fips_dsa_ossl.o dsa/fips_dsa_gen.o
dsa/fips_dsa_selftest.o dsa/fips_dsa_key.o dsa/fips_dsa_lib.o
dsa/fips_dsa_sign.o rsa/fips_rsa_eay.o rsa/fips_rsa_gen.o
rsa/fips_rsa_selftest.o rsa/fips_rsa_x931g.o rsa/fips_rsa_sign.o
rsa/fips_rsa_lib.o dh/fips_dh_check.o dh/fips_dh_gen.o
dh/fips_dh_key.o dh/fips_dh_lib.o fips_end.o
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Cross compiling 1.2.2 for the Analog Devices Blackfin -- FIPS_text_start()/FIPS_text_end() returns 0 on the target

[Mike Crowe]

Hi folks,

I've patched fips_canister.c to properly retrieve the blackfin
instruction pointer.  When I run openssl on the target now, I now get
reasonable numbers (though they still don't match incore).


===
root:/ OPENSSL_FIPS=1 openssl ciphers FIPS
SIG:
sig: 0x2e1f9e0
FIPS_text_start: 0x2d3cd88
FIPS_text_end=0x2d624cc
FIPS_rodata_start=0x2dd0294
FIPS_rodata_end=0x2dd5568
FIPS_signature=0x2e361fc

.text:0x2d3cd88+153412=0x2d624cc
.rodata:0x2dd0294+21204=0x2dd5568
Computed:   3098a7d1ede446fb5c4bef2d5568b7ea7edd2f68
HMAC_SHA1_SIG:  1f176a4fb51e3f477180c7d62f5af03c900d8e8c

FINGERPRINT_premain: FIPS_signature mismatch
===




FWIW, incore shows:
===
FIPS_rodata_end=000D5568
FIPS_rodata_start=000D0294
FIPS_signature=001081FC
FIPS_text_end=000624CC
FIPS_text_start=0003CD88
FINGERPRINT_ascii_value=000D6000
DOTrodata=000D0294
DOTrodata_OFF=000D0294
DOTtext=0003CB50
DOTtext_OFF=0003CB50
TSTART 568
TLEN 153412
TOFF 249216
INCORE_ADJUST -8
RSTART 0
RLEN 21204
ROFF 852628
FSTART 23916
FLEN 40
FOFF 876544
Signature is: 1f176a4fb51e3f477180c7d62f5af03c900d8e8c
===
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Documentation pointers

[Mike.]

On 10/4/2013 at 9:52 PM Dave Thompson wrote:

| From: owner-openssl-us...@openssl.org On Behalf Of Mike.
| Sent: Friday, October 04, 2013 16:28
|
| I have just started to learn OpenSSL, and I am having troubles
| finding documentation that is helpful.
| 
| www.openssl.org seems to have lots of reference documentation,
but
| not too much in usage documentation, e.g., what are the typical
| contents expected in the SAN for a CA cert vs. those of a server
| cert.
| 
|FWIW the first three sections under www.openssl.org/docs/ are
web-ized 
|copies of the man pages that exist on your own system if you
download 
|build and install on Unix, or probably if you install someone
else's 
|packaged build (rpm etc) (I don't know if it's possible to package
man 
|separately or not at all, but it would be very silly). On Windows 
|builds the manpages aren't normally done because Windows doesn't 
|usually have the pod+man infrastructure, but the pod files are in 
|sourcetree/doc/{apps,ssl,crypto} and not too hard to read if
needed.
|
| [snip]
=

Thanks very much for that most helpful answer.  I started to look at
what you mentioned, and am getting to the point that I know what I
need to look for in the docs, and I'm also starting to know where to
find it.  :)

Also, last night I looked back through the past few months of this
mailing list, and I found a link to this tutorial (
http://pki-tutorial.readthedocs.org/en/latest/ ) that has been
helpful to me.

Thanks again for your reply.

Mike.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Documentation pointers

[Mike.]

I have just started to learn OpenSSL, and I am having troubles
finding documentation that is helpful.

www.openssl.org seems to have lots of reference documentation, but
not too much in usage documentation, e.g., what are the typical
contents expected in the SAN for a CA cert vs. those of a server
cert.

My copy of O'Reilly's book on OpenSSL is well-used, but it is also
over ten years since it was printed.  

I've spent a lot of quality time in google, but that has yielded
lots and lots of websites, many with conflicting information, and
information that yields syntax errors when I try to implement it.


Basically, for example, what I want to do is understand the Setting
Up A Certificate Authority section of O'Reilly's book (starting on
page 59).   Excerpts of a config file are given, but with only
superficial information about the values contained in a config file.

I want to understand what commands invoke what v3 extension
sections, e.g., (example 3-5, page 65 in O'Reilly) when I invoke the
openssl req command to generate a CA csr, how does that translate
into the part of the config file that specifies what extensions will
be included in the csr?

Ditto for openssl req for a server csr.


All the pieces seem to be documented, but I am having difficulty
figuring out how the pieces fit together.

Does anyone know of a place where that next step is discussed and
explained?

Thanks.





__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: PKCS#1 key vs PKCS#8...

[mike pilato]

Remove

On Jun 5, 2013 9:08 AM, Dr. Stephen Henson st...@openssl.org wrote:

 On Tue, Jun 04, 2013, sanjaya joshi wrote:

  Hello,
I am using strongswan(v_4.5.3) for ipsec, that uses my X509 certificate
  and RSA private key.
  If i use RSA private key(un-encrypted) that is PKCS#8 encoded, then
  strongswan is not able to load the key. But it works, if i use a
  traditional PKCS#1 encoded RSA key.
 

 That's strange. If it uses the standard PEM routines to read in a private
 key
 OpenSSL should transparently handle PCKS#8 format.

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Why openssl disabling SO_KEEPALIVE for wrapped sockets?

[Mike Kazantsev]

Hello,


Looking into what disables SO_KEEPALIVE option on neon (webdav lib)
sockets, where I added enabling it after socket creation (done in
single place), I've found that openssl's apps/s_socket.c has the code
to explicitly disable keepalives for stream sockets.

Current code (init_client_ip function) goes like this:

  #if defined(SO_KEEPALIVE)  !defined(OPENSSL_SYS_MPE)
if (type == SOCK_STREAM)
{
i=0;
i=setsockopt(s,SOL_SOCKET,SO_KEEPALIVE,(char *)i,sizeof(i));
if (i  0) { perror(keepalive); return(0); }
}
  #endif


Seeking rationale for doing that, git-blame pointed to a huge commit
that did import of code from SSLeay, with no history (with possible
explaination) beyond that.

Looking at other ssl implementations' - gnutls and nss - code for the
same setsockopt (hopefully with comment about why it's there), I've
found no trace of tampering with it in either one.

Web search unfortunately also yielded no meaningful results.


So, I wonder, why openssl might want to explicitly disable it?

Does having SO_KEEPALIVE on has any known security implications?

Is it done because some code in openssl can't work reliably with that
option enabled (as so it's better to leave it disabled)?

Am I wrong about that particular code path and should look for
something else disabling keepalives - openssl doesn't do it?


Thanks in advance for any hints.


-- 
Mike Kazantsev // fraggod.net


signature.asc
Description: PGP signature

Re: Recommended/allowed private key lengths Reg.

[Mike Mohr]

Perhaps some on this list are better qualified than me to answer this
question, but this is my $0.02.

Generally speaking, higher-bit key lengths (than 2048) become much slower
when used on embedded hardware (even high-end smartphones).  In some cases
it may be impossible to support keys longer than 2048 bits due to hardware
constraints (i.e. smart meters, security cards, etc).  I believe that the
Fortinet firewalls support SSL offloading up to only 2048 bit key length.

On the other extreme, an 8192-bit RSA key for an Apache server will cause a
user-noticeable delay on an otherwise unloaded server while performing the
initial handshake.  Large numbers of sessions would bring such an
installation to its knees.  A denial of service attack would be easy to
accomplish against such a configuration.

A 4096-bit key seems a bit extreme as well, but is probably useful for
low-volume installations where key material must have high assurance.  Last
I heard, the largest key which has been publicly factored was 768 bits.
 Unless practical quantum computers become available, a 2048-bit key should
be more than sufficient for most use cases.

Mike

On Thu, Feb 21, 2013 at 11:38 PM, Ashok C ash@gmail.com wrote:

 Hi,

 What is the current industry standard for private key lengths?
 As of now, my application supports 2048 bit-wide keys.
 I'm planning to support higher key lengths now, and want your suggestions
 on how big a key I should support?

 --
 Ashok

Re: FIPS Mode

[Mike Hoy]

I've googled around for that and for a layman like myself I didn't find
anything that 'held my hand' through the process. If you know how to do
this could you elaborate on how to disable Diffie-Hellman key exchanges?

Thanks,

Mike Hoy

On Sun, Jul 8, 2012 at 3:33 PM, jb-open...@wisemo.com wrote:

  Use the 3rd option suggested by McAfee, it is better than their first
 two options.

 The 3rd option is to configure the ciphersuite used by the server to not
 include any Diffie-Hellman key exchanges until your choice of distribution
 includes OpenSSL 1.0.1 with the new FIPS module.
 On 08-07-2012 20:58, Mike Hoy wrote:

 We received the following from McAfee PCI Compliance service:

Description
   The remote SSL/TLS server accepts a weak Diffie-Hellman (DH) public
 key value.

 This flaw may aid an attacker in conducting a man-in-the-middle (MiTM)
 attack against the remote server since it could enable a forced
 calculation of a fully predictable Diffie-Hellman secret.

 By itself, this flaw is not sufficient to set up a MiTM attack (hence
 a risk factor of 'none'), as it would require some SSL implementation
 flaws to affect one of the clients connecting to the remote host.

   General Solution
   OpenSSL is affected when compiled in FIPS mode. To resolve this
 issue, either upgrade to OpenSSL 1.0.0, disable FIPS mode or configure
 the ciphersuite used by the server to not include any Diffie-Hellman
 key exchanges.

 PolarSSL is affected. To resolve this issue, upgrade to version
 0.99-pre3 / 0.14.2 or higher.

 If using any other SSL implementation, configure the ciphersuite used
 by the server to not include any Diffie-Hellman key exchanges or
 contact your vendor for a patch.



  We want to know how to disable FIPS mode. We cannot upgrade OpenSSL
 without compiling it and we would rather use yum to upgrade our software on
 our servers. CentOS is only offering .9.x currently. My understanding is
 that only people working for the government would be utilizing FIPS mode
 while browsing the net. So is our solution correct: Disable FIPS mode? If
 so how does one go about doing this on a GoDaddy dedicated CentOS system?

  Thanks,
 --
 Mike Hoy


 Enjoy

 Jakob
 --
 Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
 Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
 This public discussion message is non-binding and may contain errors.
 WiseMo - Remote Service Management for PCs, Phones and Embedded




-- 
Mike Hoy

Re: McAfee Claims TLS Vulnerability

[Mike Hoy]

 Use a SSL/TLS scanner to verify SSL is not available; and TLS ciphers
 are available.

How would I verifity that SSL is not available and TLS ciphers are
available?


 Since you are using a FIPS build, MD5 and lesser
 friends should not be available. You can use

#openssl ciphers shows that MD5 is being used. It is listed in the output
of that command.

 openssl from the command
 line, or a tool such as http://sourceforge.net/projects/sslscan/ or
 http://code.google.com/p/sslyze/.

 Jeff

McAfee Claims TLS Vulnerability

[Mike Hoy]

We use McAfee to scan our website for vulnerabilities. They claim the
following:

 Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported.
 Configure SSL/TLS servers to only support cipher suites that do not use
 block ciphers. Apply patches if available.

I ran #openssl version and it says we are using OpenSSL 0.9.8e-fips-rhel5
01 Jul 2008.

Do we need to upgrade our OpenSSL to upgrade our TLS/SSL server? Sorry if
the question is way off-base but I am not a system administrator normally.
This is new to me. We use CentOS and #yum install openssl claims it is
already at the higest version. Any suggestions appreciated.

Thanks,

-- 
Mike Hoy

Re: OpenSSL 1.0.1 released

[Mike Frysinger]

On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
OpenSSL version 1.0.1 released
===
 
http://www.openssl.org/source/exp/CHANGES.
 
The most significant changes are:
 
   o TLS/DTLS heartbeat support.
   o SCTP support.
   o RFC 5705 TLS key material exporter.
   o RFC 5764 DTLS-SRTP negotiation.
   o Next Protocol Negotiation.
   o PSS signatures in certificates, requests and CRLs.
   o Support for password based recipient info for CMS.
   o Support TLS v1.2 and TLS v1.1.
   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
   o SRP support.

i don't see mention of ABI compat changes, and it seems to not be compatible.  
did someone forget to update the version string in crypto/opensslv.h ?  it 
still says 1.0.0 ...
-mike


signature.asc
Description: This is a digitally signed message part.

Why do these 12 lines of Win32 code work on XP but hang forever in Vista and Windows 7?

[Mike Nosler]

This Delphi code starts a minimal SSL server:

WSAStartup(MakeWord(1,1), WData);
SSL_library_init;
SSL_load_error_strings;
ctx := SSL_CTX_new(SSLv23_server_method);
SSL_CTX_use_certificate_chain_file(ctx, 'cert.pem');
SSL_CTX_use_PrivateKey_file(ctx, 'key.pem', 1);
SSL_CTX_check_private_key(ctx);
bio_ssl := BIO_new_ssl(ctx, 0);
bio_in := BIO_new_accept('443');
BIO_set_accept_bios(bio_in, bio_ssl);
BIO_do_accept(bio_in); // set up the socket
BIO_do_accept(bio_in); // wait for connection

Everything works fine on XP.  The code stays in the second
BIO_do_accept() waiting for a connection, and sending an HTTPS request
from a browser causes BIO_do_accept() to return.

On 32-bit Vista Home Premium and 64-bit Windows 7, the second
BIO_do_accept() hangs forever, and the browser can't connect.  Why?

The various definitions used are:

const
  SSLEAY32DLL = 'ssleay32.dll';
  LIBEAY32DLL = 'libeay32.dll';
  LIBSSL32DLL = 'libssl32.dll';

function SSL_CTX_check_private_key(ctx: Pointer): BOOL; cdecl;
external SSLEAY32DLL;
function SSL_CTX_new(meth: Pointer): Pointer; cdecl; external SSLEAY32DLL;
function SSL_CTX_use_certificate_chain_file(ctx: Pointer; FName:
PChar): Integer; cdecl; external SSLEAY32DLL;
function SSL_CTX_use_PrivateKey_file(ctx: Pointer; FName: PChar;
AType: Integer): Integer; cdecl; external SSLEAY32DLL;
procedure SSL_library_init; cdecl; external SSLEAY32DLL;
procedure SSL_load_error_strings; cdecl; external SSLEAY32DLL;
function SSLv23_server_method: Pointer; cdecl; external SSLEAY32DLL;

function BIO_new_ssl(ctx: Pointer; client: Integer): Pointer;
cdecl; external LIBSSL32DLL;
function BIO_new_accept(port: pchar): Pointer; cdecl; external LIBEAY32DLL;
function BIO_ctrl(bp: Pointer; cmd: Integer; larg: Longint; parg:
Pointer): longint; cdecl; external LIBEAY32DLL;
function BIO_set_accept_bios(b, bio: pointer): integer; const
BIO_C_SET_ACCEPT = 118; begin result := BIO_ctrl(b, BIO_C_SET_ACCEPT,
2, bio); end;
function BIO_do_accept(b: pointer): integer; const
BIO_C_DO_STATE_MACHINE = 101; begin result := BIO_ctrl(b,
BIO_C_DO_STATE_MACHINE, 0, nil); end;

var WData: TWSAData; ctx, bio_ssl, bio_in: pointer;

Changing the 32-bit .EXE's various compatibility modes (Windows XP,
Windows NT, etc) has no effect. I'm using OpenSSL 1.0.0d
(LIBEAY32.DLL, LIBSSL32.DLL, SSLEAY32.DLL).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Can't load openssl-1.0.0d when building php-5.3.6 on CentOS x64

[Mike Peters]

I get the following error:

/usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(x86_64cpuid.o): relocation 
R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a 
shared object; recompile with -fPIC

I built openssl by:

./config no-shared -fPIC

RE: Can't load openssl-1.0.0d when building php-5.3.6 on CentOS x64

[Mike Peters]

Fixed it by building a shared library and making sure the proper links were in 
/usr/local/ssl/lib.

From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Mike Peters
Sent: Sunday, June 19, 2011 11:10 AM
To: openssl-users@openssl.org
Subject: Can't load openssl-1.0.0d when building php-5.3.6 on CentOS x64

I get the following error:

/usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(x86_64cpuid.o): relocation 
R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a 
shared object; recompile with -fPIC

I built openssl by:

./config no-shared -fPIC

Re: cross compiling for ARM running Android

[Mike Mohr]

Please have a look at the NDK documentation.  You need to extract the
toolchain using a provided script which targets the appropriate API level.
The codesourcery toolchain does not target the correct libc.
On Jun 16, 2011 9:43 AM, Nahid Alam sha...@gmail.com wrote:
 Hi,

 I am using OpenSSL 0.9.8k to write a simple AES encryption application
that
 works fine in x86. It uses EVP library APIs for encryption/decryption
 purpose.

 Now I need to compile it for Tegra2 (ARM) which is running Android 2.2
 I am using Code Sourcery to cross compile for ARM using

 $arm-none-linux-gnueabi-gcc -lcrypto -o test test.c

 But getting fatal error: openssl/evp.h: No such file or directory

 Any ideas? Do I need to cross compile openssl 1st?
 --
 Regards
 Nahid

Re: No shared cipher error using ECDSA

[Mike Bell]

Thanks Viktor,
 
I hadn't properly understood the relationship between the certificate and the 
cipher, so I'll look at that now. I think I'm also confusing the OpenVPN  
OpenSSL relationship. 
 
OpenVPN does appear to be using TLS according to the logs, so I had tried to 
specify 
   tls-cipher ECDHE-ECDSA-AES256-SHA
in CLIENT.OVPN and SERVER.OVPN config files, but got the same error. 
 
Thanks for your help, you've given new ideas to research. 
 
 
 
On Fri, May 13, 2011 at 06:36:34PM +0100, Mike Bell wrote:

 I had originally put 
 cipher AES-128-CBC
 in SERVER.OVPN  CLIENT.OVPN, not OPENSSL.CNF files (it's been a long week!)

I am not familiar with your VPN product, so you'll have to figure out
what configuration options are applicable. If the product uses SSL cipher
suites, then a cipher name is almost always a cipherlist, whose syntax
is described in the ciphers(1) manpage. If on the other hand, as the
protocol in question is not TLS, cipher specification uses a different
syntax, then you need to figure out how to configure a cipher that is
compatible with ECDSA certificates.

Do not confuse a block algorithm e.g. (AES-128-CBC) with a cipher-suite,
which specifies also the authentication and message digest algorithms.
Generally, OpenSSL ciphersuites are defined for TLS. It is not clear
how these translate to your VPN device.

-- 
Viktor.


From: Victor Duchovni victor.ducho...@morganstanley.com
To: openssl-users@openssl.org openssl-users@openssl.org
Sent: Friday, 13 May 2011, 17:56
Subject: Re: No shared cipher error using ECDSA

On Fri, May 13, 2011 at 05:41:52PM +0100, Mike Bell wrote:

 However I keep getting a no shared cipher error. 
 
 In my client  server openssl.cnf files I've specified
 cipher AES-128-CBC

This is not an EC cipher, and if you configure an EC cert, but specify
a cipher that is one of the ones reported by openssl ciphers -v aECDSA,
you get no shared cipher errors.

    ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(256)  Mac=SHA1
    ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH    Au=ECDSA Enc=3DES(168) Mac=SHA1
    ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(128)  Mac=SHA1
    ECDHE-ECDSA-RC4-SHA    SSLv3 Kx=ECDH    Au=ECDSA Enc=RC4(128)  Mac=SHA1
    ECDHE-ECDSA-NULL-SHA    SSLv3 Kx=ECDH    Au=ECDSA Enc=None      Mac=SHA1

Don't explicitly specify the cipher, just the certificates are sufficient,
or specify a cipher class

    !eNULL:!SSLv2:aECDSA:@STRENGTH

which eliminates the NULL cipher:

    $ openssl ciphers -v '!eNULL:!SSLv2:aECDSA:@STRENGTH'
    ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(256)  Mac=SHA1
    ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH    Au=ECDSA Enc=3DES(168) Mac=SHA1
    ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(128)  Mac=SHA1
    ECDHE-ECDSA-RC4-SHA    SSLv3 Kx=ECDH    Au=ECDSA Enc=RC4(128)  Mac=SHA1

-- 
    Viktor.
__
OpenSSL Project                                http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                          majord...@openssl.org

No shared cipher error using ECDSA

[Mike Bell]

Hi, 

I’m trying to create a VPN using OpenVPN over OpenSSL encrypted with AES and 
using an elliptical curve DSA.

However I keep getting a “no shared cipher” error. 

The full error log is :-
MULTI: multi_create_instance called
Re-using SSL/TLS context
Control Channel MTU parms [ L:1557 D:138 EF:38 EB:0 ET:0 EL:0 
]   
    
Data Channel MTU parms [ L:1557 D:1450 EF:57 EB:4 ET:0 EL:0 
]
 
Local Options String: 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto 
UDPv4,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 
2,tls-server'   
Expected Remote Options String: 'V4,dev-type tun,link-mtu 1557,tun-mtu 
1500,proto UDPv4,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 
2,tls-client' 
Local Options hash (VER=V4): 
'b7f67de4'  
 
Expected Remote Options hash (VER=V4): 
'8326dbaa'  
   
TLS: Initial packet from xxx.xxx.xxx.xxx:3077, sid=1725da0c f1237109
TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL 
routines:SSL3_GET_CLIENT_HELLO:no shared 
cipher  
TLS Error: TLS object - incoming plaintext read 
error   
 
TLS Error: TLS handshake 
failed  
 
SIGUSR1[soft,tls-error] received, client-instance restarting

In order to use ECDSA I’m using the following commands to create the keys :-

For CA :-
openssl ecparam -name secp160k1 -out %HOME%\ecparameters

openssl req -days 3650 -newkey ec:%HOME%\ecparameters -sha1 -nodes -x509 
-keyout %KEY_DIR%\ca.key -out %KEY_DIR%\ca.crt -config %HOME%\openssl.cnf 
-verbose –text

For SERVER :- 
openssl ecparam -name secp160k1 -out %HOME%\ecparameters

openssl req -days 3650 -nodes -newkey ec:%HOME%\ecparameters -sha1 -keyout 
%KEY_DIR%\%1.key -out %KEY_DIR%\%1.csr -config %HOME%\openssl.cnf -verbose

openssl x509 -req -in %KEY_DIR%\server.csr -CA %KEY_DIR%\ca.crt -CAkey 
%KEY_DIR%\ca.key -extensions server -CAcreateserial -out %KEY_DIR%\server.crt 
-text -extfile %HOME%\openssl.cnf

For CLIENT :-
openssl ecparam -name secp160k1 -out %HOME%\ecparameters

openssl req -days 3650 -nodes -newkey ec:%HOME%\ecparameters -sha1 -keyout 
%KEY_DIR%\%1.key -out %KEY_DIR%\%1.csr -config %HOME%\openssl.cnf -verbose

openssl x509 -req -in %KEY_DIR%\%1.csr -out %KEY_DIR%\%1.crt -CA 
%KEY_DIR%\ca.crt -CAkey %KEY_DIR%\ca.key -extensions v3_req -extfile 
%HOME%\openssl.cnf –text

In my client  server openssl.cnf files I’ve specified
cipher AES-128-CBC

If I generate the certificates using the standard installed batch files (ie not 
using ECDSA) I can connect no problem, so I’m guessing there must be something 
wrong with the commands to generate the certificates. 
I’ve tried several other ECPARAM curves but still get the error. 

Can anyone tell me what I’m doing wrong, or point me to some commands to get 
ECDSA working please.

I’m using openssl version 1.0.0.d  OpenVPN version 2.2.0 on Windows XP

Thanks

No shared cipher error using ECDSA

[Mike Bell]

Hi, 


I’m trying to create a VPN using OpenVPN over OpenSSL encrypted with AES and 
using an elliptical curve DSA.

However I keep getting a “no shared cipher” error. 

The full error log is :-
MULTI: multi_create_instance called
Re-using SSL/TLS context
Control Channel MTU parms [ L:1557 D:138 EF:38 EB:0 ET:0 EL:0 
]   
    
Data Channel MTU parms [ L:1557 D:1450 EF:57 EB:4 ET:0 EL:0 
]
 
Local Options String: 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto 
UDPv4,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 
2,tls-server'   
Expected Remote Options String: 'V4,dev-type tun,link-mtu 1557,tun-mtu 
1500,proto UDPv4,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 
2,tls-client' 
Local Options hash (VER=V4): 
'b7f67de4'  
 
Expected Remote Options hash (VER=V4): 
'8326dbaa'  
   
TLS: Initial packet from xxx.xxx.xxx.xxx:3077, sid=1725da0c f1237109
TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL 
routines:SSL3_GET_CLIENT_HELLO:no shared 
cipher  
TLS Error: TLS object - incoming plaintext read 
error   
 
TLS Error: TLS handshake 
failed  
 
SIGUSR1[soft,tls-error] received, client-instance restarting

In order to use ECDSA I’m using the following commands to create the keys :-

For CA :-
openssl ecparam -name secp160k1 -out %HOME%\ecparameters

openssl req -days 3650 -newkey ec:%HOME%\ecparameters -sha1 -nodes -x509 
-keyout %KEY_DIR%\ca.key -out %KEY_DIR%\ca.crt -config %HOME%\openssl.cnf 
-verbose –text

For SERVER :- 
openssl ecparam -name secp160k1 -out %HOME%\ecparameters

openssl req -days 3650 -nodes -newkey ec:%HOME%\ecparameters -sha1 -keyout 
%KEY_DIR%\%1.key -out %KEY_DIR%\%1.csr -config %HOME%\openssl.cnf -verbose

openssl x509 -req -in %KEY_DIR%\server.csr -CA %KEY_DIR%\ca.crt -CAkey 
%KEY_DIR%\ca.key -extensions server -CAcreateserial -out %KEY_DIR%\server.crt 
-text -extfile %HOME%\openssl.cnf

For CLIENT :-
openssl ecparam -name secp160k1 -out %HOME%\ecparameters

openssl req -days 3650 -nodes -newkey ec:%HOME%\ecparameters -sha1 -keyout 
%KEY_DIR%\%1.key -out %KEY_DIR%\%1.csr -config %HOME%\openssl.cnf -verbose

openssl x509 -req -in %KEY_DIR%\%1.csr -out %KEY_DIR%\%1.crt -CA 
%KEY_DIR%\ca.crt -CAkey %KEY_DIR%\ca.key -extensions v3_req -extfile 
%HOME%\openssl.cnf –text

In my client  server openssl.cnf files I’ve specified
cipher AES-128-CBC

If I generate the certificates using the standard installed batch files (ie not 
using ECDSA) I can connect no problem, so I’m guessing there must be something 
wrong with the commands to generate the certificates. 
I’ve tried several other ECPARAM curves but still get the error. 

Can anyone tell me what I’m doing wrong, or point me to some commands to get 
ECDSA working please.

I’m using openssl version 1.0.0.d  OpenVPN version 2.2.0 on Windows XP

Thanks

Re: No shared cipher error using ECDSA

[Mike Bell]

Thanks very much for the fast response Victor.
 
I wonder if I've confused things here with a typo. 
 
I had originally put 
    cipher AES-128-CBC
in SERVER.OVPN  CLIENT.OVPN, not OPENSSL.CNF files (it's been a long week!)
 
I've tried removing the cipher statement from the OVPN files but I'm still 
getting the no cipher found error. 
 
Can you explain a little more about using the cipher class method please, I'm 
not sure how to specify that in SERVER.OVPN
 
Taking a step back, is it valid to use an AES cipher suite and an EC DSA 
signature algorithm ? Our security people are insisting on AES and either EC 
DSA, DSA or RSA as the signature algorithm, but with a preference for ECDSA. 
 
Thanks
 

From: Victor Duchovni victor.ducho...@morganstanley.com
To: openssl-users@openssl.org openssl-users@openssl.org
Sent: Friday, 13 May 2011, 17:56
Subject: Re: No shared cipher error using ECDSA

On Fri, May 13, 2011 at 05:41:52PM +0100, Mike Bell wrote:

 However I keep getting a no shared cipher error. 
 
 In my client  server openssl.cnf files I've specified
 cipher AES-128-CBC

This is not an EC cipher, and if you configure an EC cert, but specify
a cipher that is one of the ones reported by openssl ciphers -v aECDSA,
you get no shared cipher errors.

    ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(256)  Mac=SHA1
    ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH    Au=ECDSA Enc=3DES(168) Mac=SHA1
    ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(128)  Mac=SHA1
    ECDHE-ECDSA-RC4-SHA    SSLv3 Kx=ECDH    Au=ECDSA Enc=RC4(128)  Mac=SHA1
    ECDHE-ECDSA-NULL-SHA    SSLv3 Kx=ECDH    Au=ECDSA Enc=None      Mac=SHA1

Don't explicitly specify the cipher, just the certificates are sufficient,
or specify a cipher class

    !eNULL:!SSLv2:aECDSA:@STRENGTH

which eliminates the NULL cipher:

    $ openssl ciphers -v '!eNULL:!SSLv2:aECDSA:@STRENGTH'
    ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(256)  Mac=SHA1
    ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH    Au=ECDSA Enc=3DES(168) Mac=SHA1
    ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(128)  Mac=SHA1
    ECDHE-ECDSA-RC4-SHA    SSLv3 Kx=ECDH    Au=ECDSA Enc=RC4(128)  Mac=SHA1

-- 
    Viktor.
__
OpenSSL Project                                http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                          majord...@openssl.org

no shared cipher:s3_srvr.c

[Mike Markley]

I'm working on an OpenSSL based server that is running into a problem
with the above error when the remote client tries to connect. I've
built a debug version of OpenSSL for iPhone and I'm dumping all the
ciphers in ssl3_choose_cipher. What I don't understand is, at least at
the name level all the ciphers that the remote client specifies are
available in the list of ciphers that OpenSSL has but none of the
masks match up. Am I missing a setup step? I'm using the sample code
in the book Network security with OpenSSL as a starting point. I don't
have source to the remote client so I don't have any way of debugging
from that side of the equation.

Thanks,
Mike
m...@buddytv.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: no shared cipher:s3_srvr.c

[Mike Markley]

So the problem could be that my cert chain is not correct and I'm
chasing down the wrong path by looking at the ciphers?

On Tue, May 10, 2011 at 3:08 PM, Dr. Stephen Henson st...@openssl.org wrote:
 On Tue, May 10, 2011, Mike Markley wrote:

 I'm working on an OpenSSL based server that is running into a problem
 with the above error when the remote client tries to connect. I've
 built a debug version of OpenSSL for iPhone and I'm dumping all the
 ciphers in ssl3_choose_cipher. What I don't understand is, at least at
 the name level all the ciphers that the remote client specifies are
 available in the list of ciphers that OpenSSL has but none of the
 masks match up. Am I missing a setup step? I'm using the sample code
 in the book Network security with OpenSSL as a starting point. I don't
 have source to the remote client so I don't have any way of debugging
 from that side of the equation.


 Note that the ciphersuite availability depends on the key(s) and
 certificate(s) configured in the server. If you have none then only
 unauthenticated ciphersuites are used which are disabled by default cipher
 strings. If you have RSA, RSA ciphersuites are included, DSA includes the DSA
 (DSS) ones etc.

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: no shared cipher:s3_srvr.c

[Mike Markley]

I'm using a self signed certificate that is generated by my App. The
generation code is used for a client connection and that code is
working. Should I be able to use a self signed certificate? I'm
getting a crash course in SSL at the moment so I'm still figuring a
lot of this stuff out.

On Tue, May 10, 2011 at 3:46 PM, Dr. Stephen Henson st...@openssl.org wrote:
 On Tue, May 10, 2011, Mike Markley wrote:

 So the problem could be that my cert chain is not correct and I'm
 chasing down the wrong path by looking at the ciphers?


 Not the chain, just you need at least one server certificate and most usually
 an RSA one. Also check the PRNG is seeded correctly.

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Problem with x509 certificate created using OpenSSL on iOS

[Mike Markley]

I've created an x509 certificate using the sample code provided in
mkcert.c. The certificate works fine in doing the basic SSL handshake
and I can use i2d_x509 to extract the bytes and then convert it back
to d2i_x509 and print it using X509_print_fp. For some reason though
if I try to convert it into an iOS certificate the call fails. The
only thing I've been able to find is a thread on one of the Apple
lists that says that the version can't be zero but my certificate
version is 3. Is there some other field that I need to set that would
not be correctly set by the mkcert.c code?

Thanks
Mike
m...@buddytv.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Problem with unknown CA

[Mike Markley]

Thanks, We're still learning a lot about how this all works. Tracked
this down to a different issue in our code base.

2011/4/30 Ziyu Liu lzyz...@126.com:

 At 2011-04-30 04:33:43，Mike Markley m...@buddytv.com wrote:

I'm trying to establish an SSL connection with a server and my
handshake is failing with 'alert unknown ca' I'm using a self signed
certificate and I'm also specifying SSL_VERIFY_NONE in my call to
SSL_set_verify. Is this message indicating a problem with my self

 The flag SSL_VERIFY_NONE just means that you(here,client) do not
 want to check your peer(server)'s certificate.On the contrary,the server
 may check your certificate if it sets a SSL_VERIFY_PEER flag.

 The 'alert unknown ca' error occurs when SSL checked a wrong cerficate.So I
 guess that the error is occurred because the server consider the client's
 certificate is wrong.


  signed certificate or is it a problem with the certificate from the
server? The server is supposed to be returning a self signed
certificate as well. Am I missing a call somewhere to allow the server
to use self signed certificates?

 Many errors can occur 'unknow'.Check your server if it configed correctly
 and check if you generate the right certificate(be careful to the CN
 section).
 By the way , the SSL uses SSL_CTX_load_verify_locations to load a few
 certificate to verify the certificate which is sent from the peer.It trusted
 a peer if and only if
 1.the peer has a private key versus the certificate which the peer sent.
 2.There is a cerficate, in the certificates loaded by the
 SSL_CTX_load_verify_locations,such that it can verify the peer's
 certificate.

Thanks,
Mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


 
 体验网易邮箱2G超大附件，轻松发优质大电影、大照片，提速3倍!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Asynchronous read/write streams in Objective-C

[Mike Markley]

Is it possible to wrap an SSL/BIO connection with NSInputStream and
NSOutputStream objects? What we are seeing now is that using the
exposed API to create the streams results in the data not being
written onto the wire using SSL. Will I have to create my own stream
wrappers to achieve asynchronous I/O?

thanks,
Mike
m...@buddytv.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Problem with unknown CA

[Mike Markley]

I'm trying to establish an SSL connection with a server and my
handshake is failing with 'alert unknown ca' I'm using a self signed
certificate and I'm also specifying SSL_VERIFY_NONE in my call to
SSL_set_verify. Is this message indicating a problem with my self
signed certificate or is it a problem with the certificate from the
server? The server is supposed to be returning a self signed
certificate as well. Am I missing a call somewhere to allow the server
to use self signed certificates?

Thanks,
Mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Setting x509 Certificate algorithm

[Mike Markley]

I am creating a self signed x509 certificate using code based on the
mkcert.c sample code included in the OpenSSL demo sources. I need to
set the algorithm to sha256WithRSAEncryption and I cannot figure out
how to do this with the APIs. I always end up with
sha1WithRSAEncryption. Am I trying to do the impossible here?

Thanks,
Mike
m...@buddytv.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: openssl dgst using ecdsa-with-SHA384

[Shelley, Mike]

Thanks for the response, using -sha384 appears to be working and
verifies correctly.

Mike

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Sunday, April 24, 2011 4:17 AM
To: openssl-users@openssl.org
Subject: Re: openssl dgst using ecdsa-with-SHA384

On Wed, Apr 20, 2011, Shelley, Mike wrote:

 Hi all,
 
  
 
 I'm having a problem using ecdsa with SHA 384 when creating a message
 digest.  I will admit I'm not too familiar with openssl and digests,
but
 I have code that works using -ecdsa-with-SHA1.  I need to change that
to
 use ecdsa-with-SHA384.  I looked at the release notes to see that this
 should be supported with openssl version 1.1.0 and later, but I've
tried
 that version as well as the latest 1.0.0d, and get a unknown option
 '-ecdsa-with-SHA384' 
 
  
 
 The command I use is:
 
 /usr/local/openssl/bin/openssl dgst -ecdsa-with-SHA384 -binary -out
 signersCertDgst.tmp x509/public.pem
 
  
 
 This same command works when using -ecdsa-with-SHA1
 
  
 
 I've looked at the openssl source and it appears to support the
 -ecdsa-with-SHA384, but it's not straight forward to trace it through
 the source code.
 
  
 
 Has anyone gotten this to work?  Am I doing something wrong?  I assume
 -sha384 is different than -ecdsa-with-SHA384.  
 

Actually that's how you do it use -sha384 and use an EC key to sign the
result.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Setting x509 Certificate algorithm

[Mike Markley]

That did it! Thank you, I'm neck deep into code that I don't fully
understand, I greatly appreciate the help.

Mike

On Wed, Apr 27, 2011 at 3:54 PM, re est re.est1...@gmail.com wrote:
 Hi,
 Have you tried changing this
         if (!X509_sign(x,pk,EVP_sha1()))
 to
         if (!X509_sign(x,pk,EVP_sha256()))


 On Thu, Apr 28, 2011 at 4:13 AM, Mike Markley m...@buddytv.com wrote:

 I am creating a self signed x509 certificate using code based on the
 mkcert.c sample code included in the OpenSSL demo sources. I need to
 set the algorithm to sha256WithRSAEncryption and I cannot figure out
 how to do this with the APIs. I always end up with
 sha1WithRSAEncryption. Am I trying to do the impossible here?

 Thanks,
 Mike
 m...@buddytv.com
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: DH session Key length

[Mike Mohr]

Look, the typical way you'd use the DH shared secret would be to hash
it using an appropriate hash function.  I personally like using Tiger
with AES-192, YMMV.

On Tue, Apr 19, 2011 at 3:56 PM, ikuzar razuk...@gmail.com wrote:
 So,  have I to generate a prime with length = 3200 bits ?, ( the
 corresponding exponent will belong to 3200-bit MODP group ) in order to
 generate an AES 128 session key ? ( I use 2 as generator ).
 Here http://tools.ietf.org/html/rfc3526, it is said :
    The new Advanced Encryption Standard (AES) cipher [AES], which has
    more strength, needs stronger groups.  For the 128-bit AES we need
    about a 3200-bit group [Orman01]. ..;
 in this IETF, 6 MODP groups are exposed. 3200-bit is not among this
 groups...
 Concretly, what should I write to obtain AES 128 session key? i Wrote
 something like this ( in command line ):
 openssl dhparam -outform PEM -out dhParams.pem -2 3200
 Then I decode dhParams.pem into internal C struct: dh. Then I
 call DH_generate_key(DH *dh);
 , then DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh); with the
 peer pub_key
 and I finally want to store this session key at key


 2011/4/19 Michael Sierchio ku...@tenebras.com

 Addendum - depending on the use of DH (usually using the DH shared
 secret as a basis for key exchange), the choice of prime is more
 important than private exponent length.  Safe primes or strong primes
 are warranted.  Most systems use small generators (e.g., 2).

 - M

 On Mon, Apr 18, 2011 at 7:25 PM, Mike Mohr akih...@gmail.com wrote:
  You might take a look at RFC 3526:
 
  http://tools.ietf.org/html/rfc3526
 
  It is my understanding that the DH exponent can be significantly
  shorter than the modulus without compromising security.  RFC 3526 is
  from 2003, but I haven't found anything published since then that
  would make me think its assertions are invalid or outdated.  The
  paranoid tinfoil hat crowd can probably take twice the maximum bit
  count from section 8 (620x2=1240) and be happy.
 
  Mike
 
  On Mon, Apr 18, 2011 at 8:01 AM, ikuzar razuk...@gmail.com wrote:
  Hello,
  I 'd like to know the length of DH session key generated by
  DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here :
  http://www.openssl.org/docs/crypto/DH_generate_key.html
  It is said that key must point to DH_size(dh) bytes of memory. is 128
  bits
  the default length ? how can I adjust this length according the
  symetric-key
  algorithm I use ( AES128/ICM)
  Thanks for your help.
 
 
  __
  OpenSSL Project                                 http://www.openssl.org
  User Support Mailing List                    openssl-users@openssl.org
  Automated List Manager                           majord...@openssl.org
 
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: some questions about openssl

[Mike Mohr]

IMHO openssl is unsuitable for this purpose.  Openssl is really good
at what it does, don't get me wrong, but using it in a boot loader
probably isn't the easiest/smartest idea.  What you really want is a
subset of PKCS#1 - that is, EMSA-PSS encoding and verification plus
RSASP1/RSAVP1.  I'm working on some code which happens to implement
exactly this feature set using GMP, and it could trivially be ported
to some smaller bigint library.  I release all my code under GPL3+,
and you're welcome to use it as such - but it sounds like you're
working on some tivoized system, which is incompatible with GPL3.

Mike

On Wed, Apr 20, 2011 at 12:39 AM, loody milo...@gmail.com wrote:
 hi all:
 My quesitons about openssl are below:
 1. I want to take advantage of RSA and SHA in openssl  for secure booting.
 Can they run as standalone program, that means they can run without
 libc support.

 2. I want RSA and sha authentication run in DRAM instead of flash,
 such that the speed will be faster. Is that possible to fix the link
 address of openssl?



 --
 Regards,
 miloody
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: DH session Key length

[Mike Mohr]

Ikuzar,

I'm not sure what software you're writing.  Please understand that I'm
not trying to be mean spirited when I say this, but if you don't
already know the difference between symmetric vs public-key crypto
then you should not be writing this type of code.  Stop doing it until
you have a firm grasp on the basic concepts.  Any code you write now
is nearly guaranteed to be incorrect.  You should take a few months to
read the book I linked you to earlier and really understand the basic
concepts.  You will get much better support from this mailing list
once you do.

Mike

On Wed, Apr 20, 2011 at 3:06 PM, ikuzar razuk...@gmail.com wrote:


 2011/4/19 Dave Thompson dthomp...@prinpay.com

        From: owner-openssl-us...@openssl.org On Behalf Of ikuzar
        Sent: Monday, 18 April, 2011 11:01

        I 'd like to know the length of DH session key generated by
  DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) .
  Here : http://www.openssl.org/docs/crypto/DH_generate_key.html
        It is said that key must point to DH_size(dh) bytes of memory.
  is 128 bits the default length ? how can I adjust this length
  according the symetric-key algorithm I use ( AES128/ICM)

 The size of both private (x) and public (y) values in DH
 is the same as the size of the prime P or very nearly.
 If the parameters were generated with openssl commandline
 'dhparam' the default size of P was 512 bits, which is
 probably not secure.

 If P = 512 bits is not secure so shared key ( 512 bits ) generated with this
 P is not secured. Necessarily, shared key with 128 bits is not secured, and
 then AES 128 is not secured  ?
 I am confused...
 Is there any way to understand in 2, 3 words how to generate a shared key
 with 128 bits length from Dh params ?  For example g = 2, P = 128 = shared
 key length = 128
 Thanks,
 Ikuzar



 (I know factoring thus RSA up to
 700-something is broken; I haven't heard of results for
 discrete-log thus DH and DSA, but on my limited knowledge
 of number theory I think it should be about the same.)

 (Good) asymmetric algorithms need more bits for comparable
 security than (good) symmetric ones. Experts do not agree
 on an exact correspondence, but in (very) rough terms
 elliptic-curve algs are about 2x symmetric, and traditional
 asymmetric (RSA, DH, DSA, etc) are in the vicinity of 20x.

 NIST Special Publication 800-57 available under csrc.nist.gov
 seems to be a good reflection of reasonably current thinking.
 There is or at least was a few years ago an independent site
 with the consensus of leading academic crypto researchers,
 but I can't find it now.

 (If you don't know it, NIST = National Institute for Science
 and Technology is a part of the US government Department of
 Commerce; it was formerly NBS National Bureau of Standards.)


 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

openssl dgst using ecdsa-with-SHA384

[Shelley, Mike]

Hi all,

 

I'm having a problem using ecdsa with SHA 384 when creating a message
digest.  I will admit I'm not too familiar with openssl and digests, but
I have code that works using -ecdsa-with-SHA1.  I need to change that to
use ecdsa-with-SHA384.  I looked at the release notes to see that this
should be supported with openssl version 1.1.0 and later, but I've tried
that version as well as the latest 1.0.0d, and get a unknown option
'-ecdsa-with-SHA384' 

 

The command I use is:

/usr/local/openssl/bin/openssl dgst -ecdsa-with-SHA384 -binary -out
signersCertDgst.tmp x509/public.pem

 

This same command works when using -ecdsa-with-SHA1

 

I've looked at the openssl source and it appears to support the
-ecdsa-with-SHA384, but it's not straight forward to trace it through
the source code.

 

Has anyone gotten this to work?  Am I doing something wrong?  I assume
-sha384 is different than -ecdsa-with-SHA384.  

Any help would be appreciated!

Re: DH session Key length

[Mike Mohr]

You might take a look at RFC 3526:

http://tools.ietf.org/html/rfc3526

It is my understanding that the DH exponent can be significantly
shorter than the modulus without compromising security.  RFC 3526 is
from 2003, but I haven't found anything published since then that
would make me think its assertions are invalid or outdated.  The
paranoid tinfoil hat crowd can probably take twice the maximum bit
count from section 8 (620x2=1240) and be happy.

Mike

On Mon, Apr 18, 2011 at 8:01 AM, ikuzar razuk...@gmail.com wrote:
 Hello,
 I 'd like to know the length of DH session key generated by
 DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here :
 http://www.openssl.org/docs/crypto/DH_generate_key.html
 It is said that key must point to DH_size(dh) bytes of memory. is 128 bits
 the default length ? how can I adjust this length according the symetric-key
 algorithm I use ( AES128/ICM)
 Thanks for your help.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: (DH) how to send dh-pub_key to peer

[Mike Mohr]

ikuzar,

You cannot send the public key to a peer as-is.  The DH structure
contains bignums which must be serialized prior to transmission.  Do
you understand that DH is subject to a MITM attack unless the messages
are signed or encrypted somehow?

If you insist on using the low-level objects, I'd suggest you read the
following book first:

http://www.amazon.com/Information-Security-Principles-Mark-Stamp/dp/0471738484

On Thu, Mar 24, 2011 at 5:35 PM, ikuzar razuk...@gmail.com wrote:
 Hello,
 I 'd like to know how to send dh-pub_key to peer ?
 I know that to send const DH* const_dh, I have to convert it into pem format
 like this i2d_DHparams(const_dh, dhbuf);, then I send dhbuf.
 But to send only dh-pub_key, I did not find any function to convert it into
 PEM ...
 Thanks for your help.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to verify that DH private and public key have been generated ?

[Mike Mohr]

Try checking the bit count of the structure members. The private and public
keys should be similar in size to p.
On Mar 23, 2011 10:27 AM, ikuzar razuk...@gmail.com wrote:
 Hello,
 I 'd like to know how to verify that DH private and public key have been
 generated ?
 In my DH struct, p and g had been generated with commands line ( openssl
 dhparam... )

 struct
 {
 BIGNUM *p; // prime number (shared)
 BIGNUM *g; // generator of Z_p (shared)
 BIGNUM *priv_key; // private DH value x
 BIGNUM *pub_key; // public DH value g^x
 // ...
 };
 DH


 Priv_key and pub_key are generated later with DH_generate_key(dh).

 I would like verify if DH_generate_key( ) has generated the priv_key ( an
 human proof, example by using DHparams_print_fp(fp, dh ); ) I used this
 function but it did not print private key into file pointed by fp.

 Thanks for your help.

Re: How to verify that DH private and public key have been generated ?

[Mike Mohr]

ikuzar,

I'm sorry to be blunt, but if you don't understand what I'm saying
then you shouldn't be writing code that deals with low-level
cryptographic objects/primitives.  See the recent revelations from
Sony and Nokia for why: even multinational corporations with hundreds
of specialist developers can all too easily ship epic failboat code.
 As Dr. Henson has already pointed out you should use the subroutines
that OpenSSL provides to you.

On Wed, Mar 23, 2011 at 4:50 PM, ikuzar razuk...@gmail.com wrote:
 I do not understand what you mean.

 1) I tried to print data's size returned by  i2d_DHparams(const_dh,
 dhbuf);  without computing private nor public key. I have got 138 bytes.
 Then I remade the same operation but I had computed private and public key
 using DH_generate_key(dh);
 and I have still got 138 bytes ...it seems to be odd for me, because I think
 dh's size must be greater after computing keys.

 2) I tried the following check before and after computing keys :
  if (dh-priv_key == NULL)
   printf(\n1)dh-priv_key is NULL\n);
  else
   printf(\n1)dh-priv_key is not NULL\n);
 Before computing key, I have got priv_key is NULL. After computing, priv_key
 is not NULL

 I 'm wondering what happens... could you tell me more about bit counting ? I
 do not understand The private and public keys should be similar in size to
 p. 

 Thanks for your help.


 2011/3/23 Mike Mohr akih...@gmail.com

 Try checking the bit count of the structure members. The private and
 public keys should be similar in size to p.

 On Mar 23, 2011 10:27 AM, ikuzar razuk...@gmail.com wrote:
  Hello,
  I 'd like to know how to verify that DH private and public key have been
  generated ?
  In my DH struct, p and g had been generated with commands line ( openssl
  dhparam... )
 
  struct
  {
  BIGNUM *p; // prime number (shared)
  BIGNUM *g; // generator of Z_p (shared)
  BIGNUM *priv_key; // private DH value x
  BIGNUM *pub_key; // public DH value g^x
  // ...
  };
  DH
 
 
  Priv_key and pub_key are generated later with DH_generate_key(dh).
 
  I would like verify if DH_generate_key( ) has generated the priv_key (
  an
  human proof, example by using DHparams_print_fp(fp, dh ); ) I used this
  function but it did not print private key into file pointed by fp.
 
  Thanks for your help.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: must 'x' in g^x be a prime number

[Mike Mohr]

Although the generator g can be any number, it is typically 2 or 5.
In fact, this is all that OpenSSL supports (values 2 or 5 for g).  The
typical situation is this:

(1) Alice and Bob generate random secret values a and b.  If a or b
happen to be prime, that is fine - but they need not be.
(2) Alice sends Bob A=g^a(mod p) and Bob sends Alice B=g^b(mod p).
(3) Alice calculates S=B^a(mod p) and Bob calculates S=A^b(mod p) and
they are both left with the secret S.

The key thing to notice is that the DH parameters are *public*.  That
means that the modulus and generator can be known by anyone without
compromising the integrity of the DH transaction.

I've generated a few 8192-bit moduli using openssl, and those jobs
tend to take about 3 days to complete on a 2.4GHz core.  If you need a
large modulus, say 4096 bits or higher, you're best off generating it
once on a fast machine and embedding it in your application as a byte
array.

On Tue, Mar 22, 2011 at 5:12 PM, ikuzar razuk...@gmail.com wrote:
 Hello,
 I 'd like to know  :
 1) if exponent x in g^x must be a great prime number. In some docs I saw, it
 is said that x must b a GREAT number but no information about primality ..
 2) May generation of 'x' run for hours like related here :
 http://www.openssl.org/docs/crypto/DH_generate_parameters.html ( in NOTES)
 Thanks for your help.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

components of RSA keys?

[Mike Mohr]

Good afternoon,

When generating an RSA key, several components are described in the
output file.  Per the RSA specification on wikipedia, I can identify
the following values:

prime1: p
prime2: q
modulus: N = p * q
publicExponent: e
privateExponent: d

What I'm not clear about is what function these values play:

exponent1: ??
exponent2: ??
coefficient: ??

Can someone explain?

Thanks,
Mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: components of RSA keys?

[Mike Mohr]

Thanks much for the clarification.  I'm interested in re-implementing
RSA for my own education; can someone point me to the location in the
openssl sources where the RSA keys are actually generated (so I can
see how the BIGNUMs are manipulated)?

Thanks,
Mike

On Thu, Dec 23, 2010 at 1:17 PM, Mounir IDRASSI
mounir.idra...@idrix.net wrote:
 Take a look at :
 http://en.wikipedia.org/wiki/RSA#Using_the_Chinese_remainder_algorithm

 exponent1 = dp
 exponent2 = dq
 coefficient = qInv

 --
 Mounir IDRASSI
 IDRIX
 http://www.idrix.fr

 On 12/23/2010 9:48 PM, Mike Mohr wrote:

 Good afternoon,

 When generating an RSA key, several components are described in the
 output file.  Per the RSA specification on wikipedia, I can identify
 the following values:

 prime1: p
 prime2: q
 modulus: N = p * q
 publicExponent: e
 privateExponent: d

 What I'm not clear about is what function these values play:

 exponent1: ??
 exponent2: ??
 coefficient: ??

 Can someone explain?

 Thanks,
 Mike
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: do i need a dedicated ip address for https?

[Mike Mohr]

I believe you can sort of get around that requirement using a
wildcard SSL certificate (e.g. for *.domain.tld).  But that only helps
you if you're running multiple subdomains for the same TLD.  I think I
heard something about a change to the SSL protocol which would allow
sending of the hostname during SSL negotiation, but I have no
references.  Plus any such change would require years or decades to
propogate throughout all clients on the Internet.

Mike

On Tue, Dec 21, 2010 at 10:53 PM, S Mathias smathias1...@yahoo.com wrote:
 http://help.godaddy.com/article/1054

 # Set up SSL protection on your website.

 is it an inescapable requirement to have a dedicated [not fix] ip address, 
 when i want to use ssl on my domain?

 thank you

 happy Christmas! :)



 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Using DH parameters from OpenSSL

[Mike Mohr]

Good afternoon,

I'm trying to understand the data format that OpenSSL writes out its
DH parameters in.  I am aware that the actual data is encoded using
ASN.1 DER and have a way to parse the container.  My question really
amounts to byte ordering when DH parameters are generated like this:

openssl dhparam -outform DER -5 -out parameters.dh 4096

Take, for example, the safe prime 'p' in parameters.dh.  Are its bytes
stored in MSB...LSB form, such that the number is interpreted
similarly to a human reading base 10 numbers on paper?  That is to
say, left to right 1 byte at a time?

Thanks for any clarification,
Mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Using DH parameters from OpenSSL

[Mike Mohr]

How do you mean, an additional 0 byte is prepended?  I generated
several DH parameters and exported them to C code ( -C ), some of
which has the MSB set.  It looks like BN_bin2bn is used directly on
the raw bytes of the prime without any padding.

Mike

On Tue, Dec 14, 2010 at 12:54 PM, Erik Tkal et...@juniper.net wrote:
 DER encoding of numeric data should always be network byte order MSB...LSB.  
 Note that if the high order bit is set then an additional 0 byte is prepended.

 
 Erik Tkal
 Juniper OAC/UAC/Pulse Development


 -Original Message-
 From: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Mike Mohr
 Sent: Tuesday, December 14, 2010 3:42 PM
 To: openssl-users@openssl.org
 Subject: Using DH parameters from OpenSSL

 Good afternoon,

 I'm trying to understand the data format that OpenSSL writes out its
 DH parameters in.  I am aware that the actual data is encoded using
 ASN.1 DER and have a way to parse the container.  My question really
 amounts to byte ordering when DH parameters are generated like this:

 openssl dhparam -outform DER -5 -out parameters.dh 4096

 Take, for example, the safe prime 'p' in parameters.dh.  Are its bytes
 stored in MSB...LSB form, such that the number is interpreted
 similarly to a human reading base 10 numbers on paper?  That is to
 say, left to right 1 byte at a time?

 Thanks for any clarification,
 Mike
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Wrong cipher selected in handshake?

[Mike Brennan]

Greetings,

It seems that Openssl doesn't always obey the server's priority
ordered list of ciphers (set with SSL_set_cipher_list()), even when
that list is syntactically correct, when the ciphers are available,
and when the client capabilities don't constrain the choice.

Example: I can specify on the server a cipher list where AES128-SHA has 
the highest priority, and is supported by the client, but is not chosen
during the handshake.

I first noticed this when trying to configure mod_ssl (Apache httpd),
using OpenSSL/0.9.8m.  I subsequently verified the same behavior 
by writing client and server programs that directly call the Openssl
library (0.9.8h).  I have also verified using s_client and Firefox as 
clients against mod_ssl and against my own server program.

The custom cipher string I'm using in mod_ssl's SSLCipherSuite
directive, and in my own server program, is:

   !ADH:!eNULL:!EXP:!LOW:AES128-SHA:DHE-RSA-AES128-SHA:HIGH:MEDIUM

When this string is used, the cipher selected by the handshake is 
DHE-RSA-AES256-SHA, even when the client supports AES128-SHA.

Here's what I observed when I tested using my own client and
server programs with various cipher lists.  In the following table, 
default is what you get if you don't specify a cipher list by calling 
SSL_set_cipher_list(), custom is the string above (starting with !ADH), 
and AES128-SHA means that ONLY that single cipher was specified in 
SSL_set_cipher_list().  Immediately before the handshake, 
SSL_get_cipher_list() was called in all cases, on both server and client, 
to verify the effective cipher list. On both client and server, the selected 
cipher is obtained by calling SSL_get_current_cipher() after the handshake.
The current cipher can also be obtained by examining s_client's output, and
by examining the certificate details in Firefox.

 Server   Client  Result
 --   --  --
 default  default DHE-RSA-AES256-SHA
 custom   default DHE-RSA-AES256-SHA
 AES128-SHA   default AES128-SHA
 default  AES128-SHA  AES128-SHA

As indicated in the table, when I set AES128-SHA to be the ONLY 
cipher on either server or client, AES128-SHA is chosen in the handshake.
But it isn't chosen in the custom,default case.

More details:

When I set my custom cipher list 

   !ADH:!eNULL:!EXP:!LOW:AES128-SHA:DHE-RSA-AES128-SHA:HIGH:MEDIUM

on the server (using SSL_set_cipher_list()), and call SSL_get_cipher_list()
on the server immediately before the handshake, here's the priority ordered
list that the OpenSSL library reports:

  priority: 0: AES128-SHA
  priority: 1: DHE-RSA-AES128-SHA
  priority: 2: DHE-RSA-AES256-SHA
  priority: 3: DHE-DSS-AES256-SHA
  priority: 4: AES256-SHA
  priority: 5: DHE-DSS-AES128-SHA
  priority: 6: EDH-RSA-DES-CBC3-SHA
  priority: 7: EDH-DSS-DES-CBC3-SHA
  priority: 8: DES-CBC3-SHA
  priority: 9: DES-CBC3-MD5
  priority: 10: RC4-SHA
  priority: 11: RC4-MD5
  priority: 12: RC2-CBC-MD5
  priority: 13: RC4-MD5

On both server and client, the default list is:

  priority: 0: DHE-RSA-AES256-SHA
  priority: 1: DHE-DSS-AES256-SHA
  priority: 2: AES256-SHA
  priority: 3: EDH-RSA-DES-CBC3-SHA
  priority: 4: EDH-DSS-DES-CBC3-SHA
  priority: 5: DES-CBC3-SHA
  priority: 6: DES-CBC3-MD5
  priority: 7: DHE-RSA-AES128-SHA
  priority: 8: DHE-DSS-AES128-SHA
  priority: 9: AES128-SHA
  priority: 10: RC2-CBC-MD5
  priority: 11: RC4-SHA
  priority: 12: RC4-MD5
  priority: 13: RC4-MD5
  priority: 14: EDH-RSA-DES-CBC-SHA
  priority: 15: EDH-DSS-DES-CBC-SHA
  priority: 16: DES-CBC-SHA
  priority: 17: DES-CBC-MD5
  priority: 18: EXP-EDH-RSA-DES-CBC-SHA
  priority: 19: EXP-EDH-DSS-DES-CBC-SHA
  priority: 20: EXP-DES-CBC-SHA
  priority: 21: EXP-RC2-CBC-MD5
  priority: 22: EXP-RC2-CBC-MD5
  priority: 23: EXP-RC4-MD5
  priority: 24: EXP-RC4-MD5

Any idea why my custom list doesn't result in AES128-SHA being selected
in the handshake?

-Mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Wrong cipher selected in handshake?

[Mike Brennan]

That is nice to know.  Thank you!  That fixed my problem.

 
 On Mon, Dec 06, 2010 at 11:36:01AM -0600, Mike Brennan wrote:
 
  It seems that Openssl doesn't always obey the server's priority
 
   s/doesn't always obey/never by default obeys/
   
  ordered list of ciphers (set with SSL_set_cipher_list()), even when
  that list is syntactically correct, when the ciphers are available,
  and when the client capabilities don't constrain the choice.
 
 By default the server respects the client's priority. If you want
 the server to pre-empt the client's preference list, try:
 
 SSL_CTX_set_options(3) or SSL_set_options(3):
 
   SSL_OP_CIPHER_SERVER_PREFERENCE
When choosing a cipher, use the server's preferences instead of
the client preferences. When not set, the SSL server will always
follow the clients preferences. When set, the SSLv3/TLSv1 server
will choose following its own preferences. Because of the differ-
ent protocol, for SSLv2 the server will send his list of prefer-
ences to the client and the client chooses.
 
 -- 
   Viktor.
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 


    __
 / / /  /  /_/ /_
/   /  /  /\  /__Mike Brennan
 Pittsburg State University
 Pittsburg, KS 66762

 psu...@pittstate.edu
  
 620-235-4603 fax: 620-235-4377
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

sometimes coredumps via apache-openssl-malloc

[Mike Pechkin]

hi,

OS: Solaris 10 (Sun Fire T2000) (+ 10Recommended)
openssl: 0.9.8n from opencsw
apache: 2.2.15 compiled by Sun Studio 12 (+ lastest patches)

This combination coredumps several times a day:

# mdb ./core.httpd.29115
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
 ::stack
libc.so.1`__lwp_park+0x14(dec86a00, 0, ff041910, 0, 1c00, 1d3c)
libc.so.1`malloc+0x44(64, 1, e8070, fe6cc190, ff03e3c0, ff0485b8)
libcrypto.so.0.9.8`CRYPTO_malloc+0x7c(fe74f46c, fe74f46c, 131, 64, fe769608,
fe779f18)
libcrypto.so.0.9.8`EVP_DigestInit_ex+0x204(0, fe779f18, 0, fffe6474,
de07b8fc, fe768ff8)
libcrypto.so.0.9.8`ssleay_rand_add+0x37c(ff79, 4, de07b90c, fe77d8a8,
fe77d530, fe768ff8)
libssl.so.0.9.8`ssl23_accept+0x30(70ac98, 3514c, 0, 724158, fec86fa0,
fec51e50)
mod_ssl.so`ssl_io_filter_connect+0x3a0(6bea80, 72c1f8, 1, 0, 0, 0)
mod_ssl.so`ssl_io_filter_input+0x1a0(729fe8, 72c1f8, 1, 0, 0, 0)
ap_get_brigade+0x70(729fe8, 72c1f8, 1, 0, 0, 0)
ap_rgetline_core+0x90(72b468, 2000, de07bc44, 72b450, 0, 72c1f8)
read_request_line+0x7c(72b450, 72c1f8, , 0, 0, 72b5f9)
ap_read_request+0x224(6be558, 3, 0, 1ec, 6c0990, 1)
ap_process_http_connection+0x28(6be558, 6be2a8, 6be2a8, 5ec, 6be550, 6c0990)

ap_run_process_connection+0x74(6be558, 6be2a8, 2, 1ec, 6c0990, 1)
ap_process_connection+0x88(6be558, 6be2a8, 6be2a8, 5ec, 6be550, 6c0990)
process_socket+0xc4(6be268, 6be2a8, 2, 1ec, 6c0990, 1)
worker_thread+0x2e0(4818d0, 24afb0, 0, 0, 0, 0)
libapr-1.so.0`dummy_worker+0x24(4818d0, de07c000, 0, 0, ff2084f8, 1)
libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0)

Any ideas how to repeat or fix ?

Mike

Re: [Fwd: Compiling Squid with ssl enable]

[Mike Frysinger]

On Wed, Sep 29, 2010 at 16:04,  sq...@sourcesystemsonline.com wrote:
 Why has no nobody attended to me, i need solution urgently.

then higher a consultant
-mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: compilation problem for xscale.

[Mike Frysinger]

On Tue, May 25, 2010 at 19:09, Carruth, Rusty wrote:
 Should I send this request to the developers list rather than here?

 If so, I'll be happy to do so...

 In any case, the short version is:  I cross-compiled openssl for target
 xscale, and could not load the kernel module because some of the symbols
 (e.g. crypto_register_alg) apparently because they were exported using
 EXPORT_SYMBOL_GPL, and openssl did not convince the kernel that it could
 use the _GPL symbols. Or at least that's what it appeared to be.

 I would have thought that OPENssl, for which I have the source, would
 have met the requirements to use the _GPL symbols in the kernel.

 So - the question:  Is there some trick I need to do to convince the
 kernel (2.6.18.8) to allow openssl (0.9.81) kernel module to load?
 (Without breaking the _GPL symbols)

err, openssl doesnt provide any linux kernel modules (that i'm aware
of).  what module exactly are you trying to load ?  and where did you
get it from ?
-mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Another memory growing on AIX (fwd)

[Mike Brennan]

 I'm just curious, what was the offending library?  I have seen similar memory 
 issues \
 in the past that I never had a chance to get to the bottom of, actually 
 openssl \
 behaved differently between 0.9.8i and 0.9.8j.  But I'm wondering what 
 library you \
 had to work around.

It was a library that was created here.  Stuff I've written.  To be
blunt, the bug was in my code.  A heretofore little-used data structure
wasn't completely being cleaned up.  Though each use involved just a
pittance of leaked memory, over many thousands of ssl connections in a 
single process (which is also something new for us) it added up to a lot.
Once I fixed my bug, everything was fine.

What's interesting is the misleading implication that--based on the fact
that whenever the process size increased, it was always in SSL_connect()--
the problem was in openssl.  It was not.  It turns out that process size
increased in openssl only because of problems elsewhere.  Had memory
not been leaking elsewhere, openssl would have been reusing previously
freed memory, maintaining a constant process size.  In retrospect, I should 
have realized that openssl has been so widely used for so long that it is
bound to be pretty solid by now.

-Mike

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

FIPS 140_2 mode for mod_proxy in apache

[Mike Trent]

Is a patch for FIPS 140-2 support available for apache mod_proxy when running
SSL? FIPS 140-2
 is supported in apache SSL when in server mode with this patch: 

https://issues.apache.org/bugzilla/show_bug.cgi?id=46270
https://issues.apache.org/bugzilla/show_bug.cgi?id=46270 

However when running apache as a client via mod_proxy and running over SSL,
SSL is not running in FIPS mode. This is verified by seeing non FIPS
cryptographic items in the crypto suite in the client TLS HELLO message.

I have a thread going in the apache forum however am not getting relevent
responses so I am putting the same query in here.

http://old.nabble.com/FIPS-140_2-compliant-for-mod_proxy--ts27748496.html
http://old.nabble.com/FIPS-140_2-compliant-for-mod_proxy--ts27748496.html 

Thanks in advance for any replies.

-- 
View this message in context: 
http://old.nabble.com/FIPS-140_2-mode-for-mod_proxy-in-apache-tp27769357p27769357.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Another memory growing on AIX (fwd)

[Mike Brennan]

 
 Tim Hudson wrote:
 
Can you make a small test program which demonstrates this behaviour?
 
Typically some cleanup code is being missed when this is sort of thing is 
raised; however a bit of test code makes it fairly easy to track down 
 using a 
combination of the malloc wrapper functions, valgrind and purify.
 
 I'll try.  Currently all the functionality is in a library that
 wraps openssl, but I should be able to make single test program.
 I'll be out of the office until Monday, and will try to get to it
 then.  Thanks.
 
 -Mike

Update: The memory leak is NOT in openssl.  

While getrusage() did indeed indicate that all growth in process size 
occurred within SSL_connect(), it seems likely that's because some other
non-openssl library was not properly freeing some small amounts of
memory (136 bytes per connection); and this caused memory avaiable for
reallocation to gradually decline over the hundreds (and indeed thousands)
of connections being performed.  As this progressed, SSL_connect()
occasionally  requested more than was available, and so the process size 
increased.  But to reiterate, the problem is actually in a different library, 
not in openssl.  I was able to work around the offending library, and when I 
did the process memory size was steady over 24,000 connections.

My sincere apologies for the false alarm.

-Mike

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Another memory growing on AIX

[Mike Brennan]

Tim Hudson wrote:

   Can you make a small test program which demonstrates this behaviour?

   Typically some cleanup code is being missed when this is sort of thing is 
   raised; however a bit of test code makes it fairly easy to track down using 
a 
   combination of the malloc wrapper functions, valgrind and purify.

I'll try.  Currently all the functionality is in a library that
wraps openssl, but I should be able to make single test program.
I'll be out of the office until Monday, and will try to get to it
then.  Thanks.

-Mike

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: problem about static link libssl.a libcrypto.a to my application(linux platform)

[Mike Frysinger]

On Wed, Nov 4, 2009 at 08:24, jj Zhu wrote:
   gcc -static /usr/lib/libssl.a /usr/lib/libcrypto.a error.o wrapsock.o
 wrapunix.o driverUtility.o driver.o -o driver
   I get these compile errors:
 driver.o: In function `logout':
 driver.c:(.text+0x16e): undefined reference to `SSL_library_init'

your link order is wrong.  the libraries have to come after all your
source files.

you also shouldnt use full paths.  use the normal -lssl style -- the
-static flag will select the right library.
-mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Static libraries with fPIC on 32bit system

[Mike Frysinger]

On Mon, Nov 2, 2009 at 21:37, john blair wrote:
 I have built openssl-0.9.8k and am trying to link libcrypto.a statically with 
 my project. I think libcrypto.a contains contains non-relocatable functions
 For example, consider the following:
 #include openssl/des.h
 void foo(void) {
            DES_encrypt3(NULL, NULL, NULL, NULL);
            AES_encrypt(NULL, NULL);
 }

 $ gcc -fPIC -o libfoo.so -shared foo.c /usr/lib/libcrypto.a

dont link static libraries into shared libraries and it isnt a problem

 Can someone point me to why building static libs on 32 bit system with fPIC 
 is a bad idea?

pic adds a lot of overhead with x86 due to register pressure
-mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Static libraries with fPIC on 32bit system

[Mike Frysinger]

On Tue, Nov 3, 2009 at 13:45, john blair wrote:
 dont link static libraries into shared libraries and it isnt a problem

 Ya that is true. But, I do want to link the static library to the shared 
 library.

linking static libraries into a shared library is wrong.  maybe
someone else will help you create a PIC static library, but i wont.
sorry.

 pic adds a lot of overhead with x86 due to register pressure

 Can you point me to link or something that discusses this in more detail?

google for it.  pic on x86 removes ebx from general register usage.
while your .so will have textrels and thus prevent sharing of the text
region, openssl will run faster.
-mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: FIPS_mode_set(1) - FIPS_mode_set(0) - FIPS_mode_set(1)

[Mike Trent]

This is a problem for us with FIPS module 1.2.0.


wolfoftheair wrote:
 
 Is this still present in FIPS module 1.2.0?
 
 -Kyle H
 
 On Mon, Aug 24, 2009 at 11:55 AM, Mike Trentmichael.tr...@xerox.com
 wrote:



 Mike Trent wrote:

 It seems that after setting FIPS mode off one cannot set it back on
 again
 in the same executable.

 I have a test program which does:

 FIPS_mode_set(1)  - works ok indicated by a return true.
 FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode()
 call
 returns 0, so it seems to be off.

 Then followed by again FIPS_mode_set(1) which returns a 0 indicating
 failure. A FIPS_Mode() call indicates that the test program is still in
 non FIPS mode.

 Is it possible to turn off FIPS and turn it back on in an executable?

 Thanks.

 Ok... found the answer.
 One needs to make this call:    RAND_set_rand_method(NULL);
 prior to making a FIPS_mode_set(1) after having turned off FIPS.


 --
 View this message in context:
 http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25121535.html
 Sent from the OpenSSL - User mailing list archive at Nabble.com.
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 
 

-- 
View this message in context: 
http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25530885.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

FIPS_mode_set(1) - FIPS_mode_set(0) - FIPS_mode_set(1)

[Mike Trent]

It seems that after setting FIPS mode off one cannot set it back on again in
the same executable.

I have a test program which does:

FIPS_mode_set(1)  - works ok indicated by a return true.
FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode() call
returns 0, so it seems to be off.

Then followed by again FIPS_mode_set(1) which returns a 0 indicating
failure. A FIPS_Mode() call indicates that the test program is still in non
FIPS mode.

Is it possible to turn off FIPS and turn it back on in an executable?

Thanks.
-- 
View this message in context: 
http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25121412.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: FIPS_mode_set(1) - FIPS_mode_set(0) - FIPS_mode_set(1)

[Mike Trent]

Mike Trent wrote:
 
 It seems that after setting FIPS mode off one cannot set it back on again
 in the same executable.
 
 I have a test program which does:
 
 FIPS_mode_set(1)  - works ok indicated by a return true.
 FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode() call
 returns 0, so it seems to be off.
 
 Then followed by again FIPS_mode_set(1) which returns a 0 indicating
 failure. A FIPS_Mode() call indicates that the test program is still in
 non FIPS mode.
 
 Is it possible to turn off FIPS and turn it back on in an executable?
 
 Thanks.
 
Ok... found the answer.
One needs to make this call:RAND_set_rand_method(NULL);
prior to making a FIPS_mode_set(1) after having turned off FIPS.


-- 
View this message in context: 
http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25121535.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl decrypting unknown whether DES or AES encrypted

[Mike Trent]

Mike Trent wrote:
 
 Moving from DES to AES encryption and all new encryption will be AES.
 However some existing strings were encrypted in DES. Is there a way to
 determine if a string is encrypted in DES or AES?  Will the decrypt AES
 fail on a DES encrypted string always or will openssl return a good return
 but with garbage as the decrypted string?
 
 
 
Thanks for the replies.
The solution is actually easier than first thought.
As I am doing new encryption with AES all I need to do is append a byte at
the end of the encrypted string before returning for storage. On later
examination of an encrypted string if a MOD 16 on the string length yields a
1 then I know I have the new encrypted string, and just need to drop off the
last byte and decrypt via AES. Otherwise I have DES.

-- 
View this message in context: 
http://www.nabble.com/openssl-decrypting-unknown-whether-DES-or-AES-encrypted-tp24801444p24816313.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Parameters for EC key generation

[Mike Frysinger]

On Tue, Jul 21, 2009 at 10:46, Dr. Stephen Henson wrote:
 On Tue, Jul 21, 2009, Fred Keet wrote:
 At this point I've got code that generates the ec keys from the sect163k1
 curve, and then signs a block of data. When I compare this with the ecsign
 utility they provide (apparently built on Miracl) the two signatures do not
 match, so it seems that the curve parameters will be necessary.

 What do you mean do not match? ECDSA uses a random value during signature
 generation so signing the same data with the same key is highly unlikely to
 produce the same signature.

the ecsign utility requires you provide the random seed.  it doesnt
seem like openssl does, so the source will need hacking for that i
guess.
-mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Parameters for EC key generation

[Mike Frysinger]

On Mon, Jul 20, 2009 at 09:51, Fred Keet wrote:
 I'm in the process of writing an application that signs binary data for
 loading
 onto a Analog Devices BlackFin microprocessor. These chips have built in
 support for verification of code. The chip gets loaded with the EC public
 key,
 and then you just update the code and signature on every update.

 My problem is with their specific implementation of FIPS 186-2. They specify
 the
 parameters as below, and I would like to know which are important, and where
 do I add them? They use a Koblitz curve for the keys (sect163k1). I'm under
 the
 impression that just using the correct curve should be sufficient, but would
 like
 to make sure.

 1. m: 163 (dimension of binary field)
 2. a: 1
 3. b: 1 (a and b are the constants in the elliptic curve equation: y2 + xy =
 x3 + ax + b)
 4. Xg: 2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8
 5. Yg: 289070FB05D38FF58321F2E800536D538CCDAA3D9 (Xg and Yg define a point G
 on the        curve above)
 6. n: 400020108A2E0CC0D99F8A5EF (n is the order of the point
 G)
 7. k3: 7
 8. k2: 6
 9. k1: 3 (k1, k2, and k3 specify the field pentanomial x^m + x^k3 + x^k2 +
 x^k1 + 1)

http://marc.info/?t=12472506313r=1w=2
-mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

trying to replicate ECC signing with openssl

[Mike Frysinger]

i was given a small ecsign.exe program that takes some ECC parameters, the 
private key, a random number, and outputs a signature of the specified binary.  
i'm trying to ditch this program in favor of the openssl suite (for obvious 
practical reasons).

for example, the parameters file looks like (where # are comments):
163 # m: dimension of binary field
1 # a constant
1 # b constant
400020108A2E0CC0D99F8A5EF # Xg
2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8 # Yg
289070FB05D38FF58321F2E800536D538CCDAA3D9 # n
7 # k3 constant
6 # k2 constant
3 # k1 constant

the private key looks like (no, not a security issue, this is a demo key):
1133A74FDA4FA538C92CE543521336B038D18EB5B

the random number (again, demo value):
3A852AFB339E7AE3220CED10F478E0A018AAD27EF

and for its output signature on a random file, we get:
3C47B123C88549E6E375B2393AFBF604AEB9E9CE3
3069158A3B7AAA828086DAEC4875D949070885D24

it also produces this, but i believe it is a reformatting of the above:
E39C9EEB4A60BFAF93235B376E9E54883C127BC40300245D887090945D87C4AE6D0828A8AAB7A35891060300

ive been trying to figure out exactly how to invoke openssl to get the 
equivalent behavior.  using -name sect163k1, it seems i do not need to set 
a/b/n manually as the ones used are the default.  but i cant figure out where 
to plugin Xg/Yg/k3/k2/k1.  i'm creating the parameters file with:
openssl ecparam -name sect163k1 -rand randfile -param_enc explicit -text

but this is about where i'm stuck.  i guess the output of ecparam is the .pem 
file that i'd combine with the private key above to feed to `openssl ec` to 
sign the binary in question.  but i'm not sure how to convert the private key 
to the pem format ... when i use -genkey, the resulting base64 encoded key 
looks to be much longer than the private key i have above ?
-mike


signature.asc
Description: This is a digitally signed message part.

SSLVerifyClient in apache + openssl

[Mike Pechkin]

hi,

Is it a bug ?

This is scenarion for CentOS 5.3 (apache 2.2.3 + openssl-0.9.8e)
1. Simple httpd.conf (nothing special) + ssl part, selfsigned certs + CA:

SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512
SSLSessionCache shmcb:/var/cache/mod_ssl/ssl_scache(512000)
# try default too
SSLMutex default

VirtualHost 172.25.16.86:8443
...
SSLEngine on
Location /
SSLRequire %{SSL_CIPHER_USEKEYSIZE} = 128
/Location
SSLCertificateKeyFile /root/mihailp1-ca/mihailp1.key
SSLCertificateFile  /root/mihailp1-ca/mihailp1.crt
SSLCACertificateFile /root/mihailp1-ca/mihailp1-ca.crt
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM

LocationMatch ^/nike(.*)
SSLVerifyClient require
SSLVerifyDepth 3
SSLOptions +OptRenegotiate
/LocationMatch

/VirtualHost

2. I've installed a user's cert, it works:
# openssl verify -CAfile mihailp1-ca.crt browser.crt
browser.crt: OK


3. Interesting part starts here.
[Wed Apr 15 13:24:57 2009] [debug] ssl_engine_kernel.c(1598): Inter-Process
Session Cache: request=SET status=OK
id=16EA972E4C09B2D7B7B788ABB2273BF3A0E3856A161CA98F62C083B2AF45A8AF
timeout=300s (session caching)

4. I see only ...request=SET... requests and firefox open pop-up window
(User Identification request) to click OK. This is boring for 10k users.
It doesn't use session cache.

5. If i use apache + openssl 0.9.7 it works as before without pop-up window,
it uses the same certs and configs at the same time.

6. the problem in httpd is ssl_engine_kernel.c:

if ((dc-nOptions  SSL_OPT_OPTRENEGOTIATE) 
(verify_old == SSL_VERIFY_NONE) 
((peercert = SSL_get_peer_certificate(ssl)) != NULL))
{
renegotiate_quick = TRUE;
X509_free(peercert);
}
7. SSL_get_peer_certificate in 0.9.8 returns NULL, openssl 0.9.7 returns not
NULL and variable renegotiate_quick sets TRUE and it will do *quick*
renegotiation.

Help.

--mpech

Re: Creating a PKCS7 file

[Mike J]

Thanks, this seems to work pretty good.

I read that with a PKCS7 file, there was the option of having one or more
co-signers.
So I sign the file, send it to someone else, and they co-sign the file and
then send it to a third
party who is then able to verify it with the root CA.

I can't seem to figure out howto get co-signing to work.
The openssl Documentation says there is a smime -resign function, but my
version doesn't seem
to include it ( 0.9.8g is the signer version and 0.9.7f is the verifying
version)

Is co-signing available in openssl?

Thanks.



On Mon, Dec 15, 2008 at 12:07 PM, Victor Duchovni 
victor.ducho...@morganstanley.com wrote:

 On Mon, Dec 15, 2008 at 12:40:39PM -0500, Victor Duchovni wrote:

  On Mon, Dec 15, 2008 at 11:37:04AM -0600, Mike J wrote:
 
   It looks like the smime utility is what I'm looking for, however I'm
 running
   into issues with it.
   I'm working with binary files here, some that could potentially be
 50MB.
  
   I create the signed file with:
   openssl smime -sign -in file.bin -binary -signer cert.crt -inkey
   ./private.pem -out file.bin.signed
 
  You forgot -outform DER or -outform PEM (whichever is required by
  the consuming application).

 You'll also need -nodetach, if you want the PKCS#7 file to include
 the content, rather than just contain a detached signature. If your
 certificate is signed by an intermediate CA, you'll also need -certfile,
 which should contain the intermediate CA certs, and optionally the root
 CA cert.

   Seems to work. I then try to verify it with:
   openssl smime -verify -in file.bin.signed -out file.bin.orig
 
  Don't forget -inform DER or -inform PEM.

 --
Viktor.
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Creating a PKCS7 file

[Mike J]

I have a binary file that needs to be digitally signed in a PKCS7 format.

I've looked at some of the openssl documentation and I see commands that can
be used to look at PKCS7 formated files
but not ways of creating them.

Does openssl have a program that will do this for me? I want to hand openssl
the file, private key, and maybe a certificate
and I want openssl to calculate the signature and attach it to the file such
that it's in a PKCS7 format.

Any suggestions?

Thanks!

Re: Creating a PKCS7 file

[Mike J]

It looks like the smime utility is what I'm looking for, however I'm running
into issues with it.
I'm working with binary files here, some that could potentially be 50MB.

I create the signed file with:
openssl smime -sign -in file.bin -binary -signer cert.crt -inkey
./private.pem -out file.bin.signed

Seems to work. I then try to verify it with:
openssl smime -verify -in file.bin.signed -out file.bin.orig

And I get the following error message:
25997:error:2107A088:PKCS7 routines:SMIME_read_PKCS7:no multipart body
failure:pk7_mime.c:313:

Return code is 3.

Is openssl not suited to handle binary files like this? Or am I doing
something wrong here?

Thanks.


On Mon, Dec 15, 2008 at 9:47 AM, Dr. Stephen Henson st...@openssl.orgwrote:

 On Mon, Dec 15, 2008, Victor Duchovni wrote:

  On Mon, Dec 15, 2008 at 09:02:34AM -0600, Mike J wrote:
 
   I have a binary file that needs to be digitally signed in a PKCS7
 format.
  
   I've looked at some of the openssl documentation and I see commands
 that can
   be used to look at PKCS7 formated files
   but not ways of creating them.
  
   Does openssl have a program that will do this for me? I want to hand
 openssl
   the file, private key, and maybe a certificate
   and I want openssl to calculate the signature and attach it to the file
 such
   that it's in a PKCS7 format.
  
   Any suggestions?
 
  CMS http://tools.ietf.org/html/rfc3852 support is in the OpenSSL 0.9.9
  dev snapshots, but is not in 0.9.8. Perhaps this will do what you need.
 

 The smime utility is in all but ancient versions of OpenSSL... that
 handles
 PKCS#7.

 Steve.
 --
 Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
 OpenSSL project core developer and freelance consultant.
 Homepage: http://www.drh-consultancy.demon.co.uk
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Change the DES Code for myself

[Mike Fudd]

Hello Mailinglist,
 
I'm a student and I must change a DES Implementation according to a lecture I 
had last week. Now I'm looking for the DES source in OpenSSL. I have seen the 
crypto\DES directory, but every change in a cbc function doese not work. (I add 
on top of the function a fprintf(stderr) or a  fopen/fwrite command.) I think 
this source is not use if I execute make and make install. I think the 
asm/perl code is used in the subdirectory.
 
Does someone know how I could disable the asm code, in a way that the the 
enc_des.c file would be used?
 
 
Thanks a lot
 
Mike
_
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

RSA Private Key Algortthm

[Mike -- EMAIL IGNORED]

Where can I find a detailed description of how to
compute the RSA private key?  Well structured C
or C++ code might do.

Thanks,
Mike.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: RSA Private Key Algortthm

[Mike -- EMAIL IGNORED]

On Sat, 04 Oct 2008 18:20:45 -0700, David Schwartz wrote:

[...]

 http://en.wikipedia.org/wiki/RSA
 
 In the section Operation, the first set of 5 steps beginning with
 Choose two distinct large random prime numbers p and q documents the
 process of computing an RSA private key.
 
 If you want example code, the OpenSSL distribution includes that in
 appls/genrsa.c.
 
 DS
 
[...]

I have been looking at the article you mention, and it
does not provide enough detail.  In particular, in the
terms of that article, it indicates that Eve could
compute d if she could factor n to obtain p and q.  I
assume that if I knew how d is computed, I would see
why this is so.  I do not see this in the article,
and I have not been able to goog it.

Mike.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Error when creating certificate in HPUX

[Huey, Mike]

If you are on 11.11 you need to see if you have random number generator 
installed.  You can get the rand gen product for 11.11 from:
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=KRNG11I

If you do not want to install a random number generator, then check to see if 
prngd is running.  If prngd is not running you can start it by

:/sbin/init.d/prngd.rc start

It would be useful to know what version of HP-UX and OpenSSL you are using.

You can get the latest openssl for HP-UX at:
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=OPENSSL11I

-Mike

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tan, Liao
Sent: Wednesday, September 03, 2008 5:52 AM
To: openssl-users@openssl.org
Subject: Error when creating certificate in HPUX

Folks,
 Im trying to find solution for this issue. When running the command below

openssl genrsa -des3 -out mydomain.com.key 1024

to create the key pair certificate, it gives me the error:

=
 warning, not much extra random data, consider using the -rand option
Generating RSA private key, 1024 bit long modulus
26995:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not 
seeded:md_rand.c:503:You need to read the OpenSSL FAQ, 
http://www.openssl.org/support/faq.html
26995:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN lib:rsa_gen.c:183:
=

Please, any idea on wot´s going on? This is a production machine, Im in touch 
with the SA, I wont be able to perform tests, reallocate files, etc.

Please your prompt attention.
Thank you
Ingrid


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

SSL without alias specified

[Mike Pagano]

When I created my private key I never specified an alias.

I used:

openssl genrsa -des3 -out domain.com.key 1024

Then my CSR was created with:
openssl req -new -config openssl.cnf -key domain.com.key -out domain.com.csr

I sent to Verisign and received my certificate.

The problem is that Verisign documentations states for tomcat installation:

Enter the following command to import your SSL Certificate:
 
keytool -import -alias your_alias_name -keystore your_keystore_filename 
-trustcacerts -file your_certificate_filename
 
NOTE: The alias name in this command must be the same as the alias name
used during the generation of the private key and CSR.
 
Unfortunately, I didn't specify an alias name when I created the private
key and CSR.

My question: Is there a default alias for the key and csr when I create it? Can 
I retrieve this alias? 
Or do I have to recreate my key and csr and get it signed all over again?


  
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: [FWD] request UP UX openssl A.00.09.07l

[Huey, Mike]

You could update to the latest OpenSSL from HP-UX: 
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=OPENSSL11I

This contains FIPS 1.1.2 OpenSSL

FIPS OpenSSL, used in FIPS mode, does restrict the algorithms used to a subset 
of the normal list of OpenSSL algorithms.

See: http://oss-institute.org/fips-faq.html#a6 for a list of algorithms 
supported in FIPS mode.

Regards,
-Mike

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lutz Jaenicke
Sent: Monday, June 30, 2008 12:04 AM
To: openssl-users@openssl.org
Cc: Soverini Luca
Subject: [FWD] request UP UX openssl A.00.09.07l

Forwarded to openssl-users for public discussion.

Best regards,
Lutz

- Forwarded message from Soverini Luca [EMAIL PROTECTED] -

Importance: normal
Priority: normal
From: Soverini Luca [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Fri, 27 Jun 2008 15:46:56 +0200
Subject: request UP UX  openssl A.00.09.07l
Thread-Topic: request UP UX  openssl A.00.09.07l
thread-index: AcjYXEOhcfCnezkxSVmEAjNRSa5lIQ==
Accept-Language: it-IT, en-US
acceptlanguage: it-IT, en-US

Can i have a help? How I can disable in openssl, HPUX platform  SSV2 and weak 
cipher in favour of large encryption keys?

Cordiali saluti

Luca Soverini

T.IO.DC.NE
Delivery  Operations/Server Unix


Le informazioni contenute o allegate alla mail sono classificate :TELECOM 
S.p.A. - Uso interno - e sono dirette unicamente al destinatario in indirizzo 
che si impegna a mantenere riservate le informazioni relative alla presente. 
Chiunque riceva questa mail per errore è tenuto ad informare immediatamente il 
mittente ed a distruggere le informazioni in essa contenute.
Si ringrazia per la collaborazione.




CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and 
may contain confidential information. If you have received the message in 
error, be informed that any use of the content hereof is prohibited. Please 
return it immediately to the sender and delete the message. Should you have any 
questions, please contact us by replying to [EMAIL PROTECTED]

Thank you

www.telecomitalia.it




- End forwarded message -
--
Lutz Jaenicke   [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~jaenicke/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: won't compile on hp ux 11.23 itanium

[Huey, Mike]

FYI, we do have precompiled versions of OpenSSL for HP-UX available at:
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=OPENSSL11I

By default on 11.11 and 11.23 we setup the 0.9.7m env.  After installing you 
need to go to /opt/openssl and
./switchversion.sh to get to the 0.9.8g env.

-Mike


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of gryzman.mac
Sent: Friday, May 02, 2008 1:32 PM
To: openssl-users@openssl.org
Subject: Re: won't compile on hp ux 11.23 itanium

as suggested, I used gcc instead, and got this:
gmake[3]: Entering directory `/tmp/openssl-0.9.8g'
ld: Duplicate symbol __divxf3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__divxf3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__divxf3.o]
ld: Duplicate symbol __divtf3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__divxf3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__divxf3.o]
ld: Duplicate symbol __divdf3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__divdf3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__divdf3.o]
ld: Duplicate symbol __divsf3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__divsf3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__divsf3.o]
ld: Duplicate symbol __divdi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__divdi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__divdi3.o]
ld: Duplicate symbol __moddi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__moddi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__moddi3.o]
ld: Duplicate symbol __udivdi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__udivdi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__udivdi3.o]
ld: Duplicate symbol __umoddi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__umoddi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__umoddi3.o]
ld: Duplicate symbol __divsi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__divsi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__divsi3.o]
ld: Duplicate symbol __modsi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__modsi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__modsi3.o]
ld: Duplicate symbol __udivsi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__udivsi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__udivsi3.o]
ld: Duplicate symbol __umodsi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__umodsi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__umodsi3.o]
ld: Duplicate symbol __ia64_save_stack_nonlocal in files /usr/local/
lib/gcc/ia64-hp-hpux11.23/4.2.3/hpux64/
libgcc.a[__save_stack_nonlocal.o] and /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__save_stack_nonlocal.o]
ld: Duplicate symbol __ia64_nonlocal_goto in files /usr/local/lib/
gcc/ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__nonlocal_goto.o] and /
usr/local/lib/gcc/ia64-hp-hpux11.23/4.2.3/hpux64/
libgcc.a[__nonlocal_goto.o]
ld: Duplicate symbol __ia64_restore_stack_nonlocal in files /usr/
local/lib/gcc/ia64-hp-hpux11.23/4.2.3/hpux64/
libgcc.a[__restore_stack_nonlocal.o] and /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[__restore_stack_nonlocal.o]
ld: Duplicate symbol __ia64_trampoline in files /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__trampoline.o] and /usr/local/
lib/gcc/ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[__trampoline.o]
ld: Duplicate symbol __multi3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[_muldi3.o] and /usr/local/lib/gcc/ia64-
hp-hpux11.23/4.2.3/hpux64/libgcc.a[_muldi3.o]
ld: Duplicate symbol __negti2 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[_negdi2.o] and /usr/local/lib/gcc/ia64-
hp-hpux11.23/4.2.3/hpux64/libgcc.a[_negdi2.o]
ld: Duplicate symbol __lshrti3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[_lshrdi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[_lshrdi3.o]
ld: Duplicate symbol __ashlti3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[_ashldi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[_ashldi3.o]
ld: Duplicate symbol __ashrti3 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[_ashrdi3.o] and /usr/local/lib/gcc/
ia64-hp-hpux11.23/4.2.3/hpux64/libgcc.a[_ashrdi3.o]
ld: Duplicate symbol __cmpti2 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64/libgcc.a[_cmpdi2.o] and /usr/local/lib/gcc/ia64-
hp-hpux11.23/4.2.3/hpux64/libgcc.a[_cmpdi2.o]
ld: Duplicate symbol __ucmpti2 in files /usr/local/lib/gcc/ia64-hp-
hpux11.23/4.2.3/hpux64