5
$\begingroup$

Let's say I make a signing and verification ECDSA module. The signing module receives a plain message and outputs a signed message. The verification module takes the signed message and checks consistency.

Theoretically which things should be known to both modules:

  1. Padding scheme for message
  2. Hashing function
  3. Scheme for combining message and signature
  4. Something else?

Additionally, the signing module should know the private key, and the verification module the public key. How these keys were generated (parameters used, such as curve used) is irrelevant to signing and verification modules.

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ You don't need a padding scheme for ECDSA and the parameters (ie curves) of the keys do matter to the modules, even though they are usually encoded along with the keys. $\endgroup$
    – SEJPM
    Commented Nov 10, 2017 at 11:49
  • $\begingroup$ Padding scheme is not used or is fixed? The only parameter of the keys required by the modules is curve used or some other parameter also? $\endgroup$
    – croraf
    Commented Nov 10, 2017 at 11:56
  • 1
    $\begingroup$ I think there is some padding going on internally, but this is fixed for ECDSA. So you don't need point 1. Additionally to 2. and 3. you also need the curve and all the usual parameters this entails (curve parameter, common base-point, co-factor, curve order). $\endgroup$
    – SEJPM
    Commented Nov 10, 2017 at 12:06
  • 2
    $\begingroup$ There really isn't any padding in ECDSA; the hash value is treated directly as a integer (modulo q if the hash is larger than the curve order) $\endgroup$
    – poncho
    Commented Nov 10, 2017 at 14:12
  • $\begingroup$ Well, when it comes to the order of the proposed points 1 & 2: if any padding is required then it is for, and part of the hashing function, and it actually doesn't change the message itself. Most hash functions operate over block sized input. These blocks are generally put in a buffer, and then the padding is performed within that buffer (using an update / final approach, where the padding is performed after the last input byte is received). As a user you won't notice though. $\endgroup$
    – Maarten Bodewes ♦
    Commented Apr 30, 2023 at 12:32

2 Answers 2

Reset to default
6
$\begingroup$

Theoretically which things should be known to both modules:

  1. Padding scheme for message

As mentioned in the comments, the 'padding scheme' for ECDSA is either fixed or arguably nonexistent. You take the hash value, zero extend it if it's smaller than the group size, you take it modulo $q$ if it's bigger than the group size, and then fit that integer into the ECDSA equations.

  1. Hashing function

Yes, bare ECDSA signatures and public keys have no way of indicating what hash function is used. IMHO, it should be listed in the public key; it isn't (at least in my experience)

  1. Scheme for combining message and signature

Well, you appear to be under the impression that we always attach the signature to the message. Sometimes this is true, as in PGP. However sometimes this isn't true at all, for example, if we are using signatures to authenticate IKE; there, the value we sign is actually derived from the contents of a previous packet, hence we can't say that the message and the signature are combined at all.

What I've seen in practice is that we separate out the protocol level stuff (how are messages and signatures transported; there are a lot of varients used in practice) and the crypto stuff (how to do ECDSA); for example, on the verification side, there is some upper layer that somehow obtains the message and the signature, and then presents them both to the verifier.

Something else?

Apart from the public and private keys that you mentioned:

  • The actual curve being used; that is far from irrelevant to the crypto module.

  • The format of the signature; I've seen two variants; one is to just paste the $r$ and $s$ integers together (using a fixed length for both); the other is to ASN.1 encode it as a sequence of the two integers. Now, it's possible that the protocol-level logic that I mentioned before would standardize that...

Improve this answer
$\endgroup$
2
  • $\begingroup$ Regarding 2. Can't a private/public key be used with several hashing functions, so it cannot contain info about hashing function? $\endgroup$
    – croraf
    Commented Nov 10, 2017 at 15:21
  • $\begingroup$ @croraf: in theory, yes, however I have a hard time thinking of a situation where using distinct hashes for the same public key makes sense. And, even if we do come up with some scenario, it's not at all clear we should be optimizing for such oddball cases. $\endgroup$
    – poncho
    Commented Nov 10, 2017 at 15:53
3
$\begingroup$

In addition to the answer by poncho one can also choose another base point than the one usually suggested with the curve specification. This does not change the curve or ECDSA security properties.

It is mentioned as a method for domain separation in FIPS 186-4 § D.1.1.5 Choice of Base Points. Note that this is removed from FIPS 186-5 (see related comment).

One application of this customization is sketched in Split-ECDSA § 3.4 for knowledge proofs.

From the same paper (Proposition 2.1): one could also choose to represent signatures using commitments $(R,s)$ instead of the usual $(r,s)$ where $R=(x,y)$ and $r=\overline x\mod q$. This property can be useful when combining ECDSA with other algorithms.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.