At 08:52 AM 10/22/2003 +0100, John Ross wrote:
>I personally concur with the following point being made by John Messing:
>
>"The issue to my way of thinking is primarily one of security.
>Unencrypted hashes and audit records of authentication in a database
>require heightened database security to prevent alteration of the
>records, while encrypted hashes or digital signatures can take up a
>part of the security burden by virtue of protections provided to the
>private key"
>
>In addition an encrypted hash can be done by a relatively small bit of
>trusted code and done by a tamper proof hardware module (for example a
>FIP140-3 device. Hence by using encrypted hash it is simple for
>independent third parties to verify evidence.
I would point out that databases and cryptographic measures can be used
together, so John's issue isn't an either/or choice. For example, maybe a
DSS server signs with a large RSA key, but doesn't want to return the
several-hundred-byte-large digital signature to the client. Instead, the
digital signature is stored in a database entry and the client is given a
shorter "ticket" that refers to this entry.
Later, when the client contacts the server to verify the signature, the
client presents the ticket, and the to-be-verified documents or document
hashes, and the server retrieves the signature from the DB and uses that to
verify the documents.
I guess my point is: if we have protocol support for this type of solution,
where the client doesn't actually have a cryptographic signature, but just
has a ticket that refers to some "electronic signature", this can support
other server techniques besides just storing raw hashes in a database.
In fact, neither the client nor the protocol would know how the server is
mapping from the ticket to the actual document hash (whether through a
cryptographic verification, a DB lookup, etc).
Trevor
