Re: [openssl-users] Cleanup and changing the malloc routines

[Jakob Bohm]

On 03/09/2015 04:38, Salz, Rich wrote:


We are considering a big cleanup to the memory-allocation API’s in the 
next release.


Please take a look at the attached documentation, which describes 
**ALL** of the public functions, and let us know if it will cause a 
problem.



A few practical notes:

1. I trust that functions to allocate specific data
  types (such as bignums) are not changed by this.

2. Macros that take zero arguments (such as
  "OPENSSL_malloc_init()") are not accepted by all
  compilers.  In my own API designs this has forced
  me to give such macros a dummy argument (which is
  never used, it just pleases the preprocessor).

3. When compiling without compile-time debug flags,
  the various debug arguments should not be passed
  (or otherwise referenced) by the macros, avoiding
  a bunch of "foo.c" and line number values from
  filling up the compiled binary.  Something like

#ifdef SOME_DEBUG_DEFINE
#define OPENSSL_malloc(num) (CRYPTO_malloc(num, __FILE__, __LINE__))
...
#else
#define OPENSSL_malloc(num) (CRYPTO_malloc(num, NULL, 0))
// OR
#define OPENSSL_malloc(num) (CRYPTO_malloc_nodbg(num))
...
#endif

4. For the basic functions (not the callbacks), there
  seems to be no reason not to change to size_t now.

5. Given the huge number of backward incompatibilities
  in OpenSSL 1.1.x, this seems a good time to change to
  size_t in the callbacks too.

6. Maybe there should be an alternate get/set_mem_functions
  with non-linenumber callbacks (behind the scenes, either
  would set the the other callbacks to stubs that add/remove
  the extra args, the initial defaults would be direct for
  speed and to support the "defer to default implementation"
  scenarios).

7. Maybe the get/set_mem_functions should (in their debug
  variant) should also be able to change the backend for
  debug_push/_pop.

8. For readability, defines with omitted (opaque)
  definitions should be documented with elided args such
  as #define OPENSSL_malloc(num) ... and
  #define CRYPTO_MEM_CHECK_ON 0x... to indicate that they
  do not (typically) expand to nothing/typically do expand
  to a numeric constant

9. Typo: "pointers for with the current functions"

10. It would be helpful to clarify which older functions are
  getting removed.  It's a bit like reading a patch without
  the removed lines.  Kind of impossible to tell what you
  propose to remove.



Enjoy (NOT A CONTRIBUTION)

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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

