Most (secure) signature schemes actually include the randomization as part of their process, so adding nonces to the text before signing is not necessary. OTOH, I don't see any problem in defining between the parties (in the `meta-contract` defining their use of public key signatures) that the signed documents are structured with a random field before and after the `actual contract`, as long as the fields are well defined.
there has been some claim that large random nonces as part of message ... before hashing and signing is characteristic of RSA signatures. one of the issues with DSA and hardware tokens in the 90s was that none of the hardware tokens had reliable random generators. If you were doing DSA (or ECDSA) infrastructure ... then integrity was dependent on quality random generator as part of the signature process (to preserve the integrity of the private key). In some sense, large random nonces (as part of the content to be signed) was shifted to the party(s) generating the message as part of the RSA process. In theory, DSA/ECDSA eliminates that requirement ... especially as you move in to the late 90s where hardware tokens started to appear that had quality random generators.
protocols have had severs contributing unique values in signed messages .... in things like authentication protocol .... as countermeasure to replay attacks (on the server).
protocols have had clients contributing some values in signed messages ... in an authentication protocol ... as countermeasure of server attacks on clients. It isn't necessary that the client contributed part has to bracket both the start and end of the message .... in a digital signature environment ... since the digital signature protects the whole message integrity. The client contributed part could be simple readable text disclaimer ... comparable to some disclaimers you see at the bottom of emails (especially from lawyers, doctors, and/or people that work for such firms .... you even see it in various mailing lists by people that work for the big accounting firms).
sometimes the recommendations are that both server and client contribute something unique to the signed message ... as generic countermeasures ... regardless of whether the situation is actually vulnerable to the associated attacks. In general, where the server incurs some expense and/or liability associated with every message ... the server (or relying-party) is probably interested in countermeasures against replay attacks.
one of the requirements given x9a10 working group (for the x9.59 protocol) ... was to be able to perform the operation in a single round-trip .... w/o any sort of protocol chatter. this is comparable to existing electronic payment business process. the countermeasure that the infrastructure uses for replay attacks is to have the transactions time-stamped and log is kept. transactions with time-stamps that predate the log cut-off are deemed invalid. In the x9.59 transaction scenario ... the signing entity (in theory) specifically approved every transactions and used ecdsa signature. the ecdsa signature would preserve the integrity of the transaction. the time-stamp in the transaction would indicate whether it was within the current active log window of the payment processor, and the randomness of the ecdsa signature would provide uniqueness (two transactions that were otherwise identical (in amount, time, etc) would be unique if they had different ecdsa signatures (effectively provided by the definition of dsa & ecdsa).
the addition of ecdsa signature to existing payment transaction .... exactly preserved all the existing business processes and flows ... including the requirement that the client can originate the transaction and the message flow could complete in a single round-trip.
the addition of the ecdsa signature added a) integrity of the transaction message, b) authenticated the origin, and c) provided transaction uniqueness.
no (public key) certificate was required since the transaction was being processed by the relying-party (which in the SET model was also the relying-party, had the public key on file, had the original of all the information that went into a SET relying-party-only certificate, and the only function that the SET relying-party-only certificate was to repeatedly travel from the client to the relying party increasing the payload and the bandwidth requirements by a factor of one hundred times, carrying static, trivial subset of information to the relying party ... which the relying party already had ... making it redundant and superfluous ... other than contributing enormous payload bloat).
there was one additional thing that was specified in x9.59 standard .... that account numbers used in x9.59 transactions could not be used in non-authenticated transactions (not that all the payment processors already supported feature/function of mapping multiple account numbers to the same account). the issue was that it was recognized that regardless of the crypto facilities used to protect the account number in flight, there were scores of business processes that required the account number to appear in the clear.
In the existing infrastructure that are huge numbers of unauthenticated transactions that can be performed with the account number ... which effectively turns the account number into an enormous shared-secret .... requiring enormous amounts of protection for the shared-secret. however, with all the enormous numbers of places that the clear-text account number is used ... it is not possible to also preserve the account number as a shared-secret. minor past note about security proportional to risk
<http://www.garlic.com/~lynn/2001h.html#61>http://www.garlic.com/~lynn/2001h.html#61
so the x9.59 approach was to eliminate "shared-secret" as a business characteristic of the account numbers used in x9.59 transactions. if an account number used in an (digitally signed) x9.59 transaction ... can only be used in x9.59 (digitally signed) transactions .... it no longer carries with it the "shared-secret" characteristic (since simple knowledge of the account number is insufficient to impersonate and/or perform fraudulent transactions). So if the insiders at a merchant processing end-point (or an external outsider that is harvesting merchant processing transaction files) is unable to "steal" the account number and use it fraudulently ... it no longer has to be protected as a shared-secret.
The end-point static harvesting of transaction files has been the major vulnerability for a long time. They have tended to be in the clear because of the large number of business processes that require access to the transactions. Neither SET nor SSL provided any countermeasures for this (the major) vulnerability/exploit.
X9.59 did eliminate this as a vulnerability ... since stealing the transaction file and harvesting the account numbers .... would not provide the crook any mechanism to impersonate and/or perform a fraudulent transaction. It turns out the secondary effect was that it was no longer necessary to hide the account number while in flight either (in order to preserve an account number as a shared-secret). digitally signing the transaction both preserved the integrity of the transaction as well as authenticating the origin of the transaction. This then eliminated the requirement to hide the account number as a countermeasure against the account number being exposed (and comprimising its shared-secret characteristic).
The issue with SET was that it was horribly more complex and expensive and provided no fundamental additional protection/countermeasure than existing SSL (with respect to reducing existing vulnerabilities and fraud). This was somewhat orthogonal to the problem with the horribly additional expense not being born by the primary benefiting parties.
X9.59 is an enormously simpler and less expensive protocol than either SET or SSL ... and turns out to address (in a business way) the major exploits and vulnerabilities in the existing infrastructure ... the basic characteristic that the account number is effectively a shared-secret (which neither SET nor SSL addresses). Furthermore, with the elimination of the shared-secret attribute for account numbers .... then it is no longer necessary to encrypt the transmissions (for purposes of preserving the account number secrecy).
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
