# Tag Info

10

Let me first answer your actual question (and then I'll proceed to answer something slightly different that I think will be informative and helpful). Your question asks whether it's possible to use only a DSA key. Technically speaking, this is of course possible. The reason is that a DSA key has exactly the same format as an ElGamal key. No one forces you to ...

7

No, in general the hash isn't determined by the curve definition by NIST. Reasonable mappings of course exist (for a 224 bit curve you would probably use a hash with output size of 224 such as SHA-224). The hash used should however be specified by the protocol itself. The ECDSA key size as indicated by the -b of the openssh argument is linked to the hash ...

5

Yes. Discrete-log based cryptosystems (e.g., El Gamal) have a similar property. It's "multiply", not "add", but that's just because that's the group operation for discrete-log based cryptosystems. More generally, I suggest you look at threshold cryptography. Threshold public-key cryptosystems are a class of systems that can achieve the sort of thing you ...

4

Assuming this is the paper you're talking about, your modification completely eliminates resilience to collisions in the underlying hash function $H$. The EdDSA scheme (and in the Schnorr scheme on which it is based) is highly resilient against collisions in $H$. Specifically, in the generic group model, the Schnorr scheme has been proven to be secure even ...

4

Well, if the hash function is weak, then the attacker might be able to take a valid signature for a signed message, and find a second message for which the signature for this first would also validate for the second. For example, if Alice signs the message "I like chocolate", what Bob might do is find a second message "Alice owes Bob $13,106,107.57", and ... 4 Deterministic signatures are safe in the random oracle model. Using HMAC_DRBG allowed me to rely on existing research on the safety of that construction and how close it comes to a "true" random oracle. If I had used any other "handmade" construction, then I would have had to provide extensive analysis on why it is secure. Being naturally lazy, I chose ... 4 The ECDSA algorithm can't be used for encryption. It's not that there's no accepted way to do it, it's that it's simply not possible to do so. Likewise, RSA signing can't be used to encrypt (there's a mandatory hash in signing that you don't want in encryption). However, RSA signatures work similarly to RSA encryption; they aren't interchangeable, but ... 3 During verification you perform$u_1 = H ( m ) w \bmod{q}$would return the same$u_1$for multiple hash values. In general you only want one hash to succeed, even if it is unlikely that an adversary can generate a hash that equals$n q + H(m) w$. Of course this means that any hash with the leftmost bits identical to the org. hash is also acceptable, but ... 3 First to explain you, why you get 512-bit outputs from a 256-bit curve: The output is basically a point (x-coordinate is enough) and a message-dependant value, with the x-coordinate being expressed as integer. You can verify the signature by checking for a specific relationship between the point and the message-dependant value and the public key point. In ... 3 Generically speaking you can do this but you shouldn't. It may well be possible to perform specific calculations when a random number is used for both (I'll leave it to the more theoretically inclined to create a demo if this is possible for ElGamal / DSA). Another reason is that the single secret gets known then both keys/algorithms will be compromised. ... 3 An attack is described in Section 4.1.6 of the SEC1 document. Regarding xagawa's answer: The attack you describe is different from that described in Section 4.5 of the Blake-Wilson--Menezes paper. Specifically, their attack: (a) does not require knowledge of the secret ephemeral key$k$, and (b) changes the reference point$P$, which is not allowed in ... 3 In your particular case the order of the point divides$p-1$, this means that the embedding degree of your curve is 1. You should be able to apply the MOV attack to transfer your instance of ECDLP into an instance of DLP over$\mathbb{F}_{p}^*. This would allow you to use the Index Calculus to solve your problem. As the Index Calculus is subexponential, ... 3 According to this answer, RSA with the "usual" "padding scheme, described in PKCS#1 as the 'old-style, v1.5' padding," can be made to satisfy that; one would need to specify NULL or omission and require that the public exponent's prime factors are all easily findable and sufficiently bigger than the 4th root of the modulus. 2 It depends. If the entire input itself is within a DER encoded structure, then I would bug out. There is nothing defined for BER, CER or DER that would allow padding of structures within constructed values. If the input is just followed by additional data or junk bytes then it is up to the protocol or otherwise your discretion if you want to accept the ... 2 I don't think there's an exact "correct" behaviour in this case. It would be up to the implementation to decide, since the spec is only concerned about the DER encoded portion. If your implementation parses the input as it moves along only, and doesn't concern itself with the overall size, then it would work fine. Having said that, I believe the best ... 2 ECC public keys are not random numbers. They are generated through a scalar multiplication of a random scalar with a known/public point on the curve, called Generator. The entropy lies entirely in the random scalar. Two public keys will collide if the random scalars collide. When you say "256bit ECDSA public key" you probably mean that your elliptic ... 2 In ECDSA, the message is never encoded as a point in the elliptic curve. Signing in ECDSA loosely works like this: \begin{align*} k &= \text{random}(0, n) \\ (x, \_) &= k \cdot G \\ r &= x \bmod n \\ s &= k^{-1}(H(m) + r \alpha) \bmod n \end{align*}r$and$s$are the signature, and as you can see$H(m)$is only ever used as an ... 2 ECKEY object may contain: Group Private key Public key Both Group and Private key are needed to be able to calculate signature. It is most convenient to use generic ECKEY object (from API perspective), as it easy to e.g. convert between commonly used PKCS#8 PEM encoded EC private keys and ECKEY objects, and because just a BIGNUM would not be sufficient. ... 2 Sure you can do. There are many lattice attacks, using your second assumption, to ECDSA (which also applied to DSA). For instance see Smart and Howgrave-Graham and Shparlinski and Nguyen. All the lattice attacks base on finding small solutions (for the ephemeral key$k$and the private key$a$) to the signing equation$sk-ra\equiv H(m)\pmod q.$If you have ... 2 ECDH is not for signing. Your sign method using ecdh does not look like any valid signature scheme I have ever seen, and is therefore likely wildly insecure. Note that the Q&A you link to is asking a very different question. 2 What is its signature length ? Depends on what algorithms you use, but with ECDSA the signature length is twice the length of the order of the base point. For P-521 that's 1042 bits, or 132 bytes when using whole bytes for each part. For E-521 it's 1038 bits or 130 bytes. How is it better ? The design criteria for E-521 are stated in A note on ... 1 Except if you are picky with updates of references, there is such standard. DSA, RSA, ECDSA-$F_p$, ECDSA-$F_{2^n}$, are approved by ETSI TS 102 176-1 V2.1.1 (2011-07) (Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms), which essentially ... 1 From what you say, I assume that you are talking about the Crypto 3 challenge from HackingWeek. As Ruggero explained, the curve is vulnerable to both the MOV attack and the older FR attack that works similarily, using Weil or Tate pairings (respectivly). A simple sage code for the FR-attack would be: q = 134747661567386867366256408824228742802669457 Zq = ... 1 The problem with DRM is that the keys must be revealed to the end user machine and thus susceptible to interception. Not to mention I believe that the Sony PlayStation uses ECDSA to secure its firmware and it got cracked. 1 lm = nm; low = nw; hm = lm; high = low; You're setting hm = nm since lm = nm. Correct is: hm = lm; lm = nm; high = low; low = nw; 1 In binary, your hash value is: 11011110100111110010.... And so the leftmost 17 bits would be 11011110100111110 or 1BD3E in hex. Normally, for curves we actually use for ECDSA,$n$is a multiple of 8 (and so we just use the leftmost$n/8\$ bytes); in your (toy) case, we need to be a bit more careful (and end up not preserving byte boundaries).

1

If I'm understanding things correctly, you want to make sure that the public key you receive actually belongs to the person you want to communicate with. Thus you want to avoid MITM attacks, which is non-easy. Standard (TLS/S/MIME/...) solution would be to create a certificate signed by someone you trust to assure you that the particular public key belongs ...

1

Here are some test vectors for secp256k1 in the spirit of the test vectors you referenced: Curve: secp256k1 ------------- k = 1 x = 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 y = 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8 k = 2 x = C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5 y = ...

1

The web site of https://ellipter.com says, they are using encryption.

1

Saying that ECDH does not do authentication is not entirely accurate. If you use ECDH with static, known public keys and both sides prove knowledge of the shared secret, then you do get authentication. However, with ephemeral keys you need some way to authenticate the exchange of public keys. That could be ECDSA or it could be any other authentication. So ...

Only top voted, non community-wiki answers of a minimum length are eligible