Re: [openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format

[Viktor Dukhovni]

On Thu, Sep 03, 2015 at 08:21:25AM -0700, tmcclure0501 wrote:

> We have an embedded MQTT framework that we want to configure for mutual
> authentication.  The framework is complaining that it needs a key format of
> PKCS#1.  We have p12 and pem formats of the key.  Does openssl support
> converting keys to the PKCS#1, if so what is the command? 

I've never heard of a PKCS#1 key format, I'm only aware of

PKCS#8  - Private key
PKCS#12 - Private key and related certificates

Consult the documentation for the product, this is not an OpenSSL
question until at least the desired key format is known.

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

Re: [openssl-users] Cleanup and changing the malloc routines

[Salz, Rich]

1. I trust that functions to allocate specific data 
  types (such as bignums) are not changed by this.
They are not.

2. Macros that take zero arguments (such as 
  "OPENSSL_malloc_init()") are not accepted by all 
  compilers.  In my own API designs this has forced 
  me to give such macros a dummy argument (which is 
  never used, it just pleases the preprocessor).
Luckily, we are limiting to c89, so this isn't an issue.

3. When compiling without compile-time debug flags, 
  the various debug arguments should not be passed 
  (or otherwise referenced) by the macros, avoiding 
  a bunch of "foo.c" and line number values from 
  filling up the compiled binary.  Something like
This is a good idea.  In fact, I'll make all the memory-debug stuff 
disabled via the #ifdef.

4. For the basic functions (not the callbacks), there 
  seems to be no reason not to change to size_t now.
Agreed.  It will happen in 1.1, just not the planned commit.

5. Given the huge number of backward incompatibilities 
  in OpenSSL 1.1.x, this seems a good time to change to 
  size_t in the callbacks too.
Yup, same reason.

6. Maybe there should be an alternate get/set_mem_functions 
  with non-linenumber callbacks (behind the scenes, either 
  would set the the other callbacks to stubs that add/remove 
  the extra args, the initial defaults would be direct for 
  speed and to support the "defer to default implementation" 
  scenarios).
If you look, that's what the current (undocumented) code does.  It was 
really hard to understand.  I think being able to replace malloc/realloc/free 
at runtime, as opposed to editing the source and building your own version, is 
the wrong trade-off to make.  But that's the goal of this thread:  to find out 
if anyone is actually doing that.

7. Maybe the get/set_mem_functions should (in their debug 
  variant) should also be able to change the backend for 
  debug_push/_pop.
Same as #6.

8. For readability, defines with omitted (opaque) 
  definitions should be documented with elided args such 
  as #define OPENSSL_malloc(num) ... and 
  #define CRYPTO_MEM_CHECK_ON 0x... to indicate that they 
  do not (typically) expand to nothing/typically do expand 
  to a numeric constant
That seems reasonable; anyone else agree?

9. Typo: "pointers for with the current functions"
Thanks!

10. It would be helpful to clarify which older functions are 
  getting removed.  It's a bit like reading a patch without 
  the removed lines.  Kind of impossible to tell what you 
  propose to remove.
Here's the internal git commit message.  Do you need/want more detail?
Make the "change wrapper functions" be the only paradigm.
Wrote documentation!
Format the 'set func' functions so their paramlists are readible
Format some multi-line comments.
Remove LEVITTE_DEBUG_MEM
Remove ability to get/set the "set options" functions at runtime.
Remove ability to get/set the "memory debug" functions at runtme.
Remove CRYPTO_pop_all
Remove MemCheck_* and CRYPTO_malloc_debug_init macros
Remove memleak_callback stuff.
Remove {OPENSSL,CRYPTO}_remalloc.
Remove {OPENSSL,CRYPTO}_strdup; use BUF_strdup.
Add CRYPTO_mem_debug(int flag) function.
Add test/memleaktest.
Rename CRYPTO_dbg_xxx to CRYPTO_mem_debug_xxx
Rename CRYPTO_{push,pop}_info to CRYPTO_mem_debug_{push,pop}
Rename CRYPTO_malloc_init to OPENSSL_malloc_init; remove needless calls.
Rename *_realloc_clear to *_clear_realloc, like *_clear_free
Only two macros CRYPTO_MDEBUG,CRYPTO_MDEBUG_ABORT to control this.




Enjoy (NOT A CONTRIBUTION)

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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

Re: [openssl-users] PEM X509 certificate with no newline

[Viktor Dukhovni]

On Thu, Sep 03, 2015 at 04:35:00PM +, Salz, Rich wrote:

> > PEM_read_bio_X509() fails because of the missing newlines.
> 
> The underlying base64 decoder is horrible.  It accepts invalid 8bit chars, 
> and silently enforces a line-length limit.
> 
> Wanna rewrite it? :)

A large part of the complexity is that the base64 BIO is doing
buffering wrong.  Instead of buffering character data it buffers
lines, and thus has to set a line length limit.

Perhaps this BIO is intended to be used on multi-component PEM
files, and to automatically stop when it reaches "-END ...".
I've not looked too closely and the use-cases.

In any case, it is the messiest and least efficient (in terms of
lines of code not run-time) code I've seen in OpenSSL.  This code
is very old, and has barely been touched for decades (except for
a subtle bug fixed a few years back by EAY himself IIRC).

The mess is just not very appealing to go near.  The first step
would be to figure out what the base64 BIO is currently doing and
what we want it it to do going forward.  Writing new code is likely
easier than figuring out what it is doing now.

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

[Viktor Dukhovni]

On Thu, Sep 03, 2015 at 11:29:01AM -0700, Kevin Long wrote:

> Can I not use the file directly, as to not rely whatsoever on the OS?s PRNG ?

That would be unwise.  Much too easy to make a mistake and get that
wrong.  The best thing to do with additional entropy sources is to
mix them with existing ones, rather than rely on them exlcusively,
and especially if doing so means clever work-arounds that might go
wrong.

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

[Kevin Long]

Hi Mike (and all).

Thanks for the info.  I understand the implications of storing the randomized 
data to storage and precautions would be taken to air-gap this info from the 
outside world.  


> If not, you can use the TRNG for all newly issued certificates moving forward.

Can you pease syntax? I have googled but I’m unclear if this would be with 
-rand flag, or setting the RANDFILE variable, or something else.  Provided the 
randomized numbers are in a binary file, can you advise how to use this file 
for the generation of future keys/certs from the existing CA.

Thank you






> On Sep 3, 2015, at 2:23 AM, Mike Mohr  wrote:
> 
> 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

___
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

[Kevin Long]

Can I not use the file directly, as to not rely whatsoever on the OS’s PRNG ?



