# Questions tagged as ['dsa']

Recently I noticed that my device generates *short-sized* `Nonces`

.

Approximately $2 ^ {243} - 2^{244}$.

Could it turn out that there will be a small leak of information about the first * 3 bits* of

`Nonces`

?Accordingly, if `Nonces`

is short, then it must contain null at the beginning.
That is, the first * 3 bits* of

`Nonces`

contain null at the beginning.*Hence, for the sake of safety:*

When creating an **ECDSA** signatur ...

i am on a task in cryptography and need a hint (PLEASE NO SOLUTION).

The Task is:

I can send Messages (Digital Numbers) to a Docker Container. The response are the values p,q,g,z1,s,r and hashvalue(m+z1). So... when i enter the number 1 i get the DSA values used for signing.

Unknown is the value of k, z2 and x (the private key)

Known is that p,q,g,z1,z2 are fixed for every message. So they are the same ev ...

Can multiple signatures of the same message with the same private key (different nonces) lead to a private key trace?

Lets say I have a message that needs to be signed by two keys that were generated using ECDSA

Is it possible to make a signature that accounts for both keys, meaning I can verify with both and see they are valid?

An example, if we need a cryptocurrency example:

Address 1 has 10 coins Address 2 has 10 coins

Both inputs are in the transaction, and now need to be signed. Is it possible to make it so only one ...

Can I know just from a Bitcoin public key if the private key is odd or even?

[moderator note] That is, can we find parity of the private key from a secp256k1 public key?

For the original dump of digits, see here.

I was wondering why ecdsa generates a signature in form of a pair (r and s) and why it can't be only one value.

I'm trying to implement kleptography SETUP attack of ecdsa with python. Just a simply script to verify the algorithm. However i can't get the right output as the paper said. Where is the problem? Can anyone help?

```
from ecpy.curves import Curve, Point
import hashlib
import gmpy
cv = Curve.get_curve('secp256k1')
G = Point(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
0x48 ...
```

I want to generate a public key that I can use to sign messages and receive messages (using ECDH for exemple).

I want to do so to have the smallest payload to share.

Is it possible and proved secure ?

