Re: OpenSSL-3.+ how to configure [random]?

unsubscribe Get Outlook for iOS<https://aka.ms/o0ukef> From: openssl-users on behalf of Dr Paul Dale Sent: Wednesday, November 10, 2021 2:20:03 PM To: openssl-users@openssl.org Subject: Re: OpenSSL-3.+ how to configure [random]? I'm pretty sure the

Re: OpenSSL-3.+ how to configure [random]?

On 11/10/21, 15:20, "openssl-users on behalf of Dr Paul Dale" wrote: > > I'm pretty sure the underlying problem is that there is a call to > RAND_set_rand_method() or RAND_set_rand_engine() occurring (likely the > latter). Probably... > These completely replace the built in RNG infrastruc

Re: OpenSSL-3.+ how to configure [random]?

I'm pretty sure the underlying problem is that there is a call to RAND_set_rand_method() or RAND_set_rand_engine() occurring (likely the latter). These completely replace the built in RNG infrastructure with the RAND_METHOD/engine.  If the engine then fails to produce output for any reason, t

Re: OpenSSL-3.+ how to configure [random]?

> > >Currently I've no idea and can't reproduce locally :( > > > > Maybe you'd know how to force the "-engine rdrand" path through > > "openssl.cnf"? > > > > >A rogue configuration file coul

Re: OpenSSL-3.+ how to configure [random]?

Dr Paul Dale" wrote: > > > > >Currently I've no idea and can't reproduce locally :( > > > > Maybe you'd know how to force the "-engine rdrand" path through > > "openssl.cnf"? > > > > >A rogue confi

Re: OpenSSL-3.+ how to configure [random]?

ough > "openssl.cnf"? > > >    A rogue configuration file could cause the DRBGs/seeds to fail.  > > Do you > >    have seed=rdrand line in the random section?  That will cause > > the > >    seeding source to fail to load at all. > > No, I don&

Re: OpenSSL-3.+ how to configure [random]?

"-engine rdrand" path through "openssl.cnf"? > >> A rogue configuration file could cause the DRBGs/seeds to fail. Do you >> have seed=rdrand line in the random section? That will cause the >> seeding source to fail to load at al

Re: OpenSSL-3.+ how to configure [random]?

't reproduce locally :( Maybe you'd know how to force the "-engine rdrand" path through "openssl.cnf"? A rogue configuration file could cause the DRBGs/seeds to fail. Do you have seed=rdrand line in the random section? That will cause the seeding

Re: OpenSSL-3.+ how to configure [random]?

to fail. Do you >have seed=rdrand line in the random section? That will cause the >seeding source to fail to load at all. No, I don't - and providing empty config causes the same result: $ OPENSSL_CONF=/dev/null openssl3 rand -hex 4 $ OPENSSL_CONF=/dev/null openssl3 rand -en

Re: OpenSSL-3.+ how to configure [random]?

Currently I've no idea and can't reproduce locally :( A rogue configuration file could cause the DRBGs/seeds to fail.  Do you have seed=rdrand line in the random section?  That will cause the seeding source to fail to load at all. Pauli On 10/11/21 1:10 pm, Blumenthal, Uri - 05

Re: OpenSSL-3.+ how to configure [random]?

Thank you! I'm trying to: a. understand why something like "openssl-3 rand -hex 4" does not work (returns empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine, and gives me my random bytes - here's an illustration $ openssl3 version OpenSSL 3.1.

Re: OpenSSL-3.+ how to configure [random]?

ve and user friendly :( Pauli On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote: "man config" for OpenSSL-3.0 and newer says that there can be "[random]" section in "openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed *prop

OpenSSL-3.+ how to configure [random]?

"man config" for OpenSSL-3.0 and newer says that there can be "[random]" section in "openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed *properties*. Unfortunately, it did not bother to even list the possible/allowed values, let

Re: Random and rare Seg faults at openssl library level

On 12/01/2021 04:23, Gimhani Uthpala wrote: > Hi team, > https://www.openssl.org/docs/man1.0.2/man3/CRYPTO_set_locking_callback.html > :  From this , learnt that for openssl multi-threaded applications to be > run safely, the callback functions to be implemented. > > I am using this in a multi-

Re: Random and rare Seg faults at openssl library level

Hi, On 07/01/21 23:53, Gimhani Uthpala wrote: On Thu, Jan 7, 2021 at 3:08 AM Ken Goldman > wrote: On 1/6/2021 12:10 PM, Gimhani Uthpala wrote: > I am getting seg-faults at openssl level. This only occurred very randomly and the following are stacks th

Re: Random and rare Seg faults at openssl library level

Hi team, https://www.openssl.org/docs/man1.0.2/man3/CRYPTO_set_locking_callback.html : From this , learnt that for openssl multi-threaded applications to be run safely, the callback functions to be implemented. I am using this in a multi-threaded application and Above scenario was again recreated

Re: Random and rare Seg faults at openssl library level

On 2021-01-07 18:05, Ken Goldman wrote: On 1/7/2021 10:11 AM, Michael Wojcik wrote: $ cat /etc/redhat-release && openssl version CentOS Linux release 7.9.2009 (Core) OpenSSL 1.0.2k-fips  26 Jan 2017 Ugh. Well, OP should have made that clear in the original message. And this is one of the pro

RE: Random and rare Seg faults at openssl library level

From: Gimhani Uthpala To: Ken Goldman Cc: openssl-users@openssl.org Date: 01/07/2021 05:53 PM Subject:[EXTERNAL] Re: Random and rare Seg faults at openssl library level I only have this 1.0.2.k-fips one version installed in both compiling and running

Re: Random and rare Seg faults at openssl library level

On Thu, Jan 7, 2021 at 3:08 AM Ken Goldman wrote: > On 1/6/2021 12:10 PM, Gimhani Uthpala wrote: > > > I am getting seg-faults at openssl level. This only occurred very > randomly and the following are stacks that seg faults at openssl level in > the given 2 cases. We are using openssl 1.0.2k. >

Re: Random and rare Seg faults at openssl library level

On Thu, Jan 7, 2021 at 1:53 PM Jan Just Keijser wrote: > On 06/01/21 21:57, Michael Wojcik wrote: > > > > The same way you'd track down an intermittent cause of Undefined > Behavior in any other program: some combination of dynamic monitoring, > symbolic execution, static code analysis, source co

Re: Random and rare Seg faults at openssl library level

On Thu, Jan 7, 2021 at 1:51 PM Jan Just Keijser wrote: > Hi, > > On 06/01/21 18:10, Gimhani Uthpala wrote: > > Dear team, > I'm running an application which uses openssl for secure communication > between processes. I am getting seg-faults at openssl level. This only > occurred very randomly and

Re: Random and rare Seg faults at openssl library level

On 1/7/2021 10:11 AM, Michael Wojcik wrote: $ cat /etc/redhat-release && openssl version CentOS Linux release 7.9.2009 (Core) OpenSSL 1.0.2k-fips 26 Jan 2017 Ugh. Well, OP should have made that clear in the original message. And this is one of the problems with using an OpenSSL supplied by t

RE: Random and rare Seg faults at openssl library level

> From: Jan Just Keijser > Sent: Thursday, 7 January, 2021 01:23 > > On 06/01/21 21:57, Michael Wojcik wrote: > > > > > > But you're asking the wrong question. The correct question is: Why are you > > using an outdated version of OpenSSL? > > possibly because: > > $ cat /etc/redhat-release && open

Re: Random and rare Seg faults at openssl library level

On 06/01/2021 17:10, Gimhani Uthpala wrote: >   I am setting context to use SSLv23_method() s. However, I can see > ssl3_ methods being called. Is there any issue with that?   Just answering this one side question: no, this is normal behaviour. Matt

Re: Random and rare Seg faults at openssl library level

Please remove my email > On Jan 7, 2021, at 3:23 AM, Jan Just Keijser wrote: > > On 06/01/21 21:57, Michael Wojcik wrote: >> >> The same way you'd track down an intermittent cause of Undefined Behavior in >> any other program: some combination of dynamic monitoring, symbolic >> execution, st

Re: Random and rare Seg faults at openssl library level

On 06/01/21 21:57, Michael Wojcik wrote: The same way you'd track down an intermittent cause of Undefined Behavior in any other program: some combination of dynamic monitoring, symbolic execution, static code analysis, source code review, testing variants, tracing, fuzzing, post-mortem analys

Re: Random and rare Seg faults at openssl library level

Hi, On 06/01/21 18:10, Gimhani Uthpala wrote: Dear team, I'm running an application which uses openssl for secure communication between processes. I am getting seg-faults at openssl level. This only occurred very randomly and the following are stacks that seg faults  at openssl level in the g

Re: Random and rare Seg faults at openssl library level

On 1/6/2021 12:10 PM, Gimhani Uthpala wrote: I am getting seg-faults at openssl level. This only occurred very randomly and the following are stacks that seg faults  at openssl level in the given 2 cases. We are using openssl 1.0.2k. The usual cause is that you are compiling with one version

Re: Random and rare Seg faults at openssl library level

On 06/01/2021 20:57, Michael Wojcik wrote: But you're asking the wrong question. The correct question is: Why are you using an outdated version of OpenSSL? -- Michael Wojcik :whip-crack: !

RE: Random and rare Seg faults at openssl library level

> From: openssl-users On Behalf Of Gimhani > Uthpala > Sent: Wednesday, 6 January, 2021 10:10 > I'm running an application which uses openssl for secure communication between > processes. I am getting seg-faults at openssl level. This only occurred very > randomly and the following are stacks th

Random and rare Seg faults at openssl library level

Dear team, I'm running an application which uses openssl for secure communication between processes. I am getting seg-faults at openssl level. This only occurred very randomly and the following are stacks that seg faults at openssl level in the given 2 cases. We are using openssl 1.0.2k. Went thr

SSL_peek_ex() hangs multiple times at random

Hi Everyone, I'm currently using the networking library libneon (version 31.2) which internally uses openSSL 1.1.1d The issue is that a hang occurs at random in SSL_peek_ex() API multiple times in a day. 'strace ' shows the SSL_peek_ex() API is stuck in an unfinished read. Could

Re: Proposed change to linux kernel about random numbers

processes + * ask for truly secure random numbers and absolutely want + * to wait for the entropy pool to fill, and others just + * do "getrandom(0)" to get some ad-hoc random numbers. + * + * If you're generating a secure key, you'd better ask for + * more than 128 bits of r

Proposed change to linux kernel about random numbers

Please take a look at https://lore.kernel.org/lkml/CAHk-=wiGg-G8JFJ=r7qf0b+utqa_weouk6v+mcmfsljlrq6...@mail.gmail.com/ and consider giving your comments. TL;DR: see the comment below. + * Hacky workaround for the fact that some processes + * ask for truly secure random numbers and absolutely

Re: Support for /dev/*random in OpenSSL 1.1.1

> Now I see this in e_os.h: > > /* > * Linux kernels 4.8 and later changes how their random device works and there > * is no reliable way to tell that /dev/urandom has been seeded -- > getentropy(2) > * should be used instead. > */ > # ifndef DEVRANDOM_SAFE_KERNEL >

Support for /dev/*random in OpenSSL 1.1.1

: /* * Linux kernels 4.8 and later changes how their random device works and there * is no reliable way to tell that /dev/urandom has been seeded -- getentropy(2) * should be used instead. */ # ifndef DEVRANDOM_SAFE_KERNEL #define DEVRANDOM_SAFE_KERNEL4, 8 # endif So openSSL 1.1.1 will

Re: Validating RSA Random Probably Prime KAT !!

e > give the corresponding APIs to be used. > > I considered prandom, qrandom as factors p, q and tried checking RSA key > generation with the mentioned exponent. But results are not as expected. I > guess prandom, qrandom are to be used as only initial random prime numbers > and see that key

Validating RSA Random Probably Prime KAT !!

mentioned exponent. But results are not as expected. I guess prandom, qrandom are to be used as only initial random prime numbers and see that key generation tries to generate a new random number when they are not meeting the criteria as mentioned in the *.txt file (reason as part of Result) . Just my

Re: [openssl-users] /dev/random in FIPS mode Error: PRNG not seeded

& Encryption Phone +61 7 3031 7217 Oracle Australia -Original Message- From: Cipher [mailto:dhanukumar1...@gmail.com] Sent: Wednesday, 12 September 2018 7:24 PM To: openssl-users@openssl.org Subject: [openssl-users] /dev/random in FIPS mode Error: PRNG not seeded Hello, We have a cu

[openssl-users] /dev/random in FIPS mode Error: PRNG not seeded

1 certification and we should be using /dev/random. So we patched e_os.h to change order to use "/dev/random" than /dev/urandom. i.e before define DEVRANDOM "/dev/urandom","/dev/random" after define DEVRANDOM "/dev/random","/dev/ur

Re: [openssl-users] Using random bytes only in openssl_encrypt versus real private key

In message <6126f3d3-91a0-02b3-20e8-ab26dbf8b...@gmail.com> on Sun, 2 Sep 2018 06:48:09 -0500, Jim Dutton said: > It appears that the (PHP) openssl_encrypt function will accept a string of > random bytes as the encryption key in place of a generated private key. It > works withou

Re: [openssl-users] Using random bytes only in openssl_encrypt versus real private key

n "generated private key". Somewhat of a semantic ambiguity. On 09/02/2018 17:08, Viktor Dukhovni wrote: > > >> On Sep 2, 2018, at 7:48 AM, Jim Dutton wrote: >> >> It appears that the (PHP) openssl_encrypt function will accept a string of >> random byt

Re: [openssl-users] Using random bytes only in openssl_encrypt versus real private key

> On Sep 2, 2018, at 6:51 PM, Jim Dutton wrote: > > It is interesting to note that the openssl_private_encrypt function appears > to require a "true" private key and either expects or defaults to RSA. Not surprising, given the name and brief documentation. > In both cases neither PHP-OpenSSL

Re: [openssl-users] Using random bytes only in openssl_encrypt versus real private key

o "encrypt" functions. Sent from my iPad (on iOS11 with only a few lost apps) - J.Dutton > On Sep 2, 2018, at 5:08 PM, Viktor Dukhovni > wrote: > > > >> On Sep 2, 2018, at 7:48 AM, Jim Dutton wrote: >> >> It appears that the (PHP) openssl_encrypt fu

Re: [openssl-users] Using random bytes only in openssl_encrypt versus real private key

> On Sep 2, 2018, at 7:48 AM, Jim Dutton wrote: > > It appears that the (PHP) openssl_encrypt function will accept a string of > random bytes as the encryption key in place of a generated private key. This is an interface to data encryption with the OpenSSL *symmetric* encryptio

Re: [openssl-users] Using random bytes only in openssl_encrypt versus real private key

>This begs the question: what does openssl_encrypt actually do with just a > string of random bytes passed as the "key". I can't find anything in the OpenSSL or PHP/openssl source code that clearly identifies any particular action There is no such name (git gr

[openssl-users] Using random bytes only in openssl_encrypt versus real private key

It appears that the (PHP) openssl_encrypt function will accept a string of random bytes as the encryption key in place of a generated private key. It works without any errors or warnings. So does the openssl_decrypt function. This begs the question: what does openssl_encrypt actually do with just

Re: [openssl-users] AES-256 Do I need random IV?

ERATED, &generated[0]) == 0) { exit(1); } memcpy(key, generated, SZ_KEY); key[SZ_KEY] == '\0'; memcpy(iv, (unsigned char *)generated + SZ_KEY, SZ_IV); iv[SZ_IV] = '\0'; 2017-04-27 15:34 GMT+03:00 Salz, Rich via openssl-users : >> For AES-256 encryption, should IV be

Re: [openssl-users] AES-256 Do I need random IV?

an attack. Here the recommendation to use not only unique but unpredictable (aka random) IV. So it boils down to your user case and that model: e.g., if it may be possible for an attacker to feed you ciphertext and learn the results of your decryption - your IV may need to be random. Regards

Re: [openssl-users] AES-256 Do I need random IV?

> For AES-256 encryption, should IV be random? I am already using a random > salt, so I was wondering if IV should be random too. It should be non-repeating. It can just be a counter. (Yes, I know OP didn't ask about AESGCM. But if they're coming here for advice ... ) -

Re: [openssl-users] AES-256 Do I need random IV?

On 27/04/2017 14:00, Yaşar Arabacı wrote: Hi, For AES-256 encryption, should IV be random? I am already using a random salt, so I was wondering if IV should be random too. Thanks in advance AES itself takes neither an IV nor a salt. AES in CBC mode takes a 128 bit IV for the CBC mode, it is

Re: [openssl-users] AES-256 Do I need random IV?

On Thu, 27 Apr 2017 15:00:37 +0300 Yaşar Arabacı wrote: > For AES-256 encryption, should IV be random? I am already using a > random salt, so I was wondering if IV should be random too. An IV is part of a cipher mode. AES-256 is just a block cipher. You can't use it on its own. So

[openssl-users] AES-256 Do I need random IV?

Hi, For AES-256 encryption, should IV be random? I am already using a random salt, so I was wondering if IV should be random too. Thanks in advance -- http://ysar.net/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Custom Random number generation while in Fips mode

is, Jr. > wrote: > > > On Jul 27, 2016, at 8:18 PM, pratyush parimal > > wrote: > > > > Hi all, > > > > I work on a consumer application which is striving to be fips-140-2 > > compliant. > > > > I'm using OpenSSL as recommended

Re: [openssl-users] Custom Random number generation while in Fips mode

ompliant. > > > > I'm using OpenSSL as recommended in the fips guide by invoking > fips_mode_set(). However, in certain parts of the same application, I'm > using my own non-OpenSSL random number generator to generate salts for > hashing passwords for the app user accounts(I

Re: [openssl-users] Custom Random number generation while in Fips mode

in parts of the same application, I'm using > my own non-OpenSSL random number generator to generate salts for hashing > passwords for the app user accounts(I'm not using RAND_bytes). > > Does anyone know if using my custom random number generator in this way > viola

[openssl-users] Custom Random number generation while in Fips mode

Hi all, I work on a consumer application which is striving to be fips-140-2 compliant. I'm using OpenSSL as recommended in the fips guide by invoking fips_mode_set(). However, in certain parts of the same application, I'm using my own non-OpenSSL random number generator to generate

Re: [openssl-users] force to use /dev/random for openssl fips module

xxiao, have you changed the code to also increase the timeout and not try to use other devices to get entropy? If /dev/random is blocking at the time, it may run into issues trying to look for other sources of entropy than giving up. On Tue, Dec 8, 2015 at 8:25 PM, xxiao8 wrote: > I don

[openssl-users] force to use /dev/random for openssl fips module

I don't know how critical is the DEVRANDOM for openssl-fips, in e_os.h I saw this: #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom" we have a hardware RNG that is feeding /dev/random via: /sbin/rngd -r /dev/hwrng -W 4000 so

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

> 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

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

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 ra

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

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

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

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 gener

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

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

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

gt; 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, filesyst

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

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 (

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

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

Re: [openssl-users] ECDSA with random number

ound any possible place where I would be able to pass random value. Any > ideas? To check that signatures are produced properly, verify the signature by running the signature verification algorithm. Unfortunately, ECDSA does not easily admit determininistic test vectors. The CFRG is discussin

Re: [openssl-users] ECDSA with random number

Hi Piotr, As you have found out, choosing the per message random number in ECDSA signature is crucial for the security of private key. Leaving this responsibility on users is dangerous. This is the reason you won't find any crypto API to feed the random number for ECDSA signature. If you

[openssl-users] ECDSA with random number

As in the subject is it possible to generate signature with given random number? According to the documentation of ECDSA uses RNG so it would be difficult to find out private key from signature but i want just to test my data to check if signature is being generated properly and i have'nt

Re: openssl ECDH random number

On 7 October 2013 19:39, Dave Thompson wrote: > You don’t need to change OpenSSL to do what you say you want; just create an > EC_KEY with the curve, > > set the desired private key value, and do a point multiplication to get the > public key value and set that. > > > > This is assuming a key to b

RE: openssl ECDH random number

wner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of M.W. Aruna Withanage Sent: Monday, September 30, 2013 12:24 To: openssl-users@openssl.org Subject: *** Spam *** openssl ECDH random number Hi, For my MSc project I am using openSSL for encryption and key distribution. I

openssl ECDH random number

Hi, For my MSc project I am using openSSL for encryption and key distribution. I have a requirement to replace the secret random number(private key) generated for ECDH with my own random number. I hope to edit the openSSL source. For that I need to know what is the source file I need to look at

Re: using TRNG via /dev/random

shold parameter that causes > it to decide at what level of entropy in the pool it will start to pull > more entropy in through rngd. > > It defaults to a low level, but there is high demand during the boot > process, which results in entropy starvation and /dev/random blocking > d

Re: using TRNG via /dev/random

faults to a low level, but there is high demand during the boot process, which results in entropy starvation and /dev/random blocking during the boot process. I checked this by using bootchart which can log the level of entropy in the kernel entropy pool during the boot sequence. With a higher

Re: using TRNG via /dev/random

hi david! do you have a patch about this hack? 2013/9/25 David Johnston > On 9/24/2013 11:58 AM, Roberto Spadim wrote: > >> There's space to create a new random device at /dev if you want too =) >> /dev/nbrandom ? no block random? :) >> >> 2013/9/24 R

Re: using TRNG via /dev/random

On 9/24/2013 11:58 AM, Roberto Spadim wrote: There's space to create a new random device at /dev if you want too =) /dev/nbrandom ? no block random? :) 2013/9/24 Richard Könning : Am 24.09.2013 02:05, schrieb starlight.201...@binnacle.cx: At 12:59 9/23/2013 -0700, Michael Sierchio

Re: using TRNG via /dev/random

There's space to create a new random device at /dev if you want too =) /dev/nbrandom ? no block random? :) 2013/9/24 Richard Könning : > Am 24.09.2013 02:05, schrieb starlight.201...@binnacle.cx: > >> At 12:59 9/23/2013 -0700, Michael Sierchio wrote: >>> >>> >

Re: using TRNG via /dev/random

Am 24.09.2013 02:05, schrieb starlight.201...@binnacle.cx: At 12:59 9/23/2013 -0700, Michael Sierchio wrote: I'll repeat myself - the fact that the /dev/random implementation you're using blocks is a serious design flaw. Convince Linus, the GPG developers et al.--not me. No

Re: using TRNG via /dev/random

Am 23.09.2013 21:59, schrieb starlight.201...@binnacle.cx: At 20:27 9/23/2013 +0200, Richard Könning wrote: /dev/random is a PRNG which blocks when the (crude) entropy estimation of the entropy pool falls below a limit. Besides this there are afaik no big differences between /dev/random and

Re: using TRNG via /dev/random

At 12:59 9/23/2013 -0700, Michael Sierchio wrote: > >I'll repeat myself - the fact that the >/dev/random implementation you're using >blocks is a serious design flaw. Convince Linus, the GPG developers et al.--not me. Till then I respect their view as embodied by the la

Re: using TRNG via /dev/random

On Mon, Sep 23, 2013 at 12:59 PM, wrote: > At 20:27 9/23/2013 +0200, Richard Könning wrote: >>/dev/random is a PRNG which blocks when the (crude) >>entropy estimation of the entropy pool falls below a >>limit. Besides this there are afaik no big >>differences b

Re: using TRNG via /dev/random

At 20:27 9/23/2013 +0200, Richard Könning wrote: >/dev/random is a PRNG which blocks when the (crude) >entropy estimation of the entropy pool falls below a >limit. Besides this there are afaik no big >differences between /dev/random and /dev/urandom. In the sense that all TRNG out

Re: using TRNG via /dev/random

Am 22.09.2013 19:27, schrieb starlight.201...@binnacle.cx: No /dev/urandom is a PRNG. /dev/random is a TRNG. Read the code https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=272b98c6455f00884f0350f775c5342358ebb73f /dev/random is a PRNG which

Re: using TRNG via /dev/random

No /dev/urandom is a PRNG. /dev/random is a TRNG. Read the code https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=272b98c6455f00884f0350f775c5342358ebb73f The TPM here generates 40Kbits/sec, or 5000 bytes/sec--more than enough for the situation at

Re: using TRNG via /dev/random

On Sun, Sep 22, 2013 at 10:00 AM, wrote: > Not interested in any PRNG. /dev/random is a PRNG. As I pointed out, "True" RBGs don't produce enough material. The problem is the fact that /dev/random blocks.

Re: using TRNG via /dev/random

Not interested in BSD or Yarrow PRNG. Not interested in any PRNG. Interested in True RNG from hardware as mixed by Theodore Ts'o excellent, predominant and continually evolving (https://lkml.org/lkml/2013/9/13/624) "/dev/random". Have more than enough TRNG for the needs of

Re: using TRNG via /dev/random

On Sat, Sep 21, 2013 at 2:09 PM, David Lawless wrote: > ... > Next I did this: > >cd /dev >mv urandom urandom.hold >mknod urandom c 1 8 > > Which causes /dev/urandom to make use of > the /dev/random driver in the kernel. > > The above sort-of w

using TRNG via /dev/random

Hello, I'm interested in having 'openssl' version 1.0.1e make use, by default, of hardware generated true random numbers for creating session keys. So far I've configured a STElectronics ST33 TPM as the majority source of /dev/random entropy by configuring and starting th

using TRNG via /dev/random

Hello, I'm interested in having 'openssl' version 1.0.1e make use, by default, of hardware generated true random numbers for creating session keys. So far I've configured a STElectronics ST33 TPM as the majority source of /dev/random entropy by configuring and starting th

Re: Generating the same RSA PKI without using random seed

On 5/12/2013 10:42 PM, MrUmunhum wrote: Hi group, I have a C program that does peer to peer functions. I am using RSA PKI to encrypt the packets. I need to be able to generate the same PKI keys on both machines. So I don't want to use a random seed. RSA_generate_key() calls random. Is

Generating the same RSA PKI without using random seed

Hi group, I have a C program that does peer to peer functions. I am using RSA PKI to encrypt the packets. I need to be able to generate the same PKI keys on both machines. So I don't want to use a random seed. RSA_generate_key() calls random. Is there another API I can call that does no

Re: Are Openssl Random Number Generator NIST compliant ?

On 6 March 2013 03:55, Nayna Jain wrote: > > Hi all, > > Are RAND_seed(), RAND_add() NIST SP 800-151A compliant ? 800-151 does not appear to exist, got a link? __ OpenSSL Project http://www.openssl

Are Openssl Random Number Generator NIST compliant ?

Hi all, Are RAND_seed(), RAND_add() NIST SP 800-151A compliant ? NIST SP 800-151A compliant enforces that RBGs specified in SP 800-90 (HASH, HMAC, CTR, DUAL_EC) and ANS X9.62-2005 (HMAC) are acceptable standards I think this depends on the engine being loaded. HOwever, not sure what engine is

Re: Client Random

Thanks Jakob. But still, it is not clear to me. If server random is not present, a malicious user can copy all the messages from client and can replay them multiple times leading to DoS attack. But even if client random is not present, I believe, attacker cannot replay messages from server side as

Re: Client Random

On 2/5/2013 12:05 PM, Thulasi wrote: Hello all, ** This is not regarding OpenSSL software but about the protocol in general. I am trying to understand the use of 32 byte(4 byte data + 28 byte rand) client random which is part of Client Hello. I understand that Server Random is required to

Re: genrsa question how secure is the random creation

On Tue, Dec 11, 2012 at 8:06 PM, Michael Sierchio wrote: > - Select an interval near the desired size [ 2^1023 + 1^1022 + 1 , 2^1024 - 1 ] > - Sieve out composites divisible by small primes > - Select two probable primes such that (p - q) is reasonably large > (2^100 or so) to defeat the differ

Re: genrsa question how secure is the random creation

> On Tue, Dec 11, 2012 at 6:27 PM, redpath wrote: >> When using this command >> >> openssl genrsa -out test.pem 2048 >> >> an RSA pair is created. Its not so much I want to know how a pair is >> randomly selected >> but how secure is that rando

Re: genrsa question how secure is the random creation

On Wed, Dec 12, 2012 at 12:39 PM, Salz, Rich wrote: > Until someone breaks the website, spoofs it, buys out the owner, etc. > > Q2.4: Are the numbers available in a secure fashion? > > Yes, since April 2007 you can access the server via https://www.random.org/ > > I should probably note that while

RE: genrsa question how secure is the random creation

Until someone breaks the website, spoofs it, buys out the owner, etc. Q2.4: Are the numbers available in a secure fashion? Yes, since April 2007 you can access the server via https://www.random.org/ I should probably note that while fetching the numbers via secure HTTP would protect them from b

  1   2   3   4   >