> On Sep 3, 2015, at 11:23 AM, Viktor Dukhovni  
> wrote:
> 
> On Wed, Sep 02, 2015 at 09:53:05PM -0700, Kevin Long wrote:
> 
>> 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:
> 
> Cat those files into /dev/urandom or /dev/random.  That'll mix them
> into the system's entropy pool.  Then generate keys as usual from
> /dev/urandom.
> 
> -- 
>   Viktor.
> ___
> 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

[Viktor Dukhovni]

On Wed, Sep 02, 2015 at 09:53:05PM -0700, Kevin Long wrote:

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

Cat those files into /dev/urandom or /dev/random.  That'll mix them
into the system's entropy pool.  Then generate keys as usual from
/dev/urandom.

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

[Graham Leggett]

On 3 Sep 2015, at 19:23, Viktor Dukhovni  wrote:

> Cat those files into /dev/urandom or /dev/random.  That'll mix them
> into the system's entropy pool.  Then generate keys as usual from
> /dev/urandom.

I have used a deck of playing cards as a source of entropy, saved to a ram disk 
on a system with no swap, used then discarded. This has the advantage that you 
know where the randomness comes from.

Regards,
Graham
--

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

[openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format

[tmcclure0501]

We have an embedded MQTT framework that we want to configure for mutual
authentication.  The framework is complaining that it needs a key format of
PKCS#1.  We have p12 and pem formats of the key.  Does openssl support
converting keys to the PKCS#1, if so what is the command? 

Thanks, 
Tim




--
View this message in context: 
http://openssl.6102.n7.nabble.com/Converting-a-p12-or-PEM-formatted-private-key-to-a-PKCS-1-format-tp59924.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cleanup and changing the malloc routines

[Salz, Rich]

> > Remove {OPENSSL,CRYPTO}_strdup; use BUF_strdup.

Reconsidering, I did this backward.  The right thing is to use OPENSSL_strdup, 
not BUF_strdup. 
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] PEM X509 certificate with no newline

[Salz, Rich]

> PEM_read_bio_X509() fails because of the missing newlines.

The underlying base64 decoder is horrible.  It accepts invalid 8bit chars, and 
silently enforces a line-length limit.

Wanna rewrite it? :)

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

Re: [openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format

[Viktor Dukhovni]

On Thu, Sep 03, 2015 at 04:06:06PM +, Viktor Dukhovni wrote:
> On Thu, Sep 03, 2015 at 08:21:25AM -0700, tmcclure0501 wrote:
> 
> > We have an embedded MQTT framework that we want to configure for mutual
> > authentication.  The framework is complaining that it needs a key format of
> > PKCS#1.  We have p12 and pem formats of the key.  Does openssl support
> > converting keys to the PKCS#1, if so what is the command? 
> 
> I've never heard of a PKCS#1 key format, I'm only aware of
> 
> PKCS#8- Private key
> PKCS#12   - Private key and related certificates
> 
> Consult the documentation for the product, this is not an OpenSSL
> question until at least the desired key format is known.

Perhaps what you're looking for is the legacy RSA key format (PEM
or DER encoded).

-BEGIN RSA PRIVATE KEY-
-END RSA PRIVATE KEY-

The "openssl rsa" command (unlike the "pkey" command) outputs RSA
keys in either DER or PEM formats.

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

Re: [openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format

[Jakob Bohm]

On 03/09/2015 18:16, Viktor Dukhovni wrote:

On Thu, Sep 03, 2015 at 04:06:06PM +, Viktor Dukhovni wrote:

On Thu, Sep 03, 2015 at 08:21:25AM -0700, tmcclure0501 wrote:


We have an embedded MQTT framework that we want to configure for mutual
authentication.  The framework is complaining that it needs a key format of
PKCS#1.  We have p12 and pem formats of the key.  Does openssl support
converting keys to the PKCS#1, if so what is the command?

I've never heard of a PKCS#1 key format, I'm only aware of

 PKCS#8 - Private key
 PKCS#12- Private key and related certificates

Consult the documentation for the product, this is not an OpenSSL
question until at least the desired key format is known.

Perhaps what you're looking for is the legacy RSA key format (PEM
or DER encoded).

-BEGIN RSA PRIVATE KEY-
-END RSA PRIVATE KEY-

The "openssl rsa" command (unlike the "pkey" command) outputs RSA
keys in either DER or PEM formats.


So to summarize:

First use the command "openssl pkcs12" and a text
editor to split the p12 file into individual
certificate and encrypted private key files.

Then use the "openssl rsa" command to convert the
encrypted private key files from PKCS#8 format to
"old-openssl/PKCS#1" format.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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

Re: [openssl-users] Cleanup and changing the malloc routines

[Viktor Dukhovni]

