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] 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 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: 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: 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: 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

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