<p>Assuming no bugs, obviously:</p>
<ol>
<li><p>Only potential side-channel leakage, and on major platforms likely no timing leaks even (there are tests to detect non-constant time behavior in the compiled code).</p>
</li>
<li><p>Any randomness an attacker does not have access to helps.</p>
</li>
<li><p>There will likely still be context objects (among other reasons, to carry randomization data), but they will be more lightweight to construct. The &quot;default&quot; static context will likely be expanded to support all operations, but not have any randomization.</p>
</li>
</ol>
<p>In general I would advise you to hide contexts from the user, but construct them at initialization time using randomness, and cache them for later usage.</p>
<p>Source: am co-maintainer of the library.</p>

CC BY-SA 4.0
2021-12-03T15:30:00.643Z
Thank you for your contributions. I am glad to know my understanding is correct.
user3074620
CC BY-SA 4.0
2021-12-03T15:14:10.043Z
2021-12-03T15:14:10.043Z
Pieter Wuille
<p>I am designing an API which will utilize libsecp256k1.</p>
<p>I am trying to hide most of the low-level stuff, and context is one of the things I want to handle for a consumer of my API. It would be difficult to have the user mess with contexts when they don't want to care about the crypto low-level things.</p>
<p>As I understand, the signing context should be randomized for security purposes.</p>
<ol>
<li>What is the worst case scenario if I release a library that uses a non-randomized signing context for these functions? Side-channel weakness? Definite secret key leakage? etc.</li>
<li>How much would a weak prng randomization help, if any? (for environment where csprng is not available, etc.)</li>
<li>I read that they are moving toward possibly removing need for context management and including some sort of precompiled global solution. Would this remove the need to worry in exchange for slightly larger binary if used?</li>
</ol>
<p>Thank you in advanced!</p>

<secp256k1>
What are the risks of using a non-randomized context with signing contexts?
user3074620
# What are the risks of using a non-randomized context with signing contexts?

(Asked by: username_0 on 2021-12-03)

I am designing an API which will utilize libsecp256k1.

I am trying to hide most of the low-level stuff, and context is one of the things I want to handle for a consumer of my API. It would be difficult to have the user mess with contexts when they don't want to care about the crypto low-level things.

As I understand, the signing context should be randomized for security purposes.

1. What is the worst case scenario if I release a library that uses a non-randomized signing context for these functions? Side-channel weakness? Definite secret key leakage? etc.
2. How much would a weak prng randomization help, if any? (for environment where csprng is not available, etc.)
3. I read that they are moving toward possibly removing need for context management and including some sort of precompiled global solution. Would this remove the need to worry in exchange for slightly larger binary if used?

Thank you in advanced!

**Tags:** secp256k1


---

## 1 answers

### Answer by username_1 on 2021-12-03. Score: 2 | Accepted answer

Assuming no bugs, obviously:

1. Only potential side-channel leakage, and on major platforms likely no timing leaks even (there are tests to detect non-constant time behavior in the compiled code).
2. Any randomness an attacker does not have access to helps.
3. There will likely still be context objects (among other reasons, to carry randomization data), but they will be more lightweight to construct. The "default" static context will likely be expanded to support all operations, but not have any randomization.

In general I would advise you to hide contexts from the user, but construct them at initialization time using randomness, and cache them for later usage.

Source: am co-maintainer of the library.

> **Comments:**
> **username_0**: Thank you for your contributions. I am glad to know my understanding is correct.  

---

