# What is customizable in ECDSA signature and verification?

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

Theoretically which things should be known to both modules:

2. Hashing function
3. Scheme for combining message and signature

Something else?

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

• 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. – SEJPM Nov 10 '17 at 11:49
• 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? – croraf Nov 10 '17 at 11:56
• 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). – SEJPM Nov 10 '17 at 12:06
• 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) – poncho Nov 10 '17 at 14:12

Theoretically which things should be known to both modules:

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

• Regarding 2. Can't a private/public key be used with several hashing functions, so it cannot contain info about hashing function? – croraf Nov 10 '17 at 15:21
• @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. – poncho Nov 10 '17 at 15:53