> 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 t
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 w
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
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/certifica
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 in
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
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 co
> > 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
> 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: http
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
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 aimi
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 thoug
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
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 macr
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.
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
> convertin
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
--
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
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
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
>
20 matches
Mail list logo
