# Tag Info

## Hot answers tagged signature

5

Yes! (restrictions apply). ISO/IEC 9796-2 (scheme 1, SHA-1 hash, option 1 also known as implicit hash identifier, alternative signature production function) is a fully standard signature scheme, based on RSA, widely used in the Smart Card industry for public key certificates and message authentication, that adds only 22 bytes of signature overhead (if the ...

5

The standard way to do this is with a hash list. That is, you would hash each of the messages $m_i$ to produce a hash $h_i = H(m_i)$, and then combine all the hashes and hash them to obtain a master hash $h = H(h_0 \| h_1 \| h_2 \| \dots \| h_n)$. Finally, you can e.g. digitally sign the master hash to prove that the hash, and by extension all the ...

5

Although I can't see any immediate weaknesses, I also don't see how it adds significant value over DSA (while being significantly slower). It claims to be based on two hard problems, discrete log and factoring. However, it doesn't give any particular proof that if you could forge signatures, you can solve both problems. It also doesn't look particularly ...

5

Towards the security of the signature scheme, no precaution against timing attack is necessary when verifying an asymmetric signature. That's because there is no secret involved, thus no information leak to fear. However it can happen that the message, or the signature itself, is intended to be secret; a leak by timing dependency (during computation of the ...

5

My answer is not original, as I am simply summing up information from different questions already solved in this site. Nevertheless, I thought it could be interesting to collect everything in one answer. The first thing you have to know is to differentiate between a digital signature and a message authentication code (MAC). In this case, HMAC is a MAC and ...

4

I think you have some misunderstanding here. Finding collisions when knowing the trapdoor is a required feature, but leaking the trapoor when knowing collisions is an undesirable "feature" (which some constructions suffer from). A chameleon hash function (aka trapdoor commitment) allows you given the trapdoor to find pairs $(m,r)$ and $(m',r')$ with $m\neq ... 4$q$does not divide$s^e-h(m)$, but$p$does, so since the gcd must divide both$s^e-h(m)$and$n$it's$p$. To be even more explicit, we know that$p$divides both$s^e-h(m)$and$n$. The only larger divisor of$n$that is also divisible by$p$is$n$itself, but if$n$would divide$s^e-h(m)$, then$q$would also divide$s^e-h(m)$, which we already assumed ... 4 Yes, you can, but you would need access to raw or textbook RSA encryption and you would have to implement the PKCS#1 v1.5 or PSS padding primitives yourself. Beware that PKCS#1 v1.5 compatible padding is different for encryption signature generation. If you only have PKCS#1 v1.5 encryption or OAEP encryption available then the encryption routine will ... 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

The main benefit of adding randomness in RSA signature padding is that it simplifies and strengthens security arguments. At least that's claimed by PKCS#1v2, paragraph above 8.1.1 (emphasis mine) RSASSA-PSS is different from other RSA-based signature schemes in that it is probabilistic rather than deterministic, incorporating a randomly generated salt ...

4

DSA relies on $k$ being independent from $d$. You define $k$ as: $k=z^\prime d\mod n$ Substituting $k$ in the signing equation you get: $s = k^{-1} (z+rd) \mod n$ $s z^\prime d = z + rd \mod n$ $d=z (sz^\prime -r)^{-1} \mod n$ The attacker knows everything on the right side and can recover the private key.

4

The question "why is preimage resistance needed for hash functions" is not really relevant. This is because collision resistance implies preimage resistance. Thus, it is just a fact that if you have collision resistance then you must have preimage resistance. So, instead, I will relate to what preimage resistance is good for at all. In more technical ...

3

The initial idea of Fiat and Shamir was to eliminate the interaction in public coin protocols (note that public coin means that the random choices of the verifier are made public) and was used to convert three move public coin identification scheme into conceptually simple signature schemes (it has later been proven by Pointcheval and Stern that under the ...

3

The only way you could do this if if you could affect the padding schemes appropriately. Mathematically, textbook RSA encryption with the private key is the same as textbook RSA signature generation. Nobody should use textbook RSA, however. In practice, padding schemes are used and they differ between the two operations. So unless you can turn off padding ...

3

No, not really. Elliptic curve signatures are the smallest you'll find in common use. An $n$-bit elliptic curve produces $2n$-bit ECDSA signatures. The smallest standard curves that offer some security are 160-bit, and those are not really recommended (e.g. NIST recommends 224+ bits). That would give you 40 byte signatures. Lower than 64, but not 32. So 40 ...

3

I'm trying to get my head around how the crypto solves this problem. It doesn't. You need to trust the platform you use to do the signing. For instance, my bank has replaced the "signature" generation device that I previously used with one that displays the actual transaction, so I don't have to trust the information on the computer screen that much.

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.

3

It is logically impossible to transfer a private key. The key will continue to be a signature key, but it will cease to be "private" the minute it is transferred. A signature key that isn't private isn't a private key. If you want the document to be signed by the user (in any semantically coherent sense), this operation has to take place on a device ...

3

To start with, it's certainly not a bad idea to avoid SHA-1 when other algorithms exist, which do not have the SHA-1 weaknesses to anyone's knowledge. The security of SHA-1 depends on how you're using it. The vulnerability is what's known as a collision vulnerability: an attacker has the ability to create two input strings with the same SHA-1 hash with less ...

3

If we signed a secret message $m$ by publishing its signature $σ$ computed as $m^d\bmod N$, at least two very bad things would happen: The message would not be so secret anymore That's because anyone knows the public key $(N,e)$, and thus from $σ$ can compute $σ^e\bmod N$, which is $m\bmod N$. This reveals a lot of information about $m$, which goes ...

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

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

In this notation, $f^k(x)$ means "apply $f$ $k$ times in succession". For example, $f^3(x)$ is defined to be $f(f(f(x)))$. Because of this definition $f^a(f^b(x)) = f^{a+b}(x)$ holds trivially (even though we known nothing else about $f$), as the the left side means "do $f$ $b$ times, and then do it $a$ times", while the right means "do $f$ $a+b$ times". ...

3

At first I want to cite Lindell and Katz book: A "plain Rabin" encryption scheme, constructed in a manner analogous to plain RSA encryption, is vulnerable to a chosen-ciphertext attack that enables an adversary to learn the entire private key. Although plain RSA is not CCA-secure either, known chosen-ciphertext attacks on plain RSA are less damaging ...

3

Among several aspects of the question, I'll cover only protection against replay of commands. A common technique (among several) is to have commands tied to a nonce, that somewhat is accepted only once by the slave device receiving the command. The nonce is included in the input of a MAC or public-key signature algorithm that protects the integrity of the ...

3

If Eve can find an $n'$ that is prime (and $n'-1$ is relatively prime to $e$),then she can easily sign any message with that $n', e$ pair. So, the question is: what is the probability that there exists a prime $n'$ such that there is only one bit difference between $n$ and $n'$, and $n' \not\equiv 1 \pmod {e}$ ? The answer is that it is quite good if \$e ...

3

Peter Schwabe, one of the authors of Ed25519, directed me to a recent paper titled "EdDSA for more curves". The section "Security notes on prehashing", page 5, says that the Ed25519 algorithm without prehashing the message is resistant to collisions in the hash function, while using the algorithm with prehashing is not. Of course the hash function is not ...

3

If you are using a secure signature algorithm, padding and all, then it must be secure for messages of any length. So in that sense you are good. However, in many protocols your messages must include something to prevent replay attacks, like an incrementing counter, in which case you shouldn't be signing just a single number if the messages are meant to say ...

2

It is outside the scope of TLS and must be arranged out of band. Raw public keys come without any signatures and cannot be verified without additional knowledge. Section 1 of the RFC mentions a few ways how they might be verified in some situations. They all amount to receiving the public key through some other authenticated channel. The TLS client ...

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. ...

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