As of 2021, is RSA the only practical (i.e. safe, production-ready) option for asymmetric encipherment of symmetric keys at rest? ECDSA is obviously preferable over RSA in the case of signing, but (unless I'm woefully misinformed) it doesn't support key encipherment. If RSA is the only practical option at present, are there any notable efforts toward future alternatives that I should be aware of?

I'm currently working on a distributed threshold DSA scheme that requires to find the product of two sums via secure multi-party computation. Specifically speaking, every one of $n$ parties $P_i$ possesses a DSA key pair $(sk_i, pk_i)$, where $sk_i=d_i \in \mathbb{Z}_q$ and $pk_i = g^{d_i}$. I want to collectively generate a signature $S_{\Sigma} = k_{\Sigma}^{-1}(m+r_{\Sigma}d_{\Sigma})$, where$k_ ...

It is known that it is possible to apply the Chinese remainder theorem and attack `RSA`

under precise conditions.

https://tls.mbed.org/public/WSchindler-RSA_Timing_Attack.pdf

But the question is, can the Chinese remainder theorem in `ECDSA`

be applied to the parameters in `secp256k1`

?

With an RSA key pair, from my understanding, Alice who holds the private key is able to encrypt a message into a signature. She would then send the signature together with her original message to Bob. Bob would then be able to use Alice's public key to decrypt the signature which would then return the message. The decrypted message would then be compared with the original message. If they are the same, ...

In DSA signature where signing is done via

$$s = k^{-1}(H(m) + xr) \mod{q} $$

I understand why if two messages singed by the same private key $x$ use the same $k$ value you can recover the private key

But I've read various comments and answers that say if two messages signed by the same private key have the same $r$ value that is all that is needed to recover the private key, and I don't understand ...

The ECDSA standard mandates that during verification we check that an intermediate calculation does not lead to the point-at-infinity (see Step 5. in this summary on Wikipedia ). But *why* do we check for this? That is, how do you as an attacker actually trigger this event without knowledge of the private key?

In the above I assume that all the other checks of ECDSA are in place ($r,s \in [1,n-1]$, pu ...

I'm studying lattice attack using this sage script. There are 2 options in script: LSB and MSB. The most interesting option for me is MSB. It recovers private key with less then 100 signatures provided with script. When I run it with my PQG generated by openssl and my own signatures with zeroed 8-bit MSB I was able to recover private key with 800 signatures in one case and unable to recover even wi ...

**Update: I made my lattice attack worked finally. As the actual reason is quite complicated I decide to write an answer below to describe how it worked so anyone with similar question might get inspiration from my work. The Question is not modified.**

I was studying lattice attack recently. I tried to use data from TPM-FAIL to help me understand this attack and try to implement an attack using "textbook meth ...

In the paper: "The Random Oracle Model: a Twenty-Year Retrospective", section 7.3 by Koblitz & Menezes,the authors tried to prove the security of ECDSA+.

But after looking at the entire proof, I didn’t find that they considered the probability that both forgers would choose the same $M$ and $R'$ for the $j$-th time.

In my cognition, after considering the probability of simultaneously selectin ...

I recently started reading RFC 6979. I'm curious why it needs so many loops.

This post asks a similar question: "RFC 6979 - Why not simply hash the message & the private key for deterministic ECDSA?", but my doubts are still unanswered.

Why can't the $k$ used in ECDSA be just like $k = SHA256(sk + HASH(m))$ ?

Is it just because HMAC_DRBG has a better security proof ?

It's clear that using the private ECDSA key $x$ as an additional input into the hash algorithm, as specified in RFC 6979, doesn't *harm* security (assuming HMAC_DRBG is a PRF).

But is it *necessary*?

Would there be any problem with allowing the signature algorithm to have the same output of $k$ for the same message regardless of the key used? Per Is it safe to reuse a ECDSA nonce for two signatures if the ...

A large number of SCA papers that talk about ECDSA mention the need for blinding/randomisation of the signing process, typically with a single-sentence comment about replacing the projective coordinates (X,Y,Z) with randomised ones (lambda^2*X,lambda^3*Y,lambda*Z) and declaring the problem solved, but nothing really seems to provide any detail of what specific steps are required. In particular looking at ...

As I am going through the “Fast Multiparty Threshold ECDSA with Fast Trustless Setup” paper by Gennaro & Goldfeder, 2018, I am stumbled by the key generation protocol (Sect. 4.1, p.10):

In Phase 1, they create a (commitment, decommitment) pair using a commitment scheme. Earlier in the paper, they mention that “in practice one can use any secure hash function *H* and define the commitment to *x ...*

Given the following information:

"curve": "P-256",

"qx": "729C51D177EBE2079A0FB7B0B3C2145159CF81EC61960E642A1744719AA9F913",

"qy": "8C36BCF51475016E614F8C7E0CB1B37C7EA65B4ECCF809852C9B2D0E438710BD"

The above coordinates are supposedly valid as per the test vector expected results:

"testPassed": true

I need to determine if the above public key coordinates are valid points on the curve or not. I have t ...

The recommended parameters for a secp256k1 ECDSA curve are:

(All values are in hexadecimal)

```
p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
a = 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
b = 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000007
G = 02
79BE667E F9DCBBAC 55A06295 CE870B07
029BFCDB 2DCE28D9 5 ...
```

I was reading the “Fast Multiparty Threshold ECDSA with Fast Trustless Setup” paper by Gennaro & Goldfeder, 2018 and I encountered this portion (Sect. 2.4, p.6):

This excerpt leaves me slightly confused. First, there’s seemingly a mismatch (a typo?) between *r* and *R* — or is it that *R* is the set from which *r* is sampled? Second, most important, what are these coin tosses? There’s no men ...