[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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