Travis H. wrote:
This reminds me a bit of a suggestion I once heard for protocol
designers that the messages of the various steps of the protocol
include a step number or something like it to prevent cut-and-paste
attacks (presumably each message has some redundancy to protect the
integrity/authenticity as well, like a running hash covering all the
previous messages (in this direction)).
I wonder if something similar couldn't be done with digital
signatures, where the input is padded with data that indicates the
semantics of the signature; not unlike the forms which say "by signing
here I agree that..."
This also makes it very difficult for the opponent to do any kind
of chosen-plaintext trickery since the plaintext will be framed
with this data that the opponent does not control, but that is
also true with other padding options and such.
re:
http://www.garlic.com/~lynn/aadsm26.htm#65 Public key encrypt-then-sign or
sign-then-encrypt?
some aspects of this was discussed in old dual-use attack thread ... it possibly
isn't enuf to encapsulate all scenarios where the person intends to use the digital signature
in manner analogous to human signature (indicating intent, having read,
understood,
authorizes, agrees, and/or approves) .... then if there is ever a digital
signature
applied for pure authentication purposes ... say random data from a server (as
countermeasure to replay attacks) ... then all such signed data should always
also
be bracketed by disclaimer saying that such signatures are in no way met to
imply
agreeing, approving, and/or authorization any message content.
the problem is that digital signatures are an authentication and integrity
mechanism,
and except for possible semantic confusion resulting from both "digital
signature"
and "human signature" containing the same word ("signature") ... there is no
relationship. a danger of any mis-use of digital signatures as representing
human signatures ... is if they are also used for authentication ... where the
human doesn't actually physically examine and understand every bit that a
signature might be applied to. if the human doesn't actually physical examine
and understand every bit that they might apply a signature too ... then it
becomes a requirement that all such (signed and unexamined) bits are wrapped
with strong disclaimer about any existence of a digital signature is not met to
imply read, understood, approves, agrees, and/or authorizes.
... aka any random data not examined, but signed ... could in fact contain
padding
and comments about aggreement ... to appear as if the signer actually wrapped
it (instead of the attacker).
lots of past posts discussing "signatures" ... included having been called in
to help word-smith the cal. state electronic signature legislation.
http://www.garlic.com/~lynn/subpubkey.html#signature
related and slightly facetious posting here:
http://www.garlic.com/~lynn/aadsm26.htm#69 survey of RFC S/MIME signature
handling
as part of this thread
http://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature
handling
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