On Thu, Sep 03, 2015 at 04:20:47PM +, Salz, Rich wrote:

> Remove {OPENSSL,CRYPTO}_strdup; use BUF_strdup.

My DANESSL library (used by Exim) uses OPENSSL_strdup.  Any reason
to not leave a compatibility #define behind?

There are likely other projects using that function.

[ Yes we're aiming to have native DANE support in OpenSSL 1.1.0,
and Exim can eventually switch to that, but it'll take time, and
initially there'll be Exim versions using external DANE validation
on top of OpenSSL 1.1.0. ]

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

Re: [openssl-users] PEM X509 certificate with no newline

[Viktor Dukhovni]

On Thu, Sep 03, 2015 at 12:28:48PM -0400, Ken Goldman wrote:
> My application receives an X509 certificate string in PEM format (separators
> and base64 encoded certificate) with no newlines.
> 
> PEM_read_bio_X509() fails because of the missing newlines.
> 
> I can write some preprocessing code to add newlines every 72 characters when
> writing the BIO.

Make that 64.

> Is there a strightforward approach, where I can send the entire PEM string
> and get back the X509 structure without preprocessing?

Inserting the newlines is simple enough.

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

[openssl-users] PEM X509 certificate with no newline

[Ken Goldman]

My application receives an X509 certificate string in PEM format 
(separators and base64 encoded certificate) with no newlines.


PEM_read_bio_X509() fails because of the missing newlines.

I can write some preprocessing code to add newlines every 72 characters 
when writing the BIO.


I also thought about using a base64 filter in the BIO and stripping the 
separators first.


Is there a strightforward approach, where I can send the entire PEM 
string and get back the X509 structure without preprocessing?


___
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

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Graham Leggett
> Sent: Thursday, September 03, 2015 14:43
> 
> I have used a deck of playing cards as a source of entropy, saved to a ram 
> disk
> on a system with no swap, used then discarded. This has the advantage that
> you know where the randomness comes from.

Yes, though even under ideal circumstances a standard deck of playing cards 
only has ~225 bits of entropy [log_2(52!)]. That's plenty for poker, but may 
not last long when used for cryptography by a busy system.

It depends what you're using it for, of course, and how well it's mixed into 
the pool; and it's a decent-sized contribution. But considering the cost of 
reseeding (manually shuffling the cards and entering the data - which is 
time-expensive and opportunity-expensive, because it involves an expensive 
human component), it's not very efficient.

You could build a card-shuffling-and-data-entering robot with some good 
physical randomness (tumbling the cards in a turbulent-air chamber, maybe), but 
there are physical-randomness alternatives with less complexity and better form 
factors.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


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

[openssl-users] DTLS cipher suite support

[Bryce Kahle]

I would like to use openssl as a basic DTLS server from the command line
using: openssl s_server -dtls1_2

The catch is I want to require the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
cipher suite. It appears OpenSSL currently doesn’t support this cipher
suite, even though it supports the both ECDHE_ECDSA and AES_128_CCM_8
individually as separate operations.

Is there some small change I can make to enable support of this cipher
suite? Perhaps this is already supported in an un-released version?

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

Re: [openssl-users] DTLS cipher suite support

[Matt Caswell]

On 03/09/15 07:22, Bryce Kahle wrote:
> I would like to use openssl as a basic DTLS server from the command line
> using: openssl s_server -dtls1_2
> 
> The catch is I want to require the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
> cipher suite. It appears OpenSSL currently doesn’t support this cipher
> suite, even though it supports the both ECDHE_ECDSA and AES_128_CCM_8

Released versions support ECDHE_ECDSA based ciphersuites, and libcrypto
supports CCM. Released versions of libssl do not support any CCM based
TLS ciphersuites.

> individually as separate operations.
> 
> Is there some small change I can make to enable support of this cipher
> suite? Perhaps this is already supported in an un-released version?

Support for this ciphersuite has recently been added to the master
branch (unreleased version 1.1.0). The changes required are non-trivial
so I would recommend against a backport. See:

https://github.com/openssl/openssl/commit/e75c5a794e71baa3d76214be3ac8dc6e082e4a1a

https://github.com/openssl/openssl/commit/3d3701ea20ca36215e3af5ac090797cfec5fca2a

https://github.com/openssl/openssl/commit/176f85a28ec73b16f68a4f1737fb4645b9e9ae7b

https://github.com/openssl/openssl/commit/f8f5f8369d1d76fd8ec28d3d2422a47f8440f452

https://github.com/openssl/openssl/commit/04dc8b36ef40d7ba8f33ff3d6c7c87a921e0715e


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