Re: Photuris terminology
"William Allen Simpson" <bsimpson@morningstar.com> Fri, 13 October 1995 03:22 UTC
Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12237 (5.65c/IDA-1.4.4 for <archive-ipsec@ftp.ans.net>); Thu, 12 Oct 1995 23:22:20 -0400
Received: by interlock.ans.net id AA76508 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 23:08:25 -0400
Message-Id: <199510130308.AA76508@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 23:08:25 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 23:08:25 -0400
Date: Fri, 13 Oct 1995 00:59:58 +0000
From: William Allen Simpson <bsimpson@morningstar.com>
To: rivest@theory.lcs.mit.edu
Cc: ipsec@ans.net
Subject: Re: Photuris terminology
Thank you for taking the time to read the draft. Are there any other cryptographic flaws or misunderstandings that you have found? Are you actually on this list? Or did Hugo "appeal to authority" again? > From: rivest@theory.lcs.mit.edu (Ron Rivest) > I agree with Hugo Krawczyk's concern that the use of the term > "Signature" (as in section 5, "Signature Exchange") is somewhat > misleading, and introduces some risk. The difficulty can be removed > by slightly changing the protocol (Hugo's proposal), or adding some > clarifying language. > > The danger, as he points out, is that the term "signature" generally > refers only to a quantity computed from the message and the private > key that can only be computed by someone possessing the private key, > while being capable of being verified by anyone holding the > corresponding public key. > ***************************************************************** > *** There is nothing in this notion of "signature" that means *** > *** that the message can not be derived from the signature. *** > ***************************************************************** It always helps when communicating persons are speaking the same language. Of course, we have had the same problem with other parts of Hugo's messages. For example, he calls things "protocols", when we would call them "algorithms". Our protocols require a specific instantiation. He refuses to condescend to discuss such mere "specifications". That is not the definition used in Photuris. Photuris relies instead on the definition from [Schneier, p 36] (which Photuris references): "That bit string attached to the document when signed ... will be called the digital signature, or just the signature." This definition is _much_ more useful. Particularly as the current Photuris draft does not require use of public/private key pairs! I understand that with your involvement in public-key algorithms you might see signatures only in the light of public and private keys. However, the default required by Photuris specifies MD5 as the signature algorithm. A long-term authentication secret is used instead of a public/private key-pair. The excised text indicated by ellipses are the following words: "(in the above example, the one-way hash of the document encrypted with the private key)" Note that even the Schneier examples use a one-way hash with private keys! > Indeed, I believe that the CCITT standards distinguish explicitly between > "signature schemes with message recovery" and "signature schemes without > message recovery". > It has always amazed me what the ITU is willing to "standardize". > Furthermore, it IS important that the signature scheme used not have > the "message recovery" property, since part of what is signed is the > computed shared-secret. > Yes, but this is "obvious", even to non-cryptographers. As I noted in another message, not revealing the secret when you use it in _any_ transform is a rather fundamental and well-known principle. This applies to authentication, encryption, and key generation, as well as the signature. Photuris makes no attempt to be a "pure" cryptographers' thesis. Such a thesis would run to hundreds of pages. Instead, Photuris is a protocol specification which can be implemented by non-cryptographers. It selects from a few _useful_ tools. The usefulness of the tools is determined in advance. > At the minimum, this requirement should be noted in the document. Otherwise, > there is a risk that the list of approved "signature schemes" might be > inadvertently expanded in the future to include one that had message recovery. > (Not by anyone currently involved in the proposal, but by some future > caretaker...) > That presumes that "caretaking" occurs in a vacuum. Surely, when someone attempted to standardize something that silly, then the ever vigilant Hugo would leap at the opportunity to correct them! And of course, a malicious caretaker could simply _remove_ any such text as you herein propose. So nothing is gained.... > I would suggest adding language of the following form somewhere (such as > on the top of page 23): > I will again note that it is not my intention to reiterate the properties required for "good" cryptographic hashes, encryption methods, or any other algorithm. We are tool users, and it is outside the scope of the document to conduct an analysis of the tools. There are plenty of other sources and continuing research in the field. And all of the tools selected for signatures already have the property that the message _cannot_ be derived from the signature. However, at your august request (and of two others in the working group), I will incorporate something akin to this in the Security Considerations: The signature method must not allow "message recovery", to prevent determination of the shared-secret or any long-term distributed secret-key (where applicable). More specifically, it should not be feasible to compute any of the bits of the authenticated message from the signature. In general, where a secret (such as the shared-secret or session-keys) is involved in any calculation, the algorithms selected should not reveal information about the secret, either directly or indirectly. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
- Photuris terminology Ron Rivest
- Re: Photuris terminology William Allen Simpson