2 ms·

Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a strea

Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a streaming implementation of the internal pre-hash is not available) would be to allow checking integrity without authenticity, which makes little sense.

dspillett 4y ago
Perhaps they are using the hash output for quick corruption tests as well as signing for authenticity? And if they are computing a hash for that anyway, the computation saving from signing the hash not the whole content might be worthwhile?
- franky47 4y ago
  Adding a pre-hash is the overhead here, because of the internal hash. Granted, verifying only that hashes match for integrity would be cheaper than checking the signature. But since you need to to that anyway for authenticating the payload, why the intermediate step?
  - dspillett 4y ago
    > Adding a pre-hash is the overhead here, because of the internal hash. If it has no other purpose, then yes but only a small amount of overhead if the content is large because the internal hash is over a much smaller content. You have: hash(<thousands/millions/more>bits) then hash(<hundreds>bits) & sign(<hundreds>bits)* instead of hash(<thousands/millions/more>bits) & hash(<hundreds>bits) The bit you save, the hash(<hundreds>bits), is only significant if the input content is of similar size and you are performing the operation many times in quick succession. > since you need to to that anyway for authenticating the payload That is true from the client PoV. Server-side you might want to integrity check your data as part of regular proactive maintenance. Of course I'm assuming here that the digest is stored so it can be used in this way – if not then I agree it is just overhead.
deleted 4y ago
[deleted]

2 ms·

Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a strea

by franky47 4y ago

dspillett 4y ago
Perhaps they are using the hash output for quick corruption tests as well as signing for authenticity? And if they are computing a hash for that anyway, the computation saving from signing the hash not the whole content might be worthwhile?
- franky47 4y ago
  Adding a pre-hash is the overhead here, because of the internal hash. Granted, verifying only that hashes match for integrity would be cheaper than checking the signature. But since you need to to that anyway for authenticating the payload, why the intermediate step?
  - dspillett 4y ago
    > Adding a pre-hash is the overhead here, because of the internal hash. If it has no other purpose, then yes but only a small amount of overhead if the content is large because the internal hash is over a much smaller content. You have: hash(<thousands/millions/more>bits) then hash(<hundreds>bits) & sign(<hundreds>bits)* instead of hash(<thousands/millions/more>bits) & hash(<hundreds>bits) The bit you save, the hash(<hundreds>bits), is only significant if the input content is of similar size and you are performing the operation many times in quick succession. > since you need to to that anyway for authenticating the payload That is true from the client PoV. Server-side you might want to integrity check your data as part of regular proactive maintenance. Of course I'm assuming here that the digest is stored so it can be used in this way – if not then I agree it is just overhead.
deleted 4y ago
[deleted]