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

[Anne & Lynn Wheeler]

Travis H. wrote:
> Also there's a semantic issue; am I attesting to the plaintext,
> or the ciphertext?  It's possible the difference could be important.

there has been sporadic periods/attempts that effectively attempt
to equate "digital signature" with "human signature" ... possibly because
of semantic confusion since both terms contain the word "signature".
This goes beyond digital signature being able to provide integrity
and authentication (i.e. read, understood, approves, authorizes,
and/or agrees).

we saw one such when we were called into help word smith the
cal. state electronic signature (and later federal) legislation.
misc. past posts
http://www.garlic.com/~lynn/subpubkey.html#signature

another scenario that can arise is dual-use attack ... where
same private key is used to both digitally sign in authentication
protocol (i.e. presented with random "challenge" from a server
and private key automatically digitally signs the server presented
value; the signing of the server presented random value is countermeasure
to replay attacks against the server) and in the sense of human
signature (read, understood, approves, authorizes, and/or agrees).
The attacker injects a valid document in lieu of random data
in an authentication protocol that automatically performs
digital signatures.

In the 90s, there was some suggestion that possibly a payment
protocol using digital signature ... in a PKI-based paradigm,
the consumer would append a digital certificate indicating
their agreement with the contents of what was being signed
(as opposed to pure integrity and authentication). The choice
of the appended digital certificate would be used to "prove" 
non-repudiation and subsequently also be the basis for 
changing the burden of proof in disputes. Since PKI-based
paradigm don't provide for any integrity mechanism as
to what digital certificate was originally appended ... there
was possibly motivation (in such a PKI-based paradigm)
for a relying-party to discover someplace in the world
a copy of a signer's digital certification that would
better suit the relying party's purpose (than the one
that the signer actually appended) ... there would have
been significant financial incentive to the relying
party to change the burden of proof in disputes.

Since that period, the idea of PKI-based paradigms
(and/or digital certificates) being used as basis
for non-repudiation has been severely depreciated.

some of this from security acronym PAIN

P -- privacy (or sometimes CAIN, confidentiality)
A -- authentication
I -- integrity
N -- non-repudiation

encryption provides for privacy/confidentiality ... and
possibly integrity. 

digital signature provides for authentication and integrity

at various times in the past, some PKI-based paradigms
have attempted to make claims that digital signatures
also imply non-repudiation ... and could equate to
imply intent and equivalence with human signature
(read, understood, approves, authorizes and/or aggrees).

past posts mentioning dual-use attack and/or changing
burdon-of-proof
http://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm21.htm#35 [Clips] Banks Seek Better Online-Security Tools
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm23.htm#33 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there a market?
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2001g.html#59 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
http://www.garlic.com/~lynn/2005e.html#41 xml-security vs. native security
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#6 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005o.html#26 How good is TEA, REALLY?
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
http://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
http://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
http://www.garlic.com/~lynn/2006s.html#34 Basic Question
http://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#23 John W. Backus, 82, Fortran developer, dies

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com