Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement secure_random() #727

Closed
wants to merge 0 commits into from
Closed

Conversation

lovvik
Copy link

@lovvik lovvik commented Jun 5, 2024

as asked by issue #683

  • Implemented secure_random()
  • Added 2 build directories
  • Changed calls of fast_random() in src, tests and benchmarks
  • Added -lcrypto linking


if not conf.CheckLibWithHeaderExt('ssl', 'openssl/rand.h', 'C', run=not is_crosscompiling):
if not conf.CheckLibWithHeaderExt('ssl', 'openssl/rand.h', 'C', run=not is_crosscompiling) or not conf.CheckLibWithHeaderExt('crypto', 'openssl/crypto.h', 'C', run=not is_crosscompiling):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hello!
it's enough to validate the presence of openssl/rand.h here; validating every single file's presence we use in the project is too redundant

Copy link
Author

@lovvik lovvik Jun 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't really get why, but this how i could get -lcrypto to be linked.
This, on the other hand results in linkage errors :

        conf.env.AddManualDependency(libs=['ssl','crypto'], prefix=ossl_prefix)

    if not conf.CheckLibWithHeaderExt('ssl', 'openssl/rand.h', 'C', run=not is_crosscompiling): #or not conf.CheckLibWithHeaderExt('crypto', 'openssl/crypto.h', 'C', run=not is_crosscompiling):
        env.Die("OpenSSL not found (see 'config.log' for details)") ```

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't really get why, but this how i could get -lcrypto to be linked.

Ah, sorry, you are checking a different library here. Then it's OK.

You can also make shorten the condition:

if not conf.CheckLibWithHeaderExt(['ssl', 'crypto'], ['openssl/rand.h', 'openssl/crypto.h'], 'C', run=not is_crosscompiling):

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems we have AddPkgConfigDependency('libssl'), but don't have AddPkgConfigDependency('libcrypto'), it should be added, because they're different packages in pkg-config:

pkg-config --cflags --libs libssl
-lssl 

pkg-config --cflags --libs libcrypto
-lcrypto 

And in this case it indeed makes sense to add a second check. openssl/rand.h checks that libssl worked, and openssl/crypto.h checks that lubcrypto worked.

i don't really get why, but this how i could get -lcrypto to be linked.

Likely CheckLibWithHeaderExt adds it, but we should no rely on it. Actually it's probably a bug that should be fixed (not in this PR of course).

Also please avoid long lines.

Copy link
Author

@lovvik lovvik Jun 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, i now have this. The AddPkgConfigDependency('libcrypto') does it (even without CheckLib...) . is it ok ?

elif 'openssl' in system_dependencies:
    ossl_prefix = None
    # macOS: fallback to use a brew-installed openssl
    if meta.platform == 'darwin' and not is_crosscompiling:
        ossl_prefix = env.FindBrewPackage('openssl')

    conf = Configure(env, custom_tests=env.CustomTests)

    if not conf.AddPkgConfigDependency('libssl', '--cflags --libs', add_prefix=ossl_prefix):
        conf.env.AddManualDependency(libs=['ssl'], prefix=ossl_prefix)

    if not conf.AddPkgConfigDependency('libcrypto', '--cflags --libs', add_prefix=ossl_prefix):
        conf.env.AddManualDependency(libs=['crypto'], prefix=ossl_prefix)

    if not conf.CheckLibWithHeaderExt('ssl', 'openssl/rand.h', 'C', run=not is_crosscompiling) or \
        not conf.CheckLibWithHeaderExt('crypto', 'openssl/crypto.h', 'C', run=not is_crosscompiling):
        env.Die("OpenSSL not found (see 'config.log' for details)")

    env = conf.Finish()

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was not intended to remove the original fast_random version, so please just keep it

@@ -17,7 +17,6 @@ namespace core {
namespace {

uint32_t rng_state;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Comment on lines 83 to 97
// Wrappers
// To use for external calls

uint32_t secure_random() {
return fast_random();
};

uint32_t secure_random_range(uint32_t from, uint32_t to) {
return fast_random_range(from, to);
};

double secure_random_gaussian() {
return fast_random_gaussian();
};

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be implemented in target_nocsprng (as written in #683)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, i don't understand. That is target_nocsprng.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, the fast_random implementation should be the only in this file, and secure_random() function implemented through calls to fast_random*() is the only one to go to the target_nocsprng directory.

//! @file roc_core/fast_random.h
//! @file roc_core/target_nocsprng/roc_core/secure_random.h
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the original file should be kept

Copy link
Author

@lovvik lovvik Jun 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was asked by gavv : #683 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be changed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be changed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be changed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be changed; checkout the task description and revert other places please

@gavv gavv added needs revision Pull request should be revised by its author contribution A pull-request by someone else except maintainers labels Jun 7, 2024
@gavv
Copy link
Member

gavv commented Jun 7, 2024

Thanks for PR!

Regarding my comment from matrix that you linked above: #683 (comment)

I guess I was not very clear.

The idea is:

  • fast_random is always available and has a single cross-platform implementation; it's not affected by this task at all
  • secure_random is always available
  • but secure_random can have two different implementations: using OpenSSL, and fallback using fast_random (which as you remember is always available)
  • some parts of the code use fast_random, some use secure_random, depending on requirements; CSPRNG is needed when RTP RFC mandates it; but it's slower and can fail, so it's not used everywhere
  • regarding tests:
    • we need tests for fast_random and for secure_random; they're different tests at least because these functions have different signatures
    • tests for fast_random should be be affected by this task at all
    • tests for secure_random can have only one implementation, no matter if secure_random is implemented via OpenSSL or fast_random

That's what I tried to say in that comment, we don't need two separate implementations of tests for secure_random, however we still need separate tests for fast_random and secure_random.

@gavv gavv changed the title Solving issue #683 Implement secure_random() Jun 7, 2024
@lovvik
Copy link
Author

lovvik commented Jun 7, 2024

oh...i really misinterpreted it all. It will be fixed.

@github-actions github-actions bot added the needs rebase Pull request has conflicts and should be rebased label Jun 17, 2024
Copy link

🤖 The latest upstream change made this pull request unmergeable. Please resolve the merge conflicts.

@lovvik lovvik closed this Jun 25, 2024
@github-actions github-actions bot removed needs revision Pull request should be revised by its author needs rebase Pull request has conflicts and should be rebased labels Jun 25, 2024
@gavv gavv added the postponed We decided to postpone the issue for an indefinite period label Jul 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution A pull-request by someone else except maintainers postponed We decided to postpone the issue for an indefinite period
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants