20

Indeed the text quoted is wrong; at the very least, by using incorrect vocabulary. That should be: if you sign a message with your private key, the paired public key can be used to verify the signed message's integrity and origin. What small amount of truth there is in the original statement boils down to: in some asymmetric cryptosystems, including RSA¹ (...


19

The RFC specifies things in terms of bits. Each call to HMAC outputs hlen bits. tlen is the count of bits obtained so far; when at least qlen bits have been obtained, this step is finished. The sample code is written in Java in which the elementary unit of information is the octet ("byte" in usual terminology). The supported hash functions always output a ...


15

It is easy to construct a signature scheme that is existentially unforgeable but not strong. All you have to do is add a bit to the end of a strong scheme, and ignore it upon verification. This enables an attacker to flip a bit and have the new signature accepted. In some "real" settings this arises as well. For example, with ECDSA, a signature $(r,s)$ can ...


11

The server sending an encrypted challenge has a few advantages over the signature-based method you described: 1) It is more efficient for the client in the case that authentication is rejected outright. If the server doesn't recognize the client's public key, there's no reason to have the client waste time and energy generating a signature. 2) It is more ...


11

The article is surely wrong. Nowadays, the sole purpose of client-side private key in SSH is to sign messages (as their algorithms are typically ECDSA EdDSA, etc), the server doesn't encrypt the challenge, it almost certainly verifies it with the public key(s) in the authorized_keys file


9

I'll be assuming the question means Message Authentication Code (MAC) where it uses "Signature" and "Hash". MAC, signature and hash are three different things: MAC uses a secret for generation and verification, signature uses a secret for generation only, hash uses no secret. Following comment, and most important: sending in clear a MAC ...


8

It's the probability that an ECDSA signature (over the Bitcoin curve, secp256k1) will have the corresponding size. In other words, 25% of the secp256k1 ECDSA signatures have 73 bytes, 50% of them have 72 bytes and 25% of them have 71 bytes. Of course, after the signature is generated its size is settled and the probability does not apply anymore. (The reason ...


6

I am interpreting your question two ways: (1) "Why doesn't the client generate their own signed message to send to the server?" and (2) "Why doesn't the server send an unencrypted nonce for the client to then sign and send back?" To answer (1), such a scheme would be susceptible to replay attacks. An adversary need only collect one of these signed messages ...


5

Signing the public key is safe. The general assumption is that the adversary is allowed to ask any message that he knows to be signed, and that operation must not leak information about the private key (or otherwise generate a signature for a message that was not signed by the legitimate signer). In this model, the adversary knows the public key (it's ...


5

I am not sure how the IND-CCA experiment in this case works. Well, it doesn't really. There are no verification keys designated as such in the CCA experiment and there is no designated sender in the definition of a public key encryption scheme at all. So, the only way to communicate to the receiver who supposedly encrypted a ciphertext would be to put it in ...


5

You misunderstood something. HMAC-SHA-1 does not use SHA-1 as the signing algorithm. The signing algorithm is the HMAC-SHA-1 calculation, not an intermediate SHA-1 calculation. The signing algorithm takes the key and the message as inputs and produces the MAC value as output. The usual terminology for the hash algorithm that an HMAC construction uses is “...


5

That's insecure. In BLS signatures: for private key $x$ and public key $X = xP$, the signature is computed as $T = xS$, and the verification checks if $e(T, P) = e(S, X)$, which works because: $e(T, P) = e(xS, P) = e(xS, P) = e(S, P)^x$ $e(S,X) = e(S, xP) = e(S, P)^x$ If you know that $S = kP$, then you can forge a signature for a message with hash $k'$ ...


4

Supplying ECDSA with deterministic input doesn't make for a one-time signature—RFC 6979 chooses the per-signature secret as a deterministic but secret function of the message. However, there is a variant of ECDSA—or EdDSA—that could probably work. In ECDSA, a public key is a point $A$ on a curve with standard base point $G$, and a signature on a message $m$...


4

From SEC1 v2.0 (§4.1, pp. 43–47), a public key is a point $Q \in E$, and a signature on a message $m$ is a pair of integers $(r, s)$ satisfying the signature equation (condensed from several steps): \begin{equation*} r \stackrel?= f\bigl(x([H(m) s^{-1}]G + [r s^{-1}]Q)\bigr), \end{equation*} where $f\colon \mathbb Z/p\mathbb Z \to \mathbb Z/n\mathbb Z$ ...


4

It uses deterministic padding, i.e. padding with FF octets, finalized by a single 00 valued byte. So it is indeed RSASSA-PKCS1-v1_5 which uses EMSA-PKCS1-V1_5-ENCODE. Don't be fooled by the reference to RSA encryption in the OID for sha256WithRSAEncryption. That simply points to the modular exponentiation - in this case with the private key. PKCS#1 versions ...


4

Are there any methods to calculate the probability two files of the same size to have the same SHA-3 hash? Collision resistance is generally bound by the birthday bound, which equates to half of the output size. So finding two files (or input messages really) takes about $2^{h / 2}$ where $h$ is the output size of the (SHA-3) hash. And that's assuming you ...


4

Is there a reason for these differences You do realize that ECDSA is randomized [1], that is, signing the same message twice with the same private key will generate two different signatures. This is normal, and not due to you using three different ECDSA implementations. All three signatures are DER-encodings of 'a list of two integers, both of which are ...


4

It is not possible: Let $d_A, d_B$ be distinct private keys. Then $$ s=k^{-1}(z+rd_A)=k^{-1}((z+r\;(d_A-d_B)) + rd_B) $$ So the pair $(r, s)$ is not only a valid signature for the public key $d_AG$ and the (partial) hash $z$, but also for the public key $d_BG$ and the message hash $z+r\,(d_A-d_B) \pmod n$. So in many cases (if there are no restrictions ...


4

Is there a signature scheme in which $\text{signature} = \mathsf{Sign}(\text{message} \mathbin\| \text{signature})$ ? With standard RSA signatures (RSASSA-PKCS1-v1_5, RSASSA-PSS of PKCS#1), that's possible if one chooses the public/private key pair for that purpose, as a function of the message. On top of that one can even make the signature nearly anything ...


4

I am wondering, why I cannot use a plain one-time signature mechanism to sign an unlimited sequence of messages You can; your method does exactly that. However, it assumes that the verifier sees all previous signatures before verifying the next - not all use cases can assume that.


4

As pointed out by @SEJPM, you can read more about security proofs for DSA/ECDSA family on this thread. As for whether there exists an interactive protocol corresponding to DSA/ECDSA à la Schnorr identification/Schnorr signature, not that I am aware of. I would add that this is unlikely for two reasons: The (unfortunate) reason for coming up with DSA/ECDSA ...


3

You are referring to two different protocols. The second source is linked to the DSA (Digital Signature algorithm). This uses modular exponentiation in a group of prime order over the integers. The first one is a version of the DSA over Elliptic curves, namely ECDSA (Elliptic Curve Digital Signature Algorithm). They basically work the same. You have a ...


3

Would it be possible to create a signature scheme like this: As I understand it, your proposal is that the signature consists of the MAC key, along with the signed MAC value of the message. In general, this would not be secure, for two reasons: For many MACs, it is not difficult, if you know the key, to find a second message with the same MAC as an ...


3

When Alice and Bob are using a message authentication code (MAC) scheme, both of them have the shared MAC key, and both of them can generate valid MAC tags. Between Alice and Bob, they can be sure who is the sender. For example, if Bob receives a message with a valid MAC, and the message was not sent by himself, then the message must come from Alice. Hence "...


3

whether the checksum: 0xFFFF-SUM(N[i]) i=1...32 will solve the problem? Yes, it does. That's exactly how both WOTS+ in XMSS and LM-OTS in LMS work


3

Assuming that the number $i$ of signature operations that an attacker can perform is bounded to $i<\sqrt(n)$ (i.e. the birthday bound), is there a way to construct any signature scheme $S'$ that makes an existential forgery harder than $O(n)$ for an attacker, given the constraints on the atomic input into the asymmetric signature function? It would ...


3

ECDSA is specified in SEC1. It's instantiation with curve P-256 is specified in FIPS 186-4 (or equivalently in SEC2 under the name secp256r1), and tells that it must use the SHA-256 hash defined by FIPS 180-4. I'll leave aside ASN.1 decoration (since the question uses none), conversions between integer to bytestring of fixed width (which all are ...


3

Generally you'd let the device establish a symmetric / secret key first, e.g. using ECDH and then use that secret key with a MAC algorithm to perform the message authentication. In that case 16 bytes / 128 bits is plenty. For direct signatures, the BLS signature scheme is probably still the best out there, but for 128 bit level encryption - the lowest we ...


3

I'm asking if you guys know some method/algorithme to do this verification with only 17bytes max When you talk about public key algorithms with signatures that short, the number of options aren't great. You might be able to use a BLS signature with a specially constructed small pairing friendly curve; however the security wouldn't be that overwhelming (...


3

Lets fix that description of the signature generation. Please read the PKCS#1 v2.2 specifications to get the full detail. Canonical binary plaintext gets run through a hashing mechanism to make a message digest (IBM's terminology, there appear to be plenty of other terms for the hashed data). Message digest is used as input for the configured padding ...


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