Paul Syverson's paper, "Limitations on the design of public key protocols",
discusses several attack scenarios regarding the order of operations within the
flow of a cryptographic protocol (sign and encrypt, encrypt and sign, ...). If
you are interested, you can download it from
Going back to your remark, indeed, unless you avoid such threat at application
level (having for instance a list of trusted signatory), it is difficult to
avoid to be immune from such treats especially when the signature verifier is
an automatic process that performs dedicated operations after a successful
From: Antoine Alberti [mailto:aalberti(_at_)axway(_dot_)com]
Sent: 21 October 2002 11:45
Subject: RE: Ordering of encryption and signing of a S/MIME message
For security reasons, you should first sign your message and then encrypt
it with the recipient's public key. If you
perform the the reverse operation (encrypt then sign), then a threat
intercept you message, skip your signature and sign "your encrypted"
message. So the recipient will hence receive a
signed message from the threat agent and no more from you.
And how can the threat agent do this using the expected private key? And if
it can't, wouldn't the receving agent have a serious security hole if it
accepted such a message?
**** DISCLAIMER ****
"This e-mail and any attachments thereto may contain information
which is confidential and/or protected by intellectual property
rights and are intended for the sole use of the recipient(s) named above.
Any use of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any form)
by persons other than the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender either
by telephone or by e-mail and delete the material from any computer.
Thank you for your cooperation."