Re: Re: What the verifier can do

Paul Hoffman <phoffman@xxxxxxxxxx> writes:

> At 10:58 AM -0700 4/30/06, Eric Rescorla wrote:
>>I know it's pedantic, but it's important: digital signature algorithms
>>*sign* the hash. They do not, in general, encrypt it. It's true that
>>signature and encryption are similar in RSA, but they're not the same
>>in (e.g., DSA). Also, while the performance reason is important,
>>it's not the only reason. Because signature algorithms can only
>>process small chunks of data, a digest lets you sign large blocks
>>without having to worry about gluing together the signatures somehow.
>
> Pendantry accepted. But, in this case, the only signature algorithm we
> have defined is RSA.

Yes, but it's a bad idea to design systems assuming that's going
to be the only algorithm you ever use. 


>>This procedure only works if either:
>>
>>(1) You place a copy of the message digest in the DKIM headers.
>>     Based on my reading of draft-allman-*, this is not the case
>>     in DKIM. It's not the case in S/MIME either, AFAIK.
>>(2) You have a signature algorithm with message recovery
>>     (meaning that you can extract the hash from the signature).
>>     Again, this is only true of RSA.
>>
>>Otherwise you need to do a full signa ture verification for each
>>trial manipulation.
>
> Correct. #2 applies here because we have only defined RSA.

Sure, but what happens when you want to use ECDSA because you're
worried about key size constraints? Digital signature algorithms
really should be treated as black boxes, rather than modelled as
RSA.

-Ekr