Public key encrypt-then-sign or sign-then-encrypt?

Anne & Lynn Wheeler lynn at garlic.com
Wed May 9 15:54:16 EDT 2007


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 majordomo at metzdowd.com



More information about the cryptography mailing list